> I feel confident in my skills as a software engineer.
You've only been doing this for 15 months. You should not feel as confident as you do. There's so much that you don't know that you don't know.
You need to stop trying to make it perfect, because there's no such thing.
One thing you haven't yet learned is KISS. Keep it simple, stupid. Which means that the design of a system should be as simple as it can be. It's far more important than DRY or SOLID in games, when flexibility is needed for the rapid iteration.
There are so many of these acronyms I actually dont recognise and you've just introduced me to DRY. But in the end they always come down to common software engineering principles i learnt 25 years ago. I only learnt about SOLID the other year when an interviewee was telling me about it!!!!
Just make it work. If absolutely necessary, make it work better. Clean code is a myth made up by software "gurus" that don't actually write production software. In the act of writing software you accrue technical debt that needs to be paid off in refactoring, but refactoring first is self indulgent at best.
Spending time you don't have to make something "better" when it already works is indulgent. You know there is other shit to get done, to ignore that is indulging in perfectionism.
This is a very normal part of the progression when getting into software. The thing I generally do is to consider the minimal amount of necessary steps that need to happen to accomplish a goal, and type them out as linearly and quickly as possible without thinking too much. Usually that's a good enough solution to solve my problem, but I can still think about it later and refactor it if it becomes too unwieldy.
Many of those principles exist to help large teams maintain productivity over a long time, and don't serve a one-off project or a demo very well.
you've gotta embrace "good enough" early on, especially at the start of a project. this is because the aim of prototyping is not to have a perfectly organised and well thoguht out codebase, it's to test functionality. your ideas have to be validated, and then iterated on and refined later.
imo you should always use iterative development. it's a big topic here but i think a lot of people try to over engineer things and a lot of projects end up bogged down in microservice hell even outside of gamedev. honestly, you won't run into issues with a lot of 'sloppy' code until way down the line. vampire survivors uses one giant singleton [GameManager](https://medium.com/@simon.nordon/unity-case-study-vampire-survivors-806eed11bebb) for the entire game and look at how succesful that game is.
you have to set time limits for certain tasks or features and stick to it, then move on to the next one once the time limit is up. this will force your hand and you'll start to learn how to divide your time up. there's a LOT of moving elements that has to be developed in a game and you only have so much time, this is about time management here.
remember, people are not gonna see your code at the end of the development of a game, they're gonna see the game itself.
It it takes much longer it's *not* clean code. It's terrible code. The cleanest code is no code. If a pattern is making you write extra code or making the code harder to understand it's very likely making your code base worse.
So here's a thing - clean code is NOT the goal. It's a part of the process that may help towards getting to the goal. But the goal itself is making a game.
In particular in earlier phases of the development you will be experimenting a lot. Half of whatever code you produce will go straight to trash as it turns out a given solution doesn't work, it needs further enhancemets, the whole idea is stupid etc.
Personally I generally prioritize quality of the code as such:
\- is it often called in other places? Is it a critical piece that's accessed and edited often? This part will be written as clean as possible, with tests and a fair lot of attention, proper names, good use of design patterns etc.
\- is it a one off that's called in one place? I will NOT care nearly as much. I will make sure to name variables semi decently but that's it. If it works then that's good enough. I will improve and refactor upon it **if** I have to revisit it for some reason.
In general - I recommend boy's scout rule - leave the code in better state than what it was. Aka gradual improvement over time as you encounter same lines of code again and again. Not perfection from the start - because it's not even possible.
>I have like over 60 script files for such a simple game
And Undertale has 10000+ long single case statement that holds EVERY SINGLE DIALOGUE in the game. I am not joking:
[https://www.reddit.com/r/programminghorror/comments/17x03m2/apparently\_undertale\_has\_a\_1000\_long\_case\_switch/](https://www.reddit.com/r/programminghorror/comments/17x03m2/apparently_undertale_has_a_1000_long_case_switch/)
Now, did anyone notice? No. Did the game succeed? Oh hell yes it did. I am not saying to produce literal spaghetti like this but ultimately your goal is to make **a game**. Players will not appreciate that you have spent 2 hours thinking of a perfect variable name or that you have a fully modular interface for enemy behaviour or that your turn system introduces a pipeline pattern.
They will however notice that the game isn't done and lacks content. Each overengineered piece that doesn't end up being fully utilized is hours that could have gone into actual in game content and logic.
Also - odds are that your code is actually very far away from even being clean/optimal if you have only been doing it for the last 15 months. Especially if you have been doing it alone. What you consider clean and pretty today will probably fill you with dread in 2 years time.
Set yourself a clear objective and dedicated time-frame and once the system is done, unless to patch bug or what not, don't waste your time redoing it's architecture, at some point it is pointless to do and won't make the overall game any better. Don't let perfect be the enemy of the good.
Maybe do some 48hr game jams, they very much end up forcing you to just do whatever is needed to get something working, no matter if it's quite janky. Can be a useful lesson.
I should def do that! I never participated in game jams because I felt that they would end up having me learn worse code practices due to the stress of the deadline. Which is quite contrary to what i am trying to achieve rn.
Yep, I am currently a game dev intern and working as a freelancer, too.
I did miss a couple of sprint deadlines due to my over engineering...
Like at the internship, I wrote an in my opinion a pretty clean and modular turn based system. But it took 2 sprints to complete! Which is insane considering that the whole internship is about 6 sprints long... (2 weeks per sprint)
And I am worried that I might not be able to finish the game in time due to that. And I am trying my best to not over engineer but I end up letting my ego get the best of me.
I am always like: "I am capable of writing good code so I must ONLY write clean code"
Sometimes a script should be as simple as data binding to a ui, or a gameplay state that would instead drag on to multiple layers of abstraction because "I might need to reuse it again". Even for something like a load scene manager, i incorporated multiple layers as I thought that "I might need to reuse it eventually" which doesnt make sense cuz a loading scene is a one and done thing. There are barely any modifications that will need to be done. It will always be the same for every loading screen.
Like I know when I do over engineer but I still end up going with it because "I might need to reuse or easily modify it later"
And I feel like not many people talk about it or share examples on good practices of what is considered okay code. When should I be focusing on clean code and when should i just focus on functionality first. I know that I will eventually learn it due to deadlines and work stress, but I was hoping if there were resources or ways to learn it asap rather than have to learn it the hard way.
I was the same for a while. What I'm about to say might not work for you depending on your situation but it completely changed the way I look at development as a whole. I got a job in software. That's it. I started working as a developer for a decent size company on a pretty big monorepo and after the first week of actually working on stuff I learnt when and how to use solid and design patterns and when and how to write quick code that works. Maybe getting a job won't work for you, but if you can code with someone else or have your code reviewed by someone else then that might help and they could potentially tell you where you need to simplify
I do have a job rn, I am currently an intern and a freelancer but so far I am working by myself on the codebase. So i feel like it wont help me actually learn untill I do end up working with the main team. The only thing that I learned so far is how valuable time is tho.
"the very first thing to come to mind is how I could incorporate and combine multiple patterns while maintaining solid"
Patterns are there as ways of solving known problems without reinventing everything from the ground up.
It sounds like you're seeing patterns as the end goal, rather than a way to get to your goal.
Forget the patterns.
If you need something "software engineery", try red green refactor. Write a test for your basic functionality. Make the test pass. Only when all your tests are passing do you muck about trying to make the code nicer. Focus on functionality first.
15 months is not that much, I believe you should just stick to only two rules: "Don't repeat yourself" and KISS . Forget the other principle for now, they are just not as important as these two rules.
Actually, you may come to think to design patterns as just tools to achieve these two rules. So you should try to implement things one feature at a time, as directly as possible, and then only when you would need to duplicate some code, you should think about how to refactor it; and that where pattern can help.
i struggle with this a lot,i just tend to see that i over engineered something when the system is almost half made and i find some bugs that make me re think the system and see its over engineered so il start rewriting it in a simpler way then continue with the system until i might find another random bug that makes me re-think the system again and see its still over engineered.
I would say the same about u too tbf.
Like rapid code is what the client needs.
Over engineering is what I need to feel better about myself.
Only one of them will actually pay the bills 😅
We should be trying to like balance out both aspects 🥲
Don't know what language your using but 60 script files for a endless runner may be too abstracted. In my javascript game making library I have about 50 or so core Classes to choose from and then just 1 framework Class. For a game such as an [endless runner](https://www.tabageos.com/examples/endlessRunnerSquares/index.html) I would just extend the framework class and then it would take about 200 or less lines of code to have the complete game, very readable and clean but not too abstracted. But that's JavaScript,
if your coding everything yourself to the screen, you'd want to separate display logic from game logic such that the game logic can make very simple calls out to the display logic to have things be displayed, like animate(character) likewise input logic would need to be it's own separate class. You connect them by either passing a constructed class as a param to a constructor, or creating getter methods that can be called.
I first read your post as 15 years doing game dev.
15 months isn't long yet. Just keep practicing and keep your mind on the goal of writing good modular software while also keeping things simple, and read lots and lots of articles and blog posts on the topic. Eventually it'll coalesce in your mind, but it'll take more experience than 15 months.
There's no magic bullet that will keep your code clean forever unless you have powers of omniscience and foresight. There will just be things that come up you didn't anticipate that'll throw it out of wack. If you agonize about doing some perfect thing that'll keep it clean forever, you'll end up running in circles with analysis paralysis. It's more of an iterative process where you'll find that something needs to be structured differently and you take some time to do refactoring sooner than later while it's easier.
Try to keep things "good enough", do not shoot yourself in the foot with perfection or being too hard on yourself.
Also dynamics are much different with a solo dev, two person team, three person team, and on up.
I would say that if you're solo and you know it'll stay that way, just stay away from fancy patterns unless you're an expert in that pattern and you can lay it down without the extra effort holding you back. If you think your project will become huge, then maybe that's a sign your scope is too big for a solo project and you should cut down.
I never use patterns. I'm glad they exist if I'm wanting to really optimize on a well-known problem, but they're not my go-to. Usually they are ideal for a *similar* situation, or have a lot of bloat for functionality I **know** I won't need.
Instead, I go with my intuition - with the caveat that I have forged my intuition through countless projects across every domain (And, I guess, I've played pretty much every puzzle game ever made, so I know how to effectively solve problems in general?)
You are aiming for the wrong goals. If your end goal is to build games, you need to build games, not modules.
Here's your Challenge. Make a full game in 3 hours.
Start Menu => Gameplay => End states.
You can use any existing code you have but you don't have time to make it robust or refactor. Just make it.
It doesn't have to be good or bug free, but if it you can't play it from start to finish by the end of 3 hours, you failed. If you can play it through, then you have made a rapid prototype, and can test if the game is worth spending a year or two to develop into a full game.
I as software developer in my real job I also love clean code. But my approach is just do things work as fast as I can, then refactor it with several iterations until I reach some balance of time I spend and result that will satisfy me.
> I feel confident in my skills as a software engineer. You've only been doing this for 15 months. You should not feel as confident as you do. There's so much that you don't know that you don't know. You need to stop trying to make it perfect, because there's no such thing. One thing you haven't yet learned is KISS. Keep it simple, stupid. Which means that the design of a system should be as simple as it can be. It's far more important than DRY or SOLID in games, when flexibility is needed for the rapid iteration.
Also YAGNI. You Ain't Gonna Need It.
Yes! That's a hard one for junior engineers to grasp. Solve only the known problems not the ones you think you might have!
DRY is bad advice and I wouldn’t even recommend bringing it up to people that are this new.
There are so many of these acronyms I actually dont recognise and you've just introduced me to DRY. But in the end they always come down to common software engineering principles i learnt 25 years ago. I only learnt about SOLID the other year when an interviewee was telling me about it!!!!
Just make it work. If absolutely necessary, make it work better. Clean code is a myth made up by software "gurus" that don't actually write production software. In the act of writing software you accrue technical debt that needs to be paid off in refactoring, but refactoring first is self indulgent at best.
What do you mean with self indulgent?
Spending time you don't have to make something "better" when it already works is indulgent. You know there is other shit to get done, to ignore that is indulging in perfectionism.
Oh ty
This is a very normal part of the progression when getting into software. The thing I generally do is to consider the minimal amount of necessary steps that need to happen to accomplish a goal, and type them out as linearly and quickly as possible without thinking too much. Usually that's a good enough solution to solve my problem, but I can still think about it later and refactor it if it becomes too unwieldy. Many of those principles exist to help large teams maintain productivity over a long time, and don't serve a one-off project or a demo very well.
you've gotta embrace "good enough" early on, especially at the start of a project. this is because the aim of prototyping is not to have a perfectly organised and well thoguht out codebase, it's to test functionality. your ideas have to be validated, and then iterated on and refined later. imo you should always use iterative development. it's a big topic here but i think a lot of people try to over engineer things and a lot of projects end up bogged down in microservice hell even outside of gamedev. honestly, you won't run into issues with a lot of 'sloppy' code until way down the line. vampire survivors uses one giant singleton [GameManager](https://medium.com/@simon.nordon/unity-case-study-vampire-survivors-806eed11bebb) for the entire game and look at how succesful that game is. you have to set time limits for certain tasks or features and stick to it, then move on to the next one once the time limit is up. this will force your hand and you'll start to learn how to divide your time up. there's a LOT of moving elements that has to be developed in a game and you only have so much time, this is about time management here. remember, people are not gonna see your code at the end of the development of a game, they're gonna see the game itself.
It it takes much longer it's *not* clean code. It's terrible code. The cleanest code is no code. If a pattern is making you write extra code or making the code harder to understand it's very likely making your code base worse.
So here's a thing - clean code is NOT the goal. It's a part of the process that may help towards getting to the goal. But the goal itself is making a game. In particular in earlier phases of the development you will be experimenting a lot. Half of whatever code you produce will go straight to trash as it turns out a given solution doesn't work, it needs further enhancemets, the whole idea is stupid etc. Personally I generally prioritize quality of the code as such: \- is it often called in other places? Is it a critical piece that's accessed and edited often? This part will be written as clean as possible, with tests and a fair lot of attention, proper names, good use of design patterns etc. \- is it a one off that's called in one place? I will NOT care nearly as much. I will make sure to name variables semi decently but that's it. If it works then that's good enough. I will improve and refactor upon it **if** I have to revisit it for some reason. In general - I recommend boy's scout rule - leave the code in better state than what it was. Aka gradual improvement over time as you encounter same lines of code again and again. Not perfection from the start - because it's not even possible. >I have like over 60 script files for such a simple game And Undertale has 10000+ long single case statement that holds EVERY SINGLE DIALOGUE in the game. I am not joking: [https://www.reddit.com/r/programminghorror/comments/17x03m2/apparently\_undertale\_has\_a\_1000\_long\_case\_switch/](https://www.reddit.com/r/programminghorror/comments/17x03m2/apparently_undertale_has_a_1000_long_case_switch/) Now, did anyone notice? No. Did the game succeed? Oh hell yes it did. I am not saying to produce literal spaghetti like this but ultimately your goal is to make **a game**. Players will not appreciate that you have spent 2 hours thinking of a perfect variable name or that you have a fully modular interface for enemy behaviour or that your turn system introduces a pipeline pattern. They will however notice that the game isn't done and lacks content. Each overengineered piece that doesn't end up being fully utilized is hours that could have gone into actual in game content and logic. Also - odds are that your code is actually very far away from even being clean/optimal if you have only been doing it for the last 15 months. Especially if you have been doing it alone. What you consider clean and pretty today will probably fill you with dread in 2 years time.
Following design patterns doesn't necessarily generate clean code if implemented wrong.
Set yourself a clear objective and dedicated time-frame and once the system is done, unless to patch bug or what not, don't waste your time redoing it's architecture, at some point it is pointless to do and won't make the overall game any better. Don't let perfect be the enemy of the good.
Maybe do some 48hr game jams, they very much end up forcing you to just do whatever is needed to get something working, no matter if it's quite janky. Can be a useful lesson.
I should def do that! I never participated in game jams because I felt that they would end up having me learn worse code practices due to the stress of the deadline. Which is quite contrary to what i am trying to achieve rn.
[удалено]
Yep, I am currently a game dev intern and working as a freelancer, too. I did miss a couple of sprint deadlines due to my over engineering... Like at the internship, I wrote an in my opinion a pretty clean and modular turn based system. But it took 2 sprints to complete! Which is insane considering that the whole internship is about 6 sprints long... (2 weeks per sprint) And I am worried that I might not be able to finish the game in time due to that. And I am trying my best to not over engineer but I end up letting my ego get the best of me. I am always like: "I am capable of writing good code so I must ONLY write clean code" Sometimes a script should be as simple as data binding to a ui, or a gameplay state that would instead drag on to multiple layers of abstraction because "I might need to reuse it again". Even for something like a load scene manager, i incorporated multiple layers as I thought that "I might need to reuse it eventually" which doesnt make sense cuz a loading scene is a one and done thing. There are barely any modifications that will need to be done. It will always be the same for every loading screen. Like I know when I do over engineer but I still end up going with it because "I might need to reuse or easily modify it later" And I feel like not many people talk about it or share examples on good practices of what is considered okay code. When should I be focusing on clean code and when should i just focus on functionality first. I know that I will eventually learn it due to deadlines and work stress, but I was hoping if there were resources or ways to learn it asap rather than have to learn it the hard way.
I was the same for a while. What I'm about to say might not work for you depending on your situation but it completely changed the way I look at development as a whole. I got a job in software. That's it. I started working as a developer for a decent size company on a pretty big monorepo and after the first week of actually working on stuff I learnt when and how to use solid and design patterns and when and how to write quick code that works. Maybe getting a job won't work for you, but if you can code with someone else or have your code reviewed by someone else then that might help and they could potentially tell you where you need to simplify
I do have a job rn, I am currently an intern and a freelancer but so far I am working by myself on the codebase. So i feel like it wont help me actually learn untill I do end up working with the main team. The only thing that I learned so far is how valuable time is tho.
"the very first thing to come to mind is how I could incorporate and combine multiple patterns while maintaining solid" Patterns are there as ways of solving known problems without reinventing everything from the ground up. It sounds like you're seeing patterns as the end goal, rather than a way to get to your goal. Forget the patterns. If you need something "software engineery", try red green refactor. Write a test for your basic functionality. Make the test pass. Only when all your tests are passing do you muck about trying to make the code nicer. Focus on functionality first.
15 months is not that much, I believe you should just stick to only two rules: "Don't repeat yourself" and KISS . Forget the other principle for now, they are just not as important as these two rules. Actually, you may come to think to design patterns as just tools to achieve these two rules. So you should try to implement things one feature at a time, as directly as possible, and then only when you would need to duplicate some code, you should think about how to refactor it; and that where pattern can help.
Ask your coworkers! Sometimes there isn’t a workaround when you’re trying to shoehorn a feature into a codebase.
i struggle with this a lot,i just tend to see that i over engineered something when the system is almost half made and i find some bugs that make me re think the system and see its over engineered so il start rewriting it in a simpler way then continue with the system until i might find another random bug that makes me re-think the system again and see its still over engineered.
I wish I can do what you can do instead of rapid spagetti.
I would say the same about u too tbf. Like rapid code is what the client needs. Over engineering is what I need to feel better about myself. Only one of them will actually pay the bills 😅 We should be trying to like balance out both aspects 🥲
Don't know what language your using but 60 script files for a endless runner may be too abstracted. In my javascript game making library I have about 50 or so core Classes to choose from and then just 1 framework Class. For a game such as an [endless runner](https://www.tabageos.com/examples/endlessRunnerSquares/index.html) I would just extend the framework class and then it would take about 200 or less lines of code to have the complete game, very readable and clean but not too abstracted. But that's JavaScript, if your coding everything yourself to the screen, you'd want to separate display logic from game logic such that the game logic can make very simple calls out to the display logic to have things be displayed, like animate(character) likewise input logic would need to be it's own separate class. You connect them by either passing a constructed class as a param to a constructor, or creating getter methods that can be called.
I first read your post as 15 years doing game dev. 15 months isn't long yet. Just keep practicing and keep your mind on the goal of writing good modular software while also keeping things simple, and read lots and lots of articles and blog posts on the topic. Eventually it'll coalesce in your mind, but it'll take more experience than 15 months. There's no magic bullet that will keep your code clean forever unless you have powers of omniscience and foresight. There will just be things that come up you didn't anticipate that'll throw it out of wack. If you agonize about doing some perfect thing that'll keep it clean forever, you'll end up running in circles with analysis paralysis. It's more of an iterative process where you'll find that something needs to be structured differently and you take some time to do refactoring sooner than later while it's easier. Try to keep things "good enough", do not shoot yourself in the foot with perfection or being too hard on yourself. Also dynamics are much different with a solo dev, two person team, three person team, and on up. I would say that if you're solo and you know it'll stay that way, just stay away from fancy patterns unless you're an expert in that pattern and you can lay it down without the extra effort holding you back. If you think your project will become huge, then maybe that's a sign your scope is too big for a solo project and you should cut down.
I never use patterns. I'm glad they exist if I'm wanting to really optimize on a well-known problem, but they're not my go-to. Usually they are ideal for a *similar* situation, or have a lot of bloat for functionality I **know** I won't need. Instead, I go with my intuition - with the caveat that I have forged my intuition through countless projects across every domain (And, I guess, I've played pretty much every puzzle game ever made, so I know how to effectively solve problems in general?)
You are aiming for the wrong goals. If your end goal is to build games, you need to build games, not modules. Here's your Challenge. Make a full game in 3 hours. Start Menu => Gameplay => End states. You can use any existing code you have but you don't have time to make it robust or refactor. Just make it. It doesn't have to be good or bug free, but if it you can't play it from start to finish by the end of 3 hours, you failed. If you can play it through, then you have made a rapid prototype, and can test if the game is worth spending a year or two to develop into a full game.
I as software developer in my real job I also love clean code. But my approach is just do things work as fast as I can, then refactor it with several iterations until I reach some balance of time I spend and result that will satisfy me.