1
\$\begingroup\$

I know writing tests would be a good way to catch regressions. But what are some other strategies? TDD and game dev don't suit, but catching regressions is obviously something desirable. I would love to find some cheap and easier ways to catch regressions without having to invest a lot of effort or writing tests after the fact.

Strategies suggested don't have to be perfect, if they can give rough ideas or things to playtest rapidly then that would also be beneficial.

Please advise.

\$\endgroup\$

closed as too broad by doppelgreener, Gnemlock, Josh Dec 13 '17 at 16:26

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

4
\$\begingroup\$

First of all, I would challenge the assumption that TDD and game development don't mix. While there are some things in game development which are hard to unit-test (How do you write a proper unit test for a graphic effect where the only formal requirement is "looks cool"?) there are several other areas where it does make sense. Your core game rules, for example.

But even more useful than automated unit tests are automated integration tests. Create a framework for your game which allows you to automatically:

  1. Load predefined game scenes
  2. Simulate them for a few seconds, simulating player input if necessary (preferably with enhanced speed)
  3. Check if the outcome of the scenes is the outcome you expect and report if it is not

When your game uses a random number generator, make sure you seed it with the same value every test run.

Create such a test suite for every feature and create a way to run all your tests automatically. As an example, here is the test suit of the game Factorio in action:

https://www.youtube.com/watch?v=erYjMMBXy7A

Just imagine testing every single feature you see in that 84 seconds video manually. Sure, no automated test suit can replace real flesh-and-blood testplayers, but it can still save you hundreds of play hours and drastically speed up your change-test-fix cycle if you have a fully automatic test suit.

\$\endgroup\$
  • \$\begingroup\$ When I say it doesn't mix I don't mean it can't be done, just that it's not the best way. You're always tweaking and overhauling and the code evolves a lot more in gaming than in application programming. TDD is a great tool and if you're making a project where that makes sense it might be worthwhile, but from what I can see it's not usually going to be worthwhile for games. Unit testing might be a worthwhile effort but unit testing upfront as a design tool isn't the best way to produce fun gameplay, in my, perhaps naive opinion. \$\endgroup\$ – eternalNoob Nov 25 '17 at 19:45
  • \$\begingroup\$ @eternalNoob Actually unit testing can be a great safety net in an agile development project like a game. Many agile software processes emphasize unit testing, because it gives you the security to experiment without breaking things you didn't intend to break. But this goes into discussion territory, and this is a Q&A website, not a discussion forum. \$\endgroup\$ – Philipp Nov 25 '17 at 19:46
  • \$\begingroup\$ Maybe so, regressions are problematic. I desire to know ways to deal with them... but writing tests is time consuming and if you're a small team, or one man in my case, then that time would be better invested elsewhere. Another problem I see wiht tests aside from investment in creating them is time spent running them bogging down iteration on the design. I'd like dev to be fast, iteration based, and when released projects are considered alive and continue to grow from the initial seed. Reminds me, I saw a neat gdc once where bug report tools were integrated in game. \$\endgroup\$ – eternalNoob Nov 25 '17 at 19:55
  • \$\begingroup\$ @eternalNoob I'd challenge the claim that test-writing is impractical for small/1-person teams, or that it diverts investment from the game itself. Indie developer Kieran Lord put together a great presentation on lessons learned in Unity development, saying: "Automated testing = you spend your time making game, instead of spending time figuring out why it's not working. I'm a firm believer that it's more fun to be writing tests than fixing bugs." \$\endgroup\$ – DMGregory Nov 25 '17 at 20:51
  • \$\begingroup\$ @DMGregory I'll have a look. All I have to say for now is that I guess I'm the only one that quite enjoys killing bugs? haha. I also find bug hunting a pretty good learning experience. But obviously I want debugging to be easy to avoid wasting time, however, I'm thus far unconvinved that testing in game dev is the best way to go about that. I'm open to being convinced though, so maybe I'll change my mind after checking the link. Thanks for your input! \$\endgroup\$ – eternalNoob Nov 25 '17 at 21:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.