1
\$\begingroup\$

I'm making a clone of an old atari 2600 game, so it's simple, only slightly more complex than the original.

I'm realizing that even the simplest of games have different "parts", what is a good design method to be able to test those sections without having to "play through" to that part?

Specifically, (it's a "breakout" clone) if I'm modifying and testing code that runs when the game is beaten, I don't want to have to play through the whole game just to see if my code works. I can only imagine how complicated this kind of testing is for a game of substantial size.

How do real devs make their game such that they can test just a certain section, or test a section under certain possible in-game circumstances without having to play through to that part?

\$\endgroup\$
4
\$\begingroup\$

They have console commands.

There is a reason skyrim has all the commands in it. That game was very extensibly tested. And because it has couple hundred hours of content with every cave and guild, and some of this content is bound to a level, there is no way to make everyone play through everything.

Do the same, create some commands whivh put you on an entered level, one which destroys every block, etc.

You of course don't need to keep it in the game when you release it. Some games do that to make players be able to ppay around with the game a bit more.

\$\endgroup\$
  • \$\begingroup\$ Thank you! Exactly what I wanted to know (real industry uses). I'll leave the answer not accepted for a few days to see what else rolls in :) \$\endgroup\$ – Neal Davis Nov 18 '16 at 6:55
  • 1
    \$\begingroup\$ Basically the same idea, just have some debug controls but don't build them into your release. For example Shift + 1, Shift + 2 etc. just link them to a static debug class that calls LoadLevel(1), LoadLevel(2) that kind of thing. \$\endgroup\$ – lozzajp Nov 18 '16 at 9:06
2
\$\begingroup\$

A bad development team would hire a bunch of QA staff (testers) to play the game over and over again, reporting bugs into an ever vacuous database. Even with the aid of console commands this is an expensive and slow process, and not what you should be using a QA team for. The testers should be exploring edge cases and pushing the game to its logical limits, not validating your own wobbly code you couldn't be bothered to test.

A studio with solid development practices will write automated tests that run every time they check in new code. This allows certainty that new changes don't break previous functionality. With projects as vast as the ones you find in game development this is the only way to confidently deliver a functioning product. Not following these practices is what leads to crunch, and crunch kills good developers. In today's modern age of games like Overwatch or Dota 2 that have to be maintained and altered consistently after release it's the only way to iterate a product sustainably.

The answer is to automate as much testing as you can. In your case write a helper method that destroys all the blocks and then engineer a test that executes this and validates the win conditions are being satisfied. If this is difficult to test in your environment then it's potentially a sign your current code is too coupled and could do with some abstracting.

\$\endgroup\$
  • 2
    \$\begingroup\$ Coming from a QA background, I couldn't agree more. There is a caveat, though, especially for indie developers. Creating automated tests isn't always so straight forward, and it does eat up dev time. It's an excellent practice, and should be utilized where you can, but spending hundreds of hours developing test automation for every little nook and cranny can also be bad. Find a middle ground between automation and playtesting. \$\endgroup\$ – Jesse Williams Nov 18 '16 at 15:18
  • 1
    \$\begingroup\$ It's working great. I believe I have a good system up and running! It wasn't too difficult to implement but I did have to polish a couple of rough edges. Interesting that the result is a more polished, encapsulated flow. I actually feel more peaceful inside my SOUL! Lols but for reals though. \$\endgroup\$ – Neal Davis Nov 19 '16 at 0:59
  • \$\begingroup\$ I'm glad that my evangelising of Test Driven Development has paid off for you! I use tests to conquer my rampant neuroticism for hidden software failures and I never feel entirely safe until I have a good suite to run against. I hope that extra effort in setting up a test suite will continue to reap benefits for you in many iterations to come, and help you to keep your code lean and clean. \$\endgroup\$ – Huxellberger Nov 19 '16 at 13:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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