A detailed, candid postmortem of the mobile horror game -- from concept to crunch and everything in between, this article tells the story of what it took to build Weatherby Asylum.
August 26, 2015
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.
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:
Powerful Enemies: The enemies in the game had to be powerful to be scary. Encountering an enemy means certain death if you don't act quickly. From the beginning, we designed our enemies to achieve this goal. Most enemies move faster than the player character, and will kill the player in seconds when they attack. This approach had the desired effect: Enemies were certainly far more terrifying to encounter since each one could mean an end to your game.
In many survival horror games the protagonist is completely powerless against the enemies. This certainly is scary but quickly becomes repetitive and loses effectiveness after the tenth (or one-hundredth) time that you've had to run and hide from an enemy. We made the decision to give the player a variety of tools to use against the enemies, which may have reduced their scariness to some of our players. However, we feel this increased player agency resulted in a more satisfying overall experience. In addition, this approach sets the game apart from other survival horror games and resulted in a game that we feel more players will play all the way through to experience the entire experience.
Controls and Interface: We wanted to terrify players while also ensuring we had designed an effective touch-interface for movement and enemy interaction. Controls had to be solid and responsive, to allow players to act quickly. But the enemies had to challenge these controls.
We designed all of the enemies to challenge players and their abilities through the use of the controls: The player has to carefully and stealthily avoid Shamblers (one of our enemy types) and, if detected, quickly shift into flight and run away. Similarly, the Screamer type challenges players to be patient and walk slowly near them, never getting too close or making too much noise. The Follower type requires that the player keep them in their view at all times, until the player decides to make a break for it and run away.
And, of course, on top of these control challenges are the interface for item usage, which helps the player to deal with enemies by stunning them, distracting them, and later even destroying them.
Don't Show, Suggest: From the start, we didn't want Lost Within to be a gory game or get scares only through bloody scenes. While there's certainly some blood in the game, this is presented in the context of the story about the horrible events that occurred in the asylum's past. We avoided gratuitous bloodshed since we felt that atmosphere and suggestion would create a creepier environment than buckets of blood. Our own vision for scary horror is less “Saw” and more “Silence of the Lambs"; less physical gore, and more psychological terror.
Our approach was to use the power of suggestion through using the environment through found documents, graffiti, or objects left in the world. We wanted the player to be an active participant in the story, piecing together their idea of the story based upon what they were told, what they saw, and what was suggested.
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.
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:
Does it fit with the core theme of the game? While there's occasionally a brilliant idea from left-field that completely changes how you think about a game when designing it, those ideas are rare. In general, if it doesn't fit, it should be rejected.
Does it impact content creation (requiring new levels, animations, new gameplay mechanisms) to convey? We don’t automatically avoid content changes, but they should be carefully measured against what they contribute to the overall game. Sometimes, you can find an elegant solution that doesn’t require new content.
Is it a change that will make the game better, or advance it in some form? If not, or if it's a lateral change that is simply different for the sake of being different, it should likely be rejected.
Finally, there's a gut instinct to this type of task, and a good designer needs to create a strong personal filter. Does your gut tell you the idea works and should be incorporated?
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:
Under stress, it's hard to be precise with your taps. Maybe players were trying to tap on a locker, but missing it which resulted in the player character walking near the locker but not hiding within it.
Repeated taps were causing a new action to override a previous action. The player would successfully tap to run through a door but then keep tapping, which negated the previous input.
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
You May Also Like
