I’m taking an opportunity to write about my Xtreme Game Programming method. Perhaps I’ll gain some insight on how to improve it.
Basically, this method is meant to insure that adequate time is spent on the most important aspects of game development. Also, by keeping the iterations as short as humanly possible, I’m injecting as much feedback into the loop as I can.
The first step, the design phase, lets the developer plan out the next feature of his application (or the basic outline if he hasn’t already done so). I estimate that this part shouldn’t last longer than 25 minutes. This step should ideally begin with a mini-brainstorming session, followed by filtering the most captivating feature out, and expanding on it. It should focus on the user experience, and not the technical aspects. However, a gut feeling of whether it’s a small enough enhancement will definitely come in handy to keep the iteration short.
The second step is the planning & redaction of a set of function tests to ensure the correct functioning of the feature. This forces the developer to imagine and expand the end result before committing to it. I anticipate this step to take 15 minutes. According to TDD (or test-driven development), this is an essential exercise in order to forge a perfect user experience. Also, the test will make sure that the feature isn’t broken when come the time to add more. However, an iteration might be chosen to re-work/replace a feature, in which case perhaps the functional test will be re-worked itself.
The third step is the planning & redaction of a set of unit tests to ensure the correct functioning of the individual units inside the application. I anticipate this step to take 10 minutes. This step, like the last, forces the developer to be proactive, and to imagine the simplest set of objects that should be required to accomplish this goal. This is also a TDD practice. At this point, the developer should have began imagining how this feature will fit into the application, and its exact implementation. However, the thinking should remain abstract, in order to make the application easy to understand to prying eyes.
The fourth step is to finally start implementing the feature into the application, and make the new function & unit tests pass. According to TDD, at first, the developer’s sole purpose should be to make the tests pass, no matter how simplistic the code chosen to do so might be. The relevancy of this is to keep the implementation as simple as possible, and not code things that don’t need to be coded. I’m thinking that it should take around 10 minutes.
This fifth step(s) of the method are the refactoring steps. This step is repeated 4 times in a row, each lasting 5 minutes. During the phase, the developer sets out to make the code more robust, clean, and separate the responsibilities where they belong. Now that I think about it, this step should definitely be clocked at no more than 20 minutes, but can be divided in smaller cycles (2-4 minutes), or bigger cycles (6-8 minutes) depending on the size of the re-factor.
The sixth (and my favorite) step is to play the game! If the developer isn’t ready to take his creation out on a test run, he should perhaps rethink his initial purpose in creating a game. Plus, this lets him see the application from the user’s perspective, which will let him better design the next feature when come the next iteration. Even if the game is small/simple that that point, I think it’s important to at least spend 10 minutes playing through the actions, and giving yourself feedback on the strong points/weak points of the game. One should focus on having fun at that point, but also imagine possible improvements to the game.
The developer should ideally move directly to the feature design step after having test-played the game. The reason for this is that the game experience is still fresh inside the developer’s psyche, so designing the next feature will definitely be more effective. A break can be taken afterwards.
Hope you enjoyed this!