Our two-man indie studio is currently prototyping a game we've codenamed ZOMG. In this post I'd like to share our experience of prototyping and iterating ZOMG's early design, what went right, wrong and how we can improve this process in the future.
Starting out as a junior designer for a big development studio I was keen to prove myself, coming up with impressive and complicated solutions for the features I was working on. They were going to be the best, most awesome features that would change the state of play forever! Of course, when reality hit and the features were already half-implemented I realised they weren't the most awesome things ever. The whole team was in serious crunch so ripping out the code for a redesign simply wasn't an option. All that was left to do was clumsily edit the features as best as possible, which lead to some incongruity with the rest of the game.
At the time I felt pretty crappy but I came away from that experience with a better understanding of the importance of paper iteration. It seems obvious, but you don't need to wait until a feature makes it into the game to start the process of iterating and refining. Iteration on paper can save you a lot of headaches; it's cheap, can give you a clear picture on what you're trying to create and saves programmers' valuable time by not having to overhaul your system when it doesn't work out (and trust me, it won't work out first time).
You can design anything on paper so don't be put off by the fact your game is action oriented. Be creative during this process, for example if you want to see how a particular puzzle plays out in a third-person action game you can lay out the environment top-down on graph paper, use cardboard cut-outs to represent moving scenery and Warhammer figures to represent the player or enemies. You may know roughly how fast the player-character runs or climbs or takes to perform certain animations so try and recreate that in your paper prototype – use anything that can help express the experience you want to make. If you have the time and skills you could even use other game engines to mock-up your designs – whatever works! Xbox Live Arcade hit Shadow Complex used nothing more complex than cardboard and graph paper to allow the designers to play the entire game before anything was committed to code.
There is, of course, a downside. Just because something looks good on paper doesn't necessarily guarantee it'll be fun when it makes it into the game. Our initial designs of ZOMG went through several paper iterations and when we were confident we'd hit the money we made a first pass getting something playable in-game. The prototype raised more questions than it answered and eventually lead us to completely rethink the core experience.
So, what could we have done to prevent this? Well, it's difficult to be sure if additional time spent on the paper prototype could have told us the design was effectively no fun but I think if we were more thorough we'd have spotted some of the more glaring usability problems. The initial design we coded was essentially a 2D platformer where all movement and jumping was handled by the game (yep, we actually made a game that played itself - that's how we roll) and it was up to the player to control whether the character was facing forward, therefore in obstacle avoidance mode, or facing backwards, therefore shooting his pursuers. It was designed to be fast paced with twitch gameplay. What we found almost immediately was that players had no reference point to how close to an obstacle or pit they needed to be for the game to avoid it for them. There were some solutions we entertained, such as marking out 'jump zones' to indicate where the player needed to be to jump, but really it just solidified the fact that it wasn't a great idea. We were fortunate in the sense that a lot of what we'd prototyped wasn't wasted, for example the procedural terrain generator and the 2D platform engine were both proven in the initial prototype.
It's important not to treat in-game prototypes as dumping grounds for whatever ideas crop up in brainstorm sessions and to keep revising ideas until you're confident they can work in-game, but don't be afraid to discard ideas if they don't cut the mustard.
One last pointer, if you're not the one coding the feature into the game don't forget to take your paper prototype to the person who's actually doing the work. There's nothing worse than a programmer receiving a doc just dictating what they should do. It's imperative that they have ownership of the feature too, they may even come up with better solutions or spot flaws you haven't!
No comments:
Post a Comment