King's Ascent Postmortem: What we learned from creating a unique platformer with a narrative

Haven't played King's Ascent? 

Just released on Kongregate: http://www.kongregate.com/games/shoosein/kings-ascent

Also available on Newgrounds: http://www.newgrounds.com/portal/view/620100

What went right:

Simple core mechanic with a unique twist:

King's Ascent is a platformer where platforms are used not just to escape, but to damage monsters.  Since most players are already familiar with platformers, they already have skills for timing and positioning within this genre. King's Ascent builds on these skills to challenge their abilities in path finding, judging trajectory, and balancing the tradeoff between causing enough damage versus gaining a safer distance.

Our goal in making King's Ascent was to create a free game with a professional level of polish and playtesting. Given our inexperience and time constraints, it was very important to keep the mechanics simple to achieve this goal, let alone finish the game. The core mechanic of King's Ascent had originally been a backup idea for the Global Game Jam, so we knew we'd be able to pull it off in a longer time frame. 

Playtesting in person:

"Hmm..." "Gah!" "Oh!" "Heh” are all extremely important noises players make at points that respectively stump, frustrate, surprise, and amuse them. They won't remember most of these moments, especially in a game as fast paced as King's Ascent. Jotting down observational notes with a follow up interview is an effective method of pinpointing the causes of memorable joy/frustration.

One important question we asked during the playtest interviews was “What was your goal while playing this game, and what did you use to help you achieve this goal?” If the player was not doing what we intended, their answer to this question helped point out exactly what was confusing to them and how.  

Story:

King's Ascent is the story of a king who believes he's done great deeds for his people. He discovers that he's made enemies from the consequences of these deeds. These enemies are now sending giant monsters to kill him.

The story in King’s Ascent is interesting in that it’s unclear whether the king made the right or wrong decision given his circumstances. Some players argued that all the king’s actions were completely reasonable, and his enemies were simply selfish. Others sympathized with the king’s enemies, but thought they should have handled the situation differently. Some thought the king was a selfish jerk and deserved to be punished.

Most players claim that this story was what made them play King’s Ascent to the end. Although each level introduces new mechanics and new ways to use existing mechanics, even players who enjoyed the gameplay still found the story to be the main draw. For the players who felt the gameplay was too challenging, their interest to see what happens next in the story countered their frustration.

Even people who didn’t like the story still enjoyed that it existed. Some commenters that claimed to hate it still raged in a way that showed they were clearly engaged with the story, but didn't agree with the outcome. 



Setting milestones:

We spent a year making King's Ascent. Development was divided into milestones: preproduction, prototypes, finished first level and final game. Each milestone had a deliverable to show off our efforts up to that point. Completing milestones gave us motivating boosts of accomplishment. They were also a failsafe: if the team fell apart for whatever reason, we’d still have something to show off and our efforts would not be wasted. 

What went wrong:

Narrative/Voice Acting management

When we approached the story for King's Ascent, we made the mistake of treating it like art/music: something that could just be plugged in and easily iterated later. We did not take into account the impact on the game’s pacing, and no one on the team was responsible for narrative design. We were all so focused on our individual tasks that no one gave our writer feedback until a couple weeks before we scheduled our recording session.

The recording session was scheduled before the team had settled on a finalized version of the script. This was because we talked to the voice actors too early, and feared that they would lose interest if we waited too long. Additionally coordinating their time and reserving the recording studio was difficult. The rush to hold recording sessions as soon as possible ended up with us schedules them on dates when our writer was unable to attend to help direct.

While we had used placeholder voice acting to time the in game dialogue, we did not have any for the cutscenes. It wasn't until after both recording sessions that playtests revealed our cutscenes were too long. We were not able to re-record, so we had to drastically cut out recorded dialogue. Some editing had been done during the recording sessions, but none of those changes were recorded. The cutscenes had been drawn to the wrong version of the script before dialogue was thrown out; so much of that work had to be scrapped and redone.

When it came time to compress the sound to fit into the 20mb limit, neither the voice actors nor the writer were consulted for a sound check. Our voice actors were talented professionals; unfortunately the game does not fully do them justice.

Too many art styles

King’s Ascent’s combination of stain glass cutscene and checkpoints, painterly background art, 3D boss monsters and 2D cartoony characters/UI/comic-style cutscenes did not go over well with players.

Players find the 3D monsters particularly jarring. The idea with these was that the extra dimensionality would translate to be more menacing/magical. However, not enough time was spent researching the proper shaders, rendering techniques, nor paintovers that would have achieved this effect. Additionally, the limit on the number of frames for each animation combined with their size made their movements look especially jerky.

Many of these problems should have been figured out during the preproduction phase. However we just dove immediately into development with King’s Ascent. We did try a couple different techniques to render or rotoscope the bosses afterwards. However techniques that worked for one monster didn’t look good on others. Eventually we realized changing the art style on the monsters would not improve the game significantly enough to be worth the large amount of time and effort to do so. It was time to let go and move on.

Balancing against work/school

Many indie teams have day jobs. Many members of our team have day jobs, and many also had demanding schoolwork on top of that. The original plan was that King’s Ascent would be a side project in addition to part/full time jobs, school and extra-curricular activities.

Turns out, making a thoroughly polished and playtested, art heavy and story driven game was too much work to be just a side project. Some of us resorted to using King’s Ascent for class assignments. This caused a lot of stress when the development goals and the class goals did not align.

Our time limitation had a number of severe consequences:

1)      Our main programmer didn't have time to work on King's Ascent as a programmer during the spring semester, though he still contributed music. Because of this, most of the programming had to get done in a 2 week jam. The task of implementing remaining art assets in code fell to producer/level designer. This added to his stress and delayed otherwise trivial implementations because he did not know the code as well.

2)      Many tasks that should have sequenced each other due to dependencies had to be worked on in parallel. One example was cutting up the audio and drawing cutscenes with dialogue. The result was that the dialogue did not always match the expressions of the characters, which unfairly reflected negatively on our voice actors.

3)      Not enough time to search for more experienced yet dedicated people willing to work for free. Without an experienced 2D animator, there was exactly one 2 week period that any 2d animation could be finished in. This period occurred before any background art was done. As a result, the styles didn’t match and there was no time to redo the king’s character design.

Conclusion:

Lessons learned:

1)      Games are not just about gameplay. Stories, especially ones that are not just good vs evil, but allow room for debate and interpretation, are powerful tools for keeping players engaged with your game.

2)      When working with multiple artists, make sure they have a meeting to figure out how to create a cohesive style. Make sure they share concept sketches, style guides and color palettes before any animation, 3D modeling or other intensive art production occurs. Know your technical constraints: large sprites with multiple levels of shading and lots of animation occupy a large amount of the file size budget in a 2D browser based game. 

3)      Start writing the script early, in parallel or possibly before prototypes are being made for your game. Use placeholder dialogue as soon as possible, even if it’s just a random team member recording themselves with a laptop microphone, so you can catch and fix pacing problems. Hold meetings that focus solely on the story and narrative design. Have the team read the script aloud to catch lines that don't work as well off paper. Save all changes made to the script and make them accessible to team members working with it. Have at least two pairs of eyes review every aspect of your game so everyone can get feedback early on.

4)      Feedback you get from online players or surveys will be vague. The most effective playtests are done in person, with detailed observation notes and targeted questions prepared ahead of time.