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:
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.
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:
No tags.
