Gamedev from Scratch 1: Scaffolding(eev.ee)
eev.ee
Gamedev from Scratch 1: Scaffolding
https://eev.ee/blog/2021/01/26/gamedev-from-scratch-1-scaffolding/
11 comments
forget TDD when you make a game, you want fast iteration time at all cost, gameplay is king, if you can't nail it fast enough, you'll make a bad game that is not fun
it's all about the feeling
Celeste's player class: https://github.com/NoelFB/Celeste/blob/master/Source/Player/...
https://store.steampowered.com/app/504230/Celeste/
it's all about the feeling
Celeste's player class: https://github.com/NoelFB/Celeste/blob/master/Source/Player/...
https://store.steampowered.com/app/504230/Celeste/
100%. tbh if you want to deliver value in any scenario you skip TDD and anything that smells of agile or scrum.
Just deliver.
Just deliver.
Yes. Your userbase will not give a single shit about how thoroughly tested your game is or how elegant your code is. Mainly since you'll give up on it long before they ever see it.
It's a game. Treat it like one.
TDD is great for your day job, where you ship bulletproof software for work. Nobody does work for fun. Look at how many games are written in Java.
For a personal project, only write unit tests to ensure specific bugs get fixed. No more. This ensures you do the least possible amount of Work.
In the end, you'll say holy shit, I have a ton of bugs to fix-- that guy was full of shit. But you'll have a functional game to fix the bugs on within a year, rather than a pile of exquisite code that does nothing after a decade.
It's a game. Treat it like one.
TDD is great for your day job, where you ship bulletproof software for work. Nobody does work for fun. Look at how many games are written in Java.
For a personal project, only write unit tests to ensure specific bugs get fixed. No more. This ensures you do the least possible amount of Work.
In the end, you'll say holy shit, I have a ton of bugs to fix-- that guy was full of shit. But you'll have a functional game to fix the bugs on within a year, rather than a pile of exquisite code that does nothing after a decade.
sounds very similar to the arguments made against tests in a work setting.
Test as appropriate for your needs and goals. Adjust over time. There is no need to artificiality skew the balance in either setting.
Test as appropriate for your needs and goals. Adjust over time. There is no need to artificiality skew the balance in either setting.
> sounds very similar to the arguments made against tests in a work setting
I tried to be clear about that. Sloppiness at work could kill someone or bankrupt the company. You're being paid to be a professional, so be a professional and write tests.
You only have so much free time to achieve your dreams. Cut every corner you can to make it happen.
I tried to be clear about that. Sloppiness at work could kill someone or bankrupt the company. You're being paid to be a professional, so be a professional and write tests.
You only have so much free time to achieve your dreams. Cut every corner you can to make it happen.
i dont think TDD is wrong for game development - it's a matter of balance.
You don't TDD a game mechanic as soon as you make it - you can wait until you're reasonably sure, and then use TDD to flesh out the corner cases.
You can also TDD at the lower level - such as your LOD algorithm, or culling algo, etc; these don't really change much once you know you need them.
You don't TDD a game mechanic as soon as you make it - you can wait until you're reasonably sure, and then use TDD to flesh out the corner cases.
You can also TDD at the lower level - such as your LOD algorithm, or culling algo, etc; these don't really change much once you know you need them.
How do you TDD a graphics shader, or how an explosion progates across the screen?
Remmeber, don't write production code without a failing test first.
Remmeber, don't write production code without a failing test first.
I see your point that there are some thing that seem awkward for testing. It’s a good and interesting one that really should be considered. Game software is replete with examples like these.
But just to attempt… to TDD a graphics shader one would have to consider the side effects of the shader to be able to craft a test for it.
And then to reverse once again, given a graphics shader is typically up to the vis artist and that artist would need to muck around to find what looks good, it almost doesn’t make sense to write a test at the beginning.
For me, I don’t typically write non-disposable write tests on my shaders. I just make the simple shaders. If it’s a tricky shader, or I want to capture a funky edge case, I’ll write a disposable test so I can try to iterate faster on the shader. Running a test that takes 1-2 seconds to see results for each iteration of code is faster (for me) than waiting 20-30 seconds for Unity to load my test scene. I still have to visually check it at the end of the process but I find for my workflow it helps me go faster.
I wouldn’t dare say “it’s good for me, therefore everyone needs to do it.” I’m just sharing my experience.
But just to attempt… to TDD a graphics shader one would have to consider the side effects of the shader to be able to craft a test for it.
And then to reverse once again, given a graphics shader is typically up to the vis artist and that artist would need to muck around to find what looks good, it almost doesn’t make sense to write a test at the beginning.
For me, I don’t typically write non-disposable write tests on my shaders. I just make the simple shaders. If it’s a tricky shader, or I want to capture a funky edge case, I’ll write a disposable test so I can try to iterate faster on the shader. Running a test that takes 1-2 seconds to see results for each iteration of code is faster (for me) than waiting 20-30 seconds for Unity to load my test scene. I still have to visually check it at the end of the process but I find for my workflow it helps me go faster.
I wouldn’t dare say “it’s good for me, therefore everyone needs to do it.” I’m just sharing my experience.
That doesn’t sound like “test driven development” it’s just automated testing.
I wish there was a better word. I do TDD when it makes sense, but also write a test afterwards if that makes sense.
I’m personally not strict about TDD. Maybe pragmatic testing development (PTD)? And this is indeed because people have surfaced legit critiques about testing on game software (disposability of the game software, radical sweeping changes of the codebase, etc).
The critiques people have surfaced in response to my OP are valid too in general… but for me I’m trying to embrace a zen of automated testing where I want to do it by default but won’t let it block me from delivery. There just seems to be unconsidered value in writing certain genres of automated tests.
E.g. I’m fine writing a test that asserts behavior on “prefabs” (like classes, whereas instances of the class are game objects in a scene (for those not in the know)) instead of on individual components. This is from experience; the prefab’s behavior typically doesn’t change even if the underlying composition of components might radically change.
I’m personally not strict about TDD. Maybe pragmatic testing development (PTD)? And this is indeed because people have surfaced legit critiques about testing on game software (disposability of the game software, radical sweeping changes of the codebase, etc).
The critiques people have surfaced in response to my OP are valid too in general… but for me I’m trying to embrace a zen of automated testing where I want to do it by default but won’t let it block me from delivery. There just seems to be unconsidered value in writing certain genres of automated tests.
E.g. I’m fine writing a test that asserts behavior on “prefabs” (like classes, whereas instances of the class are game objects in a scene (for those not in the know)) instead of on individual components. This is from experience; the prefab’s behavior typically doesn’t change even if the underlying composition of components might radically change.
TDD is faster iteration. You’d rather run the entire game to test a single function you’re writing than run a unit test in a fraction of a second?
What you said has absolutely nothing to do with TDD. What you described is just automated test, which is a good thing.
TDD means you write a failing test case first before you write the actual function. You don't need TDD to "run a unit test to test a function in a fraction of a second".
TDD is only good when the spec is unambiguously defined (either in your mind, or written by a product designer). For example if you need a function that tests whether two AABBs are overlapped, TDD is perfect. But in game development, sometimes the spec is just "write a water shader that looks good enough", and "good enough" is not unambiguously defined. Therefore TDD is bad in this case.
TDD means you write a failing test case first before you write the actual function. You don't need TDD to "run a unit test to test a function in a fraction of a second".
TDD is only good when the spec is unambiguously defined (either in your mind, or written by a product designer). For example if you need a function that tests whether two AABBs are overlapped, TDD is perfect. But in game development, sometimes the spec is just "write a water shader that looks good enough", and "good enough" is not unambiguously defined. Therefore TDD is bad in this case.
Sounds like snapshot test driven development would work well in that case though:
https://hitchdev.com/hitchstory/approach/snapshot-test-drive...
Write a scenario that uses a new water shader - eyeball it - if it's good then "fix" the snapshot and pass it around.
Repeat with a few other scenarios to see it performing under all relevant circumstances.
It can be a bit tricky if the result of the shader is not deterministic - but there are sensible ways of dealing with that.
https://hitchdev.com/hitchstory/approach/snapshot-test-drive...
Write a scenario that uses a new water shader - eyeball it - if it's good then "fix" the snapshot and pass it around.
Repeat with a few other scenarios to see it performing under all relevant circumstances.
It can be a bit tricky if the result of the shader is not deterministic - but there are sensible ways of dealing with that.
You can't unit test fun.
TDD may be helpful later, but as long as you don't yet have a fun gameplay loop everything else is a distraction.
TDD may be helpful later, but as long as you don't yet have a fun gameplay loop everything else is a distraction.
I don’t know about this… If a game designer can articulate fun and what it means in the game, a test can assert the side effects of the system align with the game designer’s expectations.
Finding the fun, though…
Finding the fun, though…
Like really? 80% of tests I read are crap anyway. Just crap written to pass the test coverage detection.
For basic CRUD and simple business logic I see TDD work. But for example most projects I work on I have no clue what or no clue how to do it. I just write code, play around get new ideas and build upon that. It changes so frequent and is so exploratory that I can not be bothered writing any tests.
Once I "get it" I write some tests. Mostly I understand also what will need tests and what not. Personally I think this if fine.
Online everyone is writing the ideal situation. I know what to deliver, I know how to do it and this is the perfect way to do it. Mostly it is I have taken loads of assumption and figuring it out as I go. Fuck it needs to be done don't have time to "optimize" it to look perfect.
Maybe I'm just not a good developer. But I shipped enough value in my lifetime to know I'm good enough ;)
For basic CRUD and simple business logic I see TDD work. But for example most projects I work on I have no clue what or no clue how to do it. I just write code, play around get new ideas and build upon that. It changes so frequent and is so exploratory that I can not be bothered writing any tests.
Once I "get it" I write some tests. Mostly I understand also what will need tests and what not. Personally I think this if fine.
Online everyone is writing the ideal situation. I know what to deliver, I know how to do it and this is the perfect way to do it. Mostly it is I have taken loads of assumption and figuring it out as I go. Fuck it needs to be done don't have time to "optimize" it to look perfect.
Maybe I'm just not a good developer. But I shipped enough value in my lifetime to know I'm good enough ;)
Sounds like you've found what is effective in your own workflows. Thanks for sharing your experiences! I think this is the most important point: whatever needs to happen for you and those who relate to your philosophy to deliver value is good. Don’t feel obligated to listen to my insanity.
IMO I suspect we as an industry haven’t spent enough time considering the role of automated tests in video game software. I worry that it’s been written off for so long that it’s a self fulfilling prophecy. Since there isn’t tons of time spent thinking about testing whenever anyone attempts it they run into issues. When seeking help they are told tests are a waste of time. They do waste time because the “what is effective” patterns are still being discovered for as complex of software as games.
Maybe I am actually just not a good developer… But I really think there is something worth exploring.
IMO I suspect we as an industry haven’t spent enough time considering the role of automated tests in video game software. I worry that it’s been written off for so long that it’s a self fulfilling prophecy. Since there isn’t tons of time spent thinking about testing whenever anyone attempts it they run into issues. When seeking help they are told tests are a waste of time. They do waste time because the “what is effective” patterns are still being discovered for as complex of software as games.
Maybe I am actually just not a good developer… But I really think there is something worth exploring.
Yes, you absolutely want to run the entire game to test a function because if it does not work in the context of the game then it's wrong, regardless of what the spec or the tests say.
Do you really want to have to update a test every time you want the jump button to have more or less force, when tuning your platforming mechanics?
Do you really want to have to update a test every time you want the jump button to have more or less force, when tuning your platforming mechanics?
PTDD - PlayTest-driven development. Play the thing, see what works and what doesn't, iterate.
" I know I fixate on problems and “perfect” solutions at the detriment of my project’s velocity"
I have the same, which is why my current game is still not released.
Perfectionism made me reject all existing engines and write my own (I do use a physics libary, box2d, but actually am thinking about writing my own soon). I am happy with the result now, but I really had to learn to cut corners and abolish perfectionism again.
And now that WebGPU has come out(I programm on the web), I have to restrain myself to not overhaul everything again, because the GPU would unlock so much more power, making awesome new things possible in the simulation beneath..
So I am just doing one simple wgsl module to speed up one important part of the simulation, giving hopefully great performance improvements. And then do it all differently and right with the next game..
"Maybe if/when I get more skilled."
And the alternative would be tonstart now, making a very simple game, or using an existing engine.
It depends what you want to do. If you are really into complex systems, then yes - making everything from scratch, UI, Game logic, Rendering - then it all really gets complicated soon and if you didn't start right, you will never finish.
But a simple game, like a flappy birds clone or something alike, is not too complicated and will tell you, if you are really into it.
Just give it a try in a language you are comfortable with.
And of course there is no shame in using the right frameworks, libaries and engines, if you mainly want to get stuff done and play the result (which is very rewarding). Or rather, if you really want to ship a game, that runs stable and bugfree also on other peoples computers, then you will have to use existing work, or you won't get far, or will be buisy with it for a looong time, if you want to do anything not trivial.
I have the same, which is why my current game is still not released.
Perfectionism made me reject all existing engines and write my own (I do use a physics libary, box2d, but actually am thinking about writing my own soon). I am happy with the result now, but I really had to learn to cut corners and abolish perfectionism again.
And now that WebGPU has come out(I programm on the web), I have to restrain myself to not overhaul everything again, because the GPU would unlock so much more power, making awesome new things possible in the simulation beneath..
So I am just doing one simple wgsl module to speed up one important part of the simulation, giving hopefully great performance improvements. And then do it all differently and right with the next game..
"Maybe if/when I get more skilled."
And the alternative would be tonstart now, making a very simple game, or using an existing engine.
It depends what you want to do. If you are really into complex systems, then yes - making everything from scratch, UI, Game logic, Rendering - then it all really gets complicated soon and if you didn't start right, you will never finish.
But a simple game, like a flappy birds clone or something alike, is not too complicated and will tell you, if you are really into it.
Just give it a try in a language you are comfortable with.
And of course there is no shame in using the right frameworks, libaries and engines, if you mainly want to get stuff done and play the result (which is very rewarding). Or rather, if you really want to ship a game, that runs stable and bugfree also on other peoples computers, then you will have to use existing work, or you won't get far, or will be buisy with it for a looong time, if you want to do anything not trivial.
This is an interesting viewpoint. I might suggest prototyping game ideas with an existing "game creation" tool, even something like roblox. Then one has multiple pathways for their design to progress - world design, interaction, story, events, as well as engine. And one can much more easily test out different aspects of graphics and physics to see which their game engine needs or demands. There is also the ability to code engine algorithms directly and tweak so many variables in the prototyping stage, that the resulting parameters/functionality can be brought back into the actual custom game codebase.
I started game dev with flash, which was excellent for rapid prototyping and is still unmatched for casual games.
But OP especially wanted the hard way of doing it from scratch..
But OP especially wanted the hard way of doing it from scratch..
As someone who creates games for web consumption, thanks for being interested in the topic. Truly thanks. If I had to write low level WebGL (and now web GPU) code I simply wouldn’t do it. It’s hard enough creating at the higher level of abstraction of my game engine of choice. It’s just a bridge too far in my mind.
I’m now waiting for interested engineers like you to update Unity to enable use of web GPU. I embrace that it’s not a topic I want to care about as a creator, but instead as a consumer.
I’m now waiting for interested engineers like you to update Unity to enable use of web GPU. I embrace that it’s not a topic I want to care about as a creator, but instead as a consumer.
The thing with WebGPU is, that it is a very different way of programming, so you cannot just enable it and benefit from it coding the way you are used to.
Because the GPU are in fact lots of small cpus, meaning if you want performant code, it has to run parallel.
And then the fun starts with sharing ressources, coordinating etc.
So the code and data has to be structured very carefully, if you want actual improvements.
And this is not new to me, but I have never done it for something serious, so far. So for my intended use case is should work, as I need to do lots of raycasting and this is where GPUs shine. (But I still need to figure out the compute pipeline)
But in fact, I do intend to work something out, enabling other people to make use of it without having to do the deep dive.
At least in some cases ..
Because the GPU are in fact lots of small cpus, meaning if you want performant code, it has to run parallel.
And then the fun starts with sharing ressources, coordinating etc.
So the code and data has to be structured very carefully, if you want actual improvements.
And this is not new to me, but I have never done it for something serious, so far. So for my intended use case is should work, as I need to do lots of raycasting and this is where GPUs shine. (But I still need to figure out the compute pipeline)
But in fact, I do intend to work something out, enabling other people to make use of it without having to do the deep dive.
At least in some cases ..
I think you give game dev too much credit. Is full of unmaubtainable code that will never be used in another game and has bugs that don’t affect the primary goal of fun. Learn to love the spaghetti and embrace not knowing what half the stuff you wrote does the next day. If it’s fun it’s good.
There’s only a handful of long duration games under active development anyway.
There’s only a handful of long duration games under active development anyway.
I find that I tend to get to the interactivity parts of gamedev and go "maybe it'd be neat if this ran itself as a simulation".
ChatGPT even wrote a game for me and I thought the same then. I think this might be related to why I write so many dashboards as a hobby.
Spectating is pretty cool by itself perhaps?
ChatGPT even wrote a game for me and I thought the same then. I think this might be related to why I write so many dashboards as a hobby.
Spectating is pretty cool by itself perhaps?
My favourite trap question for conferences is how to TDD GUI and game development, every single aspect of it.
Don't write any kind of code, none of it, without a failing test first is the motto.
Don't write any kind of code, none of it, without a failing test first is the motto.
There is a perfect and apt answer: keep playing the game (prototype) you are developing!
Not only does it test your game under sort of realistic conditions; it also gives you constant feedback on whether the game is fun, interesting, engaging — something that's infeasible to test by code.
Not only does it test your game under sort of realistic conditions; it also gives you constant feedback on whether the game is fun, interesting, engaging — something that's infeasible to test by code.
This exercises the happy path, but otherwise works surprisingly badly for testing. You already know what the game is supposed to be about, so you can't really tell how well the interface communicates things to someone who doesn't, and you more or less automatically play it the way you're "supposed to", so you rarely hit the sorts of buggy or game breaking corner cases testing is supposed to discover.
That's why you have playtesters.
That is not an answer, you are not describing anything close to TDD.
I think it's the closest thing to TDD you can have developing a game proper.
Development of a game engine is a different matter, and affords itself to classical TDD, to my mind. You can write formal tests ahead of time, because you can feasibly understand what you want to be implement before you implement that.
Development of a game engine is a different matter, and affords itself to classical TDD, to my mind. You can write formal tests ahead of time, because you can feasibly understand what you want to be implement before you implement that.
Try to TDD a shader pipeline workflow.
No code before a red unit test.
No code before a red unit test.
You should try doing a game jam (or, multiple!) You have an extremely short time frame, and each time you start from scratch so you learn what systems work and what doesn't in a practical way that doesn't allow for perfectionism.
I've probably implemented platformers physics about 15 times now, and have a pretty good idea of how I personally like structuring game code.
I've probably implemented platformers physics about 15 times now, and have a pretty good idea of how I personally like structuring game code.
I do game jams and you’re right about their benefits.
I’ve done them using TDD as an inexperienced game dev, test free, TDD now that I have more experience, and it’s helped me clarify some of my own thoughts on how automated testing can fit into my workflow.
I’ve done them using TDD as an inexperienced game dev, test free, TDD now that I have more experience, and it’s helped me clarify some of my own thoughts on how automated testing can fit into my workflow.
I really should get to blogging about my experiences with game development so far instead of just rambling incessantly on Discord. I'm a complete noob at it, but feel like I've got a decent amount to say and the game isn't going to market itself, ya know? :) Just hard to know where the right place is to put time and energy each day when doing indie game development.
Pretty sure the first post will talk about my experience building out a simple prototype in React + PixiJS, the landscape for JS development, and rationale for rebuilding in Rust/WASM/Bevy and then the second will be on my experiences learning those tools and opining on the pros and cons.
Would that be interesting to people? Are there specific aspects of development that people want to read more about than others? I don't feel like I have much to say on graphics and sound assets or anything like that (yet?)
Pretty sure the first post will talk about my experience building out a simple prototype in React + PixiJS, the landscape for JS development, and rationale for rebuilding in Rust/WASM/Bevy and then the second will be on my experiences learning those tools and opining on the pros and cons.
Would that be interesting to people? Are there specific aspects of development that people want to read more about than others? I don't feel like I have much to say on graphics and sound assets or anything like that (yet?)
> Are there specific aspects of development that people want to read more about than others?
The pros and cons of the tools you mentioned. As a hobby Unity dev I appreciate reading about the ups and downs of tool chains excluding the big-3 (Unreal, Unity, Godot).
The pros and cons of the tools you mentioned. As a hobby Unity dev I appreciate reading about the ups and downs of tool chains excluding the big-3 (Unreal, Unity, Godot).
> Part 2: Collision → (coming soon!)
Harrumph!
Harrumph!
A) is the thing maybe gonna intersect with the thing?
B) how much does the thing intersect with the thing?
C) move the things so they aren't intersecting.
But when your position is inside your object, how do you check if you're intersecting with all the other things efficiently? That's the bit I was hoping to read about.
I found Pico-8 to be an enjoyable entry into finishing a game. I’ve just released my first finished game today using it (https://ferm.itch.io/centauri). The limitations helped me to define a scope and really helped towards the end to determine what a completed game would look like. When I would think to add a new cool feature, I’d remember I was near the token limit and prevent myself from doing that.
I've done games with unreal engine on PS4 and Godot on PC.
I agree with you, PICO-8 is fun and I can knock an original game in a weekend without worrying about any marketing or slogging through content.
PICO-8 and the TIC-80 are both great little platforms that will push your creative juices without getting you bogged down in realistic graphics, hi-q music and assets. It's also a pleasure to do as it's very easy to navigate and comes with all batteries included.
I agree with you, PICO-8 is fun and I can knock an original game in a weekend without worrying about any marketing or slogging through content.
PICO-8 and the TIC-80 are both great little platforms that will push your creative juices without getting you bogged down in realistic graphics, hi-q music and assets. It's also a pleasure to do as it's very easy to navigate and comes with all batteries included.
I'm sad that this is the second part and then the series stopped.
At one point, I tried to figure out what the recommended way to do OOP in Lua was, and if the method I'd come to use was alright. After some searching around, I came to the conclusion that every resource does it differently. I've made games in Pico-8 as well, and use something I suppose you'd call factory functions rather than what the author does here. I gave up worrying about it.
Meta comment: it is very fun seeing people who I read quite a bit of (luu) explore into topics which also interest me. I wish web rings were a thing still because pulling the ring off of danluu would be a lot of fun.
Cool to see there's demand for articles like this. I program all my games from scratch in plain old JavaScript without using a game engine, so maybe I should start doing some writing about it...
eev.ee wrote some great articles about doom, and made one of my favourite doom maps
eev.ee also writes a lot about programming language design that I've really enjoyed in the past. Definitely worth the read.
The author mixed view with model.
I trust they’ll disconnect the two at some point.
I trust they’ll disconnect the two at some point.
saw how old this was and really hoped to find more in the series!
However; I shutter in horror at the thought of embarking on this journey for myself. This is a statement about me rather than a general statement. I know I fixate on problems and “perfect” solutions at the detriment of my project’s velocity e.g. TDD for my game projects —- especially since most tutorial code isn’t written with testing in mind. I highly suspect I would be doomed to misery if I tried.
Maybe if/when I get more skilled. I feel like projects like these are an expression of programmers who are very comfortable and experienced with writing complex systems.