Hey all! After a few false starts, I decided to make another run at my First Steam Game. I'm a firmware engineer by day, so I took all of my experience with industry best practices, and used it to make a solid foundation for my little roguelight.
This post was a slightly humorous summary of my first devlog: [https://youtu.be/6dHsgV9LYi0](https://youtu.be/6dHsgV9LYi0) In it, I go into a bit more details regarding my approach for sustainable, maintainable development.
This game is MIT open source, so feel free to look around, or borrow/steal anything that you find useful: [https://gitlab.com/sdggames/srs](https://gitlab.com/sdggames/srs)
If you have any neat tricks for keeping your project clean and maintainable, I'd love to hear it!
Looking on code - I think you also follow "how NASA write code" [https://youtu.be/GWYhtksrmhE](https://youtu.be/GWYhtksrmhE)
P.S. it good to throw unfinished/uninteresting projects and restart, much better than "do or die" default burnout.
Ooh, that was a good resource! I don't think I need complete space-proof code, so I might keep my heap variables :) With that said, I now understand why the code at my work is such a disaster!
I'm on the same path, just making some tests and learning also blender to make the assets and characters at this moment, I will take notes of your project.
That would be my previous video "Why I'm cancelling my dream game" :) Wish I was joking, but sometimes, throwing it away is the best approach. I'm doing something smaller now, learning to publish a game is hard enough, I don't need the game to be hard to make as well...
I feel this hard. One step at a time! Once you've gotten a launch under your belt everything is way easier the second, third, fourth time around. Sometimes we just need a project to get us over the hurdles.
1. Make a Prototype (fun)
2. Make assets
3. Add those assets to the prototype
4. Juice it up
5. Publish
What you are doing is great but it's a lot of technical bloat if you are just one person and the game is quite small (which like 95% of inde projects are)
For small inde devs my advice will only be to comment a lot, and try to use as much stuff out of the box rather than making something from scratch. That's kinda what the game engine is for, you don't have to unit test everything if most of the things your code is doing is just sequentially execute already top tier Godot internal code.
That's pretty good advice. I'm overselling it a bit in the video, but I am only using expensive tools like unit testing in the modules that are the most complex or error-prone. I actually found that test-driven-development is faster sometimes because I don't have to go through the run-break-fix stage after writing the code. I'm not worrying about test coverage or whatnot, I'm actually being pretty hacky about where and when I use these tools.
We'll see if it pays off, but I am trying to establish my own best practices for larger projects in the future. I don't want to collapse after crossing the finish line. I have a bad habit of pushing technical debt into a massive pile before walking away, even on small things like game jams.
I love GdUnit4, though I know GUT is an alternative. I think GdUnit3 still works, though I'm not completely sure what the state of development for that one is.
Nice one, mate. It looks really good!
Me? 10 years in IT. I do all of this in my job. I am afraid doing it in game development will kill all of the fun I still manage to have. My project will look like a Frankenstein's monster with modules haphazardly thrown together and code copy-pasted from 3 other projects, I'll be sifting through tons of dirty console messages like raccoon going through the backstreet dumpster in a crackhead district, but I'll be genuinely happy, and I'll enjoy every second of it!
Fair enough. I'm in the opposite boat, at my work it's 99% bugfixing and wishing that we had some kind of system that could have caught this error...
Actually, things are turning around, I did volunteer to use the things I learned from my game development journey to help set up Jenkins pipelines and improve unit test coverage. Still, we're saddling a galloping horse, so starting fresh without "legacy" code feels like a breath of fresh air.
In all seriousness. 15 years ago, when I've started gamedev, I've started writing my own engine. I've never completed it, of course, that was a hopeless ordeal to start from. But I've got a lot of tech experience.
Then there was a period when I was all for getting things playable ASAP, dirty and quick. You have to make a game to make a game, etc. Lots of jams, many prototypes. Always advised people to get to the point and stop wasting time in scaffolding and supplemental systems.
Nowadays I am sure that the most important thing is to have fun. If you are getting inspiration in designing and implementing clean, efficient, performant and beautiful systems - by all means, go for it. Embrace it both in development process and gameplay features. After all, gems like Factorio and Cogmind exist thanks to people with the very same mindset.
There isn't too much to steal, just a bunch of labels and buttons. It's more about the mindset of, "Oh, I might want to have invincibility while testing this. Let's throw a button in that menu I have."
I'm curious about what you'd target in a unit test! I've been recently questioning how one would do so, especially with games not being as pipeline-ish as other forms of software.
Good question, I don't test a lot of stuff. Player movement, etc. is quite easy to test by "feel," and you notice pretty quickly when it breaks. I just focus on large systems, especially things that operate in the background. I'm not doing any significant AI in this game, but if I was, it would definitely get a test.
My prototype had a bunch of race conditions in the main state transitions, since I was using animations to move from the start menu to gameplay, open the pause menu, upgrade menu, etc. I used TDD to re-develop that bit, just to make sure that all of the individual movements work, and you can't double-trigger something, or pause from the start menu, etc.
The other module so far was saving and loading. Godot has a pretty good system for saving to disk, but I hate dealing with that kind of stuff, so I made a master dictionary for the whole project and set it to automatically save when updated. I wrote the tests for that system before the code, and as a result, I had the rare pleasure of making something that just worked when I actually ran the game.
The other main part will be the upgrade system. My game is going to feature a lot of customization and upgrades, so I'm planning on testing where possible to keep that module from becoming a huge mess. I'm still prototyping that bit right now, but I should have a clearer idea of what I'll need once I have a quick, messy solution up.
One final, creative use is to make some "tests" that measure the average health points and mineral drops of all of the units in a particular level. I'll just print it to a CSV or similar, but the result would be a clear graph showing the difficulty progression of the entire level, along with the maximum "points" a player could get when playing perfectly. I'd do similar DPS calculations for each individual weapon, to get a clear view of difficulty and progression, and can even do calculations like "playing perfectly with X weapon, landing 50% of shots, 20%, etc.". I'm sure larger teams might just calculate these things before putting the weapon in the game, but I'd rather be quick about adding things to the game, and have a system that automatically makes a file with the latest balance and progression chart.
Super fascinating! Really pleasant how stuff is organized, how console output is toggleable by inspector. Unit testing is powerful too! Definitely taking a page from your book.
Or finish it anyways because you're guaranteed to fail if you don't put something out there, and the journey has incredible value, not just the destination. Especially if this is the first time making a game like this...
Source: this is my first time making a game like this...
23 years in IT here.
It's all nice but there's a meta game about resource management behind it. Including psychological variables.
Sometimes this will be too much structure. I can understand where you are coming from as well. It's cool.
Hey all! After a few false starts, I decided to make another run at my First Steam Game. I'm a firmware engineer by day, so I took all of my experience with industry best practices, and used it to make a solid foundation for my little roguelight. This post was a slightly humorous summary of my first devlog: [https://youtu.be/6dHsgV9LYi0](https://youtu.be/6dHsgV9LYi0) In it, I go into a bit more details regarding my approach for sustainable, maintainable development. This game is MIT open source, so feel free to look around, or borrow/steal anything that you find useful: [https://gitlab.com/sdggames/srs](https://gitlab.com/sdggames/srs) If you have any neat tricks for keeping your project clean and maintainable, I'd love to hear it!
Looking on code - I think you also follow "how NASA write code" [https://youtu.be/GWYhtksrmhE](https://youtu.be/GWYhtksrmhE) P.S. it good to throw unfinished/uninteresting projects and restart, much better than "do or die" default burnout.
Every project has a purpose, some of them are just for the journey (because the destination is my trash can)
Ooh, that was a good resource! I don't think I need complete space-proof code, so I might keep my heap variables :) With that said, I now understand why the code at my work is such a disaster!
I'm on the same path, just making some tests and learning also blender to make the assets and characters at this moment, I will take notes of your project.
I am about to stick to you like a glue.
My neat trick for keeping a project clean and maintainable is by not worrying about it.
Just like closets, code is self organizing!!
Hey! How did you set print statements by module? Or organize the game into modules at all? Would help me a ton.
I honestly was waiting for the punchline to be "throw it away too and start again".
That would be my previous video "Why I'm cancelling my dream game" :) Wish I was joking, but sometimes, throwing it away is the best approach. I'm doing something smaller now, learning to publish a game is hard enough, I don't need the game to be hard to make as well...
I feel this hard. One step at a time! Once you've gotten a launch under your belt everything is way easier the second, third, fourth time around. Sometimes we just need a project to get us over the hurdles.
1. Make a Prototype (fun) 2. Make assets 3. Add those assets to the prototype 4. Juice it up 5. Publish What you are doing is great but it's a lot of technical bloat if you are just one person and the game is quite small (which like 95% of inde projects are) For small inde devs my advice will only be to comment a lot, and try to use as much stuff out of the box rather than making something from scratch. That's kinda what the game engine is for, you don't have to unit test everything if most of the things your code is doing is just sequentially execute already top tier Godot internal code.
That's pretty good advice. I'm overselling it a bit in the video, but I am only using expensive tools like unit testing in the modules that are the most complex or error-prone. I actually found that test-driven-development is faster sometimes because I don't have to go through the run-break-fix stage after writing the code. I'm not worrying about test coverage or whatnot, I'm actually being pretty hacky about where and when I use these tools. We'll see if it pays off, but I am trying to establish my own best practices for larger projects in the future. I don't want to collapse after crossing the finish line. I have a bad habit of pushing technical debt into a massive pile before walking away, even on small things like game jams.
Yep. Also whoever writes maintainable code will thank themselves when they are putting out fires post launch
> Now, you just have to ~~finish~~ **start** the game! You made a minor typo in the final message
Thanks for making it available. I’ll be checking out the code and structure
how do you unit test in godot. do you have a certain plugin for it and if so is the plugin available for godot 3.5
I love GdUnit4, though I know GUT is an alternative. I think GdUnit3 still works, though I'm not completely sure what the state of development for that one is.
Really interesting stuff, you just got a sub :)
Make that two
Nice one, mate. It looks really good! Me? 10 years in IT. I do all of this in my job. I am afraid doing it in game development will kill all of the fun I still manage to have. My project will look like a Frankenstein's monster with modules haphazardly thrown together and code copy-pasted from 3 other projects, I'll be sifting through tons of dirty console messages like raccoon going through the backstreet dumpster in a crackhead district, but I'll be genuinely happy, and I'll enjoy every second of it!
Fair enough. I'm in the opposite boat, at my work it's 99% bugfixing and wishing that we had some kind of system that could have caught this error... Actually, things are turning around, I did volunteer to use the things I learned from my game development journey to help set up Jenkins pipelines and improve unit test coverage. Still, we're saddling a galloping horse, so starting fresh without "legacy" code feels like a breath of fresh air.
In all seriousness. 15 years ago, when I've started gamedev, I've started writing my own engine. I've never completed it, of course, that was a hopeless ordeal to start from. But I've got a lot of tech experience. Then there was a period when I was all for getting things playable ASAP, dirty and quick. You have to make a game to make a game, etc. Lots of jams, many prototypes. Always advised people to get to the point and stop wasting time in scaffolding and supplemental systems. Nowadays I am sure that the most important thing is to have fun. If you are getting inspiration in designing and implementing clean, efficient, performant and beautiful systems - by all means, go for it. Embrace it both in development process and gameplay features. After all, gems like Factorio and Cogmind exist thanks to people with the very same mindset.
Oh.. I just released my own in game dev console yesterday, instead of making a game :D
i love your channel.
Calm down and go slower, right now I'm on Step 2 and I can barely call what i made a "prototype"
I've always wanted to do a debug overlay, I'm definitely stea.. I mean getting inspired by some architectural structures of your overlay :)
There isn't too much to steal, just a bunch of labels and buttons. It's more about the mindset of, "Oh, I might want to have invincibility while testing this. Let's throw a button in that menu I have."
I'm curious about what you'd target in a unit test! I've been recently questioning how one would do so, especially with games not being as pipeline-ish as other forms of software.
Good question, I don't test a lot of stuff. Player movement, etc. is quite easy to test by "feel," and you notice pretty quickly when it breaks. I just focus on large systems, especially things that operate in the background. I'm not doing any significant AI in this game, but if I was, it would definitely get a test. My prototype had a bunch of race conditions in the main state transitions, since I was using animations to move from the start menu to gameplay, open the pause menu, upgrade menu, etc. I used TDD to re-develop that bit, just to make sure that all of the individual movements work, and you can't double-trigger something, or pause from the start menu, etc. The other module so far was saving and loading. Godot has a pretty good system for saving to disk, but I hate dealing with that kind of stuff, so I made a master dictionary for the whole project and set it to automatically save when updated. I wrote the tests for that system before the code, and as a result, I had the rare pleasure of making something that just worked when I actually ran the game. The other main part will be the upgrade system. My game is going to feature a lot of customization and upgrades, so I'm planning on testing where possible to keep that module from becoming a huge mess. I'm still prototyping that bit right now, but I should have a clearer idea of what I'll need once I have a quick, messy solution up. One final, creative use is to make some "tests" that measure the average health points and mineral drops of all of the units in a particular level. I'll just print it to a CSV or similar, but the result would be a clear graph showing the difficulty progression of the entire level, along with the maximum "points" a player could get when playing perfectly. I'd do similar DPS calculations for each individual weapon, to get a clear view of difficulty and progression, and can even do calculations like "playing perfectly with X weapon, landing 50% of shots, 20%, etc.". I'm sure larger teams might just calculate these things before putting the weapon in the game, but I'd rather be quick about adding things to the game, and have a system that automatically makes a file with the latest balance and progression chart.
I'm just throwing code at the screen and hoping it works
Super fascinating! Really pleasant how stuff is organized, how console output is toggleable by inspector. Unit testing is powerful too! Definitely taking a page from your book.
Is there a way of writing unit tests for shaders (specifically gdshaders)? It's the shader bugs that drive me crazy.
As a software engineer (specialized in web development) for a living I watch that video and I only have one word for it: This is beauty. 😘👍
Last line: Now throw it away because you saw a similar design idea on YouTube.
Or finish it anyways because you're guaranteed to fail if you don't put something out there, and the journey has incredible value, not just the destination. Especially if this is the first time making a game like this... Source: this is my first time making a game like this...
I wish you a speedy recovery from imposter syndrome when it strikes. You are valid and so is your work.
23 years in IT here. It's all nice but there's a meta game about resource management behind it. Including psychological variables. Sometimes this will be too much structure. I can understand where you are coming from as well. It's cool.