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."
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
@@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
@@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.
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 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.
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.
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.
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!
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.
"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
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
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…
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
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.
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)
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
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.
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
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 :)
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.
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.
@@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.
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 &&
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
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❤️
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. 🙌
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.
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
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 :')
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.
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 ❤
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.
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.
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.
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!
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. :)
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 &&
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.
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
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.
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.
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.
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.
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"
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.
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
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
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
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!
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.
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.
A tip I have to a few people is to PRACTICE. Looking back at my buggy crappy games compared to now makes me proud of myself of how far I’ve come. And I don’t want to sound like an 8th grade computing teacher here, but once you’ve picked up coding and understand it it’s actually really fun!
These tips are good for beginers bad for long term. Long term you only want to write code once, you don't want to go back and optimize the code later. When you understand optimization you want to write it from the start.
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 😊
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 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 :)
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.
ya know what, the "never delete old art" tip is not talked about much in this comment section. And i want to talk about how that tip IS the one that gives me motivation, cause i look back at my old spritesheets and i think to myself... "this ''walking' animation wasnt even walking it was flailing their arms and dont going anywhere" or "damn these particle effects are literally a flashing upside down bow" oor "these icons are ugly" and thats motivating, cause i have the memories of drawing those things and thinking they were awesome, yeah well they arent anymore now they are trash... but junk that motivates still!
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.
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
If you're someone wondering why everyone keeps recommending making small games (pong, breakout, snake, tetris, etc.). Part of that is for the learning aspect since you can take what you learn from that and apply it to bigger projects (input management, camera control, menu's, etc.) but also the mental boost from it. You might not be excited about finishing it but those little wins add up and when youre 3 years into an unfinished project you'll need every bit of that you can get!
Learning to make a game on your own, is like learning how to build your own house. You gotta do your own floor, walls, plumbing, roofing, wiring, and decorating. It'll be hard, but not impossible
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.
So I’ve started creating pixel art. Not for a game or anything. I decided to do it for fun because I do have ideas for characters and I wanna see them come to life. I really love pixel art so I figured I enjoy the art, I have some ideas for characters and the idea of being able to make art has always intrigued me so why not try? It’s been a little over a week now. I defiantly understand feeling like you suck at what your doing but you only get better by doing, especially if your new. If you start and give up early on because your not making these insanely great drawings like others you’ll probably miss out on what you could be doing eventually. I understand wanting to be a pro the second you start but it doesn’t work that way. It takes patience and practice. I’ve given up on things because it wasn’t what I wanted it to even though I just started but I’m really enjoying creating pixel art even if it’s bad so I’m gonna keep at it.
I had a project that took so much more time that the engine provider dropped their support for the engine 2 years in. We had to switch engines and start over. Unfortunately life happened and the game owner decided to start over again when a new dev stepped in. I believe they will be finishing this year.
I disagree with avoiding shortcuts on things like switching from "!varName" to "varName == false" it is bad because people tends to make complex logic and you as you write your code wants to have full view of the thing that you want your program to do and more natural for me is by reading "!" as "not" so when you have statement like (ready === false) you read it as "ready equals false" but (!ready) you can easly read as "not ready". Its best to see the code of a proffesionals in your language of choice so you can be inspired by them to write like majority of people in the industry so later when you see some random code on web that you googled you will have easier time to understand what it means. There is one thing that should be avoided in "shortenning" your code but people that talks about it tends to miss the second part. It is a bad habit to making variables that have short names like "x" or "a" outside of loops when most of the time we use "i", "j" to iterate. But if you for example write a generic vector class for your game and you give it "x" and "y" property then it is ok because the class itself gives enough information to know what "x" and "y" means but if you code player (or other object / etc.) and put "x" and "y" in it, it gives not enough information is "x" a position? then why not write it as "positionX" or "position_x"? beacouse you can have also variables for rotation around axis you would add "rotationX" or "rotation_x" and your code would be more consistent and the second part - meaningless long names are no better or worse than short names. If you are struggling with naming things in your code or you are just begginer then think of it like writing for a person you dont know that dont know how you code because after 1 or 2 years (or earlier) you will be that person and you will struggle to understand what your code does and how it works and you want that code to be fast for you to understand so you wont waste time on things that you wrote before.
When learning a new language or framework I have fallen into the trap of writing, testing and optimising code only to discover (perhaps a few weeks down the line) that I have duplicated the functionality of a common library or extension, something not in the "quick overview" I had read before starting. Optimising early is very risky, even when you think you need to prove that a concept can work "efficiently enough". It's so hard to walk away from an unfinished and intellectually stimulating challenge in order to make progress elsewhere in a project. I always struggle with this aspect of development. Note: Ex pro game dev turned SE lecturer.
My #1 tip for beginners is to make your first games in ASCii. You don't know what you don't know and stripping a game down to its very basics helps making learning the basics so much easier. Make that Guess The Number game that takes 2 minutes to make. Make ASCii Tetris. Make that roguelike where you're a drunk wandering around a mall looking for a bag of cheetos. It takes years before you'll be truly decent at programming, ASCii games are the softest, quickest way to get started. My #1 advice for those wanting to go pro: if at all possible, utilize the cowardly power of friendship. If you don't love making art, having an art buddy could make hundreds of hours of labor vanish! And so on with music and programming. The Zeboyd Games guys did this, and I seriously envy them. If you're not blessed with such people in your life, then automating away this labor as much as you can should be a consideration. Musicians and artists throw stuff into the public domain sometimes, some storefronts sell models, GANs are starting to finally have useful output (especially if you only want character portraits, like in a dungeon crawl game). You can do everything yourself, but you're in a race of getting the game done before your interest in finishing it dies. The Cave Story dude took four years to finish that game, and Cave Story is a small, SMOL game..
Blockbench is simple and can do lowpoly models. Not just minecraft blocks. There's a lack of tutorials however so you pretty much need to figure out the simple interface yourself. So that could be useful for some devs.
✨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
@@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
@@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.
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
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
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…
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
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.
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
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)
"NEVER EVER EVER DELETE YOUR ART!"
*stares in slience after deleting three whole folders of scrapped project files*
LOL
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!
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
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
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!
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.
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.
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!
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❤️
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 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!
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
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
As someone who is not a beginner, I really love watching these kinds of videos!
Glad to hear it. :D
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
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: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 ❤
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.
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.
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.
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
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 &&
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.
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.
Even when I have 2 years of game dev experience, this video is still useful!
Same haha
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
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!
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.
Thanks for sharing!
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
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!
thanks for the advice with the moodmap. it helps to know where the game is going and what you want to bring to life
Thank you for the reminder. I already knew most of those tips, but is always welcome to return to the basics.
Thanks so much!
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"
I completely agree!
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 really was needing see this video 🥺
:D I'm glade!
These tips are so simple and yet so true, I should definitely be using them more often lol
Happy to hear that! :D
I don't create games but this is still fun to watch ☺️
Same
That's awesome!
This is a very competent, helpful and encouraging video. Well done, sir, and thank you.
Glad it was helpful!
i needed this I've always had problems finishing my games, thanks man!
Thanks so much!
actually very usefull. and i can see the effort you put into your videos.
I appreciate that!
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
Thanks for sharing! :D
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.
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
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
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.
Fantastic tips for aspiring game devs. Great video as always. 🙏
Thank you so much! :D
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.
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!
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.
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!
I just saved your video in my Most Important Playlist.
tip 26 don't try to make gta 6 at your first try
True!
Wow I never thought of it that way ty
Thanks for watching!
I LOVE PLAYING THE SAME EXACT INDIE GAME STYLES FOR YEARS TO COME
Nice! :D
Haven't even thought of a good portion of these tips. Thank you! Edit: Subscribed now.
Glad to hear it! Thanks so much! :D
A tip I have to a few people is to PRACTICE. Looking back at my buggy crappy games compared to now makes me proud of myself of how far I’ve come. And I don’t want to sound like an 8th grade computing teacher here, but once you’ve picked up coding and understand it it’s actually really fun!
Good point!
Just starting GameDev with Godot. Thanks for the advice!
I wish you the best of luck!
The BonusTip is the most important.
Thank you for the video.
Thanks for watching! :D
These tips are good for beginers bad for long term. Long term you only want to write code once, you don't want to go back and optimize the code later. When you understand optimization you want to write it from the start.
Yeah, I get where you're coming from. :D
0:24 That's knitting but I see your point, Yoshi's Epic Yarn was good
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
Thank You bro you are very helpful :)
Happy to help! :D
I'm studying game design at uni and yes, this is basically what's they teach us
Glad to hear it! :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
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 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.
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
Wake up babe, new Goodgis video just dropped!
Heck yeah!
ya know what, the "never delete old art" tip is not talked about much in this comment section. And i want to talk about how that tip IS the one that gives me motivation, cause i look back at my old spritesheets and i think to myself... "this ''walking' animation wasnt even walking it was flailing their arms and dont going anywhere" or "damn these particle effects are literally a flashing upside down bow" oor "these icons are ugly" and thats motivating, cause i have the memories of drawing those things and thinking they were awesome, yeah well they arent anymore now they are trash... but junk that motivates still!
Thanks for sharing!
nice tips, they are really gonna help me in the future
Glad to hear it!
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
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
Missed your videos glad to see new upload
Thanks! :D
0:25 says crocheting, shows knitting...
This is a sad day for crocheters😔
;)
I loved the “adios” at the end jaja
Thanks! ;)
If you're someone wondering why everyone keeps recommending making small games (pong, breakout, snake, tetris, etc.). Part of that is for the learning aspect since you can take what you learn from that and apply it to bigger projects (input management, camera control, menu's, etc.) but also the mental boost from it. You might not be excited about finishing it but those little wins add up and when youre 3 years into an unfinished project you'll need every bit of that you can get!
Learning to make a game on your own, is like learning how to build your own house. You gotta do your own floor, walls, plumbing, roofing, wiring, and decorating. It'll be hard, but not impossible
WOW! great video wish I was this good at making videos
All it takes is practice!
Brilliant advice buddy, Thank You
Great video, probably gonna watch it a couple of times.
Thanks!
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!
So I’ve started creating pixel art. Not for a game or anything. I decided to do it for fun because I do have ideas for characters and I wanna see them come to life. I really love pixel art so I figured I enjoy the art, I have some ideas for characters and the idea of being able to make art has always intrigued me so why not try? It’s been a little over a week now. I defiantly understand feeling like you suck at what your doing but you only get better by doing, especially if your new. If you start and give up early on because your not making these insanely great drawings like others you’ll probably miss out on what you could be doing eventually. I understand wanting to be a pro the second you start but it doesn’t work that way. It takes patience and practice. I’ve given up on things because it wasn’t what I wanted it to even though I just started but I’m really enjoying creating pixel art even if it’s bad so I’m gonna keep at it.
Keep pushing forward and you'll get great in no time! :D
I had a project that took so much more time that the engine provider dropped their support for the engine 2 years in. We had to switch engines and start over. Unfortunately life happened and the game owner decided to start over again when a new dev stepped in. I believe they will be finishing this year.
I disagree with avoiding shortcuts on things like switching from "!varName" to "varName == false" it is bad because people tends to make complex logic and you as you write your code wants to have full view of the thing that you want your program to do and more natural for me is by reading "!" as "not" so when you have statement like (ready === false) you read it as "ready equals false" but (!ready) you can easly read as "not ready". Its best to see the code of a proffesionals in your language of choice so you can be inspired by them to write like majority of people in the industry so later when you see some random code on web that you googled you will have easier time to understand what it means. There is one thing that should be avoided in "shortenning" your code but people that talks about it tends to miss the second part. It is a bad habit to making variables that have short names like "x" or "a" outside of loops when most of the time we use "i", "j" to iterate. But if you for example write a generic vector class for your game and you give it "x" and "y" property then it is ok because the class itself gives enough information to know what "x" and "y" means but if you code player (or other object / etc.) and put "x" and "y" in it, it gives not enough information is "x" a position? then why not write it as "positionX" or "position_x"? beacouse you can have also variables for rotation around axis you would add "rotationX" or "rotation_x" and your code would be more consistent and the second part - meaningless long names are no better or worse than short names. If you are struggling with naming things in your code or you are just begginer then think of it like writing for a person you dont know that dont know how you code because after 1 or 2 years (or earlier) you will be that person and you will struggle to understand what your code does and how it works and you want that code to be fast for you to understand so you wont waste time on things that you wrote before.
Thanks for sharing!
When learning a new language or framework I have fallen into the trap of writing, testing and optimising code only to discover (perhaps a few weeks down the line) that I have duplicated the functionality of a common library or extension, something not in the "quick overview" I had read before starting. Optimising early is very risky, even when you think you need to prove that a concept can work "efficiently enough". It's so hard to walk away from an unfinished and intellectually stimulating challenge in order to make progress elsewhere in a project. I always struggle with this aspect of development.
Note: Ex pro game dev turned SE lecturer.
My #1 tip for beginners is to make your first games in ASCii. You don't know what you don't know and stripping a game down to its very basics helps making learning the basics so much easier. Make that Guess The Number game that takes 2 minutes to make. Make ASCii Tetris. Make that roguelike where you're a drunk wandering around a mall looking for a bag of cheetos. It takes years before you'll be truly decent at programming, ASCii games are the softest, quickest way to get started.
My #1 advice for those wanting to go pro: if at all possible, utilize the cowardly power of friendship. If you don't love making art, having an art buddy could make hundreds of hours of labor vanish! And so on with music and programming. The Zeboyd Games guys did this, and I seriously envy them.
If you're not blessed with such people in your life, then automating away this labor as much as you can should be a consideration. Musicians and artists throw stuff into the public domain sometimes, some storefronts sell models, GANs are starting to finally have useful output (especially if you only want character portraits, like in a dungeon crawl game).
You can do everything yourself, but you're in a race of getting the game done before your interest in finishing it dies. The Cave Story dude took four years to finish that game, and Cave Story is a small, SMOL game..
Thanks for sharing!
0:40 "If you're gonna finish a game in a month, plan to finish it in two weeks." BRUH
Great video!!! This does help a lot and i will definitely rewatch it later
Glad to hear it!
This is will save me a lot of time x)
PS : Nice video :D
Thanks so much!
Blockbench is simple and can do lowpoly models.
Not just minecraft blocks.
There's a lack of tutorials however so you pretty much need to figure out the simple interface yourself.
So that could be useful for some devs.
Thanks for sharing! :D
Loved the video! What was the website you were showing during your programming fundamentals tip?
It's called www.w3schools.com/
This encouraged me. Thank you.
Glad to hear it!
Couldn't agree more with all of these!
Thanks!