Thursday, May 30, 2013

Risk And Strategy in Developing "King's Ascent"


Last Summer, over a meal of spicy curry and naan at an Indian restaurant, my friend and colleague Sharon pitched a game concept to me. She had come up with an idea for what she called a "Reverse Platformer", a game where the player runs upward and uses falling platforms to kill a large monster that chases you.

Sharon and I differ in terms of our game development strategies. Sharon is very concept-oriented. She believes in taking risks on an original idea that creates a feeling, with wacky characters and a unique artstyle. I have a more technical approach, focusing first on what is possible given the people and tools available to me, the time constraints, and the technologies. I would rather make a game based on a standard gameplay model and add a unique twist, whereas Sharon focuses on an emotion she wants the player to feel and then figures out how to get there. Together we make an argumentative but effective team.

After a heated discussion involving drawing on napkins, we both agreed that the concept was interesting. I concluded that, despite the existence of games like Doodle Jump and Catherine, the gameplay concept was novel enough to merit exploration, while being fairly low-risk. Neither Doodle Jump nor Catherine had explored the idea of falling blocks being weapons, and yet from my experience with run-and-guns like Metal Slug, the concept wasn't far-fetched. Sharon came up with a story concept that she felt linked up to the gameplay, about a morally ambiguous dictator being chased by manifestations of his inner demons who had to use the metaphorical building blocks of his own monuments as weapons.

Development Strategy

Sharon and I differed greatly in what we wanted out of the project. Sharon was tired of making low quality games with a short, 3-month development cycle. She wanted a long-term, fully-polished project that was thoroughly playtested, with lots of iteration. Frankly speaking, Sharon's vision of spending 1 or 2 years developing the game terrified me. As much as I wanted to make higher-quality games, if a 3-month long project failed at least you could pick up and start again without having wasted too much time.

We worked out a compromise. We would create a quick prototype of the game in one month. After thoroughly playtesting that game, we would decide how best to proceed with making a real, well-developed game engine. From there, we'd spend another 2 months making a polished, playable demo. At that stage, we'd take stock of what we'd accomplished and ask the team if they wanted to continue making the game. If they did, we'd spend a few more months polishing the game, creating additional levels, and additional art. If they didn't we'd at least have a nice demo to show for our time, and be able to move on to a new project.

The 1-Month Demo

Our first month's demo was decidedly primitive. Andrew Head, our programmer, and I hacked it together in a couple weeks. There was no sound and almost no graphics. But playing it was enough to determine if the concept was fun or not. We decided there was definitely something to the game concept, and it was worth continuing to explore. (You can click the image to play this demo.)

There were a lot of tough questions facing us at the end of one month. The biggest one: what happens when you reach the top of the level? The fundamental challenge we were trying to create here was a tension between escape and attack. You can't ascend without attacking, and you can't attack without ascending. What trade-offs did we want the player to have to make? I was of the mind that if the player reached the top of a level without doing enough damage, they would die, pure and simple. Andrew wanted the style of gameplay to change when reaching the top, with regenerating blocks that allowed the player to do extra damage even if they hadn't attacked effectively up until that point. Sharon was having doubts about the action-oriented gameplay and discussed explorative side passages sections and more expository game segments.

The 3-Month Demo

The next two months were hectic. Andrew worked long hard hours making a more robust game engine to support a bigger, longer game with actual graphics. Andrew and I often disagreed over whether to build for short-term playability or long-term structural elegance. In the field of gameplay, Andrew and I had made a decision that, if the player hadn't dealt enough damage to the boss before he reached the top of the level, he would die. If he did enough damage before he reached the top, he would magically fly upward until he shattered through a window of stained glass signifying the next segment. This in particular became a mystifying point of confusion for players.

At the same time, I stressed out over art and story integration. Sharon had composed an art team to handle creating the huge amount of background assets we needed for the game. Sharon's vision was to have a game with a similar visual style to Braid, which included elaborate hand drawn backgrounds, comic-style cutscenes and a script, full voice-acting, and 3-D animated boss monsters. We had a writer, a background artist, an artist creating "stained glass" pieces to break up levels, and Sharon trying to build these 3-D animated monsters while managing all these creative people. The whole process made me nervous. For one thing, the script that Matthew Glisson was composing called for at least 4 levels. If we didn't have that many (and it was clear that we wouldn't, by the end of the demo period) the story wouldn't make that much sense.

In early August, I had a chance to show our game (still titled just "Climb") to Mike Duke of EA. He gave us some pretty tough feedback. We didn't have enough to show for having worked for 3 months, the UI element looked like a collectible object, the game didn't have enough of a feeling of upwards motion. In particular, he hated the magical flying action. (Click the image to the left to play this version.) Sharon and Andrew and I had a meeting, discussing how we felt about the direction the game was going, and if there was a way to address these issues. We did the best we could in using art and exposition to make the more bizarre gameplay elements more obvious, but we couldn't fundamentally change the structure of the game if we wanted to release our demo on time.

Finally, on August 28, we completed a demo of "Climb", which you can play by clicking on the image. This demo had a number of problems: lag, some clunky platforming, extremely punishing gameplay. Our original intent had been to complete a demo we could post on Kongregate in August, and then finish the game within the next couple months. However, as proud as we were of the demo, I didn't feel that it was ready to subject to Kongregate. I had a feeling of accomplishment, but I was nervous about the weird mechanics, and wasn't sure if creating the next 3 levels would be worth it.

Stop or Continue?

Andrew, Sharon, the art team and I had a serious meeting around the end of August. I laid out what we had accomplished, and the barriers that lay in our way. We had 3 more levels to design, which meant that we had only accomplished about 1/4th of the required artwork and level design. The narrative end of the game had barely gotten off the ground. The script was unfinished, and only scratch audio had been recorded for the story. Although we had achieved gameplay, we were very far from any sort of narrative cohesion, and I was not confident in keeping the engagement of the team members for long enough to truly finish the project.

What really surprised me at this point was the dedication and perseverance of our artists. Andrew and I were pretty pessimistic about the project at this point, but Meagan, our concept and background artist, was still raring to go despite the massive amounts of work she had left to do. Carolyn, our stained glass artist, was quietly optimistic and showed no signs of wanting to stop. Sharon, despite having only completed one of the boss monsters, was insistent on persevering as long as it took to get the project done. As unoptimistic as I felt at this point, I couldn't let down such a dedicated team, and we decided to continue the project on until the end.

Fixing The Script 

The biggest barrier to finishing the game in my mind, was the script. If we didn't have the story finished, we couldn't record it, and if we didn't record it soon, we would lose the voice talent that had agreed to help us. I pushed our writer to get the first half of the script ready for a September recording session. The recording sessions were nerve-wracking. We had meetings with the voice actors, recording them over computer microphones and testing the script. Everyone was too busy to meet on-time, and as we started reading the dialog out loud, suddenly everything felt cheesy, forced, and overdone. Sharon and I pushed for a serious, straight-faced reading of the script, but our voice actors were confused by the material and had trouble taking it seriously. It took a lot of readings to get things even close to right. We had gotten the permission of Riccardo, a CMU audio guru, to use his professional recording studio for the voice acting. We could record in 2 sessions, and we had to get it right the first time because we wouldn't get another chance. Each of these 2 recording sessions was full of heart attack moments for me. The worst was during the 2nd session, when we discovered a piece of the script for the 4th level was completely missing, and our newest team member, Alex Moser, was forced to rewrite it from scratch 15 minutes before we recorded. The result of all this heartache and trouble was complete audio of all the game's dialogue. We couldn't change it, we couldn't modify it, but it was done.

No One Coded Anything For Months

The worst possible scenario occured in late 2012. Our main programmer, Andrew, got a girlfriend. This situation was almost as bad as if he had been hit by a bus. Suddenly, he had very little time for the project. I could tell he was thinking about quitting. As we began to see him less and less in meetings, I fretted that we would never be able to finish without him. I had been doing plenty of level design and tweaking, but we really relied on Andrew to solve major issues and do engine coding. If he left the project, simple tasks like reorganizing menus and reordering level segments would be beyond us. I made a drastic decision at this point. We needed to finish everything, all the coding for the entire game, in 7 days during Winter break.

On the 13th of December, Sharon, Andrew, Alex and I locked ourselves in a room and started coding. For the next 6 days, we would do nothing but code infrastructure for the game and build levels 2, 3, and 4. I won't tell you what horrors we endured to make this happen, but it worked. When we emerged, sweaty and exhausted, on the 19th of December, we had 4 levels of gameplay and a "to be concluded" screen at the end of the game. We had a system for displaying cutscene comics. We had 3 new bosses composed of clip art. Gameplay was tighter from playtesting and iteration. The game was done... except for the art.

Waiting For the Art

In some ways, January through May were the worst months for me. With main coding done, there was nothing left to do but playtest levels again. Without Andrew to fall back on, the small handful of major bugs fell to me to investigate, and despite Andrew's elegant code I often get stuck. However, most of these months I spent watching and waiting for the art to finish, putting faith in Sharon, Meagan, and Carolyn to see the project through to the end. 

Although these months were stressful for me, our artists delivered. Andrew had created a very elegant system for getting assets into the game, and including the art was easy (if time consuming).


As it stands, King's Ascent is just weeks away from being posted on Kongregate and judged by thousands of gamers. Only time will really tell how the project will be judged, but from what I've seen in playtests, the time we put into this project really paid off. Compared to our 3-month-long Game Creation Society projects, King's Ascent is head and shoulders above these games in terms of content, quality, and polish. We had a lot of bumpy moments in this project, but our long-term strategy of multiple prototypes helped mitigate risks and provided backing-out points that would have left us with nice deliverables had we decided to abandon the project at those points. We were able to adapt to and survive a number of production challenges, and continue forward constantly despite our varying workloads and time constraints. I stand behind our prototyping structure and would definitely use it again for my next project.

King's Ascent can be played at my blog by clicking the above image. Keep an eye out for our release on Kongregate next month!

What Worked
  • The 1-month, 3-month, 1-year model of prototype, demo, game, was effective.
  • Polishing a game for a long time really does make it better
  • "Outsourcing" the 3rd level and boss to another designer gave a fresh feeling to the 3rd level.
  • Google Hangout as a communication medium was effective for a distance-organized team.
  • Finishing the programming before finishing the art turned out well.

What Didn't
  • The game script and story is really important. Don't neglect it in the beginning of the design process!
  • Story and gameplay should be integrated.
  • Avoid illogical game mechanics! They're confusing and hard to design out later.
  • Don't book voice actors until you need them.

No comments:

Post a Comment

Note: Only a member of this blog may post a comment.