25 Game Dev Tips for Beginners - Tips & Tricks

[@Goodgis]

✨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.)

[@captainom5065]

Fan bro

[@Ediblespaceship273]

Ok

[@potadosm]

thanks for your great tips you are still a helpful youtuber i like you

[@MGMac_]

The last tip was corny but still somehow inspiring lol

[@ORANOID]

That was less of the tip and more of the order. You must subscribe. Haven't you already subscribed?! Would you kindly subscribe?

[@lendrigangames]

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."

[@Goodgis]

I totally agree!

[@KennyFully]

As someone who just experienced art asset related problems, I totally agree.

[@michaelluck5577]

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

[@Poopymancer]

​@@michaelluck5577 the coding is what i got stuck on too, like really early on stopped me dead in my tracks. Focusin on art projects for now then gonna give coding another go, gonna try learning gdscript

[@theConcernedWyvern]

​@@michaelluck5577 it'll get easier over time. I'm in the same boat, trust me. Coding is still a bit overwhelming, despite doing it for a few years now. You'll get faster and more comfortable over time, you just have to train your brain and muscles to get used to it.

[@ShafterPlay]

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.

[@Goodgis]

I get where you're coming from but for beginners they should focus on making their code clear and readable.

[@GrimoireM]

@@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.

[@wolf7115]

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.

[@robertonome2448]

@@wolf7115 ouch. Now thats some serious burn

[@HonsHon]

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.

[@lukeydoesstuff]

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.

[@Goodgis]

Heck yeah! Great tip!

[@iandakariann]

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.

[@iandakariann]

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.

[@--Arthur]

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.

[@soninhodev7851]

@@--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)!

[@half-live]

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!

[@Goodgis]

Thanks, I really appreciate it!

[@_bop5209]

hey you're that guy from the discord

[@half-live]

@@_bop5209 yes

[@uraniummmm1]

Samee

[@lemonke8132]

Lesson’s

[@AgentChick]

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.

[@Goodgis]

Thanks for sharing!

[@thulko]

I'm in the same boat, I tend to overthink problems and optimization too early.

[@Discolingua]

"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.

[@iandakariann]

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.

[@matheusmarchetti628]

@@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

[@stickzman]

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

[@Goodgis]

Thanks for sharing!

[@PythonPlusPlus]

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.

[@PythonPlusPlus]

@@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…

[@lorgarmor5886]

"NEVER EVER EVER DELETE YOUR ART!" *stares in slience after deleting three whole folders of scrapped project files*

[@Goodgis]

LOL

[@jaerker]

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

[@Goodgis]

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

[@kamanmarcell1413]

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)

[@SquidGodDev]

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.

[@GreenBlueWalkthrough]

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.

[@Goodgis]

Haha Thanks for sharing!

[@RonWolfHowl]

@@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.

[@AngryhammerGames]

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

[@Goodgis]

Thanks! :D

[@maxrdev703]

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!

[@Goodgis]

I really wanted to make this as non-fluff as possible. Thanks so much!

[@silentmenot]

i really was needing see this video 🥺

[@Goodgis]

:D I'm glade!

[@victor_creator]

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.

[@Goodgis]

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

[@victor_creator]

@@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.

[@flaschenzuglp9994]

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 :)

[@Goodgis]

That's a good point!

[@Mac_Omegaly]

Wow. Yikes I need to learn this. Lol

[@treysonsearle8441]

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 &&

[@Goodgis]

Tip 24 comes straight from a C++ handbook.

[@treysonsearle8441]

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

[@HonsHon]

@@treysonsearle8441 In C++ it is better to use &&, ||, and ! Idk where this guy is getting this info from.

[@danuvip]

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)

[@Goodgis]

XD

[@safasyed3457]

tip 26 don't try to make gta 6 at your first try

[@Goodgis]

True!

[@VummyProductionsOfficial]

Edward chase isn't that advanced trust me

[@Smaxx]

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.

[@Goodgis]

Thanks for sharing!

[@miked94]

It would be amazing if longer names made it faster though! It would actually encourage people to write more detailed names 😂 but of course that's not the reality of it

[@worthasandwich]

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.

[@Goodgis]

Heck yeah!

[@Charziot]

Every tip you've mentioned, is actually perfectly, you clearly have had lots of experience and I share my opinion with you also, fantastic advice and thank you for informing more people about these things as so many game developers try something it doesn't work then give up. Never give up everyone, and thank you again Goodgis.

[@al_my_pal]

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.

[@theConcernedWyvern]

There so many of those. Not to mention the amount of "Don't make your dream game" click bait that's just there to sound scary so people give them views. Even if it has a valuable lesson, it's depressing to see titles and thumbnails like that, since that sort of attitude can really scare away new devs. I agree with the advice, but I can't stand the ways it's presented.

[@JustinBieshaar]

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. 🙌

[@Goodgis]

That's a great point! Thanks for sharing!

[@KechingGI]

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 ❤

[@psistarpsi80]

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!

[@Goodgis]

Thanks so much!

[@Mr_Pringle593]

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!

[@Goodgis]

That's awesome!

[@Mr_Pringle593]

Thx, I do have a question though, what’s the best way to get feed back for your game?

[@arvidasbjrn9081]

@@Mr_Pringle593 try reaching out through game dev communities in discord, reddit, twitter, etc. and ask for feedback

[@Mr_Pringle593]

@@arvidasbjrn9081 ok, I will, thx

[@eboatwright_]

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 :')

[@Goodgis]

Sounds awesome!

[@eboatwright_]

@@Goodgis Thanks :D

[@RoseVerdict]

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

[@sicktricks95]

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.

[@Goodgis]

Thanks so much!

[@rollowollo]

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❤️

[@alexclare8256]

Wow I never thought of it that way ty

[@Goodgis]

Thanks for watching!

[@stevemcwin]

As someone who is not a beginner, I really love watching these kinds of videos!

[@Goodgis]

Glad to hear it. :D

[@CodeWithTom]

Fantastic tips for aspiring game devs. Great video as always. 🙏

[@Goodgis]

Thank you so much! :D

[@zitronekoma30]

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

[@Goodgis]

Tip 24 is too powerful for you? ;)

[@zitronekoma30]

@Goodgis hehe it would definitely make my professors mad :p

[@garyadamos]

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

[@nialyavuzturk379]

Tip 24 is actually pissing me off, the advice this guy is giving blows

[@aronjaeger]

thanks for the advice with the moodmap. it helps to know where the game is going and what you want to bring to life

[@oldfallstorm3064]

Even when I have 2 years of game dev experience, this video is still useful!

[@Goodgis]

Same haha

[@finbobyeetseggs6158]

actually very usefull. and i can see the effort you put into your videos.

[@Goodgis]

I appreciate that!

[@RomainDelmaire]

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.

[@r0hitm]

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.

[@Goodgis]

Thanks for sharing!

[@xasv1k]

Thanks for the quick and helpful tips. Just planning to take the first step (in parallel with my boring full-time job) and videos like these really give a boost

[@lisathewhitewolf]

One thing I heard that makes a lot of sense is "use the engine that does your type of game well." The other thing I would say for beginners is make sure your engine has a community that can help you and that they're not screwing over their users.

[@hribrosplayz7578]

Thank You bro you are very helpful :)

[@Goodgis]

Happy to help! :D

[@PebsieTTV]

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

[@Goodgis]

Nice, you caught that! Yes, functions are king.

[@Aaron-xr7oc]

I love modules

[@MrTomas7777]

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.

[@UserLuigi]

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.

[@Goodgis]

This is true! haha

[@Watauro]

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.

[@Goodgis]

I would love to eventually! :D

[@benjaminlehmann]

This is a very competent, helpful and encouraging video. Well done, sir, and thank you.

[@Goodgis]

Glad it was helpful!

[@binsurf]

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. :)

[@Goodgis]

Thanks for sharing!

[@HonsHon]

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 &&

[@LoggyDev]

i needed this I've always had problems finishing my games, thanks man!

[@Goodgis]

Thanks so much!

[@shima6917]

These tips are so simple and yet so true, I should definitely be using them more often lol

[@Goodgis]

Happy to hear that! :D

[@whiteninjagaming5633]

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 👍

[@dumivid]

Thank you for the reminder. I already knew most of those tips, but is always welcome to return to the basics.

[@Goodgis]

Thanks so much!

[@nocturne6320]

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.

[@Goodgis]

Thanks for sharing!

[@djblast101]

Missed your videos glad to see new upload

[@Goodgis]

Thanks! :D

[@punkysuen]

Want to add one point: Try to mock some ancient games. When I started to learn Godot several days, I spent 5 hours to create a demo which has a core gameplay similar to Lunar Rescue (1979), and my family loves it. This encouraged me a lot.

[@Goodgis]

Thanks for sharing!

[@Novanitybrandon]

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 :)

[@Goodgis]

Thanks so much! I really appreciate it.

[@aaaaabik]

0:40 "If you're gonna finish a game in a month, plan to finish it in two weeks." BRUH

[@AlrhadenJavier]

I just saved your video in my Most Important Playlist.

[@Goodgis]

[@d1amondzz_]

If "apple" variable is boolean I think a better way is to name it "apple_is_picked" or something like this, and line "if not apple_is_picked" would be more readable than "if not apple" or "if apple == false"

[@Goodgis]

I completely agree!

[@nsgames24]

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).

[@Goodgis]

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!

[@Simon-nf2kw]

I don't create games but this is still fun to watch ☺️

[@Ediblespaceship273]

Same

[@Goodgis]

That's awesome!

[@reloadfast]

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.

[@Goodgis]

Hey, thanks so much. I appreciate it! :D

[@pulsar9448]

Brilliant advice buddy, Thank You

[@miguelluceroart]

Great video man! Thanks a lot!

[@Goodgis]

Thanks so much!

[@shirt5565]

Great video!!! This does help a lot and i will definitely rewatch it later

[@Goodgis]

Glad to hear it!

[@VictorTheVan]

These are great tips!! Love you bro!

[@Goodgis]

Glad you like them!

[@VictorTheVan]

@@Goodgis I'm going to go through it a few more times to take some notes. Keep up the great work buddy😁👍

[@Archibaldii]

I have some tips 1:sleep with paper and pen cause sometimes you can dream somthing interesting 2:read books any kind wich turn creative much original 3:listen to kids shear their drawings cause they are more creative

[@Goodgis]

Thanks for sharing! :D

[@wiwita63]

Yeah, I literally wrote an entire game story idea based on a dream I had, I wrote on my phone as soon as I woke up so I can edit it later.

[@chaotickreg7024]

0:24 That's knitting but I see your point, Yoshi's Epic Yarn was good

[@Josh-un6gy]

This encouraged me. Thank you.

[@Goodgis]

Glad to hear it!

[@soundbreaker8174]

I LOVE PLAYING THE SAME EXACT INDIE GAME STYLES FOR YEARS TO COME

[@Goodgis]

Nice! :D

[@hollaxow3331]

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.

[@bruddhagrombygaming5066]

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.

[@Goodgis]

It's the best way to learn. :D

[@Yveltyyy]

nice tips, they are really gonna help me in the future

[@Goodgis]

Glad to hear it!

[@devzindie]

Very informative. Thank you very much!

[@Goodgis]

Glad it was helpful! :D

[@Marianojoey]

Awesome, thanks for the tips. :)

[@dkujo]

Great video, probably gonna watch it a couple of times.

[@Goodgis]

Thanks!

[@Dankway2]

Great video as always

[@Goodgis]

Thanks so much!

[@hectora.3220]

Just starting GameDev with Godot. Thanks for the advice!

[@Goodgis]

I wish you the best of luck!

[@souldrainage]

It helped me a lot! Thanks :)

[@Goodgis]

Glad to hear that! I wish you the best of luck!

[@milliondollarmonstertv8081]

Thank you for the great advice 👍 I live your vids

[@Goodgis]

Thanks! :D

[@tembok713]

This is so useful. Thank you

[@Goodgis]

Glad to hear it! :D

[@ramoncf7]

The BonusTip is the most important. Thank you for the video.

[@Goodgis]

Thanks for watching! :D

[@tommasofilipponi2608]

I'm studying game design at uni and yes, this is basically what's they teach us

[@Goodgis]

Glad to hear it! :D

[@startek119]

I’m making an open world game about robots. You’re a robot and you go around repairing factories, exploring, fighting off hostile robots and building an army.

[@alicemystery5332]

thanks i liked these tips and found them very encouraging

[@Goodgis]

Glad it was helpful!

[@SkinnerSpace]

Nice tips, as always awesome video!

[@Goodgis]

Thanks so much!

[@bananapix2433]

Couldn't agree more with all of these!

[@Goodgis]

Thanks!

[@dian6763]

0:25 says crocheting, shows knitting... This is a sad day for crocheters😔

[@Goodgis]

;)

[@programmingmonkey1423]

This is will save me a lot of time x) PS : Nice video :D

[@Goodgis]

Thanks so much!

[@SkidesGames]

Wake up babe, new Goodgis video just dropped!

[@Goodgis]

Heck yeah!

[@twomur_]

such an amazing video!

[@Goodgis]

Thank you!!

[@duztine]

Very helpful, thank you

[@Goodgis]

Glad to hear it!

[@pedromartindelcampogonzale9613]

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 😊

[@Goodgis]

That's awesome though! haha

[@CompressedEarthBlocks]

Haven't even thought of a good portion of these tips. Thank you! Edit: Subscribed now.

[@Goodgis]

Glad to hear it! Thanks so much! :D

[@diarioparaemprendedores]

I loved the “adios” at the end jaja

[@Goodgis]

Thanks! ;)

[@LanceAntisin100]

Thanks Goodgis, very cool.

[@Goodgis]

Any time!

[@calebotoh]

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 :)

[@Goodgis]

Thanks for sharing! :D

[@ossdemura]

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.

[@Goodgis]

Good tip!

[@galaxytinus7781]

Thanks for the tips didn't think of some of them they are very helpful

[@Goodgis]

That's a shame. :D

[@Stacked.Stone24]

hi i liked your content can you tell me how to download Pygame and is it safe and good to use Pygame for making video games to make money?

[@mr_noodler]

When you solo dev, you only need to write the code that you like to read. I also recommend that a developer get the official training for their game engine instead of a 3rd party course. The advice from the source is the best

[@Goodgis]

That's kind of a bad mindset to get. You should make your code readable but I do agree with matching your engines brand standards.