Here is a quick summary of the 18 laws: Law 1: Never make your dream game; Use small games as a start Law 2: Finish projects at all cost; Iterate relentlessly Law 3: Reflect -> Evolve -> Post Mortem Law 4: Serve the player, Not oneself Law 5: Build games, not tech Law 6: Tools are for purpose, not for burden Law 7: Keep it simple stupid Law 8: Kill your darlings (Cut, Add & Adapt) Law 9: Don't fall in love with the outcome but fall in love with the progress Law 10: Specialize for mastery not mediocrity Law 11: Gamedev is greater than the sum of its parts Law 12: Befriend other gamedevs Law 13: Practice crushes theory (Make theory your side dish) Law 14: Never fully follow tutorials Law 15: Never relearn what you have already learnt Law 16: Resist grand temptations Law 17: Time equals money Law 18: Death of passion is death of gamedev Bonus Law: 80/20 rule
I would replace the following 2: Law 5: If you want to make games then don't create tools, but if you love making tools then show them off with games. Law 6: All tools are always a burden, but if you have the best tools then you have least burden.
I could easily add one more thing that kills most games in pre alpha: over or under engineering. Basically, before pre production you kind of know what the game is going to be, so use that to your advantage. If the game is just a puzzle game, that required basic shooting for 4 puzzles, then you wont need a complex, multi threaded, gpu parallelized, extensive weapon system that realistically calculates knock back, muzzle flash, weapon clogging, dirt accumulation in the barrel etc. On the other hand, if you have an fps shooter, then making a basic idle-shoot-hide enemy AI isnt gonna cut it, and the later you realize it, the worse. In that case it would actually be pretty smart to have a complex behavior tree with advanced decision making; thats what makes your AI noteworthy and challenging after all. Some would people say that pre production isnt meant to be too complex, but that it should rather deliver a MVP before anything else. And to be honest, look at yandere simulator. The developer had under engineered the students, and a decade later he is in a massive tech dept with unimaginably slow progress on the game. TL:DR, create according to your scope.
I'd say there are a few exceptions to listen to the player if the project is meant to be something very niche, since the general audience would probably have advice that is harmful to the overall game's ability to be what is intended, though that would probably be more useful if you were making a more general game.
No you are right, you should absolutely listen to the players, since they are the consumers. But it's important to not take all their words to heart and do what they say. An example of this is companies that listen too much on professionals in their games. Whilst that is great for the people that plays the game competetive, it becomes a split community and game for the casuals.
Very useful overall. Don't agree with 2 though; when Project isn't going anywhere and you have learned from doing it so far; stop and move on! Law 4: Early on serve yourself and dont worry about the player as early on is the stepping stones of development; think player once you can give them something worthwhile! Law 10: (think of your 80/20 rule here!) Mastery costs time and money, aim for Good Enough! Back to Law 2: Limited improvements through iteration is good. Iterating relentlessly leads to feeling of never good enough and again time costs money. Law 1: should add: Use small games as a start and build on your achievements working towards a viable releasable game. I am sure there are many other opinions, but I too have been in GameDev for many years.
I think law 1 is the most important one for new game devs. I tried starting making games three times in my life, twice I tried to make my dream game as my first game, and gave up because its too hard to make a dream game. Now for the past year I've been working on a game thats not my dream game, but an important stepping stone towards making my dream game, and because I started with making a non dream game, Im on my way to starting a carreer in games.
Awesome to hear! Yeah these things often gets explained to us the hard way. It’s never about the fact that you should never make your dream game, it’s that you should be very prepared before doing so.
Sorry but these are totally not laws, even if they are generally good advice. A law should be something that is true regardless of situation, so for example there are many very successful 'generalist' game devs so your law 10 isn't a law at all (I don't even agree with that one at all).
I respect your point, and I agree that repetition can be important to grasp things and gain knowledge. What I do want to highlight is the issue I’ve seen, especially in game dev-people (myself included) redoing the same project or feature repeatedly because we’ve learned something new, and then getting stuck in a cycle. The challenge is to avoid getting caught in endless rework, which can keep you from making real progress.
Repeating is about solidifying knowledge, not expanding. Not the best with a practice that needs many hats, unless you have an intentional improvement plan. For example, I built a game of a bad unity tutorial. Rn I'm trying to use what I've learned to "follow" the tutorial without using the same code. This skill is one that can allow any tutorial to be used and me understanding how to use the code, and make it clean and fixable. After that, I will make a good Unity tutorial about it, which will allow a deeper understanding, and build devlog skill. Then, make the game following my new tutorial in Godot, to gain the ability to use even tutorials for other engines or without code, and build them. Then make the final video. Godot is a newer game engine that changes constantly, and I plan to build onto the default engine. These combine to limit the amount of help I can get. So the ability to use help regardless of if it matches my techstack, and avoid tutorial hell.
repetition consolidates knowledge better the greater the gap between repetitions. so finishing projects then repeating the same skills in the next project gives you both a greater gap between repetitions so your brain has to work harder to make those connections and also gives you practice doing the other parts of the project / learning how the skill you’re working on relates to all those parts
Regarding the KISS principle, I feel like I'm the exception to this rule. Whenever I sacrifice structure for getting things done faster and more simple, everything just falls apart once I'm about to introduce a new feature that the current code wasn't made to accomodate for. Possibly the main reason I hate game jams.
Excellent advice! Knowing is different from having internalized it. I think i had to make all the mistakes to go from knowing about this to following most of it. And i think that made all the difference in transitioning from "i'm making yet again a game where my ambition vastly overshadows my skill and i'll abandon it when it reaches 20% finished and the exciting bits are done" to "hey i'm actually finishing reasonably scoped games" :D
Completely agree with ditching the idea of a "dream game." Everyone wants to make their "dream game" and then expect to sell a million copies of it. That's just a fantasy. I think it's better to find a way to make smaller projects really cool. Like making a simple, small scale game but have a really cool character design or a really cool premise that you really like.
Absolutely. Well the biggest issue with making your dream game is that it’s hard to set boundaries and specific goals for when it is done. You will often get in a rut of just keep making and never finalizing
I'm in my twenties and have reached a crossroads where I need to decide what to pursue full-time with complete focus. Should I follow my passion for game development, or focus on web development for financial stability?. Thank you :}
It’s really hard to answer that question for you, weight the pros and cons and see what makes more sense. What I can contribute with is that gamedev is not an “unstable financial market” anymore, it makes more than movies and music combined per year, it’s just difficult to get into. Also, you are not set for life with your decision, see it as seasons instead, you can try gamedev for a few years, and if you don’t like how it’s going, you can always do something else :)
@@oskar_schramm, Thank you so much! I will try for a year; let's see how it goes. Thank you for the quick reply. I look forward to more content from you! :)
@@oskar_schramm I laughed because the way you present it, it appears to me that the phrase implies that no one should ever make the gamer of their dreams :) . But I know you meant "as the first project"
a lot of solid advice, but there's an old gamasutra article about gamedev & post-mortems from before 2015 I think, couldn't find it online, apparently it's gone, where they basically combed through post-mortems, and found that for every team that benefited from doing 1 thing, another team benefited from doing the opposite. You have to balance law 2 against law 1, you have to balance law 13 against the fact that obviously you still need some theory (you never want to spend 150h learning a lesson that's explained on page 2 of a common theory article), and I think law 15 can be balanced against laws 2&3&10 (iteration & specialization are in fact super valuable). Also the 80/20 rule isn't technically real, it's just a pattern that shows up sometimes (there was a debunk video on that at some point lol). Rest is generally solid tho :3 edit: someone actually made a full study of >150 postmortems now :D edit2: actually the study is not very good lol
Hey thanks, interesting about the post mortem studies, should’ve read up on that. Nice additions to the conversation as well! There are always exceptions, this is just generalized things that most people should follow. I’m not saying everything works for everyone, that would be impossible to state.
Law 4 can be misinterpreted as "the player won't see the source code, so it's okay if it's messy," which is utterly wrong. I think it would be better to rephrase it so people don't take it the wrong way.
Why, that is true. It's not optimal, but it's fine if you can manage it. Undertale has some really miserable code, but the creator delivered and the game has no game-breaking bugs.
This is covered elsewhere, but the "utterly wrong" way to take it is absolutely right. Messy code that works is infinitely more valuable than a perfectly organised code structure that's only missing the implementation. There are benefits to having your code be elegant, readable, or conform to commonly accepted standards. All else being equal, if you could write the same function in the same time and you have to decide if it should be messy or not, you'd pick the clean solution every time. But those time savings are useless if they don't actually produce a game. If your planning or refactoring takes much longer than the quick and dirty option, you'll probably never break even on the delay it caused.
I hear people talk about how much money it takes to make a game . Like what the assts ? Not if you make them yourself. Paying people? not if you make the game yourself . I get like paying somebody to make music and sound effects I get advertising
Well if you are serious about any product you will have professionals in each regard do their thing, and pay them salary or outsourcing. Of course one can do everything themselves, but then the scope becomes smaller, and the time horizon longer. The new AAA games can't be made by 1 person, but a fun indie game can.
If you make them yourself, then the cost is still the time opportunity cost to make it. How much money are you not making by working a job during that time? That is your opportunity cost. Your time isn't free, that is a lie people tell themselves to avoid the realization of how much it really cost them.
@@AdroitConceptions I am disabled and do not have a job . My disabilities make it difficult to do any job safely . Now when I get programming down I may be able to get a job and because of my social security benefits I have to get a job where there is no question that I will make $70,000 a year .As far as social security I could replace the money . Like I said my programming skills are not up to par
@@therabidpancake1 what I said is true in the general case, it sounds like your in an exception situation because your considered disabled and getting disability benefits. That still creates an issue for you, if you make money by selling a game, it could cause you to loose your benefits, so if it is as you say, your time is probably worth a good $50/hour. If you end up making money from your game(s), that is likely where you would need to be if you lost your benefits (yes that works out higher then the $70k/year you said, self employment taxes/etc are higher then those when working a job)
Really solid advice. I do not agree with "lot small projects" though, because this is not how the all time greats did it. Minecraft and Stardew Valley were not made by guys who did millions of small projects. They did however finish the one thing they started.
those guys who made minecraft stardew already have experience of making small project thats the reason they have learned skills to make big games. 'lot of small projects' is a good rule, every new game dev should follow small project rules to build skills of debugging, solving bugs,glitches,errors,mistakes before thinking of making gta or coll of duty type games, small project means making games which can be completed in weeks to few months , like flappy birds,ludo etc . which helps to build skills. and later on build more complex and bigger games. otherwise it will like studying in high schools and trying to solve quantam mechanics equation.
There absolutely comes a point, where you should make a bigger game, but getting to that point is way further away than most people think/want to to be.
I make tutorials for the small engine I use and I get questions from people that dont want to do the small projects. They just want to make a mmo. Or they want to make the next minecraft, but they lack the experience to even start. Yet no advice is good enough. At the end of the day you need to learn and master your tools. The best way to do that is to grind small projects. Otherwise you will just have a big dream and no way to realize it.
@@loxaevion I think where the discussion goes wrong is: The size of the project is an issue of workload, knowledge, consistency and timeframe for the first rewards vs relevance to goals. If a person wants to develop a 3D MMO they haven't understood the workload/requirements of it. Lets say 5 years of a team of a least 20 people full time. That would mean either 8hrs x 255 workdays x 5 x 20 (for people) then you get 320k workhours (not accounting for needing to learn skills). You can try to do this in 100 years or look for something that is more measurabel. When people answer this question with "start small" it sound more like someone wants to sell your their religion . Do this analysis with Stardew Valley, you get 5 years of daily 12 hrs = 15.3k work hours. Working hours is an insanely consistent (though not the hole truth) measurement. Picking a type of workload with a suiting example I think works better in communication. Not everybody likes flappy birds. I for example hate tetris. If someone tells me to code tetris I choose the corporate 9 to 5 job over that. Gauntlet or roguelike? Maybe more. But that is just me.
there are few things I would disagree about. For instance: "never make your dream game" NEVER? Then fuck all this gamedev. I came here to chew bubble gum and make my dreams come true, and I'm all out of bubblegum. Sure, I have to level up by killing the skeletons and goblins, but NEVER???...NEVER! Some of yr advice is cool, like always finish a project. I would add that you should finish for the sake of finishing. So that you would become a person which ships the product. You start to deliver. Finish the project even when it is not perfect. Anyway I will stop typing now, I gotta project to finish, bye!
He implies it as "your first game shouldn't be your dream game", when he talks about us imagining ourselves as level 1 players who are trying to go against the boss. So it isn't "never", it's when we are at an appropriate level we can try it out. "Don't make your dream game for the first couple of projects" just doesn't sound as snappy.
Toby Fox followed these rules. Toby worked with Temmie Chang, he did make some small earthbound hacks before he undertook Undertale. He loves making the games, and he doesn't have any unnecessary features.
Fun fact when I was bigger Ther it's person that have learn my the biscis for code's. But indeed copy and paste exactly what this person tall my I mixed max this line's the talld my and this person have impressed 😁. It's not that I have made completely code back I don't know most off codeing back then but wean I code instead of fallow the tutorial later be later I I just what the saying and after that I experiment in what other way I able to use those function's. And this 💯 work's not only that I use this method out site off code for example thi unity have system that call line rendering I have figured out that this system works perfectly for billboard's even thins system disaing for rops and lasers it works perfectly for billboard's so I use it.
I did not quite get what you meant with this comment, but did you mean that copy-pasting and then tweaking lead to better understanding? I think that it depends, but game code in magazine is something that used to exist and helped people get started making games. So I agree that you should look at how other game dev do things and play/remix/etc those snippets for your own goals. Have a great day :D
@@raphaeld9270 yes that's what I'm saying the person have told the basics. have impressed that after copy what it's i have started tweaking the code in the order to understand more about codes.
Copy pasting and then adjusting or backwards engineering is generally a really great way to learn! The problem comes when we just copy paste things we don’t really try to understand or know what they do.
Smaller projects will never give you the skills required to build a large project. So starting with a dream game is the quickest way to understand programming and game design. Just don't do produce graphics till you have gameplay complete. Same with caring about customers: if you are making your dream project, you're the customer, so you dont need any market research.
I agree with the point you made that smaller games won’t give you the experience to work in a big production/longer game, but I really don’t think making your dream game is a good idea. But what I do think is smart, is working your way up like a staircase. Not all your games have to be small, but start small and build bigger and bigger projects and after getting comfortable with many smaller projects, you can and should take on that bigger project (that still isn’t your dream game imo)
Is your latter point sarcastic or do you actually believe you don't need any market research if you make what you want to make? Question: how many games have you shipped this way?
@@jurvanoerle2845 I think they mean that if you are making a game for a market of one (yourself), then you only need to research that single person market. But I think that finishing many things is often more motivating and allows for more learning than to potentially finish a single big thing.
the best thing is just a group of passionists, visionist, artists, ritualists, writers,... goes to game dev school. And this school needs to be at your near local school place of curse
![BOWKYLION - วิงวอน (ex-change) [Official MV]](http://i.ytimg.com/vi/cLdnZWDaO-w/mqdefault.jpg)
Here is a quick summary of the 18 laws:
Law 1: Never make your dream game; Use small games as a start
Law 2: Finish projects at all cost; Iterate relentlessly
Law 3: Reflect -> Evolve -> Post Mortem
Law 4: Serve the player, Not oneself
Law 5: Build games, not tech
Law 6: Tools are for purpose, not for burden
Law 7: Keep it simple stupid
Law 8: Kill your darlings (Cut, Add & Adapt)
Law 9: Don't fall in love with the outcome but fall in love with the progress
Law 10: Specialize for mastery not mediocrity
Law 11: Gamedev is greater than the sum of its parts
Law 12: Befriend other gamedevs
Law 13: Practice crushes theory (Make theory your side dish)
Law 14: Never fully follow tutorials
Law 15: Never relearn what you have already learnt
Law 16: Resist grand temptations
Law 17: Time equals money
Law 18: Death of passion is death of gamedev
Bonus Law: 80/20 rule
I would replace the following 2:
Law 5: If you want to make games then don't create tools, but if you love making tools then show them off with games.
Law 6: All tools are always a burden, but if you have the best tools then you have least burden.
mfw my small game still becomes a dream game on paper even when I deliberately design small and constrain myself
it should become a real book possible
"Finish projects at all costs"
ADHD: "lol. good luck at that"
I could easily add one more thing that kills most games in pre alpha: over or under engineering.
Basically, before pre production you kind of know what the game is going to be, so use that to your advantage. If the game is just a puzzle game, that required basic shooting for 4 puzzles, then you wont need a complex, multi threaded, gpu parallelized, extensive weapon system that realistically calculates knock back, muzzle flash, weapon clogging, dirt accumulation in the barrel etc.
On the other hand, if you have an fps shooter, then making a basic idle-shoot-hide enemy AI isnt gonna cut it, and the later you realize it, the worse. In that case it would actually be pretty smart to have a complex behavior tree with advanced decision making; thats what makes your AI noteworthy and challenging after all.
Some would people say that pre production isnt meant to be too complex, but that it should rather deliver a MVP before anything else. And to be honest, look at yandere simulator. The developer had under engineered the students, and a decade later he is in a massive tech dept with unimaginably slow progress on the game.
TL:DR, create according to your scope.
Yandere dev has more issues than just under engineering the students lmao. Some people are just not very good
Absolutely a great one. It’s the same concept as premature optimization.
I appreciate what you said about not following tutorials. Ive introduced a ton of issues in my projects by following tutorials exactly. Great vid man
I'd say there are a few exceptions to listen to the player if the project is meant to be something very niche, since the general audience would probably have advice that is harmful to the overall game's ability to be what is intended, though that would probably be more useful if you were making a more general game.
No you are right, you should absolutely listen to the players, since they are the consumers. But it's important to not take all their words to heart and do what they say.
An example of this is companies that listen too much on professionals in their games.
Whilst that is great for the people that plays the game competetive, it becomes a split community and game for the casuals.
Very useful overall. Don't agree with 2 though; when Project isn't going anywhere and you have learned from doing it so far; stop and move on! Law 4: Early on serve yourself and dont worry about the player as early on is the stepping stones of development; think player once you can give them something worthwhile! Law 10: (think of your 80/20 rule here!) Mastery costs time and money, aim for Good Enough! Back to Law 2: Limited improvements through iteration is good. Iterating relentlessly leads to feeling of never good enough and again time costs money. Law 1: should add: Use small games as a start and build on your achievements working towards a viable releasable game. I am sure there are many other opinions, but I too have been in GameDev for many years.
this just makes me cry out of sadness
I think law 1 is the most important one for new game devs.
I tried starting making games three times in my life, twice I tried to make my dream game as my first game, and gave up because its too hard to make a dream game.
Now for the past year I've been working on a game thats not my dream game, but an important stepping stone towards making my dream game, and because I started with making a non dream game, Im on my way to starting a carreer in games.
Awesome to hear! Yeah these things often gets explained to us the hard way. It’s never about the fact that you should never make your dream game, it’s that you should be very prepared before doing so.
Sorry but these are totally not laws, even if they are generally good advice. A law should be something that is true regardless of situation, so for example there are many very successful 'generalist' game devs so your law 10 isn't a law at all (I don't even agree with that one at all).
I disagree on redoing stuff. I really consolidate knowledge by repeating.
I respect your point, and I agree that repetition can be important to grasp things and gain knowledge.
What I do want to highlight is the issue I’ve seen, especially in game dev-people (myself included) redoing the same project or feature repeatedly because we’ve learned something new, and then getting stuck in a cycle. The challenge is to avoid getting caught in endless rework, which can keep you from making real progress.
Repeating is about solidifying knowledge, not expanding. Not the best with a practice that needs many hats, unless you have an intentional improvement plan.
For example, I built a game of a bad unity tutorial. Rn I'm trying to use what I've learned to "follow" the tutorial without using the same code. This skill is one that can allow any tutorial to be used and me understanding how to use the code, and make it clean and fixable. After that, I will make a good Unity tutorial about it, which will allow a deeper understanding, and build devlog skill. Then, make the game following my new tutorial in Godot, to gain the ability to use even tutorials for other engines or without code, and build them. Then make the final video.
Godot is a newer game engine that changes constantly, and I plan to build onto the default engine. These combine to limit the amount of help I can get. So the ability to use help regardless of if it matches my techstack, and avoid tutorial hell.
repetition consolidates knowledge better the greater the gap between repetitions. so finishing projects then repeating the same skills in the next project gives you both a greater gap between repetitions so your brain has to work harder to make those connections and also gives you practice doing the other parts of the project / learning how the skill you’re working on relates to all those parts
I love topics and discussions about game dev practices. Thanks for your contribution.
Regarding the KISS principle, I feel like I'm the exception to this rule. Whenever I sacrifice structure for getting things done faster and more simple, everything just falls apart once I'm about to introduce a new feature that the current code wasn't made to accomodate for. Possibly the main reason I hate game jams.
Excellent advice!
Knowing is different from having internalized it. I think i had to make all the mistakes to go from knowing about this to following most of it. And i think that made all the difference in transitioning from "i'm making yet again a game where my ambition vastly overshadows my skill and i'll abandon it when it reaches 20% finished and the exciting bits are done" to "hey i'm actually finishing reasonably scoped games" :D
Thanks! Yes, that’s the trap of gamedev for you there, and I have done it SOO many times that I feel the duty to really try to bring it forward
I feel called out by almost all of the 18 laws here lol
It’s alright, most of us do. That’s the title of the video after all 😅
Law 1: you have to fail to be able to accept step back...
That’s a law to life
Thanks, your video came in handy, as I start my first "Big" game project atm. Thanks for your advice :)
Big projects are fun because they are so rewarding, it’s just hard to finalize them and keep the vision intact. Best of luck to your project!
Completely agree with ditching the idea of a "dream game." Everyone wants to make their "dream game" and then expect to sell a million copies of it. That's just a fantasy. I think it's better to find a way to make smaller projects really cool. Like making a simple, small scale game but have a really cool character design or a really cool premise that you really like.
Absolutely. Well the biggest issue with making your dream game is that it’s hard to set boundaries and specific goals for when it is done. You will often get in a rut of just keep making and never finalizing
I'm in my twenties and have reached a crossroads where I need to decide what to pursue full-time with complete focus. Should I follow my passion for game development, or focus on web development for financial stability?. Thank you :}
It’s really hard to answer that question for you, weight the pros and cons and see what makes more sense.
What I can contribute with is that gamedev is not an “unstable financial market” anymore, it makes more than movies and music combined per year, it’s just difficult to get into.
Also, you are not set for life with your decision, see it as seasons instead, you can try gamedev for a few years, and if you don’t like how it’s going, you can always do something else :)
@@oskar_schramm, Thank you so much! I will try for a year; let's see how it goes. Thank you for the quick reply. I look forward to more content from you! :)
19: Run from people who say NEVER
13:58 turoials
please write outside of a video editor, turning on spell check would be a bonus.
I'm making my dreamgame and nothing else will do ;)
Go hard!
i follow all these rules, im chilling
Blue snowball my beloved 💋
And now realize that u can apply all the tips to your life... that's too good to be truth, isn't it? =)
I'd keep my dream game to myself. Make other games for people that would enjoy them.
uh Law 1: NEVER make your dream game... NEVER EVER lol
Well, majority of people should follow that advice. There are ofcourse exceptions
@@oskar_schramm I laughed because the way you present it, it appears to me that the phrase implies that no one should ever make the gamer of their dreams :) . But I know you meant "as the first project"
How did you noise cancel for blue snowball?
I don’t, it’s because I have it so close to my mouth :)
a lot of solid advice, but there's an old gamasutra article about gamedev & post-mortems from before 2015 I think, couldn't find it online, apparently it's gone, where they basically combed through post-mortems, and found that for every team that benefited from doing 1 thing, another team benefited from doing the opposite. You have to balance law 2 against law 1, you have to balance law 13 against the fact that obviously you still need some theory (you never want to spend 150h learning a lesson that's explained on page 2 of a common theory article), and I think law 15 can be balanced against laws 2&3&10 (iteration & specialization are in fact super valuable). Also the 80/20 rule isn't technically real, it's just a pattern that shows up sometimes (there was a debunk video on that at some point lol). Rest is generally solid tho :3 edit: someone actually made a full study of >150 postmortems now :D edit2: actually the study is not very good lol
Hey thanks, interesting about the post mortem studies, should’ve read up on that. Nice additions to the conversation as well!
There are always exceptions, this is just generalized things that most people should follow. I’m not saying everything works for everyone, that would be impossible to state.
Law 4 can be misinterpreted as "the player won't see the source code, so it's okay if it's messy," which is utterly wrong. I think it would be better to rephrase it so people don't take it the wrong way.
Why, that is true. It's not optimal, but it's fine if you can manage it. Undertale has some really miserable code, but the creator delivered and the game has no game-breaking bugs.
the code doesn't matter the players at all if the game runs it runs
This is covered elsewhere, but the "utterly wrong" way to take it is absolutely right. Messy code that works is infinitely more valuable than a perfectly organised code structure that's only missing the implementation. There are benefits to having your code be elegant, readable, or conform to commonly accepted standards. All else being equal, if you could write the same function in the same time and you have to decide if it should be messy or not, you'd pick the clean solution every time. But those time savings are useless if they don't actually produce a game. If your planning or refactoring takes much longer than the quick and dirty option, you'll probably never break even on the delay it caused.
KISS is my biggest hurtle
Haha yeah, a classic one! You will learn with experience.
very good
I hear people talk about how much money it takes to make a game . Like what the assts ? Not if you make them yourself. Paying people? not if you make the game yourself . I get like paying somebody to make music and sound effects I get advertising
Well if you are serious about any product you will have professionals in each regard do their thing, and pay them salary or outsourcing.
Of course one can do everything themselves, but then the scope becomes smaller, and the time horizon longer.
The new AAA games can't be made by 1 person, but a fun indie game can.
@@oskar_schramm I bet you a aaa game could be made by one person but they would have to be one bad ass person.
If you make them yourself, then the cost is still the time opportunity cost to make it. How much money are you not making by working a job during that time? That is your opportunity cost.
Your time isn't free, that is a lie people tell themselves to avoid the realization of how much it really cost them.
@@AdroitConceptions I am disabled and do not have a job . My disabilities make it difficult to do any job safely . Now when I get programming down I may be able to get a job and because of my social security benefits I have to get a job where there is no question that I will make $70,000 a year .As far as social security I could replace the money . Like I said my programming skills are not up to par
@@therabidpancake1 what I said is true in the general case, it sounds like your in an exception situation because your considered disabled and getting disability benefits.
That still creates an issue for you, if you make money by selling a game, it could cause you to loose your benefits, so if it is as you say, your time is probably worth a good $50/hour. If you end up making money from your game(s), that is likely where you would need to be if you lost your benefits (yes that works out higher then the $70k/year you said, self employment taxes/etc are higher then those when working a job)
Really solid advice. I do not agree with "lot small projects" though, because this is not how the all time greats did it. Minecraft and Stardew Valley were not made by guys who did millions of small projects. They did however finish the one thing they started.
That’s not true, you simply don’t know about their small projects.
those guys who made minecraft stardew already have experience of making small project thats the reason they have learned skills to make big games. 'lot of small projects' is a good rule, every new game dev should follow small project rules to build skills of debugging, solving bugs,glitches,errors,mistakes before thinking of making gta or coll of duty type games, small project means making games which can be completed in weeks to few months , like flappy birds,ludo etc . which helps to build skills. and later on build more complex and bigger games. otherwise it will like studying in high schools and trying to solve quantam mechanics equation.
There absolutely comes a point, where you should make a bigger game, but getting to that point is way further away than most people think/want to to be.
I make tutorials for the small engine I use and I get questions from people that dont want to do the small projects. They just want to make a mmo. Or they want to make the next minecraft, but they lack the experience to even start. Yet no advice is good enough. At the end of the day you need to learn and master your tools. The best way to do that is to grind small projects. Otherwise you will just have a big dream and no way to realize it.
@@loxaevion I think where the discussion goes wrong is: The size of the project is an issue of workload, knowledge, consistency and timeframe for the first rewards vs relevance to goals.
If a person wants to develop a 3D MMO they haven't understood the workload/requirements of it. Lets say 5 years of a team of a least 20 people full time. That would mean either 8hrs x 255 workdays x 5 x 20 (for people) then you get 320k workhours (not accounting for needing to learn skills). You can try to do this in 100 years or look for something that is more measurabel.
When people answer this question with "start small" it sound more like someone wants to sell your their religion .
Do this analysis with Stardew Valley, you get 5 years of daily 12 hrs = 15.3k work hours.
Working hours is an insanely consistent (though not the hole truth) measurement.
Picking a type of workload with a suiting example I think works better in communication. Not everybody likes flappy birds. I for example hate tetris. If someone tells me to code tetris I choose the corporate 9 to 5 job over that. Gauntlet or roguelike? Maybe more. But that is just me.
NOICE
there are few things I would disagree about. For instance: "never make your dream game" NEVER? Then fuck all this gamedev. I came here to chew bubble gum and make my dreams come true, and I'm all out of bubblegum. Sure, I have to level up by killing the skeletons and goblins, but NEVER???...NEVER! Some of yr advice is cool, like always finish a project. I would add that you should finish for the sake of finishing. So that you would become a person which ships the product. You start to deliver. Finish the project even when it is not perfect. Anyway I will stop typing now, I gotta project to finish, bye!
He implies it as "your first game shouldn't be your dream game", when he talks about us imagining ourselves as level 1 players who are trying to go against the boss. So it isn't "never", it's when we are at an appropriate level we can try it out. "Don't make your dream game for the first couple of projects" just doesn't sound as snappy.
Wut about Toby Fox
Toby Fox followed these rules. Toby worked with Temmie Chang, he did make some small earthbound hacks before he undertook Undertale. He loves making the games, and he doesn't have any unnecessary features.
@@mollengaming9187 also Deltarune is his dream game. Not Undertale. If I remember correctly
@@hiiamelecktro4985 Yep, that's entirely correct, thanks for correcting me!
Fun fact when I was bigger
Ther it's person that have learn my the biscis for code's.
But indeed copy and paste exactly what this person tall my I mixed max this line's the talld my and this person have impressed 😁.
It's not that I have made completely code back I don't know most off codeing back then but wean I code instead of fallow the tutorial later be later I I just what the saying and after that I experiment in what other way I able to use those function's.
And this 💯 work's not only that I use this method out site off code for example thi unity have system that call line rendering I have figured out that this system works perfectly for billboard's even thins system disaing for rops and lasers it works perfectly for billboard's so I use it.
I did not quite get what you meant with this comment, but did you mean that copy-pasting and then tweaking lead to better understanding?
I think that it depends, but game code in magazine is something that used to exist and helped people get started making games.
So I agree that you should look at how other game dev do things and play/remix/etc those snippets for your own goals.
Have a great day :D
@@raphaeld9270 yes that's what I'm saying the person have told the basics.
have impressed that after copy what it's i have started tweaking the code in the order to understand more about codes.
Copy pasting and then adjusting or backwards engineering is generally a really great way to learn! The problem comes when we just copy paste things we don’t really try to understand or know what they do.
Smaller projects will never give you the skills required to build a large project. So starting with a dream game is the quickest way to understand programming and game design. Just don't do produce graphics till you have gameplay complete. Same with caring about customers: if you are making your dream project, you're the customer, so you dont need any market research.
I agree with the point you made that smaller games won’t give you the experience to work in a big production/longer game, but I really don’t think making your dream game is a good idea.
But what I do think is smart, is working your way up like a staircase. Not all your games have to be small, but start small and build bigger and bigger projects and after getting comfortable with many smaller projects, you can and should take on that bigger project (that still isn’t your dream game imo)
Is your latter point sarcastic or do you actually believe you don't need any market research if you make what you want to make? Question: how many games have you shipped this way?
@@jurvanoerle2845 I think they mean that if you are making a game for a market of one (yourself), then you only need to research that single person market.
But I think that finishing many things is often more motivating and allows for more learning than to potentially finish a single big thing.
@@raphaeld9270 a that makes sense. In that case, I apologize for coming off so harsh
the best thing is just a group of passionists, visionist, artists, ritualists, writers,... goes to game dev school. And this school needs to be at your near local school place of curse
📌New Discord server for anyone intersted
discord.gg/5KKGX4wxGk