Honestly... just start making stuff. Download an engine and play within it. Write stories. World build. Trial by fire is the best way to learn anything. Just get started and learn as you go. You may get so invested and find out it's for you OR you spend some time doing it but end up walking away entiely.
As always, it depends on what _"best"._ Trial by fire is best in its traction (output stickiness) and fun, but not in its fuel (time-effort input), acceleration, top speed, turning (flexibility and sunk cost), difficulty, safety (good habits and best practices), nor comprehensiveness. And it's terrible in its time-effort and safety. E.g: Books (refs, manual, research papers etc) is best in its top speed and comprehensiveness - terrible in its difficulty and fun. Videos (podcast, blogs, tweets etc) is best in its fuel, early acceleration, and difficulty - terrible in its traction, late acceleration, and top speed. Mentor (teacher, friends, experts etc) is best in its turning and safety - terrible in its... uh, price? Courses (guides, maps(whatchamacallit?), resources etc) is best in its late acceleration - terrible in its turning. ...
@@DagarCoH Not really. You can invent your own method for some functionality by "trial by fire" after realizing months later that what you wanted to achieve was already implemented and part of the engine, you just had to tick one checkbox. You have to KNOW your engine first, not just mindlessly do things "trial by fire" way.
@@MNorbert89 Disagree, unless you think someone who plays around with the tools they have first will never bother to learn them properly, which is a dubious take. Both go hand in hand, but you are best off by trying and failing fast rather than burying your head in documentation and tutorial videos first, in my opinion, because the lessons you learn that way will stick much better.
I started out with a "full game course". The biggest thing I got from that was getting to touch all parts of the engine as part of making said game. At the end the "game was pretty crap, but I definitely knew how to find my way around the engine!
Thanks for sharing. The point you made about how learning your engine being very important resonates with me. I've been following tutorials and although not fully remembering how to do the exact thing they're showing, I'm getting more confident around the engine and familiar with certain parts. Slowly but surely getting better at game development.
I think the way to actually start game development is to think of your game engine like a Lego toy. You find pieces which is the tutorial, engines, library that you would like to use. Then you think of what more you can do with the given pieces. It's like what you learn is Lego boxes with sample models. And your actual game development is like break down those models and combine them into something new. This is how I start game development: -I got a game I want to make or a game I can mod. -I play around with coding and moding with it. -Then I find out what more I can tweak and experiment with what I learn. -After I learned enough, I thinking of a game project as a goal. -Then it become a few months or a few week project. My actual story: When I was 14, I found a game called CS2D. I saw plenty of mods there. Around that time, I also learn coding in middle school. And so I dig through sample mods and find my way to create my own mod. I wasn't able to do everything I want but enjoyed making my own mod. Years later I came back to that game with my college coding course I have learned. I was able to do everything my 14 years old wished back in the day. Then I'm thinking of expanding the project and found the technical difficulty. That's when I was thinking of pick up a new game engine. I pick up a new game engine with a game I want to make in mind. And so my game development journey has already been months and still going till today.
For someone with a decent computer who want to make 3d games, Unreal and use one of the template scenes (like the third person) that comes with the engine. The next steps are watch 4 tutorials ... first how to replace the SK Manequinn with an other character model, second how to place objects in the scene to make it more interesting, third how to create a goal in the game (could be walk from A to B, or collect 10 items to finish), fourth tutorial how to compile and publish it. With this 4 steps it's possible even for beginners to make action adventures, walking simulators, 3d plattformers, or simple horror games (walking through a dark forrest or an old creepy mansion) without enemies. Not sure if Unity comes with templates like Unreal does.
I had very little coding experience (Mechanical Engineering background). What I found was the most important thing to start making progress and having fun was learning and internalizing in gruesome precise detail how to reference scripts, how to communicate between scripts, and the differences and applications of different types of scripts. In my opinion courses and tutorials fail to emphasize this kind of stuff enough, and this is the biggest cause of "tutorial hell".
I think that you should do a video or at least try Godot 4.4 when it comes out of beta... because "Godot is not good for 3D" isn't true, and it hasn't been for a while
we would need more "why are we doing this or that and what do this line do" but most people looking at UA-cam for quick fix and don't want to watch extra minutes for explanations
Good advice . In my experience, bouncing development ideas off the AI is also the best, most productive way to use it for dev, at least currently. It's like having a partner to brainstorm and sanity check ideas.
It's pretty wild how effective AI is even for idea generation. I was messing around with DeepSeek and gave it a one line premise about my game RoadHouse Manager, to extrapolate on. I was blown away that a lot of the gameplay mechanics, themes and styles it generated where right on target for what was already in my game. It even nailed 100% two games that would be closet related for the gameplay style, which I often used before to describe to others before. And my game is fairly original as well, as games go.
As a hobbyist my approach has been picking an engine that I want to learn, even if it's not ideal for the game I'm currently working on. Getting deep knowledge in one tool is more efficient than trying to optimize the engine for a single game. I also use tutorials as a guideline to how to build a system, but then I completely modify it as I go to fit it into my current project. This ramps up the learning curve, because you are not mindlessly copying, but having to solve a lot of issues as you go, which requires much deeper thinking.
I would think starting with a business plan and figure out the who are customers, what do they want, and where are they would the best way in my opinion. Makes your game dev goals clearer and measurable as you get starting with skill/tutorials, engines, game ideas, etc.
If you're literally "brand new", then commercial game-dev probably shouldn't even be on the radar yet. Certainly not until you've made a couple games and had at least friends & family check them out.
@mandisaw Yeah, developing the skills to make the games is essential, but you still need a long-term goal in mind to push forward and motivate you. To do all the necessary work to make your game dev dreams come true.
@@Nubian_King_RNM It helps, for sure. But your goals are likely to change over the time it takes to build those skills. You'll see teens in school, or adults in a job-burnout crisis, say, "oh, I want to make games for a living!" But then the reality hits of either their actual ability, productivity, or their game's reach, or their life situation, and they might want game-dev to play a different role. Totally natural.
I have been a professional developer for 25 years. I would absolutely suggest using visual scriptin when starting out, provided you are making a simple game like Pac-Man. Someone once made a great observation: Programmers say everyone should learn coding, but they don't say everyone should learn pixel art or model building. It's a great point. I think you should learn everything, but there's no reason you have to learn it all upfront.
When I was a kid [80s US], they actually did teach us all art, music, writing, drafting / design, and eventually, coding. The idea was that you should have some basic understanding of, and exposure to, how all those domains work, no matter where your talents & career might take you.
Same situation for me and I would give the same advice. Coding is the superior approach, but if you have 0 coding background, learning to do it well enough to cover the needs for a whole game is a huge undertaking. I would play around with something like blueprints instead, and when if I bump into something I couldn't achieve I would then ask a programmer (AI or real) to construct a it in a way that I myself could call it from blueprints. The important thing is to understand how things work together. You need Legos that you comprehend enough to cobble together into what you ultimately want to build. Same as with code. Alternatively you find an engine or framework that specializes in the exact genre you want and learn a very basic language like Ink or Lua to get the job done. Hope this helps 👊
Heartbeast has great tutorials for beginners, he does a good job explaining what he’s doing in each step which is sooooo much better than a lot of tutorials
Id say the best way to start is knowing how to structure a project. Because if stuff starts to get too intertwined as a solo dev you arent going to want to refactor or fix it if your classes depends on each other too much. SO Id say start with a heavy, component based architecture. Because Imo even if its overkill for smaller projects it allows it to scale out the wahzoo in the future if you decide to do it. Also components are easier to pin point an issue, refactor, and add new features since it has a plug and play structure to it. Game dev is way funner when you dont have to worry every time you want to add a feature how it may effect 5 other features in the game. Gives you more freedom to change your mind mid way and not feel like youve wasted your time.
currently doing courses from stephen in udemy . Following courses/tutorials is fine as long as u replicate something similar on your own for each part of the tutorial .
There are no straight answers-just pick an engine, find a full-game tutorial, and start. I wanted to make a simple Battle Tank-style game as a precursor to my real project, so I tried Unity. But a persistent error caused 15-minute delays for every small update, like adjusting a hitbox. I figured either my setup wasn't compatible or I was missing something. This led me to explore GameMaker and Godot. In the end, I realized GameMaker, though pricier, was the best fit for my game. No one could have answered that for me-I had to find out by doing.
After one year I am almost done with my first game. It is far from a professional game but I have learned a lot. I did not started out with guides or tutorials. Just ask yourself what do you need. The first thing you probably want to do is walk around in a 3D game. So google (no I like to do it old school without AI) on how to do it. Now you maybe want to pick up a object. After this you want to create a inventory system so your object will be shown. And the object needs to be saved to. So now you have 4 steps that you can piece together and you know for a fact that you actually need it for your own game. And if you can`t figure out how to make something. Try it again. And again. And again. It can take you hours or even days just to do only 1 step. If it really is too hard maybe you can try it again in the future if you have more experience. But don`t give up that easy!
I've had a dream of being a game developer for more than 10yrs now but resources has always been my roadblock and in this part of the world there's no much of a mentor on this subject yet so I've decided to focus on my job and save up for rhe time being but your videos always makes me go back and try to start something
I'm going suggest a small addition here. For people that have a hard time finding motivation to learn, one option that may work is to make small games and prototypes with the direct purpose of learning to make or implement specific mechanics useful to your dream game. It may not be the best or most efficient option, but can help if you need motivation.
I loved to use GPT to find specific things. Like "I want to do [basic description of mechanic part] what can I use to make this?". With this I would get for example "You can use a loop or X or Y " and look things up while still trying to learn to implement it myself. Because my biggest issue was not knowing what is possible. And google doesn't really help all that much with very open questions. In the end I got somewhere, but I did notice I really suck at programming and rather find someone else to do it xD
Oh damn, didn't expect to see creeper world in this video. Here's how I plan to learn gamedev, as a software dev who has been coding for a while now. 1. Follow along to a "make a game tutorial". 2. Branch off from that to experiment with things in the engine from something that works. 3. Read some docs (ew, but it's necessary) 4. Remake small games like pong, it's a fixed scope project. 5. Plan out a small game of your own 6. Explore how to do specific things you don't know (like a HP bar) 7. Take your knowledge from tutorials and exploration to implement your own game from scratch.
1. Visual Scripting is good to feel the flow of the program. What goes where, what is used over and over again. I remember doing charts like this in university in one class before Visual Scripting become a thing in UE. Some people just process information better visually. 2. Start by making your dream game or more accurately divide your dream game into key mechanics and make small games focused on that one mechanic. At the end you will have all the puzzle pieces, all infinity stones, to put into gauntlet. 3. Use AI to do boring stuff - documentation.
In my experience, if you are also interested in being able to make your own game art, I recommend starting with either 3D or 2D art. When making art you always end up learning more than 10 different programs and that gives you an ease in learning complex interfaces which will make the transition to an engine much easier and you can focus on programming, of course it is a longer path to make a game but you will end up with a range of useful skills
Unity is like "okay, let's spend 1.5 Gb of your drive memory on EMPTY new project and recompile everything every time when you change a single value in your code" and "you also need a really good PC, btw". Sounds nice ))
I come from a development background, so the question of how to use AI effectively is interesting. I don't worry so much about the code it gives (outside of algorithmic and mathematical solutions, I haven't had much success), but I do like it as a way to generate potential solution strategies. When I give it a particular problem I'm having, it often gives 2-3 different ways I can go about solving it. It effectively works as a designer rubber duck that I can bounce ideas off and see what sticks. But I only feel confident with it because I have a coding background. I would feel nervous trying to make something complex work based off at-generated code alone.
For visual scripting and AI, the problem is that a beginner won't *see* the nasty traps before falling into them. You could easily get weeks or months into building out something that "runs" in-editor, but then gets 5fps on device. Or you realize you want to do something custom, or need to debug, and now you have no idea where to begin. That frustration could cause ppl to ragequit game-dev altogether. Better to just be slower to learn at first, but be more resilient long-term. I want to see an AI or Blueprints game (or app) that is supported for at least 1yr post-launch, incl bugfixes and maybe tweaking design or feature issues. At the enterprise level, we have to maintain codebases for 10, 20yrs - "it worked on my machine" is not gonna cut it 😅
But only if you need _really complex unusual tasks,_ which is way less likely given that you used visual scripting in the first place. Otherwise artist and programming rookies have all they practically need.
I deepened visual scripting in ue4 and ue5 for years, then moved to learn C++ and that is a powerful improvement. You can't get everything with visual scripting, especially if we consider memory management, efficiency, code readability and customization of classes.
Worst thing I did with AI, is when I wanted to add one directory to system path, and I input the path to AI and asked can you give me the full command for that in cmd..... it gave me answer, then I paste it and hit enter... and then I read what it said, and all of a sudden I got this feeling that... This does not look right... and then I asked, what did that line do... and AI said it REPLACED my system path with that directory... so... all of a sudden all system paths from my windows... were GONE!!!, and it took me a while to figure out how to get them back.... because if I reset... the computer is not going to even start in windows without those paths.... So, in the end, I found it easier to just do restore from previous windows restore, which I think was the previous day... :D
My 2¢... start with programming first, preferably in a friendly framework like raylib (there are tons of others). Starting with c or c++ will give you a solid jumping off point to any other language. And starting with a framework will teach you about the underpinnings of movement, image loading etc. completely transferable to any other engine. After that, pick whatever engine (I'm partial to unreal, even for 2d, but I'm a glutton for punishment) and go with the advice in the vid here. Grab a good tutorial series and make it your own.
I wouldn't call raylib a "friendly framework" for a complete newbie, lol libgdx is more friendly ( i know, i know, java) because you don't need to worry about memory leaks etc godot is even better, because it's an engine, it *works* extremely fast, it's tiny and you can use c# if necessary
@@Rai2M going to disagree there, I feel like understanding how to program and understanding things from the perspective of a framework (doesn't have to be raylib, there are many) before you hit up Godot, unreal, unity etc will give you a much better foundation to work with. In the long run the couple weeks or months you spend learning the basics will help you progress in the big game engines faster. Knowing the why in a godot tutorial is much better than just knowing which button to press. In the end, it all boils down to how you like to learn.
Hey, I am a single programmer. I have never used Copilot. I have looked at code for a functionality in ChatGPT, but only after I had written it myself. It was solid, with a few little bugs, but I doubt I had spotted them right away had I not implemented it myself first
The engine high key does not matter unless you are making a severe mistake like making 3d games in gamemaker or 2D games in unreal, if you learn to code in any engine you can transfer that knowledge to anywhere else. Its more important that you pick one and be persistent.
i followed part of some movement tutorial series and i think i did my own for most of it, i didn’t like their movement code, it felt super stiff, so i wrote my own. part of it i wrote it ahead, followed along just to see, and went back to my better feeling simpler code. i did use some and it was helpful, but yea don’t follow tutorials exactly, use it as a guide to help you approach things and do it in a way that feels better to you.
For learning, learn the basics (with UA-cam or Course) then try to do a project (a combat system) that you like, and now you will know what you don't know, what make your learning more specific and fun.
Missing the GDD document topic It's boring .. but it helps so much to specifiy what do you actually need and what do you want to make. If in GDD you write "I want shotgun" the idea to pull out of tutorial what you really want is much easier, and trap of "Copy Tutorial" is easier to avoid.
@@jackcarren8781 I agree, there are many games who have made a whole game just from blueprint, for ex cho cho charles, he didnt wrote a single line of c++
@@jackcarren8781 It's a question of optimization. I like blueprints, but doing some parts in c++ is necessarry for an optimized application since its much faster than blueprints.
LOL, I'm a DEV in a business environment (Not GameDev) and the most people I know don't like AI Codegeneration (OR Low/NO Code code generation), the only people pushing for it are the managers, that want to push out solutions faster, or the junior dev's, that used to copy&paste the first google result. 🤣 Probably it has to do with maintainability, coding preferences, sufficient knowhow, or simple that we are all to old for AI. 🤔
I'd never suggest unreal for a beginner. It's pretty but, you aren't making anything on it that will run on older machines, and the visual scripting is easy to learn but it takes 10 times longer to write programs with it. Plus, it just has SO much to learn, it's really meant for teams not individuals. On top of that, AI isn't as good at helping with unreal. If you're new ,don't try to do a teams worth of work. Plus, if you decide you need it after you've learend another engine, switching is not really all that hard.
Simple. You trick someone will the skill and enthusiasm to do what's needed, profit, then cut them out of the loop. Seems to be how 'successful entrepreneurs' operate.
If I were starting again I would use RPG maker, Manu, adventure game studio or Unreal with blueprints Coz after countless months of coding classes, I was still terrible at it.
and there’s something to be said about different engines working better or worse for different people. they all go about things differently and maybe what it pushes you towards works well for one person and bad for another.
I think a best idea if you tried doing a follow through tutorial and got stuck alot like me I would pick a mini game of like Mario Party level scope and strive to make that. Also I think Unreal is just as flexible as Unity with 2d you just have to learn how to do it, but that's just my opinion obviously.
No skills, no problem! WAGMI 😂 I say don't overthink it. Just buy a book for your engine of choice, one of those "for Beginners" types. The exercises are structured to build up in sequence, with plenty of explanations & tutorial code so you can figure out where you went wrong, or how you can go off-script. For Unity, they have those Unity Learn projects for specific topics, and minigame kits, like the kart racing one. Those are good if you want to just take a weekend (or few) and need visual feedback throughout the process.
I disagree on visual scripting point. Of course it has its downsides, but i think transferring knowledge from coding to vidual scripting isnt as hard as out made it out to be, because the logic tends to be ve very similar. It didnt take me long in the process before i could watch tutorials on specific programming languages and understand how to apply that to visual scripting, and massively successful devs like two star games use exclusively visual scripting as well.
But what about the reverse? When - not if - you need something custom or new that the visual scripting can't do (or doesn't handle well enough), can you translate those skills back to handcoding? I get that coding is a new skill and learning new skills can be intimidating & frustrating. But the benefits are that you will only be limited by your own ability and motivation, not what the visual-scripting tool creator deems appropriate.
@@mandisaw Yes, I have hand coded things and my experience visually scripting helped me immensely in understanding the logic behind it. I say this as someone who tried to pick up coding literally over dozens of times over the past decade and always failed. The only reason I have *any* skill in coding now is that visually scripting allowed me to dip my feet in and understand what was going on before going into the deep end. Every attempt to dive straight into coding failed for me, especially because I have clinical ADHD and just could not force myself to pick it up simply through sheer will. One could make the same argument about training wheels for toddlers. Sure, they don't teach you exactly how to ride a bike without them, but your kid might never even *want* to pick up a bike the regular way if they never have the chance to experience riding one with the training wheels. While training wheels might not be quite as versatile as a regular bike, they do allow you to get the gist of it and acquire some skills that certainly transfer to the real deal. And in the meantime, you get to have fun riding a bike while doing so. Edit: In addition, I could make this same point over game engines. Whichever engine you choose is going to have limits that you must stay within, and those limits are set by the creators of the engine, not you. Does that mean you should jump right in by creating your own engine? I'd wager most people would say no. A crucial skill in game dev is learning to work within the bounds you're currently within. The exact limits that visual scripting created forced me to think of creative ways around them. Some of those solutions are even helpful when I hand code things too. Problem solving within a set "box" in my opinion, is a large part of the heart of game dev. At the end of the day not everyone has the time to do programming full time, and everyone has different learning styles. Hand coding may be the best choice for some people, but to brush off visually scripting as objectively a worse choice just isn't an accurate statement. It has its pros and cons, just like anything.
@jyrig Your point about learning within constraints is well-made & well-taken! 👍 It's possible however, that you just weren't ready time- or skill-wise, in a good headspace, adequately prepped, etc before, but now you are. ADHD or no, the "you" who is trying to code now, is not the same "you" who tried each of those times before. Also, the training wheels analogy holds just as well for coding by hand. Not sure what approaches you were trying before, but a well-structured curriculum, building small ideas into more complex ones, is generally the best bet for most skills. If that's working for you now, the same kind of focused step-by-step approach would likely work across whatever other skills you decided to tackle. Just something to keep in mind as your game-dev journey continues 😄
@@mandisaw I think that's definitely possible. Could be that it wasn't the visual scripting alone, but rather the culmination of knowledge from my previous attempts. And I agree with your point on hand-coding within constraints as well, definitely a viable approach! I didn't mean to say that starting with hand-coding is the wrong approach, it's been the default for a long time now for good reason. Moreso just that visual scripting isn't a bad way to get into the craft as many game dev veterans would have people believe. It's definitely got its downsides, and certain engines have better options than others, but imho, it's a very underestimated option for a lot of people looking for a place to start.
@jyrig I would say it's more of a "be careful" type of warning, vs a "Never Do This" / "Visual Scripting is Trash" kind of thing. I've spoken to so many ppl online who have elaborate dream-game plans, and they get started with visual scripting, and it works really well for them... Except I can tell from their description of genre, mechanics, platform, etc that the visual tools are gonna fall short of their goal. And ppl underestimate just how disheartening and frustrating it can be to have to recreate their project in a totally different approach. Or even if they just need to make some custom nodes or whatever, and now suddenly have to learn like C++ or C# or shader-code after all, but now midway through the project. It's a totally cool way to get started understanding your engine, how game logic & assets work together, etc. And visual tools really shine at prototyping! But I had a guy say he was building an MMO in Blueprints, and I felt the need to try to save that dude from a world of pain & stress, y'know?
For my experience with Unreal, it doesn't like when do something that the engine was not made for, you will end up fighting the engine forever. Look at UE4 and UE5 games, if your game is too different you might be better with another engine. Otherwise, I think UE is superior and faster to make a game.
"I would just choose Unity" If you're making a big open world game, especially something procedurally generated. Unity ALWAYS runs poorly. The hitching while moving around the world, especially at high speed, is an engine-wide problem that is mostly not a problem that can be solved.
kinda strange to hear you guys denounce visual scripting like this when the creator of choo choo charles who is wildly successful has said you can make anything with blueprints. speaking as a programmer.
You can make an unoptimized app in blueprints which is slower than if you moved some parts into c++. Best way is to combine both methods. For some easier stuff blueprints are fine.
I've been in internship in Unreal with 3 school camarades, one of the best in my classes, their tasks were only in C++ and mine were only in blueprint. I delivered more than them reunited together. The thing is that blueprint can be slower than C++ in some cases. Also setting up the project with Visual Studio at first is long and a pain in the a**, but blueprint is just embedded in the engine. My production speed might also have to do that there is more resources in blueprint than in C++ in unreal, especially if you do custom features.
In my experience Ai does not put attention to optimisation, it is like a amateur-junior level. It uses list when it could use arrays. It does not care about scope neither, which lead to spaghetti code.
@@paluxyl.8682 Optimization. C++ is faster and some tasks better written in code while other parts can be written in Blueprints since the benefits are minimal compared to coding in these cases. You always want to write the most optimized code possible since every fps matters for players.
![Lp. Сердце Вселенной #60 РОЖДЕНИЕ ЛОЛОЛОШКИ [Финал] • Майнкрафт](http://i.ytimg.com/vi/YoR0pAV9FVQ/mqdefault.jpg)
Honestly... just start making stuff. Download an engine and play within it. Write stories. World build. Trial by fire is the best way to learn anything. Just get started and learn as you go. You may get so invested and find out it's for you OR you spend some time doing it but end up walking away entiely.
As always, it depends on what _"best"._ Trial by fire is best in its traction (output stickiness) and fun, but not in its fuel (time-effort input), acceleration, top speed, turning (flexibility and sunk cost), difficulty, safety (good habits and best practices), nor comprehensiveness. And it's terrible in its time-effort and safety.
E.g:
Books (refs, manual, research papers etc) is best in its top speed and comprehensiveness - terrible in its difficulty and fun.
Videos (podcast, blogs, tweets etc) is best in its fuel, early acceleration, and difficulty - terrible in its traction, late acceleration, and top speed.
Mentor (teacher, friends, experts etc) is best in its turning and safety - terrible in its... uh, price?
Courses (guides, maps(whatchamacallit?), resources etc) is best in its late acceleration - terrible in its turning.
...
Agree, all other approaches are clearly inferior.
@@DagarCoH Not really. You can invent your own method for some functionality by "trial by fire" after realizing months later that what you wanted to achieve was already implemented and part of the engine, you just had to tick one checkbox. You have to KNOW your engine first, not just mindlessly do things "trial by fire" way.
@@MNorbert89 Disagree, unless you think someone who plays around with the tools they have first will never bother to learn them properly, which is a dubious take. Both go hand in hand, but you are best off by trying and failing fast rather than burying your head in documentation and tutorial videos first, in my opinion, because the lessons you learn that way will stick much better.
I started out with a "full game course". The biggest thing I got from that was getting to touch all parts of the engine as part of making said game. At the end the "game was pretty crap, but I definitely knew how to find my way around the engine!
Thanks for sharing. The point you made about how learning your engine being very important resonates with me. I've been following tutorials and although not fully remembering how to do the exact thing they're showing, I'm getting more confident around the engine and familiar with certain parts. Slowly but surely getting better at game development.
you are actually always hitting the point on making videos that actually deliver a lesson
Game design is like making food.
You can follow a recipe and do it exactly, once you understand the ingredients you can make your own dish.
I think the way to actually start game development is to think of your game engine like a Lego toy. You find pieces which is the tutorial, engines, library that you would like to use. Then you think of what more you can do with the given pieces. It's like what you learn is Lego boxes with sample models. And your actual game development is like break down those models and combine them into something new.
This is how I start game development:
-I got a game I want to make or a game I can mod.
-I play around with coding and moding with it.
-Then I find out what more I can tweak and experiment with what I learn.
-After I learned enough, I thinking of a game project as a goal.
-Then it become a few months or a few week project.
My actual story:
When I was 14, I found a game called CS2D. I saw plenty of mods there. Around that time, I also learn coding in middle school. And so I dig through sample mods and find my way to create my own mod. I wasn't able to do everything I want but enjoyed making my own mod.
Years later I came back to that game with my college coding course I have learned. I was able to do everything my 14 years old wished back in the day.
Then I'm thinking of expanding the project and found the technical difficulty. That's when I was thinking of pick up a new game engine.
I pick up a new game engine with a game I want to make in mind. And so my game development journey has already been months and still going till today.
For someone with a decent computer who want to make 3d games, Unreal and use one of the template scenes (like the third person) that comes with the engine. The next steps are watch 4 tutorials ... first how to replace the SK Manequinn with an other character model, second how to place objects in the scene to make it more interesting, third how to create a goal in the game (could be walk from A to B, or collect 10 items to finish), fourth tutorial how to compile and publish it.
With this 4 steps it's possible even for beginners to make action adventures, walking simulators, 3d plattformers, or simple horror games (walking through a dark forrest or an old creepy mansion) without enemies.
Not sure if Unity comes with templates like Unreal does.
I just finished my Software Systems module in university and it gave me a new perspective on game development tbh
I'm interested, is this like designing various systems/mechanics first? can you elaborate a bit please :)
I had very little coding experience (Mechanical Engineering background). What I found was the most important thing to start making progress and having fun was learning and internalizing in gruesome precise detail how to reference scripts, how to communicate between scripts, and the differences and applications of different types of scripts. In my opinion courses and tutorials fail to emphasize this kind of stuff enough, and this is the biggest cause of "tutorial hell".
I think that you should do a video or at least try Godot 4.4 when it comes out of beta... because "Godot is not good for 3D" isn't true, and it hasn't been for a while
3:57 This is true. Most tutorial makers are not teaching they are making follow alongs
we would need more "why are we doing this or that and what do this line do" but most people looking at UA-cam for quick fix and don't want to watch extra minutes for explanations
Good advice . In my experience, bouncing development ideas off the AI is also the best, most productive way to use it for dev, at least currently. It's like having a partner to brainstorm and sanity check ideas.
It's pretty wild how effective AI is even for idea generation. I was messing around with DeepSeek and gave it a one line premise about my game RoadHouse Manager, to extrapolate on. I was blown away that a lot of the gameplay mechanics, themes and styles it generated where right on target for what was already in my game. It even nailed 100% two games that would be closet related for the gameplay style, which I often used before to describe to others before. And my game is fairly original as well, as games go.
@@gameboardgames AI is good at kickstarting ideas, but followthrough is all up to the developer.
As a hobbyist my approach has been picking an engine that I want to learn, even if it's not ideal for the game I'm currently working on. Getting deep knowledge in one tool is more efficient than trying to optimize the engine for a single game. I also use tutorials as a guideline to how to build a system, but then I completely modify it as I go to fit it into my current project. This ramps up the learning curve, because you are not mindlessly copying, but having to solve a lot of issues as you go, which requires much deeper thinking.
I would think starting with a business plan and figure out the who are customers, what do they want, and where are they would the best way in my opinion.
Makes your game dev goals clearer and measurable as you get starting with skill/tutorials, engines, game ideas, etc.
If you're literally "brand new", then commercial game-dev probably shouldn't even be on the radar yet. Certainly not until you've made a couple games and had at least friends & family check them out.
@mandisaw
Yeah, developing the skills to make the games is essential, but you still need a long-term goal in mind to push forward and motivate you. To do all the necessary work to make your game dev dreams come true.
@@Nubian_King_RNM It helps, for sure. But your goals are likely to change over the time it takes to build those skills. You'll see teens in school, or adults in a job-burnout crisis, say, "oh, I want to make games for a living!"
But then the reality hits of either their actual ability, productivity, or their game's reach, or their life situation, and they might want game-dev to play a different role. Totally natural.
@@mandisaw
True, but if you want it bad enough you'll find a way to make it happen come hell or high water.
I have been a professional developer for 25 years. I would absolutely suggest using visual scriptin when starting out, provided you are making a simple game like Pac-Man.
Someone once made a great observation: Programmers say everyone should learn coding, but they don't say everyone should learn pixel art or model building. It's a great point. I think you should learn everything, but there's no reason you have to learn it all upfront.
Honestly, I'm a programmer for an IT company and I still prefer blueprints in UE lol so I try to tell people to keep their mind open
When I was a kid [80s US], they actually did teach us all art, music, writing, drafting / design, and eventually, coding. The idea was that you should have some basic understanding of, and exposure to, how all those domains work, no matter where your talents & career might take you.
Generalism with 1 or 2 areas of specialization is a great thing.
@Rai2M , right, and even if you do outsource, it allows you to communicate more effectively about your needs.
Same situation for me and I would give the same advice. Coding is the superior approach, but if you have 0 coding background, learning to do it well enough to cover the needs for a whole game is a huge undertaking.
I would play around with something like blueprints instead, and when if I bump into something I couldn't achieve I would then ask a programmer (AI or real) to construct a it in a way that I myself could call it from blueprints.
The important thing is to understand how things work together. You need Legos that you comprehend enough to cobble together into what you ultimately want to build. Same as with code.
Alternatively you find an engine or framework that specializes in the exact genre you want and learn a very basic language like Ink or Lua to get the job done.
Hope this helps 👊
Heartbeast has great tutorials for beginners, he does a good job explaining what he’s doing in each step which is sooooo much better than a lot of tutorials
@@_gamma., HB is awesome, but unfortunately major changes in Godot make some of his older tutorials impossible to follow.
Id say the best way to start is knowing how to structure a project. Because if stuff starts to get too intertwined as a solo dev you arent going to want to refactor or fix it if your classes depends on each other too much. SO Id say start with a heavy, component based architecture. Because Imo even if its overkill for smaller projects it allows it to scale out the wahzoo in the future if you decide to do it. Also components are easier to pin point an issue, refactor, and add new features since it has a plug and play structure to it. Game dev is way funner when you dont have to worry every time you want to add a feature how it may effect 5 other features in the game. Gives you more freedom to change your mind mid way and not feel like youve wasted your time.
currently doing courses from stephen in udemy . Following courses/tutorials is fine as long as u replicate something similar on your own for each part of the tutorial .
There are no straight answers-just pick an engine, find a full-game tutorial, and start. I wanted to make a simple Battle Tank-style game as a precursor to my real project, so I tried Unity. But a persistent error caused 15-minute delays for every small update, like adjusting a hitbox. I figured either my setup wasn't compatible or I was missing something. This led me to explore GameMaker and Godot. In the end, I realized GameMaker, though pricier, was the best fit for my game. No one could have answered that for me-I had to find out by doing.
After one year I am almost done with my first game. It is far from a professional game but I have learned a lot. I did not started out with guides or tutorials. Just ask yourself what do you need. The first thing you probably want to do is walk around in a 3D game. So google (no I like to do it old school without AI) on how to do it. Now you maybe want to pick up a object. After this you want to create a inventory system so your object will be shown. And the object needs to be saved to. So now you have 4 steps that you can piece together and you know for a fact that you actually need it for your own game.
And if you can`t figure out how to make something. Try it again. And again. And again. It can take you hours or even days just to do only 1 step. If it really is too hard maybe you can try it again in the future if you have more experience. But don`t give up that easy!
I've had a dream of being a game developer for more than 10yrs now but resources has always been my roadblock and in this part of the world there's no much of a mentor on this subject yet so I've decided to focus on my job and save up for rhe time being but your videos always makes me go back and try to start something
I'm going suggest a small addition here. For people that have a hard time finding motivation to learn, one option that may work is to make small games and prototypes with the direct purpose of learning to make or implement specific mechanics useful to your dream game. It may not be the best or most efficient option, but can help if you need motivation.
kinda love when Thomas called Code Monkey as "Mister Monkey". 🤣
I loved to use GPT to find specific things. Like "I want to do [basic description of mechanic part] what can I use to make this?". With this I would get for example "You can use a loop or X or Y " and look things up while still trying to learn to implement it myself. Because my biggest issue was not knowing what is possible. And google doesn't really help all that much with very open questions. In the end I got somewhere, but I did notice I really suck at programming and rather find someone else to do it xD
Oh damn, didn't expect to see creeper world in this video.
Here's how I plan to learn gamedev, as a software dev who has been coding for a while now.
1. Follow along to a "make a game tutorial".
2. Branch off from that to experiment with things in the engine from something that works.
3. Read some docs (ew, but it's necessary)
4. Remake small games like pong, it's a fixed scope project.
5. Plan out a small game of your own
6. Explore how to do specific things you don't know (like a HP bar)
7. Take your knowledge from tutorials and exploration to implement your own game from scratch.
1. Visual Scripting is good to feel the flow of the program. What goes where, what is used over and over again. I remember doing charts like this in university in one class before Visual Scripting become a thing in UE. Some people just process information better visually.
2. Start by making your dream game or more accurately divide your dream game into key mechanics and make small games focused on that one mechanic. At the end you will have all the puzzle pieces, all infinity stones, to put into gauntlet.
3. Use AI to do boring stuff - documentation.
In my experience, if you are also interested in being able to make your own game art, I recommend starting with either 3D or 2D art. When making art you always end up learning more than 10 different programs and that gives you an ease in learning complex interfaces which will make the transition to an engine much easier and you can focus on programming, of course it is a longer path to make a game but you will end up with a range of useful skills
Unity is like "okay, let's spend 1.5 Gb of your drive memory on EMPTY new project and recompile everything every time when you change a single value in your code" and "you also need a really good PC, btw". Sounds nice ))
I come from a development background, so the question of how to use AI effectively is interesting. I don't worry so much about the code it gives (outside of algorithmic and mathematical solutions, I haven't had much success), but I do like it as a way to generate potential solution strategies. When I give it a particular problem I'm having, it often gives 2-3 different ways I can go about solving it. It effectively works as a designer rubber duck that I can bounce ideas off and see what sticks. But I only feel confident with it because I have a coding background. I would feel nervous trying to make something complex work based off at-generated code alone.
For visual scripting and AI, the problem is that a beginner won't *see* the nasty traps before falling into them. You could easily get weeks or months into building out something that "runs" in-editor, but then gets 5fps on device.
Or you realize you want to do something custom, or need to debug, and now you have no idea where to begin. That frustration could cause ppl to ragequit game-dev altogether. Better to just be slower to learn at first, but be more resilient long-term.
I want to see an AI or Blueprints game (or app) that is supported for at least 1yr post-launch, incl bugfixes and maybe tweaking design or feature issues. At the enterprise level, we have to maintain codebases for 10, 20yrs - "it worked on my machine" is not gonna cut it 😅
I'm making a game in ue5 and you can almost do everything in blueprints. Much less intimidating at first too
Yep, same here. 1 year in and a few different projects and no issues yet
Of course, but not really complex unusual tasks. This is where visual "coding" becomes a mess )
But only if you need _really complex unusual tasks,_ which is way less likely given that you used visual scripting in the first place. Otherwise artist and programming rookies have all they practically need.
I deepened visual scripting in ue4 and ue5 for years, then moved to learn C++ and that is a powerful improvement. You can't get everything with visual scripting, especially if we consider memory management, efficiency, code readability and customization of classes.
Worst thing I did with AI, is when I wanted to add one directory to system path, and I input the path to AI and asked can you give me the full command for that in cmd..... it gave me answer, then I paste it and hit enter... and then I read what it said, and all of a sudden I got this feeling that... This does not look right... and then I asked, what did that line do... and AI said it REPLACED my system path with that directory... so... all of a sudden all system paths from my windows... were GONE!!!, and it took me a while to figure out how to get them back.... because if I reset... the computer is not going to even start in windows without those paths.... So, in the end, I found it easier to just do restore from previous windows restore, which I think was the previous day... :D
Reason #5 why you can't trust genAI with your critical systems 😢
My 2¢... start with programming first, preferably in a friendly framework like raylib (there are tons of others). Starting with c or c++ will give you a solid jumping off point to any other language. And starting with a framework will teach you about the underpinnings of movement, image loading etc. completely transferable to any other engine. After that, pick whatever engine (I'm partial to unreal, even for 2d, but I'm a glutton for punishment) and go with the advice in the vid here. Grab a good tutorial series and make it your own.
I wouldn't call raylib a "friendly framework" for a complete newbie, lol
libgdx is more friendly ( i know, i know, java) because you don't need to worry about memory leaks etc
godot is even better, because it's an engine, it *works* extremely fast, it's tiny and you can use c# if necessary
@@Rai2M going to disagree there, I feel like understanding how to program and understanding things from the perspective of a framework (doesn't have to be raylib, there are many) before you hit up Godot, unreal, unity etc will give you a much better foundation to work with. In the long run the couple weeks or months you spend learning the basics will help you progress in the big game engines faster. Knowing the why in a godot tutorial is much better than just knowing which button to press. In the end, it all boils down to how you like to learn.
Hey, I am a single programmer. I have never used Copilot. I have looked at code for a functionality in ChatGPT, but only after I had written it myself. It was solid, with a few little bugs, but I doubt I had spotted them right away had I not implemented it myself first
The engine high key does not matter unless you are making a severe mistake like making 3d games in gamemaker or 2D games in unreal, if you learn to code in any engine you can transfer that knowledge to anywhere else. Its more important that you pick one and be persistent.
i followed part of some movement tutorial series and i think i did my own for most of it, i didn’t like their movement code, it felt super stiff, so i wrote my own. part of it i wrote it ahead, followed along just to see, and went back to my better feeling simpler code. i did use some and it was helpful, but yea don’t follow tutorials exactly, use it as a guide to help you approach things and do it in a way that feels better to you.
For learning, learn the basics (with UA-cam or Course) then try to do a project (a combat system) that you like, and now you will know what you don't know, what make your learning more specific and fun.
Missing the GDD document topic
It's boring .. but it helps so much to specifiy what do you actually need and what do you want to make.
If in GDD you write "I want shotgun" the idea to pull out of tutorial what you really want is much easier, and trap of "Copy Tutorial" is easier to avoid.
I am tired of these guys underestimating blueprints.
As a programming teacher, I can confirm that blueprints is as good if not better than regular programming in most circumstances.
@@jackcarren8781 I agree, there are many games who have made a whole game just from blueprint, for ex cho cho charles, he didnt wrote a single line of c++
@@jackcarren8781 It's a question of optimization. I like blueprints, but doing some parts in c++ is necessarry for an optimized application since its much faster than blueprints.
LOL, I'm a DEV in a business environment (Not GameDev) and the most people I know don't like AI Codegeneration (OR Low/NO Code code generation), the only people pushing for it are the managers, that want to push out solutions faster, or the junior dev's, that used to copy&paste the first google result. 🤣 Probably it has to do with maintainability, coding preferences, sufficient knowhow, or simple that we are all to old for AI. 🤔
I'd never suggest unreal for a beginner. It's pretty but, you aren't making anything on it that will run on older machines, and the visual scripting is easy to learn but it takes 10 times longer to write programs with it. Plus, it just has SO much to learn, it's really meant for teams not individuals. On top of that, AI isn't as good at helping with unreal. If you're new ,don't try to do a teams worth of work. Plus, if you decide you need it after you've learend another engine, switching is not really all that hard.
Simple. You trick someone will the skill and enthusiasm to do what's needed, profit, then cut them out of the loop. Seems to be how 'successful entrepreneurs' operate.
If I were starting again I would use RPG maker, Manu, adventure game studio or Unreal with blueprints Coz after countless months of coding classes, I was still terrible at it.
10:32 i think most engines can do most game styles fine
and there’s something to be said about different engines working better or worse for different people. they all go about things differently and maybe what it pushes you towards works well for one person and bad for another.
I think a best idea if you tried doing a follow through tutorial and got stuck alot like me I would pick a mini game of like Mario Party level scope and strive to make that. Also I think Unreal is just as flexible as Unity with 2d you just have to learn how to do it, but that's just my opinion obviously.
No skills, no problem! WAGMI 😂 I say don't overthink it. Just buy a book for your engine of choice, one of those "for Beginners" types. The exercises are structured to build up in sequence, with plenty of explanations & tutorial code so you can figure out where you went wrong, or how you can go off-script.
For Unity, they have those Unity Learn projects for specific topics, and minigame kits, like the kart racing one. Those are good if you want to just take a weekend (or few) and need visual feedback throughout the process.
Dont use unity bolt for a legit project... i make an fps on it and bolt is buggy and incomplete asf 🤮🤮🤮
Good vid 👍
I disagree on visual scripting point. Of course it has its downsides, but i think transferring knowledge from coding to vidual scripting isnt as hard as out made it out to be, because the logic tends to be ve very similar. It didnt take me long in the process before i could watch tutorials on specific programming languages and understand how to apply that to visual scripting, and massively successful devs like two star games use exclusively visual scripting as well.
But what about the reverse? When - not if - you need something custom or new that the visual scripting can't do (or doesn't handle well enough), can you translate those skills back to handcoding?
I get that coding is a new skill and learning new skills can be intimidating & frustrating. But the benefits are that you will only be limited by your own ability and motivation, not what the visual-scripting tool creator deems appropriate.
@@mandisaw Yes, I have hand coded things and my experience visually scripting helped me immensely in understanding the logic behind it.
I say this as someone who tried to pick up coding literally over dozens of times over the past decade and always failed. The only reason I have *any* skill in coding now is that visually scripting allowed me to dip my feet in and understand what was going on before going into the deep end. Every attempt to dive straight into coding failed for me, especially because I have clinical ADHD and just could not force myself to pick it up simply through sheer will.
One could make the same argument about training wheels for toddlers. Sure, they don't teach you exactly how to ride a bike without them, but your kid might never even *want* to pick up a bike the regular way if they never have the chance to experience riding one with the training wheels. While training wheels might not be quite as versatile as a regular bike, they do allow you to get the gist of it and acquire some skills that certainly transfer to the real deal. And in the meantime, you get to have fun riding a bike while doing so.
Edit: In addition, I could make this same point over game engines. Whichever engine you choose is going to have limits that you must stay within, and those limits are set by the creators of the engine, not you. Does that mean you should jump right in by creating your own engine? I'd wager most people would say no. A crucial skill in game dev is learning to work within the bounds you're currently within. The exact limits that visual scripting created forced me to think of creative ways around them. Some of those solutions are even helpful when I hand code things too. Problem solving within a set "box" in my opinion, is a large part of the heart of game dev.
At the end of the day not everyone has the time to do programming full time, and everyone has different learning styles. Hand coding may be the best choice for some people, but to brush off visually scripting as objectively a worse choice just isn't an accurate statement. It has its pros and cons, just like anything.
@jyrig Your point about learning within constraints is well-made & well-taken! 👍 It's possible however, that you just weren't ready time- or skill-wise, in a good headspace, adequately prepped, etc before, but now you are. ADHD or no, the "you" who is trying to code now, is not the same "you" who tried each of those times before.
Also, the training wheels analogy holds just as well for coding by hand. Not sure what approaches you were trying before, but a well-structured curriculum, building small ideas into more complex ones, is generally the best bet for most skills. If that's working for you now, the same kind of focused step-by-step approach would likely work across whatever other skills you decided to tackle. Just something to keep in mind as your game-dev journey continues 😄
@@mandisaw I think that's definitely possible. Could be that it wasn't the visual scripting alone, but rather the culmination of knowledge from my previous attempts. And I agree with your point on hand-coding within constraints as well, definitely a viable approach!
I didn't mean to say that starting with hand-coding is the wrong approach, it's been the default for a long time now for good reason. Moreso just that visual scripting isn't a bad way to get into the craft as many game dev veterans would have people believe. It's definitely got its downsides, and certain engines have better options than others, but imho, it's a very underestimated option for a lot of people looking for a place to start.
@jyrig I would say it's more of a "be careful" type of warning, vs a "Never Do This" / "Visual Scripting is Trash" kind of thing. I've spoken to so many ppl online who have elaborate dream-game plans, and they get started with visual scripting, and it works really well for them...
Except I can tell from their description of genre, mechanics, platform, etc that the visual tools are gonna fall short of their goal. And ppl underestimate just how disheartening and frustrating it can be to have to recreate their project in a totally different approach. Or even if they just need to make some custom nodes or whatever, and now suddenly have to learn like C++ or C# or shader-code after all, but now midway through the project.
It's a totally cool way to get started understanding your engine, how game logic & assets work together, etc. And visual tools really shine at prototyping! But I had a guy say he was building an MMO in Blueprints, and I felt the need to try to save that dude from a world of pain & stress, y'know?
You should do a livestream again soon. It has been so long
im pretty sure the first thing you do is lose your mind :P Cuz you gotta be crazy to be a dev
For my experience with Unreal, it doesn't like when do something that the engine was not made for, you will end up fighting the engine forever. Look at UE4 and UE5 games, if your game is too different you might be better with another engine. Otherwise, I think UE is superior and faster to make a game.
"I would just choose Unity" If you're making a big open world game, especially something procedurally generated. Unity ALWAYS runs poorly. The hitching while moving around the world, especially at high speed, is an engine-wide problem that is mostly not a problem that can be solved.
Don't make a big open world game my dude. -M
kinda strange to hear you guys denounce visual scripting like this when the creator of choo choo charles who is wildly successful has said you can make anything with blueprints. speaking as a programmer.
You can make an unoptimized app in blueprints which is slower than if you moved some parts into c++. Best way is to combine both methods. For some easier stuff blueprints are fine.
So basically, AI chats are for lonely people who don't have someone to bounce off ideas with.
@00:15 right' - I'm out! Great short vid today guys.
I've been in internship in Unreal with 3 school camarades, one of the best in my classes, their tasks were only in C++ and mine were only in blueprint. I delivered more than them reunited together. The thing is that blueprint can be slower than C++ in some cases. Also setting up the project with Visual Studio at first is long and a pain in the a**, but blueprint is just embedded in the engine. My production speed might also have to do that there is more resources in blueprint than in C++ in unreal, especially if you do custom features.
In my experience Ai does not put attention to optimisation, it is like a amateur-junior level. It uses list when it could use arrays. It does not care about scope neither, which lead to spaghetti code.
i'm so thankful for blueprints you don't even know
What's your opinion, is it possible to make a complete game from start to finish just with blueprints?
And what could be limits of blueprints ?
@@paluxyl.8682 i am doing exactly that. i haven't come across any limits of blueprints, but i hardly push systems to the limit
@@paluxyl.8682 It is possible, but it will give you waaaaay more headache with complex tasks than code
@@paluxyl.8682 Optimization. C++ is faster and some tasks better written in code while other parts can be written in Blueprints since the benefits are minimal compared to coding in these cases. You always want to write the most optimized code possible since every fps matters for players.
unreal blueprints destroys manual programming.
First xD
Like your videos guys ;)