5 ms·

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 no

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/Player.cs https://github.com/NoelFB/Celeste/blob/master/Source/Player/... https://store.steampowered.com/app/504230/Celeste/ https://store.steampowered.com/app/504230/Celeste/

berkle4455 3y ago
100%. tbh if you want to deliver value in any scenario you skip TDD and anything that smells of agile or scrum. Just deliver.
- jstarfish 3y ago
  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.
  - unlikelytomato 3y ago
    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.
    - jstarfish 3y ago
      > 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.
- chii 3y 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 3y ago
    That doesn’t sound like “test driven development” it’s just automated testing.
    - sovietmudkipz 3y 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 3y 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 3y 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.
idontwantthis 3y ago
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?
- bluefirebrand 3y ago
  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?
- alpaca128 3y ago
  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.
  - sovietmudkipz 3y ago
    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…
    - toadi 3y ago
      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 ;)
Jare 3y ago
PTDD - PlayTest-driven development. Play the thing, see what works and what doesn't, iterate.

berkle4455 3y ago

100%. tbh if you want to deliver value in any scenario you skip TDD and anything that smells of agile or scrum. Just deliver.

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

idontwantthis 3y ago

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?

bluefirebrand 3y ago
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?
alpaca128 3y ago
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.
- sovietmudkipz 3y ago
  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…
  - toadi 3y ago
    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 ;)

Jare 3y ago

PTDD - PlayTest-driven development. Play the thing, see what works and what doesn't, iterate.