On marketing: For those that don't have any commercial aspiration for their game, it's still worth considering how you will feel at the end of the project if no one plays your game (beyond friends and family). Some are lucky enough to almost exclusively be driven by internal motivation, but I imagine that many people desire to have the world around them acknowledge them and their achievements in some way. Marketing doesn't need to be time-consuming and tedious - it's fine to create a good Steam page, make a fun demo, enroll in festivals and email youtubers/streamers.
3 main motivations: profiting, sharing, making. Profiting is the *[Hard]* difficulty, while making is the *[Easy].* _"0 players? Mostly negative? Who cares."_
@@ultimaxkom8728 On the other hand, there are plenty of games that are made for the sole purpose of profit. They make games that are intentionally, meticulously designed for addictive behaviors and then release misleading ads for them. I saw a clip from a dev talking about to get people to pay more and stay addicted. It was kind of evil.
Upgrade to *[Grand Sinner]:* dream (first) game of (pure) platformer with (anti-scalable) bad code, (most used) art & sound assets, and marketed by nothing (not even on Steam), which is made on a random engine or framework (Scratch) in 6 months (8 hours a day) crunch-style.
For point number 1, your response is similar to my own when people ask me about my gamedev journey. I am not the type of person who enjoys starting with basic tutorials and learning small things that I can maybe use later. For me, I prefer to start with the big project, fully aware that I will fail, and trying to make it anyway. I start with the big idea then break off a tiny piece of that idea to start working on, I get as far as I can until I need help, then I go learn that specific thing. It helped give me a lot of direction in the beginning, so learning felt much better since I was learning something directly applicable. So I agree, its totally fine to start with your dream game or a big game, just do so knowing that it will fail (which isn't a bad thing) and use it as direction.
Game Engines: There are a number of roadworthy buses to choose from. The skill of the bus driver is much more important than which bus you’re on. Crunching: I love game dev. I happily crunch when I want to (a lot!)
This video for some reason gave me more motivation :) I cannot believe that you still only have 12k subs btw.. I predict that your channle will grow and generate a fair amount of revenue to keep you going on your journey!
Yes - all of these takes are super fire - Tip #5 is a straight up banger. Also, this video is extremely important since it's easy to accept "standard advice" for the sake of taking it and moving on. You bring a ton of points that actively enforce critical thinking on why we should/shouldn't commit to these 'game dev sins' and that its all subjective and based on your goals. Excellent video and discussion!
There are only three rules to game development: 1) Make it work. 2) Make it effective. 3) Make it fun. Everything else is just a tip or piece of advice.
I certainly felt more than once like an imposter, still do to this day from time to time! I've been developing my first game for a little over a year now and with that, I've had to learn my way around so many things, learning fast, but also finding my own ways of solving problems the internet didn't have solutions for. Sometimes you really do feel like 'hmm, wonder how real game devs do this...' haha - I did start of my first solo game dev journey with my dream game, it's certainly a challenge but man is it worth it when you get things to work out finally! - love the content btw! :)
Remember, at the end of the day is night. On the topic: have a fun idea, and "invite" player to experience it. Imagine a bunch of features, overscope and then brutally cut about 70% of that when you finalize. Modify remaining things on the go to make them actually fun in context of your game. As for the code.... do proper architecture from the start. If you write poor architecture, then you will eventually hit critial roadblocks, and you won't be able to continue. In fact, going forward with bad code will also be very daunting and you will probably feel grumpy every time you sit down to work on your project.
I developed my first game, my ‘dream game’ for 4.5 years. I could surely have spent that time creating and launching 6 other games. But: I started aged 40, so I’ve already gone through a lot of the ‘collateral knowledge/experience’ running my own one-man consultancy in a technical field. I’ve learned LOADS on that one game, lived it full-time for almost two years, made a bit of money from if (a good amount considering it was my first game), and, importantly, I have been able to walk away from it after a few updates and move on to the next thing. I’ve learned HEAPS in the last 6 months since moving on, and my second game will be (technically so far) SO much better! I still love developing every single day - hopefully my next venture does well enough to go full time rather than the current 50%.
Love these takes! More and more I’m learning that those who are vocal about game dev are really just expressing an opinion. There is some good value in what people say but it’s not absolute truth. I’ve learned that for the most part, there are dozens of ways to tackle any problem in game dev, and there is no correct way.
lol don’t know if my comment was too ambiguous but I was just playing into Thomas’s comment 10 seconds into the video about it being his “personal goal to offend every person watching the video.” 😅
Love your point about crunch. If you ask any highly successful individuals across any industry or talent, it didn’t come without putting in the time and likely sacrifices in their personal lives. People forget a lot of classic/masterpiece games were made in terrible times of crunch from passionate people.
Hi there! You’re right; if you’re working alone on your project, perfect code may not be as crucial. But if you’re part of a team, it definitely matters. That’s why it’s worth putting in some effort to improve your programming skills. You don’t need to spend too much time on it, but it does make a difference (just my opinion as a programmer). And trust me, even in smaller Unity projects, you can encounter optimization issues if you’re running heavy processes every frame in Update, like repeatedly using FindObjectOfType or similar methods. (I’m not saying an RTX 4090 couldn’t handle this process, but an older mobile device might struggle!)
This. I'd argue that most indies are unlikely to be GPU-bound, unless they're working in high-poly HD environments, or get too tree-happy. What really kills most indie games, including 2d ones, performance-wise, is more likely memory allocations in strange places, or using code copied (or bought) without proper configuration. It's not a "sin" it's a warning 😅
I started my game with crunch (but it's just me and only until I figured out a few key technical questions that were driving me insane) on bad code: even if you're primarily a coder, your 'good code' should look bad over time if you're advancing in your craft, and just because you could redo the whole project at the end to "fix the code", shipping is more important, ship, fix bugs, make the next game with better code, or fix the code after bugs, depending on your goals with the game and if you're primarily a coder, if you're even making another game, etc.
I think when people say you are 'programming the wrong way' is really just an attempt to impart decades of experience in as short of a communication as possible. What people actually mean, when they say that, is: "I used to do that for years, but I kept hitting this one part when it would fall apart under this specific circumstance and the code just feels gross and didn't really update well, so I started building it this other way in place of it and it no longer has that major setback and is prettier to use and easier to grok". I don't think it is an attack but actually intended as a huge gift of decades worth of experience just 'given to you'. However, as with most things... experience by proxy is usually much less potent and useful than making the mistakes yourself and seeing the errors of your own ways. The vast majority of time it is preference, but sometimes those preferences are actually pretty cool. And sometimes people forget (like in code reviews) that "If it works though... and there isn't a real issue to readability,... then you should just keep that preference to yourself". ie: any code review that has this gem:"This works, but I don't like your naming convention.... isAbleToAquireMeatSandwich really should be canHazChesburgur as that's more readable to me." ... It's time to just LET PEOPLE WORK JESUS TAKE THE WHEELLLLLLL
1. Have to disagree, it's evident that game devs (especially new ones), are the opposite of scared. The reason this is said so much is to help prevent the unfortunate scenarios (and seem to endlessly happen) where people work on their dream game for X years and then fail and feel like they have thrown all their time away. (learning is always good but it's never great if you lose all motivation to continue because you failed, which leaves many people financially in a bad position or just no longer interested in learning & trying to continue). It's always good to try and this obviously shouldn't be a 'rule', but just good general advice. 2. Yep agree on this one, but can't ever forget marketing entirely though! Uhh your comments on code are wild. Have you never created any sort of system that is expensive? A chunk loader, meshing algorithms, pathfinding etc.? All of those have significant cost that scales extremely, to the point of absolute usage, if you write bad code or code without performance consideration.
#1 especially applies to the folks who either quit or were laid off, and declare they're gonna work on their dream game instead of looking for a new job. There was a lot of it during the pandemic, and I think we're seeing it again with formerly-AAA folks starting studios, despite not having the funds for the sorts of games they want to make. No shade on chasing your dreams, or being ambitious. But if your game needs to keep a roof over your head, different considerations apply.
I can agree with most of the points. But bad code is not one of them. Sure, it matters more in a big company. But writing good code helps YOU to avoid bugs which will make your awesome dream game a crap show. Also you will bring on Updates with more confidence. Clean code, refactoring and unit tests are your friends. Don't miss them out.
Haha great video and great format. As someone doing something "big, dream-game"-adjacent, I am constantly running up against the advice to build smaller things. But building the big thing is what has motivated me for years while small projects didn't capture my attention. I will say though that one bit of advice I'd add for big dream games is: go build it, but you have to be ready and willing to compromise on some, perhaps many aspects. You may even have to kill a few of your darlings (looking at you, multiplayer). But I think if you can keep the core identity of your dream alive despite the cuts, it's still worth considering.
1. "It'll be too big to finish" - only if you rush it, or don't really care for it. 2. You must market, that is why marketing exists. Jonas having a TH-cam channel IS HIS MARKETING!!! 3. Agree. 4. Unity is simply the best current choice for indies if compared to Unreal (too much work) and Godot (too little support). 5. If you don't set deadlines, prepare to work on it forever. 6. Agree. 7. Code is only bad if it doesn't work or the person working with it can't do it effectively.
When writing for switch for example the code really needs to be optimised (I used to make mobile games in j2me it mattered then too). I even found myself optimising null checks lol - and pooling is pretty much essential on poor hardware. But yeh for a PC it barely matters. The dream game thing, I just fired up a 10 yr project that I took a break from. I think the problem is it gets too complex to handle eventually so you need to start simplifying it because at some point every idea you had went in. Good video thanks.
I'm using my own programming language.But I also draw my own pixelart, since no existing assets match what I want. And whetever good assets there are get used in every 2nd indie game.
It's not about conventions, it's usually meant so folks avoid soul-crushing pitfalls. If you're just learning, better to start with basic "good hygiene" tips rather than get frustrated after your game literally doesn't run and you have no debugging skills.
I love when the developer for Balatro+. The Internet of developers jumped in and said it’s cool… It doesn’t matter… I guess those people don’t mind if your code is bad if you make a good/successful game.
Undertale had a long, painful road to console even with an external porting team, because the code was so poorly-made. No one's really arguing for perfection (doesn't exist!) just warning folks to take a beat to review their own code periodically. Even if you're working solo, future-you will appreciate it.
As a programmer, I also don't think you need to have the penultimate code quality so long as it can be read later when you're a new you. Certainly some conventions, drowning on the game and engine you're working, that you should try to follow to make things easier on yourself, but that just comes down to making a solid plan. And even that plan will likely be malleable. Now if you're creating something large or complex, yeah definitely keep that code cleaned up. Better to keep it clean initially than needing to rewrite your entire game later because you couldn't find one bug in the spaghetti.
It is annoying when a gamedev/engine subreddit/forum has one post meme-ing bad practices, and then the next post is "I don't know how to debug this problem" and they keep doubling down on their bad practices when told how to fix it in the comments. I do generally agree with the point though. Optimize for time-to-first-iteration, not performance, brevity, nor beauty.
Bad code has three consequences. You cover the first two, but its the third that can prove to be a problem for indie devs Bad code can make adding content or new mechanics becomes a torturous task. Where the choice of brute-forcing through it, or refactoring the code, can be equally painful. In indie dev where people can sometimes jump in without a plan, or a very loose one, bad code can cause friction later down the line and sap motivation. It can turn adding a new monster/item/biome from a task that takes 1-2 days, in to one that takes 2-4 weeks, or more. Programmers will probably want to go too far, but speaking as someone from a non-programming background, moving in the other direction and accidentally pigeon-holing yourself in bad code architecture due to bad code, can be just as devastating to a project
I kept waiting for what I felt was the biggest game dev sin. You can survive it, but you shouldn't do it. Which is going in without a plan, designing by the seat of your pants, and hoping for the best. I'm sure there are some who can get away with it and still be successful/happy. But even sinners can get lucky/persevere :P
I've always thought the game represents itself better than the marketing of a game does. If a game is crap but has millions put into marketing it will fail regardless of marketing. This is true for AAA games so it has to be true for indies as well. People will be more lenient on an indie game because, well, it's an indie game. But even a bad trailer for an awesome game will do better than a 10/10 trailer for a crappy looking game no one wants to play.
Yeah, this is a good video. I don't think the "sins" are so bad either, it's more like suggestions that you don't necessarily have to follow. Like, I understand the pushback against pre-made assets somewhat because of incredibly lazy asset flip games, but pre-made assets exist for a reason for the less artistically inclined. As long as things are used with intention and a clear vision, no conflicts with visual style, and adding a little bit of your own touch to things, there's nothing wrong with using assets. I guarantee even professional dev teams use them. And yeah, messy code doesn't matter if you're the only person who's gonna be working on it. Only consider learning cleaner code if you want to work with a team of other programmers.
On bad code: All code can be better, and that's not up to debate. Even the best programmers get hit with code reviews, there's always something slipping, something that could be improved, etc. And yet, when making games, all that matters is that it works. No need for fancy state machines if it's too complicated for you, just make it work. I like to use the analogy of me, as a programmer, can't do art because it's terrible. I can still do my title screen and it would be bad, but a bad title screen is much, much better than no title screen at all. Go and write that bad code, it's better than no code and no game at all
crunch is "good" if it is SHORT and aims to improve the game, make it better, more polished, NOT to finish the game somehow. Second option always mean "death march". As for coding, write the code you can understand 6 months later.
I agree with all but dream game. I think you should make it but first make smaller games of your dream game so you learn how to build and structure. It will go way faster then rebuild your dream game over and over.
Great video. Generally, I agree with all the points. However, it is missing one major context variable: Is the end goal to generate revenue or a fun side project? You touch lightly on it in this video but it should be front and center for the entire content. Lets put that aside for a second. Can you create a video (or series of video) where you interview successful business owners and startup entrepreneurs from other industries, asking them how to build a successful business? What can we learn from them and apply to the game dev world? I find it interesting that there's so much information on how to build successful businesses from other industries but still game devs insist on doing it their own way. For instance, there's no entrepreneur that would ever work on a dream project for five years without having paying customers. They'd need paying customers within maybe the first year. Yet still game devs insist on doing that. I've even seen game devs that shipped highly successful titles insist on doing that. Now obviously, this ties in to my point in the first paragraph. 🙂
I think the whole "don't use assets" is now starting to be over shadowed by the people who say "never use AI art in your game." Also, those people are inconsistent. Some will say it's ok to use AI art to make seamless textures for your 3d models, but don't use any other AI art. Or some will say it's ok for concept art, but not for anything else. Or it's ok for your youtube thumbnail but not anything else. My point is, these exceptions are extremely arbitrary and not based on any consistent logic.
Not so much arbitrary, as situational. Concept art is internal-only - AI in that context isn't much different from stock photos or art you don't have any rights to. A real artist would be way better, but if you're just some indie with a moodboard, you weren't hiring an artist anyway. Marketing art is different - it's not only unethical, it's difficult to get consistent results out of any model without so much artistic follow-up work you might as well have just hired an artist in the first place. TH-cam thumbnails for a channel (like BiteMe) is a grey area - could argue it's "disposable" art. A trailer thumbnail would fall under marketing art.
For me, I just don't want AI at to be the end product that we see. There's been a lot of people who've used AI to create 90% and then do the hard work for that other 10% just because it saves time and money. That's fine. But usually if you're just rendering out assets and not song anything with them to make them mesh well then your game probably doesn't even look appealing enough for me to have ever noticed it. XD
TL;DR: Don't follow advice blindly, what's good for 99% of the population might not work for you. I totally disagree with #7 though. Writing good code is not about it being "pristine" or optimized. It's about long-term maintainability. If you're making a small game you might get away with it, but bigger projects with longer lifespans? That will backfire pretty fast.
The biggest problem with all of these "game dev sins" videos, or game dev advice videos in general, is how every statement in these videos is treated as the ultimate truth. There is never nuance. DON'T do this and that. YOU HAVE TO do this and that. No Micheal_gamedev_95, just because YOU don't stay motivated on large scale project, doesn't mean nobody should do it.
As a programmer myself, I'm so annoyed when other programmers show up, pretending to be more pure and saint than everybody, talking about code architecture and optimized code, talking about the thing that you should NEVER do and things that you should ALWAYS do and that's just BS. Stop wasting time on that crap, you'll end up with "perfect" code and no game.
99.9% of the time, there is no reason to optimize code. The 0.1% of time, you should see the bottleneck running on the target platform and think of competent ways to address it. If you optimize code at the expense of readability, then that's just making cruddy code. For instance: You COULD unroll all your loops and do whackadoodle things all over the place (yes, this is technically multiple times faster than not, even in unity)... but unless those places are impacting the performance of the project (99.9% of the time this isn't the case) then you should NEVER write things that are hard to grok at a glance or that COMMUNICATE the wrong idea or complicate the point to any needless extent. And when you actually find a bottleneck worth addressing (actually having a performance hit), then make a system to address it that is competent and readable... one more sin is thinking lines of code are "liabilities" so dumb-dumbs do single line shenanigans that could have been made clearer in a half dozen lines of code... because they are under the really pervasive and equally wrong idea that 'more lines of code are bad'. this.IsNotReadable()?(new NotEverByALongShot(){ nope=true }).niceTryButNo:evenThoughItWasFunToWrite?ItIsStillGarbage():EachAndEveryTime.honestlyDont=true; .... could be one line but jesus... imaging needing to change even one aspect or trying to remember wtf it originally did. There is no benefit other than 'feeling smart' about it working in as few of lines as possible... we've all been there but it's a cruddy place to be. So when you actually make optimizations, you should make them well so that they can be read and understood... for instance like spatial partitioning for the instances where that helps... just make that pattern well and in a way that is maintainable... easy as...
On marketing: For those that don't have any commercial aspiration for their game, it's still worth considering how you will feel at the end of the project if no one plays your game (beyond friends and family). Some are lucky enough to almost exclusively be driven by internal motivation, but I imagine that many people desire to have the world around them acknowledge them and their achievements in some way. Marketing doesn't need to be time-consuming and tedious - it's fine to create a good Steam page, make a fun demo, enroll in festivals and email youtubers/streamers.
3 main motivations: profiting, sharing, making. Profiting is the *[Hard]* difficulty, while making is the *[Easy].* _"0 players? Mostly negative? Who cares."_
@@ultimaxkom8728 On the other hand, there are plenty of games that are made for the sole purpose of profit.
They make games that are intentionally, meticulously designed for addictive behaviors and then release misleading ads for them.
I saw a clip from a dev talking about to get people to pay more and stay addicted. It was kind of evil.
Hi, I am Aarimous and I am a Game Dev "'Sinner"'
Upgrade to *[Grand Sinner]:* dream (first) game of (pure) platformer with (anti-scalable) bad code, (most used) art & sound assets, and marketed by nothing (not even on Steam), which is made on a random engine or framework (Scratch) in 6 months (8 hours a day) crunch-style.
(Everyone) Hi Aarimous
You've been baaaaaad
For point number 1, your response is similar to my own when people ask me about my gamedev journey. I am not the type of person who enjoys starting with basic tutorials and learning small things that I can maybe use later. For me, I prefer to start with the big project, fully aware that I will fail, and trying to make it anyway.
I start with the big idea then break off a tiny piece of that idea to start working on, I get as far as I can until I need help, then I go learn that specific thing. It helped give me a lot of direction in the beginning, so learning felt much better since I was learning something directly applicable. So I agree, its totally fine to start with your dream game or a big game, just do so knowing that it will fail (which isn't a bad thing) and use it as direction.
“Standing on the shoulders of giants.” Very well said.
Game Engines: There are a number of roadworthy buses to choose from. The skill of the bus driver is much more important than which bus you’re on.
Crunching: I love game dev. I happily crunch when I want to (a lot!)
This video for some reason gave me more motivation :)
I cannot believe that you still only have 12k subs btw.. I predict that your channle will grow and generate a fair amount of revenue to keep you going on your journey!
Yes - all of these takes are super fire - Tip #5 is a straight up banger.
Also, this video is extremely important since it's easy to accept "standard advice" for the sake of taking it and moving on. You bring a ton of points that actively enforce critical thinking on why we should/shouldn't commit to these 'game dev sins' and that its all subjective and based on your goals. Excellent video and discussion!
There are only three rules to game development:
1) Make it work.
2) Make it effective.
3) Make it fun.
Everything else is just a tip or piece of advice.
Wrong order but yes. should be 3, 1, 2...
@@anonymous49125 they were just kinda listed, not exactly chronologically or by level of importance
@@kitsunemusicisfire Given that, I completely agree. You're very right.
"Make a game that you want to see made" - this!
I certainly felt more than once like an imposter, still do to this day from time to time! I've been developing my first game for a little over a year now and with that, I've had to learn my way around so many things, learning fast, but also finding my own ways of solving problems the internet didn't have solutions for. Sometimes you really do feel like 'hmm, wonder how real game devs do this...' haha - I did start of my first solo game dev journey with my dream game, it's certainly a challenge but man is it worth it when you get things to work out finally! - love the content btw! :)
I love this video. That ending made me chuckle. Thanks, Thomas!
Remember, at the end of the day is night. On the topic: have a fun idea, and "invite" player to experience it. Imagine a bunch of features, overscope and then brutally cut about 70% of that when you finalize. Modify remaining things on the go to make them actually fun in context of your game. As for the code.... do proper architecture from the start. If you write poor architecture, then you will eventually hit critial roadblocks, and you won't be able to continue. In fact, going forward with bad code will also be very daunting and you will probably feel grumpy every time you sit down to work on your project.
I developed my first game, my ‘dream game’ for 4.5 years. I could surely have spent that time creating and launching 6 other games. But: I started aged 40, so I’ve already gone through a lot of the ‘collateral knowledge/experience’ running my own one-man consultancy in a technical field. I’ve learned LOADS on that one game, lived it full-time for almost two years, made a bit of money from if (a good amount considering it was my first game), and, importantly, I have been able to walk away from it after a few updates and move on to the next thing. I’ve learned HEAPS in the last 6 months since moving on, and my second game will be (technically so far) SO much better! I still love developing every single day - hopefully my next venture does well enough to go full time rather than the current 50%.
I like your point that a game is a trick.
If you fool the player into believing they're in a game world, the trick worked.
Quite motivating! Thanks :D
Great video topic and well executed. I really enjoyed listening to your options on these hot topics. 👍🏼
Love these takes! More and more I’m learning that those who are vocal about game dev are really just expressing an opinion. There is some good value in what people say but it’s not absolute truth. I’ve learned that for the most part, there are dozens of ways to tackle any problem in game dev, and there is no correct way.
10 seconds in and I’m already offended. Well done!
Snowflake 😂😂
Bait above, or it's just a yellow snow spreading its yellowness.
lol don’t know if my comment was too ambiguous but I was just playing into Thomas’s comment 10 seconds into the video about it being his “personal goal to offend every person watching the video.” 😅
It took me 20 years but I am now making my dream game. Rats + loot + infinite skill tree etc
Dont forget when you buy assets you are also helping support other devs
Game development is continuously learning process.
Love your point about crunch. If you ask any highly successful individuals across any industry or talent, it didn’t come without putting in the time and likely sacrifices in their personal lives. People forget a lot of classic/masterpiece games were made in terrible times of crunch from passionate people.
Hi there! You’re right; if you’re working alone on your project, perfect code may not be as crucial. But if you’re part of a team, it definitely matters. That’s why it’s worth putting in some effort to improve your programming skills. You don’t need to spend too much time on it, but it does make a difference (just my opinion as a programmer).
And trust me, even in smaller Unity projects, you can encounter optimization issues if you’re running heavy processes every frame in Update, like repeatedly using FindObjectOfType or similar methods. (I’m not saying an RTX 4090 couldn’t handle this process, but an older mobile device might struggle!)
This. I'd argue that most indies are unlikely to be GPU-bound, unless they're working in high-poly HD environments, or get too tree-happy. What really kills most indie games, including 2d ones, performance-wise, is more likely memory allocations in strange places, or using code copied (or bought) without proper configuration.
It's not a "sin" it's a warning 😅
I started my game with crunch (but it's just me and only until I figured out a few key technical questions that were driving me insane)
on bad code: even if you're primarily a coder, your 'good code' should look bad over time if you're advancing in your craft, and just because you could redo the whole project at the end to "fix the code", shipping is more important, ship, fix bugs, make the next game with better code, or fix the code after bugs, depending on your goals with the game and if you're primarily a coder, if you're even making another game, etc.
I think when people say you are 'programming the wrong way' is really just an attempt to impart decades of experience in as short of a communication as possible. What people actually mean, when they say that, is: "I used to do that for years, but I kept hitting this one part when it would fall apart under this specific circumstance and the code just feels gross and didn't really update well, so I started building it this other way in place of it and it no longer has that major setback and is prettier to use and easier to grok".
I don't think it is an attack but actually intended as a huge gift of decades worth of experience just 'given to you'. However, as with most things... experience by proxy is usually much less potent and useful than making the mistakes yourself and seeing the errors of your own ways.
The vast majority of time it is preference, but sometimes those preferences are actually pretty cool. And sometimes people forget (like in code reviews) that "If it works though... and there isn't a real issue to readability,... then you should just keep that preference to yourself". ie: any code review that has this gem:"This works, but I don't like your naming convention.... isAbleToAquireMeatSandwich really should be canHazChesburgur as that's more readable to me." ... It's time to just LET PEOPLE WORK JESUS TAKE THE WHEELLLLLLL
1. Have to disagree, it's evident that game devs (especially new ones), are the opposite of scared. The reason this is said so much is to help prevent the unfortunate scenarios (and seem to endlessly happen) where people work on their dream game for X years and then fail and feel like they have thrown all their time away. (learning is always good but it's never great if you lose all motivation to continue because you failed, which leaves many people financially in a bad position or just no longer interested in learning & trying to continue). It's always good to try and this obviously shouldn't be a 'rule', but just good general advice.
2. Yep agree on this one, but can't ever forget marketing entirely though!
Uhh your comments on code are wild. Have you never created any sort of system that is expensive? A chunk loader, meshing algorithms, pathfinding etc.? All of those have significant cost that scales extremely, to the point of absolute usage, if you write bad code or code without performance consideration.
#1 especially applies to the folks who either quit or were laid off, and declare they're gonna work on their dream game instead of looking for a new job. There was a lot of it during the pandemic, and I think we're seeing it again with formerly-AAA folks starting studios, despite not having the funds for the sorts of games they want to make.
No shade on chasing your dreams, or being ambitious. But if your game needs to keep a roof over your head, different considerations apply.
I can agree with most of the points. But bad code is not one of them. Sure, it matters more in a big company. But writing good code helps YOU to avoid bugs which will make your awesome dream game a crap show. Also you will bring on Updates with more confidence. Clean code, refactoring and unit tests are your friends. Don't miss them out.
I'm committing the "8th sin" using rpgmaker mv to make my game
Spicy take on crunch but I 100% agree. 🔥
Haha great video and great format.
As someone doing something "big, dream-game"-adjacent, I am constantly running up against the advice to build smaller things. But building the big thing is what has motivated me for years while small projects didn't capture my attention.
I will say though that one bit of advice I'd add for big dream games is: go build it, but you have to be ready and willing to compromise on some, perhaps many aspects. You may even have to kill a few of your darlings (looking at you, multiplayer). But I think if you can keep the core identity of your dream alive despite the cuts, it's still worth considering.
1. "It'll be too big to finish" - only if you rush it, or don't really care for it.
2. You must market, that is why marketing exists. Jonas having a TH-cam channel IS HIS MARKETING!!!
3. Agree.
4. Unity is simply the best current choice for indies if compared to Unreal (too much work) and Godot (too little support).
5. If you don't set deadlines, prepare to work on it forever.
6. Agree.
7. Code is only bad if it doesn't work or the person working with it can't do it effectively.
When writing for switch for example the code really needs to be optimised (I used to make mobile games in j2me it mattered then too). I even found myself optimising null checks lol - and pooling is pretty much essential on poor hardware. But yeh for a PC it barely matters. The dream game thing, I just fired up a 10 yr project that I took a break from. I think the problem is it gets too complex to handle eventually so you need to start simplifying it because at some point every idea you had went in. Good video thanks.
I don’t think I have a “dream game” 🤔
I'm using my own programming language.But I also draw my own pixelart, since no existing assets match what I want. And whetever good assets there are get used in every 2nd indie game.
what a phenomenal checklist
"Ignore the programmers" is great advice. They are too hung up on conventions to ever ship a product. This is a great video Thomas :)
It's not about conventions, it's usually meant so folks avoid soul-crushing pitfalls. If you're just learning, better to start with basic "good hygiene" tips rather than get frustrated after your game literally doesn't run and you have no debugging skills.
@@mandisawWas never a problem for me.
@SpaceMyName Congratulations! But you're just one data point. Plenty of folks clearly do quit at early obstacles, the stats bear it out.
I love when the developer for Balatro+. The Internet of developers jumped in and said it’s cool… It doesn’t matter… I guess those people don’t mind if your code is bad if you make a good/successful game.
It doesn't matter, _when it doesn't matter._ Balatro is an offline card game. AA, non small mobile, multiplayer, or web games are another matter.
Undertale had a long, painful road to console even with an external porting team, because the code was so poorly-made. No one's really arguing for perfection (doesn't exist!) just warning folks to take a beat to review their own code periodically.
Even if you're working solo, future-you will appreciate it.
As a programmer, I also don't think you need to have the penultimate code quality so long as it can be read later when you're a new you. Certainly some conventions, drowning on the game and engine you're working, that you should try to follow to make things easier on yourself, but that just comes down to making a solid plan. And even that plan will likely be malleable. Now if you're creating something large or complex, yeah definitely keep that code cleaned up. Better to keep it clean initially than needing to rewrite your entire game later because you couldn't find one bug in the spaghetti.
It is annoying when a gamedev/engine subreddit/forum has one post meme-ing bad practices, and then the next post is "I don't know how to debug this problem" and they keep doubling down on their bad practices when told how to fix it in the comments.
I do generally agree with the point though. Optimize for time-to-first-iteration, not performance, brevity, nor beauty.
Bad code has three consequences. You cover the first two, but its the third that can prove to be a problem for indie devs
Bad code can make adding content or new mechanics becomes a torturous task. Where the choice of brute-forcing through it, or refactoring the code, can be equally painful.
In indie dev where people can sometimes jump in without a plan, or a very loose one, bad code can cause friction later down the line and sap motivation.
It can turn adding a new monster/item/biome from a task that takes 1-2 days, in to one that takes 2-4 weeks, or more.
Programmers will probably want to go too far, but speaking as someone from a non-programming background, moving in the other direction and accidentally pigeon-holing yourself in bad code architecture due to bad code, can be just as devastating to a project
Yep don't hold back in making your dream game. Do get lots of player feedback if you want to sale it
I kept waiting for what I felt was the biggest game dev sin.
You can survive it, but you shouldn't do it.
Which is going in without a plan, designing by the seat of your pants, and hoping for the best.
I'm sure there are some who can get away with it and still be successful/happy. But even sinners can get lucky/persevere :P
Spiritual successor??? Lol
I've always thought the game represents itself better than the marketing of a game does. If a game is crap but has millions put into marketing it will fail regardless of marketing. This is true for AAA games so it has to be true for indies as well. People will be more lenient on an indie game because, well, it's an indie game. But even a bad trailer for an awesome game will do better than a 10/10 trailer for a crappy looking game no one wants to play.
I’m not sure if I can repent for all my sins.
Oh my, are you implying that rolling a ball around the screen is somehow lesser? ;) Good video, all very true. Do what gets results.😍
New subscriber buddy
Yeah, this is a good video. I don't think the "sins" are so bad either, it's more like suggestions that you don't necessarily have to follow. Like, I understand the pushback against pre-made assets somewhat because of incredibly lazy asset flip games, but pre-made assets exist for a reason for the less artistically inclined. As long as things are used with intention and a clear vision, no conflicts with visual style, and adding a little bit of your own touch to things, there's nothing wrong with using assets. I guarantee even professional dev teams use them.
And yeah, messy code doesn't matter if you're the only person who's gonna be working on it. Only consider learning cleaner code if you want to work with a team of other programmers.
You missed your goal of making everyone mad who watched this video, because I loved everything you had to say. Nice share.
On bad code: All code can be better, and that's not up to debate. Even the best programmers get hit with code reviews, there's always something slipping, something that could be improved, etc. And yet, when making games, all that matters is that it works. No need for fancy state machines if it's too complicated for you, just make it work. I like to use the analogy of me, as a programmer, can't do art because it's terrible. I can still do my title screen and it would be bad, but a bad title screen is much, much better than no title screen at all.
Go and write that bad code, it's better than no code and no game at all
You should do another video with the 7 Heavenly Virtues.
crunch is "good" if it is SHORT and aims to improve the game, make it better, more polished, NOT to finish the game somehow. Second option always mean "death march".
As for coding, write the code you can understand 6 months later.
great video
I agree with all but dream game. I think you should make it but first make smaller games of your dream game so you learn how to build and structure. It will go way faster then rebuild your dream game over and over.
Great video. Generally, I agree with all the points. However, it is missing one major context variable: Is the end goal to generate revenue or a fun side project? You touch lightly on it in this video but it should be front and center for the entire content.
Lets put that aside for a second. Can you create a video (or series of video) where you interview successful business owners and startup entrepreneurs from other industries, asking them how to build a successful business? What can we learn from them and apply to the game dev world?
I find it interesting that there's so much information on how to build successful businesses from other industries but still game devs insist on doing it their own way. For instance, there's no entrepreneur that would ever work on a dream project for five years without having paying customers. They'd need paying customers within maybe the first year. Yet still game devs insist on doing that. I've even seen game devs that shipped highly successful titles insist on doing that. Now obviously, this ties in to my point in the first paragraph. 🙂
I think the whole "don't use assets" is now starting to be over shadowed by the people who say "never use AI art in your game." Also, those people are inconsistent. Some will say it's ok to use AI art to make seamless textures for your 3d models, but don't use any other AI art. Or some will say it's ok for concept art, but not for anything else. Or it's ok for your youtube thumbnail but not anything else. My point is, these exceptions are extremely arbitrary and not based on any consistent logic.
Not so much arbitrary, as situational. Concept art is internal-only - AI in that context isn't much different from stock photos or art you don't have any rights to. A real artist would be way better, but if you're just some indie with a moodboard, you weren't hiring an artist anyway.
Marketing art is different - it's not only unethical, it's difficult to get consistent results out of any model without so much artistic follow-up work you might as well have just hired an artist in the first place.
TH-cam thumbnails for a channel (like BiteMe) is a grey area - could argue it's "disposable" art. A trailer thumbnail would fall under marketing art.
For me, I just don't want AI at to be the end product that we see. There's been a lot of people who've used AI to create 90% and then do the hard work for that other 10% just because it saves time and money. That's fine. But usually if you're just rendering out assets and not song anything with them to make them mesh well then your game probably doesn't even look appealing enough for me to have ever noticed it. XD
Nice video
It would be nice to have chapters in this video :/
Its funny if you reference Jonas while he has like 200.000 youtube followers and already a huuuuge amount of audience.
You got me so good with that AI joke; I stopped dead in my tracks. Lol 😂
Great
its ok, but too simple imho, maybe for younger guys might be valuable. Think u could go deeper in issues we face like self pressure
6:50 you got me there for a second 😂
TL;DR: Don't follow advice blindly, what's good for 99% of the population might not work for you.
I totally disagree with #7 though. Writing good code is not about it being "pristine" or optimized. It's about long-term maintainability. If you're making a small game you might get away with it, but bigger projects with longer lifespans? That will backfire pretty fast.
Cool
The biggest problem with all of these "game dev sins" videos, or game dev advice videos in general, is how every statement in these videos is treated as the ultimate truth. There is never nuance. DON'T do this and that. YOU HAVE TO do this and that. No Micheal_gamedev_95, just because YOU don't stay motivated on large scale project, doesn't mean nobody should do it.
As a programmer myself, I'm so annoyed when other programmers show up, pretending to be more pure and saint than everybody, talking about code architecture and optimized code, talking about the thing that you should NEVER do and things that you should ALWAYS do and that's just BS. Stop wasting time on that crap, you'll end up with "perfect" code and no game.
Making a game is all about being foolish lol 😆 i say this, do foolish stuff with your game man. 🎮
99.9% of the time, there is no reason to optimize code. The 0.1% of time, you should see the bottleneck running on the target platform and think of competent ways to address it.
If you optimize code at the expense of readability, then that's just making cruddy code.
For instance: You COULD unroll all your loops and do whackadoodle things all over the place (yes, this is technically multiple times faster than not, even in unity)... but unless those places are impacting the performance of the project (99.9% of the time this isn't the case) then you should NEVER write things that are hard to grok at a glance or that COMMUNICATE the wrong idea or complicate the point to any needless extent.
And when you actually find a bottleneck worth addressing (actually having a performance hit), then make a system to address it that is competent and readable... one more sin is thinking lines of code are "liabilities" so dumb-dumbs do single line shenanigans that could have been made clearer in a half dozen lines of code... because they are under the really pervasive and equally wrong idea that 'more lines of code are bad'. this.IsNotReadable()?(new NotEverByALongShot(){ nope=true }).niceTryButNo:evenThoughItWasFunToWrite?ItIsStillGarbage():EachAndEveryTime.honestlyDont=true; .... could be one line but jesus... imaging needing to change even one aspect or trying to remember wtf it originally did. There is no benefit other than 'feeling smart' about it working in as few of lines as possible... we've all been there but it's a cruddy place to be. So when you actually make optimizations, you should make them well so that they can be read and understood... for instance like spatial partitioning for the instances where that helps... just make that pattern well and in a way that is maintainable... easy as...