Postmortem: Sarbakan's Lazy Raiders
June 9, 2010 Page 2 of 3
4. Level Design
Early on in the project, our lead programmer hatched a cool level editor. In less than a week, he had it built and debugged. The tool's main objective was to hide the middleware interface so that a non-programmer would be able to create and modify levels without any training.
The editor had the basic functionality to create, move and copy objects. It also allowed the designer to modify object parameters. All changes could be saved and played on the spot to verify the fun factor and the difficulty of the new puzzle.
With this little gem, the level designer could build levels by himself without needing to commandeer a programmer, effectively saving us both time and grief. With it, we created 300 levels, the top 80 of which made their way into the game. It was also the perfect tool to crush those pesky bugs as they reared their ugly heads.
Another tool that simplified our work was RLD (realistic level design), also known as the LOL (log of levels). This dynamic document displays the content of each level and the score values and assigned difficulty rating of each object.
This document serves as a sort of game inventory to validate the entry of each new game mechanic, ensuring a smoother learning curve and creating variety over time. All the data can be consulted in graph form for a better visual understanding of the ramping.
5. Tests, Tests, and More Tests
The internal testing team was included early on in the production process, if only for reasons of proximity. The level designer had been part of the QA team before this project and his desk hadn't yet been moved. This physical proximity, added to the history of teamwork between the level designer and the testers, led to the quick death of countless bugs. They shortly became masters of whack-a-bug.
The further along we were in the production process, the closer loomed Microsoft's certification test. Having by then learned caution, we decided to submit Lazy Raiders to pre-certification testing with one of our partners, Enzyme Testing Labs. This allowed us to identify and pinpoint a lot of issues and bugs, most of which were easy to fix.
We were left with only three important bugs, which we were free to address, with time to spare, before final certification. In the end, our bug count was extremely low, and Lazy Raiders passed certification hands down on the first try. Our testing foresight came at a price, though; 15 percent of the total project budget. It may seem a hefty price to pay, but it was worth it because it spared us from the extra production costs inherent to a last minute bug hunt.
Not all testing was focused on technicalities. In addition to external usability tests, we put in place a system to test and validate the quality of the game in-house. Staff members were asked to play the game and fill in a questionnaire to communicate appreciation on different aspects of the game. These tests were made on every important build to identify and correct major issues before submitting the game to the publisher.
What Went Wrong
1. Me, Myself, and I
As we were venturing into new territory, we did some research. Okay -- a lot of research. We wanted everything to be perfect, so we dug up every little fact we could on downloadable console game development and read through dozens of postmortems to try and learn from others' mistakes. Once we'd compiled all that data, we set down ten golden rules that we were sure would lead us to victory.
Confident in our perfect little bible, we followed these golden rules blindly instead of focusing on what was really important: the fun factor. We concentrated on how the game should be done instead of what it should be.
Also, smug in our perfect process, we failed to listen to the first wave of comments, defending our IP instead of catering to the players' needs. Thankfully, our Microsoft producer steered us on the right track before it was too late; but we'll get to that later.
You might wonder what were the rules that blinded us. Some were artistic in nature, others touched programming and production. Three of them were about the game design proper:
1. Nothing can move by itself, gravity will do the job.
2. Every trap needs a counterpart.
3. Everything needs to be consistent and logical.
Rule #1 survived the contact with reality, but the two others didn't. Rule #2 made the game so complex that new players were overwhelmed; it had to be broken to provide smoother ramping. Rule #3 was broken to give more emphasis to the flip mechanic, so that we could have such things as minions who undergo transformations during flipping. It's not logical, but it improves the game.
Page 2 of 3