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.
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.
Honestly found this very encouraging. I've always been very daunted by how gatekeep-y the community can be and hearing what you've said resonated with a lot of things and verified a lot of believes I've had about gamedev that usually is met with a lot of naysaying. I think that that kinda backlash is mostly a lot of internalised insecurity and actually inexperience, but its EVERYWHERE. It's very refreshing to see someone stand up to question the status-quo, so thanks a lot for that : )
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.
I'm kinda similar. I find it hard to learn various things if I don't have immediate use for them. I prefer finding out what I need to do, then I look up how to do it if I can't figure it out myself. That's how I learn.
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! :)
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!
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!
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%.
Thanks Thomas, a great video with lots of encouraging content. I have always struggled with the "dream game" one, because I don't have any interest in making "games in general" - I just have the game idea that I want to see a reality. It's hard to find motivation to work on smaller projects - even if in the long run they might be building skills that allow you to come back to the bigger idea. It took me 20 years to get from "starting & failing to make my dream game" to "finally having enough skills/resources/connections to actually make my dream game" and if you'd told me that up front I might have never started!
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!)
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.
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.
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.
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.
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 😅
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.
Great video, and definitely one that more people (even seasoned professionals in the game dev industry) should watch. To make a hot take as well.. I believe that all these "sins" are actually a way to find an excuse why you should *not* make a game: "Oh, I can't make a game unless I am a god-tier programmer, have every single asset custom made, perfect life-work balance and start marketing three to five months before I was born" Maybe I took that a bit too far.. :D
This is a great video! Yeah these can be good advice, but you don't need to listen to any of it, if that's not what you want. Make game and learn! You can do things the "right" way, whenever you want to do so
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.
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.
Bad code may work for tiny projects with less than 10k or so lines of code, but beyond that it at some point becomes a nightmare to maintain it, even if you're the only author. I've conciously decided to mostly ignore code quality in my prototype projects so far, because I knew that I'd throw away a lot of it anyway. However, I'm approaching the point where adding or changing features becomes extremely slow and preventable bugs keep creeping in. Also, performance IS an issue. And currently, the bottlenecks are not related to rendering, but to networking and generally processing of lots of units (regardless of whether or not they are actually rendered).
💯% agree. And most of the toxic fundamentalists will never see their own dream projects to completion because of their mindset that everything needs to be perfect.
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.” 😅
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.
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.
Attempt number 1 : made map too big ( a continent), finished nothing Attempt number 2 few months later : made decent map, with elevators, interiors, lightning, - ignored optimization and path finding, everything got screwed up because of it Attempt number 3 few months later : made small map, optimized, but ignored asset texture sizes, so the download is 30GB and i am not even 10% done, so abandoning (GLB textures, 5 mb, looks good enough, no need 100 mb for an old tire) Attempt number 4 : no map, just animating. Animations per day keeps doctors away
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
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.
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.
Jonathan blow once shitted on John carmacks Doom code for being crude in its approach, but later changed his mind when he understood it was easier to read than abstracted code that would be considered cleaner and more efficient but probably took longer to write. I agree with everything you said and I also believe there is a happy medium between writing a recursive statement and hard coded if/elses, for your sake and your peers.
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. RUclips 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
I wish I could have time to crunch - working on my Project 1 hour per week max for couple of months now :( Having a family and a full-time job is hard....
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
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.
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.
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
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.
Bad code is only bad if the people who need to work on it cannot do so. If it’s just you, and you write your code so future you can read it, then it is good code, regardless of how “correct” your solution is.
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. 🙂
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.
The only deadly sin is treating advices too seriously and calling not following them a "deadly sin". This is both a jab at the video and at any "right ways" of doing things. Every "right way of doing things" should be treated as food for thought, not an imperative.
"Using assets" i think you should work with wording, asses it just anything what isnt code in game, textures are assets, music are assets, sprites are assets, this sin should named as "Using asset store"
Your opinion on programming is pretty generalized, depending on your game some knowledge about data types could save you a lot of computations and free CPU time. Coming from C and the embedded world, it's always better to be cache optimized. An std::vector can save you a lot of RAM access, especially a bottleneck on consoles since they have a unified memory architecture where CPU and GPU share the same RAM. So yeah, I clearly go with you that you don't over-optimize your code, especially pre-mature optimization has killed a lot of progress for me. But knowing at least the basics of data types and how CPUs work will prevent you from huge pitfalls.
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.
Unless you're actually a veteran programmer, you don't understand the satisfaction you get from an elegant system architecture that helps you update your game easily, expand your vision, and debug faster. So I say whatever you can do, do it... but if you're a real programmer... that you understand.
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
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.
Also you can always market after the fact, or just focus on making the game first
Brother gave me a heart attack at 6:48
Same
Honestly found this very encouraging. I've always been very daunted by how gatekeep-y the community can be and hearing what you've said resonated with a lot of things and verified a lot of believes I've had about gamedev that usually is met with a lot of naysaying. I think that that kinda backlash is mostly a lot of internalised insecurity and actually inexperience, but its EVERYWHERE. It's very refreshing to see someone stand up to question the status-quo, so thanks a lot for that : )
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.
I'm kinda similar. I find it hard to learn various things if I don't have immediate use for them. I prefer finding out what I need to do, then I look up how to do it if I can't figure it out myself. That's how I learn.
“Standing on the shoulders of giants.” Very well said.
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! :)
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!
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!
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%.
Thanks Thomas, a great video with lots of encouraging content. I have always struggled with the "dream game" one, because I don't have any interest in making "games in general" - I just have the game idea that I want to see a reality. It's hard to find motivation to work on smaller projects - even if in the long run they might be building skills that allow you to come back to the bigger idea. It took me 20 years to get from "starting & failing to make my dream game" to "finally having enough skills/resources/connections to actually make my dream game" and if you'd told me that up front I might have never started!
I love this video. That ending made me chuckle. Thanks, Thomas!
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!)
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.
Quite motivating! Thanks :D
Great video topic and well executed. I really enjoyed listening to your options on these hot topics. 👍🏼
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.
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.
RE: Crunch. If you're inspired to work, you should work. Never, ever say "no" to inspiration. If you do, it will go away, and it won't come back.
"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.
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 😅
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.
Great video, and definitely one that more people (even seasoned professionals in the game dev industry) should watch.
To make a hot take as well.. I believe that all these "sins" are actually a way to find an excuse why you should *not* make a game:
"Oh, I can't make a game unless I am a god-tier programmer, have every single asset custom made, perfect life-work balance and start marketing three to five months before I was born"
Maybe I took that a bit too far.. :D
This is a great video! Yeah these can be good advice, but you don't need to listen to any of it, if that's not what you want.
Make game and learn! You can do things the "right" way, whenever you want to do so
OMG I am a Game Dev "Sinner" 😂
EDIT: 6:47 this took me by surprise 😅😅
It took me 20 years but I am now making my dream game. Rats + loot + infinite skill tree etc
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.
"Make a game that you want to see made" - this!
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.
Dont forget when you buy assets you are also helping support other devs
Bad code may work for tiny projects with less than 10k or so lines of code, but beyond that it at some point becomes a nightmare to maintain it, even if you're the only author. I've conciously decided to mostly ignore code quality in my prototype projects so far, because I knew that I'd throw away a lot of it anyway. However, I'm approaching the point where adding or changing features becomes extremely slow and preventable bugs keep creeping in. Also, performance IS an issue. And currently, the bottlenecks are not related to rendering, but to networking and generally processing of lots of units (regardless of whether or not they are actually rendered).
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.
Your AI art comment made me chuckle.
Subbed!
💯% agree. And most of the toxic fundamentalists will never see their own dream projects to completion because of their mindset that everything needs to be perfect.
You should do another video with the 7 Heavenly Virtues.
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.” 😅
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.
Perfectly fits my situation-despite not knowing how to code, I even managed to make a game using only UE's Blueprints. Thankfully, it runs correctly.😂
what a phenomenal checklist
Game development is continuously learning process.
New subscriber buddy
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.
Attempt number 1 : made map too big ( a continent), finished nothing
Attempt number 2 few months later : made decent map, with elevators, interiors, lightning, - ignored optimization and path finding, everything got screwed up because of it
Attempt number 3 few months later : made small map, optimized, but ignored asset texture sizes, so the download is 30GB and i am not even 10% done, so abandoning (GLB textures, 5 mb, looks good enough, no need 100 mb for an old tire)
Attempt number 4 : no map, just animating. Animations per day keeps doctors away
For writing bad code, i think undertale is a perfect example of this. The games code is notoriously spaghetti code but its an amazing game despite it
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
great video
I'm committing the "8th sin" using rpgmaker mv to make my game
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.
@@anonymous49125 they were just kinda listed, not exactly chronologically or by level of importance
What do you mean with "effective"?
Spicy take on crunch but I 100% agree. 🔥
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.
Jonathan blow once shitted on John carmacks Doom code for being crude in its approach, but later changed his mind when he understood it was easier to read than abstracted code that would be considered cleaner and more efficient but probably took longer to write. I agree with everything you said and I also believe there is a happy medium between writing a recursive statement and hard coded if/elses, for your sake and your peers.
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.
RUclips 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
I wish I could have time to crunch - working on my Project 1 hour per week max for couple of months now :(
Having a family and a full-time job is hard....
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 don’t think I have a “dream game” 🤔
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.
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.
Oh my, are you implying that rolling a ball around the screen is somehow lesser? ;) Good video, all very true. Do what gets results.😍
Yep don't hold back in making your dream game. Do get lots of player feedback if you want to sale it
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
Nice video
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.
You mean I can't use assets! What the heck is wrong with this guy? I'm so mad I can hardly stand up.
You missed your goal of making everyone mad who watched this video, because I loved everything you had to say. Nice share.
It would be nice to have chapters in this video :/
Bad code is only bad if the people who need to work on it cannot do so. If it’s just you, and you write your code so future you can read it, then it is good code, regardless of how “correct” your solution is.
I’m not sure if I can repent for all my sins.
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. 🙂
Spiritual successor??? Lol
6:50 you got me there for a second 😂
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
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.
The only deadly sin is treating advices too seriously and calling not following them a "deadly sin". This is both a jab at the video and at any "right ways" of doing things. Every "right way of doing things" should be treated as food for thought, not an imperative.
hallow knight is still the TOP platformer to me
You got me so good with that AI joke; I stopped dead in my tracks. Lol 😂
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
Cool
Its funny if you reference Jonas while he has like 200.000 youtube followers and already a huuuuge amount of audience.
"Using assets" i think you should work with wording, asses it just anything what isnt code in game, textures are assets, music are assets, sprites are assets, this sin should named as "Using asset store"
Your opinion on programming is pretty generalized, depending on your game some knowledge about data types could save you a lot of computations and free CPU time.
Coming from C and the embedded world, it's always better to be cache optimized. An std::vector can save you a lot of RAM access, especially a bottleneck on consoles since they have a unified memory architecture where CPU and GPU share the same RAM.
So yeah, I clearly go with you that you don't over-optimize your code, especially pre-mature optimization has killed a lot of progress for me.
But knowing at least the basics of data types and how CPUs work will prevent you from huge pitfalls.
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.
Surely my unique original dragon based mmo dream game will work as my first game surely
Unsubbed
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.
Unless you're actually a veteran programmer, you don't understand the satisfaction you get from an elegant system architecture that helps you update your game easily, expand your vision, and debug faster.
So I say whatever you can do, do it... but if you're a real programmer... that you understand.
Making a game is all about being foolish lol 😆 i say this, do foolish stuff with your game man. 🎮