27
\$\begingroup\$

As being Scrum certified, I tend to prone for Agile methodologies while developping a system, and even use some canvas from the Scrum framework to manage my day-to-day work.

Besides, I am wondering whether TDD is an option in game development, if it is viable?

If I believe this GD question, TDD is not much of a use in game development.
Why are MVC & TDD not employed more in game architecture?

I come from industrial programming where big projects with big budgets need to work flawlessly, as it could result to catastrophic scenarios if the code wasn't throroughly tested inside and out.

Plus, following Scrum rules encourages meeting the due dates of your work while every single action in Scrum is time-boxed! So, I agree when in the question linked above they say to stop trying to build a system, and start writing the game. It is quite what Scrum says, try not to build the perfect system, first: make it work by the Sprint end. Then, refactor the code while working in the second Sprint if needed!

I understand that if not all departments responsible for the game development use Scrum, Scrum becomes useless. But let's consider for a moment that all the departments do use Scrum... I think that TDD would be good to write bug-free code, though you do not want to write the "perfect" system/game.

So my question is the following:

Is TDD viable in game development anyhow?

Improve this question
\$\endgroup\$
10
  • \$\begingroup\$ What is the discussion from this question going to add beyond the question you linked? \$\endgroup\$
    – user744
    Jan 25, 2011 at 23:04
  • \$\begingroup\$ I present the Scrum framework of project management in Agile software development and argue as to what Scrum wants from a developer during a Sprint, hence making TDD viable as an option. I want to get the others' point of view on the subject from the Scrum point of view, not only under the TDD or MVC aspect. I want to understand how is TDD not viable when argued from this side of the medal, other than just considering TDD itself as a standalone approach. \$\endgroup\$
    – Will Marcouiller
    Jan 25, 2011 at 23:11
  • \$\begingroup\$ @Will TDD == Top Down Design or Test Driven Design? I was thinking Top Down and was going to give an answer of manageability in the long term but then saw the other answer were interpreting TDD in a way I was not... \$\endgroup\$
    – James
    Jan 26, 2011 at 0:00
  • \$\begingroup\$ @James: Test Driven Development. \$\endgroup\$
    – chaos
    Jan 26, 2011 at 0:04
  • \$\begingroup\$ @James: Sorry for the confusion! I didn't know about the other meaning of the acronym, since what I had in mind was Agile Software Development with Scrum. \$\endgroup\$
    – Will Marcouiller
    Jan 26, 2011 at 0:49

6 Answers 6

Reset to default
12
\$\begingroup\$

It's certainly viable, although a lot of game programmers haven't really gotten on board with the idea yet, or have a good understanding of how to test complicated systems. I admit myself that I rarely use it, except for non-gameplay-related systems that are easy to test.

Expect to use a lot of mock objects. Because of how tied together a lot of systems are, it's hard to test individual components of that.

Plus a lot of things can't be thoroughly tested. How do you test-drive, say, a particle system? How do you test that your animation system is working correctly? A lot of things are visual in nature, and aren't obvious (at least to me) as to how to do proper testing.

There are, however, a lot of things that aren't necessarily unit tests in the traditional sense of the word, but that exists as "tests" for specific features. Things like test levels for AI navigation are pretty common, but aren't necessarily the easiest things to automate.

There are certain aspects of games that can (and probably should) have unit tests written for them. Any kind of generic "file reading" system should be tested. Maybe have some tests for initialization of hardware things (3d surfaces, etc). Maybe have some mock servers and test your client/server interaction code. Things like that.

Improve this answer
\$\endgroup\$
6
  • 10
    \$\begingroup\$ These are great proposals for the presence of automated testing, but not at all for test-driven development. \$\endgroup\$
    – user744
    Jan 25, 2011 at 23:25
  • 1
    \$\begingroup\$ Interesting opinion, Tetrad! Thanks for your grain of salt. You ask how to test visual animation? Hard to say as for 3D systems, since I've never yet written a single game, perhaps after some having developed a few tiny games! Besides, in 2D, I have often seen objects represented by matrix, and matrix parsers to render the image on screen. Hence, making sure that after some directional key-pressed, the right information's found at the right place in the resulting matrix could be a beginning, I guess. I just don't yet know enough about visual components of a game, and I sure will this year! =) \$\endgroup\$
    – Will Marcouiller
    Jan 26, 2011 at 1:07
  • \$\begingroup\$ I'm back after some coding to say that I have answered a question this week (my first on GD! =)) that required knowledge of OOP concepts. The OP wanted to move a snake upon Keys.Down, Keys.Left, etc. That to say that the game knows where the user wants the snake to go, and the snake has to go where the game tells it to, though that is only the snake that knows how to move in the different directions, hence also of its position in the game. Having told this, IMHO, makes the Snake class a testable one! (To be continued...) \$\endgroup\$
    – Will Marcouiller
    Feb 4, 2011 at 15:01
  • \$\begingroup\$ Not only is it testable, but it now is a good candidate for TDD. Lets say the snake is initialized at position Vector2.Zero, with a speed of 10.0f on both X and Y axis in this 2D game. First question is: Is it positioned at its supposed initial position and how to test it? Then, you think that the Position property shall be publicly exposed. Second: how to make it move? Movement methods should be good, so you write a test for each direction method MoveDown, MoveLeft and so on. Now, go and write your method declaration and see if the test complains. Then, reverify the snake's position \$\endgroup\$
    – Will Marcouiller
    Feb 4, 2011 at 15:07
  • \$\begingroup\$ after a MoveDown method call! Since you know that the Position property is thoroughly tested, that is a member on which you can count! You may guess the continuation here! ;-) That is to say that visual components can definitely not be tested, but the snake should look like a snake, all depending of what kind of snake you want in the game. The artist drawing the snake should prove enough satisfaction with her/his drawing of the snake, that is not to be tested through TDD, of course! But its position relative to other objects can, and the class that represents this snake too. In fact, TDD \$\endgroup\$
    – Will Marcouiller
    Feb 4, 2011 at 15:12
12
\$\begingroup\$

I don't think TDD, as such, is appropriate as a foundation for game development. Automated unit testing as part of methodology, sure, but too many of the key concerns of game development are subjective and not machine-testable for testing to be the driver of development. How are you going to write a scripted test for whether a game mechanic is fun? That a level is visually appealing? Even that a level takes a typical player around 15 minutes to complete? TDD fits situations where the maturity of a project can be quantitatively measured in terms of its compliance to a specification, and that just isn't game development.

Improve this answer
\$\endgroup\$
8
  • 3
    \$\begingroup\$ What do you mean when you say that game development isn't of compliance to specifications? My point is that you must know what kind of game you write when you want to write one. As such, specifications, requirements shall be written as features or the like; let's take a Product Backlog example in Scrum. You know the user stories you will have to develop in your game so that you write the expected game! Then, for another example, you will perhaps need to detect collisions in a fighting game, these are testable things! Whether the game is fun is more of the story or than programming, IMHO. \$\endgroup\$
    – Will Marcouiller
    Jan 26, 2011 at 0:58
  • 1
    \$\begingroup\$ @Will Marcouiller: I don't mean to imply that we don't have specifications or can't measure compliance with them, but that less of what's important about the project can be meaningfully specified than in other kinds of development. You can write "the game should be fun" into your spec, but that's not a specification with technical meaning. You can and should test for what's testable, but the point of TDD is that testing isn't just part of the process, it's the entire basis of the process, a fundamental mindset, and I don't see that jibing well with a highly subjective field. \$\endgroup\$
    – chaos
    Jan 26, 2011 at 1:03
  • 3
    \$\begingroup\$ @Will Marcouiller, I highly, highly, disagree that the fun of the game comes down to the story. All the fun in the game comes down to the gameplay, story is just a bonus. \$\endgroup\$
    – AttackingHobo
    Jan 26, 2011 at 6:09
  • 2
    \$\begingroup\$ @Will: No, he's saying that the enjoyment a user derives from a game cannot be determined via automated test, and that games have large quantities of things that can only be tested by sending the game into consumer's hands. \$\endgroup\$
    – DeadMG
    Jan 26, 2011 at 18:40
  • 1
    \$\begingroup\$ @DeadMG: That's more true than anyone would like, but my point (not necessarily AttackingHobo's) involves the fact that the development process itself has to incorporate testing, by designers and producers and developers and testers, that can't be quantified in a unit test, that is to do with the quality of experience and feel and style and aesthetic effect that the game creates. To tell people that they're doing TDD when that's such an important part of development is basically just to lie to them. \$\endgroup\$
    – chaos
    Jan 26, 2011 at 18:47
7
\$\begingroup\$

It's a bit difficult to work out exactly what you're asking since the title is purely about TDD but you seem to be making Scrum an integral part of the question too - and as I understand it, one does not require the other.

If I believe this GD question, TDD is not much of a use in game development.

That is correct. I don't think I've ever heard of it used in practice in the games industry. (But then I never heard of it used outside the games industry either - just by individuals.)

I come from industrial programming where big projects with big budgets need to work flawlessly, as it could result to catastrophic scenarios if the code wasn't throroughly tested inside and out.

Games don't need to work flawlessly. So there is much less emphasis on code correctness. TDD doesn't guarantee code correctness, but some people feel it reduces the incorrectness. I'm yet to see proof of this.

Plus, following Scrum rules encourages meeting the due dates of your work while every single action in Scrum is time-boxed!

I've never seen a methodology that didn't encourage meeting due dates, or having actions that weren't time-boxed. The problem is that no matter what methodology you use, estimating software complexity is quite hard. It's not impossible, but estimating it accurately is not much to do with the process. If my task is to add a new GUI panel, or to fix a bug with the animation, or add a new statistic to characters, then the use of Scrum is not going to speed that up at all, and the use of TDD is going to slow down the task (at the possible benefit of reducing further maintenance tasks later). They're certainly not going to make it easier to estimate the task duration.

I think that TDD would be good to write bug-free code, though you do not want to write the "perfect" system/game.

If TDD is proven to write better code than other methods, then yes.

Is there proof of this? The fact that industry might use it is not proof. Industry is well known for producing poor code that is delivered late. The absence of examples of major TDD projects that have failed or run late may just be because it's a new approach and few people have actually finished such a project yet. (And the ones that are running late... may still be running.)

Is TDD viable in game development anyhow?

Viable? Of course. Beneficial? That's yet to be proven.

Improve this answer
\$\endgroup\$
7
  • 1
    \$\begingroup\$ Unfortunately, TDD and Scrum are still misunderstood. And this is true for existing projects that neither will help speed up bug corrections or else. Scrum is a framework to develop complex systems, as a game seems to be. Scrum encourages bug-fixing from a Sprint to another so that they never accumulate. TDD place you on the user's side. By user, I mean colleague programmers who will use your code. It forces you to think how it should be used to make your code easy to use for others. Hence, it leads to better design, per experience. That all said, you got interesting views on subject. \$\endgroup\$
    – Will Marcouiller
    Jan 26, 2011 at 1:19
  • 1
    \$\begingroup\$ Forcing bugs to not accumulate just causes features to slip - you can't magically produce more time. My understanding is that Scrum does not have any particular method specific to bugs anyway. As for TDD forcing you to think about how other people will use your code, it is not the only way to go about that. Therefore it is not necessarily better, and certainly not necessarily the most effective use of time. \$\endgroup\$
    – Kylotan
    Jan 26, 2011 at 14:46
  • 1
    \$\begingroup\$ FYI, Noel Llopis uses TDD for his indie games, and his old company High Moon Studios used it extensively. Haven't got a citation, sorry. \$\endgroup\$
    – tenpn
    Feb 3, 2011 at 16:15
  • \$\begingroup\$ You got some good points interesting to read! Thanks for your contribution. Nonetheless, I would like to add that TDD is yet another approach just like XP (extreme programming). And yes, Scrum does not provide any particular method specific to bugs, and rather invest on self-organization of the Team (of developers). Scrum doesn't tell you how to do things, it only says what should be done. It is the Team's commitment to walk through what has to be done. Scrum only bets on self-organized cross-functional Teams. It is the Team that decide how features should be developed and tested,etc \$\endgroup\$
    – Will Marcouiller
    Feb 4, 2011 at 14:38
  • \$\begingroup\$ (continue...) I have answered my first question this week about classes here on GD. The OP wanted to get to know how to make his sprite move upon directional keypresses. Being comfortable with OOP concepts, I figured out that I should perhaps use classes to develop my first game using XNA. That said, my Spacecraft class becomes a fully testable class with methods and properties. This is the kind of stuff that absolutely can, IMHO, be fully tested using TDD. Let's say you need a spacecraft, then you write the tests for what you need it to accomplish one test at a time. \$\endgroup\$
    – Will Marcouiller
    Feb 4, 2011 at 14:44
5
\$\begingroup\$

No, Test Driven Development is not suited for Game Development. Sure you can write tests for some parts you do want to test, but the Game Development process is completely different from Test Driven Development which requires having exact specifications before progress is started.

Games rarely have exact specifications when started. And if they do, they always change and evolve during the development process.

Game design is an art, you can't have specific tests to know when art is good or complete.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Don't you think that fun factor should be considered to be when analyzing the game itself, functional analysis or the like? You may set up a set of features that together will make the game fun to play, and thise features are then testables! I'm only trying to put different opinions forward to go in-depth about the topic and the arguments that you come up with. Thanks for your contribution! =) \$\endgroup\$
    – Will Marcouiller
    Jan 26, 2011 at 14:10
  • 4
    \$\begingroup\$ A lot of development comes down to tweaking small things and seeing how fun they are to play. You can't test those things unless they are 100% set in stone. And testing a system after it is done is not TDD, it is testing, but not Development that is driven by testing. \$\endgroup\$
    – AttackingHobo
    Jan 26, 2011 at 17:15
  • 3
    \$\begingroup\$ If you think most real-world projects have exact specifications when they start, then you probably have not worked on a lot of real-world projects. \$\endgroup\$
    – BlueRaja - Danny Pflughoeft
    Jun 16, 2011 at 18:16
5
\$\begingroup\$

sorry for my poor english and sorry for my biased point of view: i am not a game designer but a coder.

I think there are some misunderstanding in this discussion. i'll talk about TDD in more general form, the so called BDD. Behavior driven development is not a way to test project (the tests are something like side effects). BDD is a way to design, a way to do refactor and software design during all the production (see some mottos as KISS, "keep quality in", "test early, test often") and not in a alone phase. BDD is the opposite of some classical software process like waterfall process or some other iterative methodology to make software.

Another point is that automatic tests are for that features that could be tested automatically by a computational machine. there is no test for fun in games, and there is no test for usability of a graphical user interface. fun or usability are materials for other jobs and not for software development like interaction designer, world and level d. in the same way that artistic parts(modelling, texturing, etc) are for artist that use computers as tool for creativity - obviously those jobs could be performed by the same person that write code, but this is not the point. physics could be tested, optimization algorithms could be tested, singual object behaviours could be tested (with mocks, stubs and dummy as mentioned before)

the last think is that, imho, is that not only game design but whole writing code is an art.

Improve this answer
\$\endgroup\$
5
\$\begingroup\$

Here's a case study from someone who thinks TDD and gamedev mix pretty well:

http://powertwenty.com/kpd/downloads/TestDrivenDevelopmentInPython.pdf

Admittedly, this is a small project in Pygame, but it gives the idea of which parts can be tested with a graphical game and which can't. I was surprised at how much could be done with TDD in this scenario.

Improve this answer
\$\endgroup\$
1
  • 2
    \$\begingroup\$ Without a comparison to a control group that did the same project (clone an existing trivial arcade game in a very high level language), it says nothing about whether TDD is effective or not. It just says he used TDD. \$\endgroup\$
    – user744
    Jan 26, 2011 at 19:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .