25 Game Dev Tips for Beginners - Tips & Tricks
Вставка
- Опубліковано 17 тра 2024
- New to game dev, or maybe you've been doing it for awhile but struggling? Today, I'll be sharing my top 25 tips and tricks. From pixel art to coding, I'll share with you what I've learned over 10 years of making games.
If you like my videos and find them helpful, you can support me over my Patreon page here: ✨ / goodgis ✨
┈ Software I use! ┈
● Godot Engine - godotengine.org/
● Pyxel Edit - www.pyxeledit.com/
● LabChirp - labbed.itch.io/labchirp
● Paint.NET - www.getpaint.net/
● Blender- www.blender.org/
┈ Who is Goodgis? ┈
I’m a full time Graphic Designer, Game Dev, & UA-camr. I specialize in making cute, colorful games in Godot and telling my story through my videos. I also run my own little game studio called Firith. My dream is to hire my friends and make Firith a full-time job. I’m known for games such as The Keeyp, Wizbirds, Snomes, and Dewdrop Dynasty.
✦ Discord - / discord
✦ Twitter - / gooodgis
✦ Games - firith.itch.io/
Chapters:
0:00 Introduction
0:09 Tip 1 - Always Prototype Your Game
0:15 Tip 2 - Take Inspiration from Everyday Life
0:27 Tip 3 - A Game is Like a Marriage
0:36 Tip 4 - Game Dev Takes Twice as Long
0:44 Tip 5 - Get Feedback as Soon as Possible
0:54 Tip 6 - Reuse Your Code
1:03 Tip 7 - Start Marketing Your Game
1:12 Tip 8 - Make a Devlog
1:23 Tip 9 - Game Engines Aren't Important
1:35 Tip 10 - Stick with a Tool
1:45 Tip 11 - Free Software is Good
1:54 Tip 12 - Watch a Tutorial Everyday
2:11 Tip 13 - All Engines have Bugs
2:22 Tip 14 - Copy Peoples Art (But Don't Post It)
2:35 Tip 15 - Use a Color Palette
2:45 Tip 16 - Create a Moodboard
3:03 Tip 17 - Keep Your Art Simple
3:15 Tip 18 - Never Delete Your Art
3:28 Tip 19 - Fundamentals are Key
3:48 Tip 20 - Watch CS50
4:03 Tip 21 - Make Small Games
4:21 Tip 22 - Learn Your Language
4:38 Tip 23 - Naming Consistency
4:52 Tip 24 - Write Readable Code
5:15 Tip 25 - Create, then Optimize
5:31 Bonus Tip
6:09 Shoutouts
┈ Similar Videos ┈
Goodgis - Pixel Art Tips from a Professional Artist - Tips & Tricks
• Pixel Art Tips from a ...
Goodgis - The Best FREE Software for Game Development! (In my Opinion)
• The Best FREE Software...
Reece Geofroy - How To Pixel Art - Beginner To PRO Tutorial
• How To Pixel Art - Beg...
Reece Geofroy - How To Pixel Art In 10 Minutes | Pixel Art Tutorial
• How To Pixel Art In 10...
Ask GameDev - 7 Game Design Mistakes to Avoid!
• 7 Game Design Mistakes...
#gamedev #gamedesign #indiedev #Goodgis #pixelart #gameart
![100 Gamedev Tips for New & Aspiring Game Developers [100th Episode Special!]](/img/n.gif)
✨Tip 26 - Make sure to LIKE & SUBSCRIBE for more awesome game dev videos.✨
(Okay...so maybe that was less of a tip and more of a suggestion.)
Fan bro
Ok
thanks for your great tips you are still a helpful youtuber i like you
The last tip was corny but still somehow inspiring lol
That was less of the tip and more of the order. You must subscribe. Haven't you already subscribed?! Would you kindly subscribe?
My reflexive advice for someone that's picking between art styles is, "err on the side of what you can crank out because you can more reliably finish that."
I totally agree!
As someone who just experienced art asset related problems, I totally agree.
and then theres me who can crank out pretty high end pixel art designs, music, vfx etc quickly but takes forever to write code. i hate it but i so desperately want this to become real, yet i can never get to the point where i do the stuff i love to do
4:54 Totally agree with writing readable code, I just don't think && and ! are the problem at all, in my opinion, if someone sees that as "hard to read" they should probably take a step back. I think bad/inconsistent indentation, confusing variable names, repeated code and organization in general are way greater problems that beginner coders do very often.
I get where you're coming from but for beginners they should focus on making their code clear and readable.
@@Goodgis For me I make sure I write comments to ensure I have the appropriate context for what I'm doing if it's using something complicated, or pulling from other scripts. That lets you use the shorthand you know but if you're doing something weird you'll have the context on the page itself.
A good example of what I mean is writing a turn counter for an RPG battle. That's pulling a lot of data from different places but generally running the same calculations on all of it, and you might not even show the results on screen outside of testing. Keeping the relevant information from other pieces nearby helps a lot.
I agree with you. "!apple" isn't in any way hard to read. If someone is such a beginner that they get confused by the bang operator, they need to look at a few more coding tutorials before trying to make their inevitable MMO they want to make.
@@wolf7115 ouch. Now thats some serious burn
It always confuses me why people have such an issue with &&, ||, and !
They have been around programming forever and should be easy to understand and read.
My unofficial Tip 26:
Comment your code. It makes it _SO_ much easier to fix bugs or change things when you can see what pieces of code serve which purposes.
Heck yeah! Great tip!
I can add that you want to keep your old code so you can reuse or remember old solutions to problems. Having to go back and spend forever trying to figure out your old code is painful.
Good comments allow future you to quickly learn from past you.
I guess that's also the Purpose behind the Dev log. You can read it too see why you did what you did and compare it to what you know now.
My official tip 27: DON'T depend on code commenting. Extremely bad practice, since they are not what is running.
Instead of naming your function `Derp()`, name it `OnDeath()`
Instead of naming your variable `monsters`, name it `monstersRemaining`
The issue with commenting, is that when you or someone else update the code, it is more likely than not, that the comment will over time become more misleading than helpful.
@@--Arthur Agreed, as soon as i started coding, i was using your tip 27. There was absolutelly zero confusion on what everything did. And i didnt write a single comment, in fact the comments that there were, were actually trash code i might delete one day (that day never came)!
These were lesson's I had to learn the hard way over my four years of development. Thanks for getting this crucial tips out there for people starting out!
Thanks, I really appreciate it!
hey you're that guy from the discord
@@_bop5209 yes
Samee
Lesson’s
Great vid! On the "controversial" tip, I agree keep your code readable! But I'd argue this is more about naming properties and functions, and not cramming too much on one line. Replacing !variable with variable == false leans towards being overly verbose to me (I would read !variable as "not variable" personally), but whatever makes it easier for you to understand your own code when coming back to it
Thanks for sharing!
I Agree, it doesn’t really make code more complicated at all. Rather I would suggest that beginners learn De Morgans Law, which can reduce the number of logical operators used.
@@Goodgis Perhaps your problem might be because you don’t use correct naming for boolean vars. The standard is usually to make them yes/no questions. e.g. hasApple, isHungry, wasRunning, hadLunch, wishesToSnack…
A BIG tip I have to give programmers is to avoid micro optimizations. As a coder it's generally very easy for me to sometimes fall into a pitfall of seeing a piece of my code and trying to optimize it into oblivion.
If you have fun, then power to you, coding is a hobby after all, but if you're just doing it to save those precious 2ms, it's not worth it by any means, you can do so much better stuff with your time than spending a couple hours optimizing a system for a negligible boost in efficiency.
Thanks for sharing!
I'm in the same boat, I tend to overthink problems and optimization too early.
"Don't optimize or refactor until the program is mostly done" is important advice. It's not a good use of dev time, and more importantly, a lot can change during a development cycle and it's good to be flexible and not over-commit to a specific approach until you have figured out how the whole program fits together. When you have to make big changes, it's easier to be honest with yourself that something needs to get cut when you haven't already spent a weekend making it look Just Right.
Heavens I only just started I'm already seeing myself trying to fall into that trap.
I finally get something working then find myself spending hours trying to make it work 'better'. It's literally just a prototype and I don't plan on keeping it for the full game but it's still 'can't i make it cleaner if...'
Pushing myself last that, it feels like I'm doing better just getting it to work for one interation then next time do more research then improve on the design the second time.
@@Discolingua I should've read this comment before. What I've learned with this experience is: use your own code. You'll see it differently when looking from a user point of view, instead of a developer
Awesome! Short but totally on point video! Thanks for the chapter notes too.
Chapters:
0:00 Introduction
0:09 Tip 1 - Always Prototype Your Game
0:15 Tip 2 - Take Inspiration from Everyday Life
0:27 Tip 3 - A Game is Like a Marriage
0:36 Tip 4 - Game Dev Takes Twice as Long
0:44 Tip 5 - Get Feedback as Soon as Possible
0:54 Tip 6 - Reuse Your Code
1:03 Tip 7 - Start Marketing Your Game
1:12 Tip 8 - Make a Devlog
1:23 Tip 9 - Game Engines Aren't Important
1:35 Tip 10 - Stick with a Tool
1:45 Tip 11 - Free Software is Good
1:54 Tip 12 - Watch a Tutorial Everyday
2:11 Tip 13 - All Engines have Bugs
2:22 Tip 14 - Copy Peoples Art (But Don't Post It)
2:35 Tip 15 - Use a Color Palette
2:45 Tip 16 - Create a Moodboard
3:03 Tip 17 - Keep Your Art Simple
3:15 Tip 18 - Never Delete Your Art
3:28 Tip 19 - Fundamentals are Key
3:48 Tip 20 - Watch CS50
4:03 Tip 21 - Make Small Games
4:21 Tip 22 - Learn Your Language
4:38 Tip 23 - Naming Consistency
4:52 Tip 24 - Write Readable Code
5:15 Tip 25 - Create, then Optimize
Thanks! :D
"NEVER EVER EVER DELETE YOUR ART!"
*stares in slience after deleting three whole folders of scrapped project files*
LOL
On that readable code tip (#24), I'd refine that to say "make sure you can read your own code." In a game I'm currently working on, I've added some variables that I could very easily get away without using. The only reason I have them is because they make my code cleaner and easier to work with.
Also, make sure you can understand your own code and follow exactly what it does line by line. It is a good idea to create some model or system to define how your code will work, and stick to that model unless an adjustment is absolutely necessary. To that end, I will create empty methods if that's how my model works.
I agree but I also disagree. You should make code readable for anyone, so if you hire a developer down the road they can actually understand what you wrote. :D
@@Goodgis I've only thought about programming as a solo developer... so I don't tend to worry about making sure others can read my code...
I guess if I were working with someone else on a project, I would try to make sure we can both understand what's going on. But until something like that happens, I'll probably keep going the way I am, since there's not really any reason to do things differently.
I would also like to say that comments are a thing that exists, but excessive use of them may or may not be a good idea.
Fantastic video!
To the apple ==false thing.
The better thing is normally if(apple) or if(! apple) the problem is your variable name. So it's more of "use better names for variables" - > if (isAppleEaten) makes more sense :)
That's a good point!
Wow. Yikes I need to learn this. Lol
Dude, your videos are the ones that keep me going back to game programming, or programming in general, when my head just gives up.
I´m so bad at motivating myself, and ADD plus 3 kids and life does not help that much. Ever since I was like 13, I´ve had dreams of making games. It was not as easy then as it is now, or at least did not have the right people around me for that, so that really makes me a bit jealous on the kids today that can start with such a good base of programs and learning material.
I can´t thank you enough for the videos ^^ Keep it up, you´re awesome! You are making some changes on people here :D
Never give up on your dreams. No matter what life throws at you. I honestly wish you the best of luck and thanks so much for the kind words! :D
Thats same to me(except kids and time of dreaming about game creating cuz im just 12, i started wondering about it much earlier,max 3 years ago)
I’d love to see more videos like this! It was snappy and quick to the point. Really useful and I can see myself using some of these tips!
I really wanted to make this as non-fluff as possible. Thanks so much!
Your tone in this video is encouraging, very appreciated amongst the sea of other youtube videos that make game dev more intimidating than it needs to be.
4:52 My first thought: "How would this be controversial?" Then after seeing the examples *_*eye twitch*_* Haha just playing - great tips! My tip is using easing functions, particles, and sfx makes your game look/feel a million times more satisfying and when it feels better it's more motivating to keep working on your game, and for me motivation is the hardest thing, not necessarily the knowledge/skill.
I mean in my Table Top dev work it's the opsite for me... Short hand is king as you need info to be dense, readable and easy to see at a glance... Kinda like code... Exapt bugs are in slow motion and it's easy to fix them on the spot if you know your game well. That said my game also has a glossary to look up the short hand easly.
Haha Thanks for sharing!
@@GreenBlueWalkthrough True! I feel like it really depends on the average experience of your team. For a first game-sure, be verbose so you can remember what things mean. Once you're on a team of experienced devs though, it's time to shed that boilerplate.
One bonus tip for tip 24:
I hate writing documentation and extra comments. I bet many of you do, too! So, instead of wasting tons of time on documentation and comments, which you don't want to do, just get used to use more expressive names. `square_root_a` is a lot more readable than `sra`, even though it might be longer to type (which auto-completion can fix for you, too). Never ever use one-letter variable names, unless it's just some counter or [i]ndex. The finished game (or program in general) won't run any slower or faster based on the length of your names.
Thanks for sharing!
5:49 Thanks so much for this bit man, I was making my first game last night and I spent 2 complete hours just listening to the Windows error sound whenever I ran my code and gave up. Thanks this gave me motivation to continue ❤
Thank you so much, I always feel I don't get any support when I make my games and everyone thinks I'm going to give up. This video helped me get back on track. Thanks❤️
i realy love your content! you help a lot with giving me motivation to work on my programming skills! keep on making this awesome content 👍
Thanks for the nice advices!
I knew much of them already but here are the Tips & Tricks i recommend focus at:
1, 3, 4, 5, 6, 8, 12, 14, 16, 17, 18, 19, 21, 24, 25
But it can change depending on what your goal is though (efficiency, quality or quantity)
XD
These are great tips! From me as a full-time game dev, I can't say it enough to aspiring game devs to focus on the fundamentals and learn the actual language before diving too much into the engines. It's really a short term vs long term plan which of long term always wins. 🙌
That's a great point! Thanks for sharing!
I would typically assume comparisons between a boolean variable and either true or false happen due to lack of understanding the language rather than an intentional choice of the writer. This is a pretty common pattern used by people new to coding. In software teams this is pretty unanimously frowned upon. The argument being that you are introducing a comparison where you do not need one. But if this works for you in a solo project, do whatever is most readable to you.
I agree with another comment here about variable names, usually bools should be named so when you read the if, it reads "if is an apple", and then it more clearly would complicate things to write "if is an apple is true"
Love the tips! Would be interested to see you have conversations with more specialized skills (coding, art, music, etc) and compare their tips vs the tips of a generalist solo dev.
Thanks so much!
5:07 never ever do this
'if boolean == false' is horrible form, if an exclamation mark is really too difficult then just use the not keyword but please don't abuse comparison operators like that
Tip 24 is too powerful for you? ;)
@Goodgis hehe it would definitely make my professors mad :p
We use ‘if boolean != false’ at my work all the time as embedded programmer but it could be just a quirk of C programming or our style guide
As a web developer it's preferred to just ! And && over the == false or and. So tip 24 is subjective just make sure you don't go back and forth from and and &&
Tip 24 comes straight from a C++ handbook.
Hmm might be how JavaScript get complied on our applications but our backend we keep it the same coding standard. I assume c++ compiles the same with "and" and == false
@@treysonsearle8441 In C++ it is better to use &&, ||, and !
Idk where this guy is getting this info from.
Missed your videos glad to see new upload
Thanks! :D
actually very usefull. and i can see the effort you put into your videos.
I appreciate that!
Brilliant advice buddy, Thank You
Thanks goodgis, you rlly inspire me, I love seeing your new videos when I find out you uploaded, you truly are great. Hope I become a great gamedev like you :)
Thanks so much! I really appreciate it.
i needed this I've always had problems finishing my games, thanks man!
Thanks so much!
Great video!!! This does help a lot and i will definitely rewatch it later
Glad to hear it!
These are great! I'm working on my ANSI / ASCII Roguelike, and I keep getting caught up in tiny details like changing the color of the player and enemies when they're frozen or poisoned, and tweaking the UI :')
Sounds awesome!
@@Goodgis Thanks :D
This is a very competent, helpful and encouraging video. Well done, sir, and thank you.
Glad it was helpful!
I come from the TTRPG space. My big bit of advice is to keep your old drafts. You never know when you will want to go back and look at them. It gan be easy to get lost when writing and it can ground you to go back and see older versions of your game.
Heck yeah!
These tips are so simple and yet so true, I should definitely be using them more often lol
Happy to hear that! :D
These are great tips!! Love you bro!
Glad you like them!
@@Goodgis I'm going to go through it a few more times to take some notes. Keep up the great work buddy😁👍
4:04 I actually did this one on my own, cause I realized I was working on too big of a project, and I need to actually make a finished product before I start with bigger games, this is a really good tip!
That's awesome!
Thx, I do have a question though, what’s the best way to get feed back for your game?
@@Mr_Pringle593
try reaching out through game dev communities in discord, reddit, twitter, etc. and ask for feedback
@@arvidasbjrn9081 ok, I will, thx
Thank you for the reminder. I already knew most of those tips, but is always welcome to return to the basics.
Thanks so much!
This encouraged me. Thank you.
Glad to hear it!
Thank You bro you are very helpful :)
Happy to help! :D
I teach younger kids game dev, and these are things I try to stress to them often. It's great I have a really concise video to show them now!
Thanks so much!
Great video man! Thanks a lot!
Thanks so much!
Thank you for the great advice 👍 I live your vids
Thanks! :D
Very informative. Thank you very much!
Glad it was helpful! :D
Thanks for making this video, dude. A lot of those tips are pretty helpful.
But honestly for me (as of making this comment), I don't know why, but I feel like I'm ready to dip my toes into indie game dev, but the game that I have in mind (at least in terms of its story) is coming along really slow. I want the story to be one of the main selling points of the game and I was thinking of making a demo of the game first, at least until I have the story fully thought out, so that way, I can get folks' input on what they think needs to be fixed, changed, etc.
But in the meantime, I'm working on the game's music and I even decided to dip my toes into drawing, as well (but I want to keep the art style simple, not something that will take way too much time to do).
Thanks like you have a pretty cool idea! I would recommend you start prototyping the game as soon as you can and worry about all the other stuff later. :D I wish you the best of luck!
As someone who is not a beginner, I really love watching these kinds of videos!
Glad to hear it. :D
i really was needing see this video 🥺
:D I'm glade!
Awesome, thanks for the tips. :)
Great tips Goodgis but I would love a series about godot, I even try at looking at tutorials and most of them are kind of outdated or something but for you since you know godot it would be great for you to teach us, my mom even saw your vids and she even said maybe you should because it is great to help people when they don't understand but it is your choice so we will see, but have a great day and can't wait for another video.
I would love to eventually! :D
Fantastic tips for aspiring game devs. Great video as always. 🙏
Thank you so much! :D
thanks i liked these tips and found them very encouraging
Glad it was helpful!
It helped me a lot! Thanks :)
Glad to hear that! I wish you the best of luck!
0:23 The yarn nerd in me is quibbling about knitting being shown on-screen when crochet is mentioned lmao. Still, these are all definitely things I'm gonna want to keep in mind, especially now that the Unity debacle's gotten game development back in the forefront of my brain! Great vid! :D
nice tips, they are really gonna help me in the future
Glad to hear it!
This is so useful. Thank you
Glad to hear it! :D
Great video, probably gonna watch it a couple of times.
Thanks!
Thanks for the tips didn't think of some of them they are very helpful
That's a shame. :D
Thank you for these great tips. God bless! 🙂🙏🏼❤️
Glad it was helpful!
I am not developing a game, just thinking about it, this is the first video I watch from you and man, your positivity is awesome.
Hey, thanks so much. I appreciate it! :D
4:38 Is the most important. I feel like tutorials don’t tend to take this seriously enough, so beginners never learn the importance of naming consistency.
Yeah, I agree
Even when I have 2 years of game dev experience, this video is still useful!
Same haha
The BonusTip is the most important.
Thank you for the video.
Thanks for watching! :D
ayyy thanks for spreading sum wisdom bruh🔥
Any time!
Haven't even thought of a good portion of these tips. Thank you! Edit: Subscribed now.
Glad to hear it! Thanks so much! :D
Great video as always
Thanks so much!
0:24 That's knitting but I see your point, Yoshi's Epic Yarn was good
4:52 about the readability. The thing is sometimes to get the most performance of the hardware, esp during 90s and 2000s code, people used various tricks like direct memory handling and bit manipulation that was far from being readable. One good example is Quake III's fast inverse square root algorithm. Computers have gotten faster nowadays but again, for considerable larger games someone may want to use those tricks for even better performance. But I don't know if it's still necessary, I've just started to get into games, although I've a good amount of prior programming experience.
Thanks for sharing!
Wow I never thought of it that way ty
Thanks for watching!
Just starting GameDev with Godot. Thanks for the advice!
I wish you the best of luck!
Very helpful, thank you
Glad to hear it!
Nice tips, as always awesome video!
Thanks so much!
3 things;
1 - There is nothing wrong with using programming shorthand - it's efficient coding (ie. && instead of and, !var instead of ==false). If someone can't read that, then they need to do a refresher on the language. Most engines are some level of interpreter, so the more the optimized code, the less it has to do and your game is smoother.
2 - Comment the hell out of your code - this will make it clear to you and anyone else reading your code to know what you or your code are doing. This is essential for facilitating reuse.
3 - Have fun. :)
Thanks for sharing!
Yeah idk why so many people make a big deal out of that. And, the person who made this must be reading the whackiest c++ handbook ever if they are telling him to use and instead of &&
Thanks for the tips bro
Any time!
Couldn't agree more with all of these!
Thanks!
Here is a tip that's most important. Always try to work on your game when you have the free time. I make this mistake all the time, because I end up getting demotivated when coming back to my project or I forget about it. Use your time wisely.
This is true! haha
Well, here I am revisiting this video (thx to YT) now that I've decided to commit some of my free time to make games. I have WAYY too many ideas for games, most of which are really ambitious, to the likes of Genshin and similar games.
Thankfully, I did Computer Science early on, so I have a bit of a head start in programming, especially in Python. I chose Godot as my game engine, of which I have somewhat got a grasp of. I am now practicing the programming aspect, and these tips are helpful. I'll keep them in mind. The help is appreciated.
Happy to hear it! :D
Tip #6 is a bit misleading as you're showing code that's been copied and pasted. This is a bad idea. Reusing code does NOT mean copying & pasting it, that should never ever ever ever be done. You've got to create a function that you can call from anywhere with parameters that specify what that could should do. Other than that, this is an ace video as always
Nice, you caught that! Yes, functions are king.
I love modules
Well, if it's between different projects, then copy-paste is perfectly ok, if not inevitable (unless you're loading some external module that you update separately).
Within the same project, I'd say it's alright if you duplicate it or maybe even triplicate it, to avoid premature generalization/abstraction; but if you keep copying the same code over and over then there's definitely room for improvement.
The point about learning language itself first, then going into the game engine should be #1 tbh.
I see so many people on Reddit, or other forums trying to make a game and asking for help with code that despite short already looks like spaghetti that will be nightmare to work with in the future.
My tip is learn programming first, then do game development, as programming is arguably one of the important skills when developing a game. Go create some random program running in console, anything, make a game of tic-tac-toe, recreate Snake, etc. Just make sure you understand how to write clean code that will be easily maintainable and expandable.
Thanks for sharing!
Those are good tips and tricks for beginners, nice video!
Thanks so much! :D
My bonus tip is to finish the game you are making.
Even if it's just a 2 weeks project, even if you think it's absolute trash, or even if it's 1 single level where all you do is jump on one enemy.
Make a condition for the game to end and finish it properly.
Not only is it always gratifying to finish something you've been working on, but you'll go into your next project knowing that you can put the previous one behind.
I LOVE PLAYING THE SAME EXACT INDIE GAME STYLES FOR YEARS TO COME
Nice! :D
Thanks Goodgis, very cool.
Any time!
The tutorial one is a very good idea 💡
Thank you! 😊
WOW! great video wish I was this good at making videos
All it takes is practice!
Loved the video! What was the website you were showing during your programming fundamentals tip?
It's called www.w3schools.com/
I don't create games but this is still fun to watch ☺️
Same
That's awesome!
Hi. Thanks for the video, really useful.
I'm creating a game for my gf, she has not played much videogames, and I'm struggling with the difficulty curve. I'm trying to make easy yet fun levels (it's a platformer) , but the levels are still frustratingly difficult for her. It's my first game so I don't have experience with this, I just want to create a game where we both can have fun 😊
That's awesome though! haha
for tip #23, I think it's best if you stick to the naming conventions of the language you're writing in. Especially if you're working in a team.
Best one out there!
Thanks! :D
The time thing can really depend on experience. As you mentioned, you should take your estimated time and roughly double it. If you're completely new to game dev, I'd suggest maybe working on games that take 1-2 weeks, so you get used to the work flow. Even if you've made a few games and/or worked on games for a long time, it's still pretty accurate to multiply your estimated time by 1.5-2x because you generally always underestimate things. Sometimes this is wrong and you overshoot, but it's better to overestimate than underestimate.
Readable and reusable code is key! Always comment your code, more so explaining how it works and your future self will thank you. You won't be able to write reusable code all the time and that's okay, sometimes it's hard to make things generic enough for reuse. This is a skill you will gain over time, so you shouldn't expect to do this straight away. Try to code without thinking about it too much, otherwise, you will sit there forever trying to come up with "the perfect solution". A lot of the time you will have to come back and rewrite what you thought was "perfect", so you might as well write what feels natural rather than some overly complicated function etc. In regards to the reusable code, you should try to modularise as much of your code as possible. Keep your scripts/classes (assuming an OOP language) small, only having a single job. This is the same for functions, if it starts taking on multiple responsibilites, break it into another function or class. If you can do this, you will find that more of your code can be reused throughout the code base. As I mentioned earlier, you're not expected to do this immediately and you will develop this over time.
Premature optimisation is another thing to watch out for. This is where you try to improve something as early as possible, without knowing if it was worth the trouble. Usually this will end up eating your time and/or over complicating things. You should always optimise your code near the end of the development cycle, in the polish stage. That said, there are cases where you might have to do so, eg. a core system is making your game run incredibly slow, to an unplayable degree. I feel that's the only time you should try to optimise or even rewrite some code.
I could probably go on, but I hope this helps some people :)
Thanks for sharing! :D
Awesome tips! I add also: your game is not your code, so it's ok if the code is not looking suuuuper pretty or it's super optimized as soon as it runs smoothly in the target hardware. Especially if you are a solo gamedev.
Good tip!
Another tip is make a mark or write somewhere what you where doing before pause, to continue there.. Also when you need to finish another part in order to finish the first correctly.
I sometimes got lost in my own code for not having a note of where should I go back.
Thanks for sharing!
This is great thanks
Thanks for watching! :D
@@Goodgis I am developing a game now thanks to you and this vid you are so inspiring
Thanks!
This is will save me a lot of time x)
PS : Nice video :D
Thanks so much!
Helpful Stuff!
Glad you think so!
I just saved your video in my Most Important Playlist.
I love your vids ur so encouraging
Thanks so much! :D I try.
these are really good tips, especially the coding ones.
Thanks so much! :D
i completely agree about the copy other peoples art (without posting it) part. we learn from human interaction, you base your opinions off of what you're taught. the brain feels something, and it stores it. so tracing will help you get an idea of what you want to make.
It's the best way to learn. :D
I'm studying game design at uni and yes, this is basically what's they teach us
Glad to hear it! :D