3 ms·

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 rea

by chii 4y ago

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.

Gigachad 4y ago
That doesn’t sound like “test driven development” it’s just automated testing.
- sovietmudkipz 4y ago
  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.
pjmlp 4y ago
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.
- sovietmudkipz 4y ago
  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.

by chii 4y ago

Gigachad 4y ago

That doesn’t sound like “test driven development” it’s just automated testing.

sovietmudkipz 4y ago
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.

pjmlp 4y ago

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.

sovietmudkipz 4y ago
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.