16 de octubre de 2019

From blockout to launch - a behind the scenes look at Kine's level design

Games

Indies

Kine

Design

Art

Gwen Frey

Tech Blog

Por Gwen Frey

#Blocktober is a month-long celebration of level design in video games. Typically, a designer shares early block outs of their work and delivers a peek into how games evolve from concept to finished product. I’ve always loved this time of year and wanted to share my own experience designing the narrative puzzle game Kine in the hopes it is useful for other developers. My process for designing this game can be divided into four phases: The phase where I was creating the puzzles, the phase where I was designing a world and a narrative for those puzzles to fit into, the phase where I was reworking the game so my artists could iterate, and finally, the finishing phase where I was porting, localizing, and shipping the game. Here are some time lapse videos and takeaways from each phase:

Phase one:

In the beginning of this project, I had only planned to do the first of these four phases. I was going to create a simple puzzle game where each puzzle loaded one at a time. In this version of the game, a player would use a simple UI to choose a level to play, and completing that level unlocked the next level in a sequence. Kine began as a hobby project while I had a full-time job, so I was developing this game during my nights and weekends. Phase one took exactly eight months of me working alone in my free time.

A major takeaway from this phase was just how much content was cut early on. In this first phase, I tossed out well over half of the mechanics that I had tried. I don’t have footage of all of the various puzzle-type-things I attempted, but in the beginning, if a player rolled off of the world, they would land on a limb. That felt unpredictable and was cut. Now if you roll off the world, you trigger a fail-state and roll back to where you were. I tried having puzzles where various objects would stick to you, and I tried having puzzles where there were drums in the world and you could only move forward towards the exit if you hit a drum every fourth move. All of these ideas were cut in favor of a smaller number of mechanics that were similar and worked well together. Even after trimming down the number of mechanics, I crafted as many puzzles as I could with the mechanics that remained. Then I cut at least half of those puzzles as well, so only the best ones remained.

In this first phase, I struggled with how to structure the puzzle sequences. I wanted to force the player to play puzzles in a specific order rather than allowing them to choose any puzzle to play at any time. By sequencing puzzles, I could tell a narrative, or I could ensure that the difficulty curve was very precise. However, if a player was stuck on a puzzle and didn’t have other options, then that player would walk away from the game. I needed the player to have multiple sets of puzzles that they could play at any time. This is why Kine has three characters with their own puzzle sequences that a player can switch between. If there was only one set of puzzles to play at any given time, then I wouldn’t be able to avoid the player getting frustrated and quitting the game permanently.

After I finished phase one, I was proud of what I had made. I knew I could polish what I had and ship it within a few months if I wanted, but I didn’t feel done yet. I was having a great time and I decided to scope up the game and dedicate some time to stitching all of the puzzles together into a world.

Phase two:

This is phase two of Kine’s design. Phase two took me exactly 14 months as a solo developer as I transitioned into working my day job part-time. At first, phase two went very smoothly. I arranged the puzzles I had sorted into paths and then wrote a Bluetility to procedurally generate the art for it in this version of the game.

Knitting all the puzzles together into a tightly confined world didn’t take long, but it did cause a lot of headaches later on. I immediately reached a point where I couldn’t iterate on any puzzle - the floor of one level was the wall of another one. Moving a puzzle one unit over to fix a bug meant shifting large parts of the world and often introduced bugs in other puzzles. I had planned to design interesting moments where puzzles combine into bigger puzzles, or where you traipse around the entire world as one big puzzle at the end. I believed that this would make my work worthwhile. However, I never managed to make that into a fun experience and all of those ideas were cut from the game. In the end, I'm not sure if the effort put into stitching the world together very tightly was worth it. If I could do this again, I would have spaced everything out much more.

During this phase, I struggled heavily with the overworld map. I wanted the player to be able to click the level from a pulled-back view of the world and jump directly into it. I was imagining a path with different icons on it that a player could click to start a level. I wanted something similar to an old-school Mario game. However, I never managed to get that to work with the actual geometry and game world. In the end, I settled with having the level selection buttons and descriptions for the level selection on the left side of the screen. As you mouse over each level in the level select, the corresponding level in the game would glow. This allowed the player to see a representation of the paths in the world, but also allowed me to space the buttons out so they were easier to click.

If you look carefully during the time lapse of this phase, you will also see another cut feature - I had extra flavor text for each character in the game. If the player was playing with one character too long, the other characters might get jealous, or they might wonder aloud if they were good enough for you. If characters Roo and Euler were in love, they would ask you to play certain levels where they could be together. I was playing Darkest Dungeon while I worked on this and I enjoyed how your roster would reflect on their recent dungeon crawl while you were in the Hamlet. I wanted to do something similar during the level select screen in Kine. However, without a character portrait visible, the flavor text didn’t have the same impact. This idea was cut and I put more narrative effort into the banter that the characters have before and during each level instead.

At the end of phase two, I quit my job to work full time on Kine. I shared the prototype from the end of this video with different publishers and platform holders, and I secured funding to further develop and finalize the project.

Phase three:

In phase three, I uprezed the environment art and UI art, added more puzzles to flesh out the story, and rewrote the dialogue. Phase three took six months of my time working full time, and $200,000 of art outsourcing. At any given moment, I had somewhere between three to six other people generating art assets throughout phase three. This included everything from concepting, marketing images, modeling, and so on. I could do another video that goes into collaborating with outsourcers or how we achieved the look of the game. However, this is Bloktober, so for this post, I’ll remain focused on the design of Kine.

My biggest design job during phase three was chunking up the world into static meshes. I had generated planes procedurally for the environment art, and now I had to transition to a system where each puzzle in the world had its own static mesh. This was complicated by the fact that the walls from one puzzle were often the floor for another puzzle. The world had to be meticulously sliced up into many different pieces for the artists that represented parts of a level. I had to script each part to slide up or down if it obstructed the camera.

I also heavily modified the level select flow during this phase. Previously, I had tabs in the UI that represented different regions of the world. The puzzle sets were located on these tabs - some sets of puzzles occured on the dance floor so they would be on the dance floor tab, and some occurred in the world so they were placed on the overworld tab, and so on. However, the order that you unlocked these puzzles was far more important to the player than where they were located in the world. Sorting the puzzles by physical location was very confusing to players. I stripped the tabs from the level-select screen so that all puzzle sets were visible under one heading. Then I added a collapsed version of the UI for each puzzle set so a player would only see basic information on a puzzle set until it was expanded. Selecting a puzzle sequence would zoom in to frame that area of the world, and the UI would expand to show narrative details. This framing was much simpler and made the game easier to understand. Finally, I added locked sections for any puzzle sets that the player hadn’t unlocked yet. This helped the player feel a sense of game progression.

I am extremely happy with the results from Phase three. I wrapped up development on Kine in the last week of June.

Phase four:

I am currently working on the last stage of game development - closing out and shipping. Kine launches on the Epic Game Store, Xbox One, PS4, and Switch on October 17, and then ships on Stadia in November. This phase involves a sizeable number of contractors to help with translating Kine to nine different languages, and porting Kine to multiple platforms.

I hope you all enjoy playing the game as much as I enjoyed making it, and I hope this #blocktober post encourages other level designers to share their development process with the world!