Going through some old folders on my computer I came across a design guidelines document I wrote up towards the end of the development of Kinetica. The document had some interesting points, so I thought I’d share it here. Plus it gives me the opportunity to stress how important playtesting is to the quality of a game.
So, “Kinetica? What’s that?” I hear people say. Well, before we did God of War and God of War II over at SCEA Santa Monica, we did a little-known racing game for the PlayStation 2 by the name of Kinetica. The art was great, the code was pretty good (we were still learning the PS2, but large portions of the code formed the foundation for the two God of War games), but the design and gameplay, IMO, left a lot to be desired. The game press pretty much agreed, and as of today Kinetica has an average score of 76% on gamerankings.com. Not bad, but certainly not great either.
In fact, the design/gameplay had serious problems from the start all the way up to the end of the project. I was pushing for playtesting of the game throughout development, which I knew would help address this.
Playtesting is when you bring in outside people, put them in front of the game, and have the designers watch in horror as the players fail to do all the things the designers had so carefully planned on them doing. The designers then fix those issues, another playtest commences, and you rinse and repeat until all gameplay problems are gone. Playtesting had been one of the cornerstones of development over at Neversoft on Tony Hawk’s Pro Skater (which at the time was the latest game I’d worked on), and the key to THPS being the smash hit it was. However, for whatever reason, playtesting never happened on Kinetica, and the gameplay lacked as a result.
Kinetica’s gameplay problems included blind jumps and blind corners, places in the levels where you could come to a complete halt, tracks that didn’t have visuals indicating where the player was supposed to go, and many others issues. To help the project management team identify these issues I wrote up the guidelines document that I mentioned at the start of the post. While a majority of the comments are specific to racing games, and some to the peculiar racing game that Kinetica was (where you could race up or down walls, or even suspended from the ceiling) I thought there were some interesting points in my list worth sharing, so here it is:
GAMEPLAY
- A first-time player should understand and enjoy the game without instructions.
- The player should always have enough information to make a sensible decision.
- Don’t allow the player to get lost. Even if the player is randomly dropped into the level at any orientation (such as after a spinout) it should still be clear in which direction he should go.
- It is important to let the player see things early on, allowing him to plan ahead.
- Don’t force the player to memorize anything, certainly not track layout. The player himself can still decide to memorize what the best race line is, etc, but this should be optional, not a requirement.
- Don’t place a turn immediately after a crest, as you cannot see the track turning. The player should be able to take turns without in advance knowing which way they turn.
- Design jumps so that you can see the intended landing area before you go airborne so the player can aim himself accordingly.
- Target the casual player, but cater for the hardcore player through alternative routes, etc.
CONTROL
- Anyone should be able to instantly pick up the controller and race around the track without any major problems.
- The player should always feel in control.
- If you take control away from the player, whether through a large jump or just a small bump, the player should always land safely (but not necessarily in a good spot).
- Be forgiving. Aid the player in performing good actions (compare allowing for late jumps in a platformer, sliding through doorways and autoaiming in a shooter, etc.)
- Distinguish between learning which buttons do what and learning to actually use the controls to the fullest extent.
- Immerse the player in the game, don’t make him remember which button does what.
IMMERSION
- Don’t interrupt gameplay.
- Avoid all constructs the player can run into and come to a complete stop from. E.g. slant or bevel corners.
- Don’t kill the player. Do whatever it takes to avoid the player falling off the level or otherwise dying. A simple mistake should never kill the player. Dying stops gameplay for 6-8 seconds and is the ultimate, frustrating, interruption.
VARIATION
- Thinking of a track as consisting of a sequence of sections, give the player more than one thing to do in a given section. E.g. provide several possible paths.
- Make multiple paths count in the sense they provide different rewards.
- Vary what the player is doing between sections. Alternatives include going fast, zigzagging, jumping, bumping, balancing, boosting, etc.
- Award repeated play. E.g. provide alternative, harder but faster paths. Wide curves with different racelines that lead into different paths. Etc.
GAMEPLAY VISUALS
- Use visual cues to help the player navigate. Use colors and light/darkness to aid player in discerning the direction in which he’s going.
- Give the player a sense of what’s up and what’s down. Distinguish floor from ceiling.
- Make the left wall different from the right wall so you can tell whether you’re going into or back out of the tunnel.
- Help player identify his location by using landmarks, both on a global and local scale. Make the colors unique to different areas of the level (but in a consistent way).
- Highlight the drivable area. Draw attention to what is important, namely the part of the track you’re supposed to race on. Disinterest the player in everything else.
- Arrows in the ground and ‘wrong way’ messages can further help aiding the player, but they should be secondary, not primary measures.
Of course, other people, notably my longtime collaborator extraordinaire and then Kinetica lead programmer Tim Moss, were also aware of these problems. However, programmers commenting on nonprogrammer subjects isn’t always the most popular thing, so towards the end of the project, David Jaffe was brought on to fix many of the things that I had already outlined (as well as other problems I had not). Unfortunately, at that point there simply wasn’t enough time to address all shortcomings, so we got somewhat average reviews (and deservedly so).
We finally got around to implementing playtesting as part of our development for God of War. While, overall, GoW is simply the result of a kickass team working really hard to produce a kickass game, I think it also shows the value of thorough playtesting. In conclusion: playtest early and playtest often, and don’t forget to consider the stuff outlined in the design guidelines listed above!