| I work on a game called Path of Exile. At our studio we don't do TDD, but we do continuous integration with a lot of asset testing. In the early days, we tried doing unit tests, but honestly, it's very hard in a game. We had little success testing gameplay code. What we have a huge amount of is asset tests. We have 4 times more non-programmers than programmers working on the game, so most of what is created isn't code anyway. Every time anyone commits anything, it goes through our continuous integration pipeline, and any asset that changed, or is dependent on an asset that changed, is loaded and tested. This includes test loading entire levels. Test loading every asset catches most types of failures. We try, where possible, to add specific tests for common mistakes in order to catch things as early as possible. For example, if an animation has "walk" or "run" in the name, then we test it also contains footstep events in the animation somewhere. If a model is used as a monster we test that it has an attachment point called "frame_upper" onto which various effects can be attached. We look for things like bounding box of an object being far away from the co-ordinate origin (a common mistake when making a big maya scene with lots of exported objects in it). We also do a test start of the servers, which includes loading all of their data, and a test start of the client. All of this means that a build that goes through green is unlikely to cause crashes for other people trying to work on the game. We do, of course, also have an excellent QA team. |
Topical question; however, since the thread on a whole has focused on the more visible but more finniky-to-test aspects of these games. Do your same statements apply more or less to the backend/networking infra? I remember the decent ball of work you guys wrote about a while back when introducing the lockstep change, was curious what went on behind the scenes to support and validate that from an ops/maintainability perspective, if you can speak on that at all.