At work-work, we’ve started experimenting with something called Test Driven Development. It’s where you start a new program by writing some tests for it. Since your program proper hasn’t been written yet, your tests will fail.
After failing, you then write your program, and run your tests again. And hopefully some or all or the tests will pass. And you keep working on your program until all your tests pass.
It sounds a little backwards, and I wasn’t really sold on the whole idea at first, but it’s growing on me.
* * *
So I was gonna enter this co-op board game contest.
And then I didn’t.
I could write up a whole postmortem, but mostly what it comes down to is, I chose not to devote a lot of time to this project. I’m still going to work on the game design. It’s deeply flawed, but I think there’s potential here. In many ways, failing this first test has been a good way to start.
* * *
Video games are filled with tests. Boss battles especially are very test-like. After grinding for hours and hours, you’ll suddenly find yourself in a situation where you have to use all the new equipment you’ve gained and defeat a screen-filling monster in an intensely concentrated test of your skills as a player.
For Tinselfly, I want tests, but more character driven. You can’t progress if you don’t get the characters you’re playing. Their assorted emotional baggage, their strengths, what things make them totally freak out for no rational reason. The story won’t continue if it thinks you’ve missed some of it.
* * *
It’s getting harder and harder to avoid working on actual playable levels for Tinselfly. I’ve done lots of setup, written lots of outlines; the visuals so far are nice… but a decade into this, I still haven’t figured out the details of where to begin, with this whole character-and-story-through-game-mechanics thing.
But it occurs to me that the answer lies in Test Driven Development. In an odd sort of way, a great many conventional stories are test driven.
You start with a hero. The hero is presented with a test in one of the first scenes of the story, and they fail the test. The exact way the hero fails should tell you a lot about them as a person. And then the hero gains new skills, has various emotional epiphanies, improves as a person, and finally passes the test they were originally confronted with. Roll credits.
Lots and lots of action movies follow this sort of template.
So without knowing the details of my first level, I can write the test for it, and just make it up as I go along, which is nice because I hate planning this sort of stuff. And then I can build the rest of the level around that test, making sure the player has ways to gain the items and area unlocks they need to complete the test, and I can keep iterating until the test is actually completable.
I think you are drawing some interesting parallels here. As you learn more about TDD and become more comfortable with it, its value and the purpose of it becomes more apparent. A couple years ago, I attended an event hosted at LeanDog Software called Code Retreat, at which a guy named Corey Haines lead us through a series of TDD exercises. I learned a lot about TDD that day and it was a great experience. I believe there’s another Code Retreat happening in the near future, you should look into it and go if you can.
I’m not an expert by any means, but I’m always happy to talk about programming concepts and stuff, and would love to talk about TDD with other people who are interested in it.
One thing I didn’t see you mention in your description of TDD is that when you write a test, you then code only the simplest, most minimal solution to pass the test. Once you get the test to pass, you can write additional tests in order to refine the solution. The idea is to eliminate unnecessary code — because all that code costs money at every step in the development lifecycle. TDD forces you to code only what is needed to pass the tests, and the tests ideally are written to match with the requirements for your project.
Having tests that you can automate and pass/fail gives you the capability to know with confidence whether a new change to the program has introduced a bug elsewhere. You can just re-run your test suite after committing a change, and in a few seconds see if any of your tests suddenly went red. This helps immensely with preventing bugs and ensuring quality.
Is playing a game a test-driven process? I don’t know. I see some parallels, sure. The player is challenged and needs to pass the “test” that the game presents to them in order to proceed. Depending on the game, the player maybe acquires new “features” (powerups, items, etc.) and has to develop skills in order to pass previously impassible tests. It’s interesting to think about. But playing the game isn’t an automated test suite; the player manually has to pass each test each time they play, and can pass or fail for reasons other than lacking the new feature and the requisite level of skill. So, I’m not sure how far the TDD metaphor can be stretched to model playing a game, or what things of value come from making that metaphor. If you find things that are valuable coming out of your process, I’d be interested to hear about them.
Huh. I didn’t know that bit about minimal solutions & writing more tests; that’s really interesting. But I’m really liking the ability to run tests after my changes and seeing if I inadvertently broke anything.
As for the gameplay parallel, the main value I see right now is getting me to think about my level design in terms of the ‘test’ at the end. If my test can’t be completed — or if it can be completed too easily I suppose — my level needs more work.
From the player’s point of view, I’m hoping this adds a sense of a clear goal for both the player and their character… a lot of games kind of disavow the notion of failure in some ways. If you die, you just backtrack to your last save point and the narrative sort of pretends your failure never happened. You might have failed as a player, but your character doesn’t remember that. Here, I kind of want the narrative to recognize the fact that you can fail a lot.
But I’m not sure how that’s all going to playout. We’ll see how it goes I guess.