Author: by Chris Rhinehart, Ryan Jackson

Chris Rhinehart was lead game designer on Lost Within. Ryan Jackson crushed countless dreams as its executive producer.

We at Human Head have wanted to create a game set in an abandoned asylum for a very long time. While this setting may initially seem clichéd, the rich history of asylums and the architecture of the buildings themselves both make for a very compelling world in which to build a game.

We extensively researched asylums via books, movies, and even entering and touring two active mental hospitals. Armed with this extensive research, we set out to make a game that was different from many other modern horror games, and one that was designed from the ground-up for touch interfaces.

When the game released and players said things such as, “I promise this game will still scare the pants off you,” and that the “horror was excellent,” we knew we had done our job.

If you haven’t checked it out, let us tell you a bit about our game. Lost Within is a psychological thriller survival-horror game for iOS and Amazon Fire devices. The game puts you in the role of a deputy sheriff sent into an abandoned asylum to perform one last sweep before the structure is demolished.

Horrible rumors surround Weatherby Asylum: Patients were experimented upon, and a serial killer ran loose, killing nurses and doctors. Upon entering the asylum, the deputy learns that it certainly is not abandoned and he encounters far more than he expected.

What Went Right

1. Cerberus, the three-headed beast monster from Hell

A common problem with game development is that your best people invariably end up as leads. And, if the project is large enough, those leads end up spending most of their time directing others rather than doing the exemplary work that got them the position in the first place. This is especially true of the project lead. So many issues regularly arise that it can be difficult for a project lead to really dig into a problem.

To get around that, we split up the project leadership between three different people. The first of the leads was responsible for ensuring that the game was solid and played well. The second lead watched over all things story to ensure that the narrative remained consistent and powerful. Finally, the third lead covered the logistics of the project, watching schedules and overall quality.

At many companies, this approach might be a disaster, but the senior staff at Human Head Studios has been working together so long that we had the level of trust required to make this arrangement work. The key to making this approach work was regular meetings and communication between the three project leaders. The three leads shared a workspace for ease of communication, keeping each other honest and accountable, and were not spread so thin that they couldn't dive into the various challenges the team faced over the course of development.

2. Ecosystem of Developers

On past projects, we would typically interface with the publisher through one person: the producer assigned to our project. Occasionally, we would receive feedback from the producer's boss, typically the executive producer. When necessary, we would talk to other people at the publisher, usually in specific disciplines, such as their art director or a marketing director.

This process lives or dies by the producer assigned to the project. When everything funnels through a single person, items can get lost or filtered, which can result in miscommunication and problems down the line if the developer and the publisher have different ideas about a particular direction or decision.

Amazon Game Studios has leads in numerous disciplines -- art, animation, sound and music, game and level design -- and for Lost Within, we felt it was important to have these experts regularly participating in the development process. We believed this would result in more feedback, more discussions, and better communication between everyone. An added benefit was that miscommunication, which is unavoidable on any project, would be less frequent and caught sooner.

Amazon agreed with this plan, and ensured that we regularly received feedback from all disciplines and had direct access to the leads. We still had a producer and executive producer assigned to the project, who provided key guidance and oversight on the project, as well as final call on decisions.

In terms of feedback, we wish we could say there was more drama and arguing than actually happened so we'd have more stories to tell. When disagreements occurred (since we're all passionate people) we discussed the issues (with minimal fist fighting) and together determined the best plan of action. There were few publisher mandates, but when they did arise, it was because Amazon felt strongly that not making a change would have a significant detrimental effect on the final game. In the end, this process helped us catch mistakes faster and craft a better experience.

3. Crunch Control

Crunch is inevitable during game development, but it doesn't have to be soul-draining. To manage crunch, we actually scheduled expected crunch time into the project so the team could plan when they might be expected to work longer hours. We scheduled “crunch week” two weeks before a milestone, which gave us the time for an extra push for the milestone in advance and also allowed us to continue the crunch up to the milestone should we require it. This approach limited crunch to no more than a week or two at a time.

In designing Lost Within, we kept an eye toward the overall scope of the game and worked with Amazon Game Studios to cut the weaker parts of it out. We all agreed that a shorter, more intense experience was preferable to a longer game padded out with filler. As it turned out, the game ended up being around 6-8 hours when we user-tested, which we think is a great length for a mobile title.

In the end, there was crunch, but it was entirely manageable. Many team members still worked long hours out of their own personal love and excitement for the game, rather than being forced by management to stay chained to their desks. Hopefully we can use this methodology in the future and throw those desk chains away entirely.

4. Proof of Concept, not a Vertical Slice

Game development often has an internal milestone called Vertical Slice. The goal of Vertical Slice is to take a few minutes of gameplay and develop them to a very high level of quality so everyone can see what the game is going to look and feel like when it's done. The problem is that a Vertical Slice traditionally means doing a lot of work that takes so many shortcuts that it's not suitable for the final game. It's throwaway work, and every day you spend doing this for the Vertical Slice is a day you aren't working on the final product.

Early on we spoke with Amazon about the pitfalls associated with a Vertical Slice milestone, and they agreed that they wanted to avoid it if at all possible. Instead, we focused on what we internally called a Proof of Concept. The goal wasn't to have every system online that the player might interact with over the course of 10 minutes, but enough that we would have a representative experience that could guide the rest of the development process.

This was very successful milestone for us since it energized the team and helped us identify areas of strength and weaknesses in design and implementation.

5. The Big Scare

When we set out to create Lost Within, our main goal was to genuinely terrify people, and make them feel they were physically inside the asylum facing numerous horrors and fighting for their life. We wanted to create a game that terrified you psychologically through narrative situations and events rather than just via cheap jump scares.

As we researched methods and brainstormed ideas for scary, psychologically terrifying moments, we realized that one key way to do this was to make players never feel like they are truly in control of the situation. The player should always have good interface controls to interact with the game, but they should always be tense about the situation and what could possibly occur ahead.

How did we accomplish this? Just a few of the methods we utilized are:

Our team wanted players to have a frightening experience that would challenge them but not frustrate them. As a team, we feel confident that we created a game that players enjoy and want to find out what happens next even though they know that there are horrible things waiting for them. However, everything comes down to player reaction so all we could do was wait for the game’s release to see if we had truly achieved our goals.

When the game became available and we started reading early customer reviews, we knew we had achieved our goals. Comments such as “I feared for my life,” “the game can really scare you,” and “I recommend this game to everyone who is interested in horror,” were like music to our ears. Knowing that people who bought the game “got” and liked what we set out to achieve is one of the best feelings game makers can have.

What Went Wrong

1. Prototypes Became Systems

Prototypes are mockups demonstrating concepts as quickly and robustly as possible to see if they are going to work and whether they merit the effort required to become a proper system. Early in the process, we quickly prototyped various core systems in the game, such as movement, enemy behaviors, searching objects, and interacting with doors. Oftentimes prototype code is both ugly and buggy. This is fine for a prototype since the goal is to represent the idea, not to create final, shippable code.

Once the prototype is approved, then it should be replaced with a proper system that is typically rewritten from scratch. Due to the rapid pace of development, we began to make use of the prototype game systems, fully intending to go back and rewrite them later. However, once systems -- such as doors -- became entrenched in the game, ripping them out and rewriting them threatened to create wide repercussions for other departments such as level and overall game design. In addition, a full rewrite would have taken too much of a programmer's time relative to the remaining tasks/bugs to finish before release.

As such, there are a few instances where you can accidently walk into or otherwise cause your view to clip through doors. They work correctly 95 percent of the time, but that last 5 percent is frustrating and annoying. It became a common joke that maybe we should just cut the doors or replace them with "Star Trek" doors that slide into the wall. Both would have solved the issues, but would have negatively impacted the realism and overall experience of the game.

2. Narrative Perspective

The narrative in Lost Within was a crucial component to the overall experience. In fact, when Amazon Game Studios expressed interest in the title, they stated that a key feature for them was having a compelling and satisfying story that players want to experience. From the start, we had an idea of the story we wanted to tell, but we knew we were going to have to iterate to find the best way to convey it effectively in-game. To that end, we contracted with a number of talented writers to help us both shape the overall narrative and execute on the character dialogue. From day one we were determined to not let the story be just a tacked on necessity.

At the start, the story was too long and too detailed. There were too many reveals, too many twists, and too much content to create in order to convey it all. We had to chop down parts of the story, rework reveals, and ensure that the key beats were properly conveyed to the player. Keeping the dialogue comprehensive, natural-sounding, and to-the-point required a lot of unexpected iteration time.

From a design perspective, this creates a unique challenge since you have to figure out what to chop and what is critical to convey the story without creating major holes in the plot. I wish there was a simple formula for the task of trimming narrative, but there really isn't. There are far better articles out there about how to be a good story editor, but it boiled down to this: Ted Halsted, the narrative director, spent a lot of time collecting feedback from the writers, the team, and Amazon Game Studios. He looked all the feedback and accepted or rejected it based upon certain criteria:

All of this is typical in game development; we haven’t worked on a game where we haven’t had to rework the story due to development concerns, time constraints, or the need to ensure that the story we are telling is clear to the player. But because of how integrated the narrative was to components such as cinematics, level design, and some aspects of game design, delays to the story caused other departments to stall or have to throw out work and redo it when aspects of the narrative changed.

3. User Testing

Every developer knows how immersed you can become in a project as time goes on. You become used to the way the game looks, works, and the various quirks within the game. That blindness can sometimes cause you to not see a major problem right in front of you. You become accustomed to the problem. That's why user testing and getting first impressions is so important, especially in a game where your first impression of each event needs to be strong. Luckily for us, Amazon was in the process of developing a top-of-the-line usability testing lab.

What they were able to provide was extremely useful, but they were developing their process as we were developing the game. Together, we needed to view the results with a critical eye rather than just accepting them at face value. For instance, occasionally we’d get one or two participants that really disliked survival horror games, but the process wasn't yet robust enough for us to go back and filter those participants’ responses out. Because the usability testing process wasn’t completely in place, everyone spent a lot of time interpreting and acting upon the results. Ultimately, we were all on the same page when reviewing the data and together we determined which feedback was valid and actionable and which could be safely ignored.

Similar to narrative feedback, we had to be careful about what feedback we accepted and rejected when reviewing user testing data. In the end when reviewing the user data, we looked for trends and tried to drill down beyond the surface responses to understand the real points that users were trying to make. In the end, we had to trust our collective guts in interpreting this data.

To give a specific example, a number of users complained that the controls were frustrating when dealing with enemies that were chasing them. These users suggestions ranged from minor tweaks to major revamping of the entire control system.

Up to this point the control schemes (tap to move and virtual sticks) had undergone extensive testing and had been very well received. Changing the schemes entirely because of a single case wasn't prudent. However, this case was an extremely important one because if the controls didn't feel good when the player was under duress, then the entire thing would give a negative impression.

We looked beyond the surface and realized that maybe the problem wasn't the controls themselves, but how the users were interfacing with the controls. When under stress, players tended to rapidly tap on the screen, trying to run to a locker or through a door. After analyzing the data, we perceived two problems:

Our fix was to change the size of the hit detection boxes during certain situations. This is very similar to the typing prediction on smartphones -- as you're typing a word the phone increases or decreases the hit boxes of letters on the keyboard to help you type the most common words. In our case, when you're getting chased by an inhabitant of the asylum, the hit detection boxes for doors and lockers grow slightly larger, making it easier for players to tap on doors and lockers.

The second fix was even simpler. When you're being chased and you tap to run into a locker or through a door, all other input is locked out for a brief period of time. This stopped extra taps from negating the player's input to enter that locker or run through that door. While this does take some control away from the player for a brief period of time, we considered this an acceptable trade-off to reduce player frustration.

After the next user test, we reviewed the data and discovered that user scores for controls had raised noticeably and the comments about control frustration dropped. It turned out that our guts were right -- it wasn't the overall control scheme, but two smaller issues that had huge ramifications.

4. Cinematics in our Storytelling

Our original intention with our cinematics was to create a distinct visual style that was also efficient to develop. To that end, we settled on an effect that combined 3D models in freeze-frame poses along with camera jittering and distortion effects. It was effective and efficient. With this in mind, the resources we set aside for cinematic development were limited in scope.

But as the narrative developed we found that the number of cinematics we needed was steadily creeping up. We were also finding that the camera motion and distortions required a significant amount of iteration time to reach the quality bar we demanded. In addition, the narrative department decided that we needed fully-animated cinematics showing critical story elements taking place in the present. In the end, cinematic development became a department all on its own, and it was constantly the highest-risk part of development.

5. Conclusion

Overall, Lost Within was great fun to work on and Amazon Game Studios is a fantastic publishing partner. Our game was featured by Apple when it initially released and currently boasts a rating of over 4.5 stars in the App Store. Human Head is currently working on two new projects and is developing some internal prototypes as well. We hope you'll try Lost Within and that you enjoy the product of our vision. We know that survival horror games aren't for everyone, but we feel that Lost Within appeals to players beyond the survival horror genre because of the compelling, unique narrative that unfolds in ways you may not expect.

Special thanks to a few people who provided crucial editorial feedback for this post-mortem: Ted Halsted, Timothy S. Gerritsen, and Lisa Fields.

Human Head was founded in 1997, and you may know us from such games as Rune and Prey. More recently, Human Head contributed to Bioshock Infinite, Batman: Arkham Origins, and Defiance.

Data Box:

Developer: Human Head Studios
Publisher: Amazon Game Studios
Release Date: April 16, 2015
Platforms: iPad, iPhone, Fire tablets, Fire phone
Number of Developers: The core team: ~20 people, but development peaked at 32 developers
Length of Development: ~18 months from concept to release
Lines of Code:  106,414