Amnesia: A Machine for Pigs was born out of an ethos shared by Swedish indie & Amnesia franchise creator Frictional Games (FG) and British independent developer The Chinese Room (TCR) towards game design and what games as a medium are capable of doing. This focuses on the creation of games that prioritize immersion, emotion, and the affective experience of the player, combined with a powerful, thought provoking and well-told story.
The game [YouTube trailer] was originally pitched as a short two-to-three hour experience entitled We are the Pig, although this initial design went through numerous changes and expansions during its development. This led to the development time extending from the initially intended 12 months up to 24 months. While the game length increased beyond the original design, some sections still unfortunately did not make their way into the final release such as the Boiler and Fattening levels.
TCR came to this development with prior experience developing games such as Korsakovia and Dear Esther that provided a number of lessons to inform the development of Pigs. FG of course had experience from their previous successful horror titles. This project was however the first time that either company had collaborated with another company on a project and this would have very noticeable consequences throughout the development process.
Pigs has released to predominantly strong critical praise, but has clearly proven to be a divisive title amongst players. The game has demonstrated success in a number of areas, however the game and the development process itself were not without their problems. In discussing both the game's successes along with these problems, this postmortem aims to provide a comprehensive overview of what was an enjoyable if sometimes arduous development.
Concept artwork for the cut Boiler level.
What Went Right
1. Creative Freedom
FG took a very hands-off approach during early development, allowing a high degree of creative freedom amongst the TCR team. FG must be commended for their willingness and openness towards experimentation with an established intellectual property such as Amnesia. Such experimentation with established formulas is something that arguably should be encouraged more across the industry in order to keep pushing at the boundaries of the established design spaces that we currently operate within.
This invitation to experiment meant that in terms of both gameplay and story, time was spent during early development throwing around a lot of different ideas for plot, puzzle scenarios, game mechanisms, enemy designs and enemy encounter scenarios. These ideas ranged from small adjustments to the established Amnesia formula through to more radical and complete departures from it. Some of the ideas that came out of this process had potential for very interesting gameplay, such as enemies that would only appear clearly in the peripheral vision of the player, and a procedurally generated three-dimensional electrified maze, similar to Vincenzo Natali's film Cube.
Early concept artwork attempting to define the appearance of different pig creatures.
While technical limitations of the HPL2 engine prevented the inclusion of the more complex ideas, a number of less technically demanding ones, encouraged by this creative freedom, did make their way into the final game. The intention from the outset was to develop a game that players could not play simply by relying on their experience with Amnesia: The Dark Descent. This was critical in giving players a new experience, and the freedom to experiment provided a catalyst for creating such an experience. The last thing TCR wanted to do was give players "just more of the same" gameplay established in FG's previous titles. While certainly some players would have been happy with this, it was not what TCR wanted to make, and furthermore was not what FG wanted TCR to make. The aim was to bring a fresh approach to the established Amnesia gameplay.
Of course in following a critical success such as The Dark Descent, it would be both naive and a severe disservice to the established fan base to not consider how a sequel may draw on the most successful elements of the original. Ripping out the heart of what makes Amnesia, Amnesia, was not the aim; it was more about structuring a new, but horrific body around an established skeleton. This also applies to linking the game to the overarching franchise mythos. Again, FG did not require there to be any notable link between the games in terms of narrative, but TCR felt that a complete departure from the mythos would risk alienating many of the established Amnesia fans. Indeed, early media releases that prompted a deluge of theories around the game's plot and characters demonstrated the level of investment the fan base had in the established lore, with forum threads spanning over 500 separate pages analyzing the minutiae of the released material on the game.
The response of the community to these early media releases was instrumental in fueling further creativity during the game's development, as a number of forum posts discussed ideas or different plot interpretations that had not been considered. While of course not all of those posts formed the basis of something that made it into the final released game, a small selection was worked into the fabric of the established game and plot where appropriate. Hopefully, some players may recognize small features within the game that they had previously postulated about!
As for the game's mechanical core, the removal of the sanity meter was a primary aim from the outset. TCR recognized the likely controversy of this, but felt that the system was fundamentally flawed as a means of telling the player they should now be scared, and approximately "how much" they should be scared. The aim was to create a game that was inherently horrifying, and thus did not require a meter or gauge to tell the player to be scared. However, throughout a long period of the game's development (approximately the first 6-7 months), and as per the game's original design document, the sanity system was to be replaced by an "Infection" system.
Early version of the infection system demonstrating visual overlays and minor perspective distortion (May 2012 Build).
The infection system would serve some of the same purposes of the sanity system, providing visual and auditory distortions and hallucinations as the infection level increased. This would escalate to Mandus having to stop, retch and/or vomit as the player moved through the game environments. Enemies attacked the player through infectious damage rather than the physical damage that is present in the final game, and players were able to heal themselves through the use of the decontamination chambers in the game. However, this system would be more abstracted than the sanity system, removing the requirement for a gauge-based representation to track "infection level." Instead the player would be able to approximate the level of infection through the visual and auditory cues provided during gameplay. The linking of this mechanic to the attacks of the enemy agents and to the lack of cleanliness in the Victorian London setting was intended to blend the mechanical workings of the game to the setting and plot in a more integrated way.
As development continued however it was clear that the system simply was not integrating well into the rest of the game, and felt too much like a "mechanic" for the sake of being a "mechanic." The infection-based attacks from enemies for example, felt weak and unthreatening at best and downright confusing at worst. Similarly, environmental infection events, however they were framed, could not shake the feeling of players walking through luminous green toxic waste in any number of classic shooters. After many attempts at integrating the system more convincingly into the game, the decision was taken to remove it. This removal, while certainly not trivial, allowed much more focus to be paid to the core essence of the game -- the story, and the environments through which it is told.
The removal of the sanity system was an important aspect of producing the game that TCR wanted to produce, and has been predominantly successful in doing so, as reflected in the writing of a number of critics that have praised its absence. While it may have been possible to continue with the infection system and build it into the game in a manner that felt more integrated, the decision to remove it allowed more attention to be given to other aspects of the game. The result is a game that is almost certainly more cohesive across its story, world and gameplay and thus is stronger as a whole. Without the level of trust and freedom provided by FG a change as critical as removing one of the core systems would have likely caused more serious concerns and delays in the development, especially as the system was such a key component of the originally pitched game.
2. Development Tools
The HPL2 engine is certainly not without its quirks, and a long time was spent during early development working out appropriate asset pipelines and the most efficient ways of implementing different features. However despite this once the tools were fully understood by the team, it was clear that their combination was capable of creating excellent products.
For a small development team particularly, it was important that everyone should be able to make use of the most critical tools, such as the level editor and be able to understand and make changes where necessary within the level scripts. The level editor provided this functionality, and with some bespoke adjustments made by TCR's programmer it was possible to customize the editor to TCR's preferred methods of working. The accessibility of the source code for the toolset meant such changes could be completed with little or no assistance from FG, which meant minimal delays during development for tool-based problems.
Similarly, the accessibility of the AngelScript-based API used for writing the game's level scripts meant that basic events could be implemented or adjusted by multiple team members rather than relying solely on the scripter. Early in development, a number of portable sections of script were produced, fully commented, that could be dropped in to any level and then adjusted as necessary by relevant team members. This was particularly useful as a means of enabling the sound team to work independently with portable scripts for systems such as randomized environmental sounds, ambient soundtrack switching and music integration.
HPL2 also already contained a number of useful debugging tools. While not being comparable to more established game engines for obvious reasons, the included features were targeted specifically at the rapid creation and testing of Amnesia style gameplay and worked very well. Once more TCR were able to implement their own additional debugging features, such as in-game dynamic prop placement to speed up the process of placing small objects accurately in the environment by doing so during run-time, as well as the ability to view the separated contents of the G-Buffer used during the process of color grading the game. The flexibility of the tools and debugging options provided a solid foundation upon which to develop the game.
3. Development Team and Communication
The core development team's ability to work well together with minimal man-management required was one of the most obvious successes of the development, and without doubt influenced the quality and cohesiveness of the final product. Multiple members of the team had previously worked together on past projects such as the Half-Life 2 mod Off Limits, which meant there was an established rapport between them. It was then very simple for the more junior staff to find their own suitable fit within the team.
Viewing G-Buffer contents in-game (Diffuse Colour, Z-Buffer and Surface Normal).
The combination of experienced staff and fresh graduate staff provided a catalyst to a number of useful if sometimes rather heated debates about the best way of implementing a particular feature, of lighting a particular area or of scripting a particular enemy encounter. Those with more industry experience of course had more existing knowledge that they could draw upon, but the lesser experienced of the team were often able to bring different ideas to the table as well. Ultimately the combination proved highly productive, even if in some circumstances these discussions took a little longer than needed.
These discussions could not have been achieved however without ensuring communication between the team was simple, reliable and fast. Throughout development, the entire team was working remotely with staff working from the UK in Portsmouth, Brighton, London, and Winchester, along with others in Belgium and FG based in Sweden. Communication was carried out primarily through Skype, with email used when paper trails were necessary. The majority of communication occurred in this Skype "virtual office" however and it proved successful. Such a setup has evident drawbacks over a normal co-located office setup, such as not being able to simply turn to a colleague's screen and explain something, instead having to draw elaborate diagrams (often in Paint) to try and explain the functionality of a particular puzzle or the sequence of events in an area. However, given the limitations the team had to work with, the communication methods were fit for purpose and served the development of the game well -- as well as generating a number of excellent pieces of programmer-art and stick-man diagrams to boot.
Lastly in this section it is necessary to mention the team's passion, and the belief in the story TCR were trying to tell. Such a statement may seem somewhat cliché, but that passion is a critical component in crafting a game that feels "complete." This passion especially applies to the political element of the story, which was a point of particular interest for the team. Having a singular vision for a game is important regardless of what game is being discussed, but for a game that rests on its ability to strike emotional as well as horrific chords with players, it is even more critical. That singular vision needs to include not only what must be happening on screen or being heard by the player at any given point, but also the emotional state the game is trying to instill in the player at any given point as well. Even with multiple staff changes during development on the art team and the sound team, that singular vision remained consistent. This again is testament to the excellent team rapport and communication, as new staff joining mid way through development were soon briefed and integrated into the team.
4. Environmental Storytelling
TCR's previous games make use of voiced narration and internal monologue as means of telling the player a story. Environment design has been important in these past titles to ensure the story is placed in rich, believable and cohesive worlds that provide context and a sense of place for the player. Storytelling through the environment itself can be seen in Dear Esther, and in Pigs the aim was to bring such environmental storytelling to the fore to a greater extent.
In a horror context, telling a story through the game world itself provides the potential for both greater poignancy as well as greater ambiguity. The poignancy is critical in creating an affective, emotional experience for the player. The game environment has far greater potential for this than a spoken or written dialogue describing that environment. For example, a single picture of the shoe room at Auschwitz, or of the lone protester facing up to a tank at Tiananmen, are far more arresting, far more powerful images than anything that could be described through words alone.
The poignancy of such environmental storytelling is important. However ambiguity is also a key part of this type of storytelling. Even the above examples offer levels of ambiguity despite seemingly portraying quite obvious events. Each pair of shoes at Auschwitz has an implied life story attached to them for example. The picture of the Tiananmen protestor poses questions regarding his thoughts and emotions at the time the picture was taken. It is these associated implications that assist in the creation of the emotionally affective aspects of a story. The image, or environment, is simply a cue to thought and to consideration, rather than an explicit, closed story. Makoto Shibata, director of the Project Zero (Fatal Frame) series discussed such an approach in an interview with The Guardian stating that it is not about simply showing scary things, but providing players with fragmented information through a variety of means that forces them to consider for themselves the horrific events of the game. Ultimately, that which occurs in the player's head will almost always form itself into something more disturbing and more horrific than anything the game could explicitly portray.
Sequences such as the Pig Nest in the Sewer level allow storytelling through the environment and characters alone, without revealing lots of explicit detail.
The script for Pigs was nevertheless initially very long and included a substantial amount of voiced internal monologue. It quickly became apparent that the amount of voiced storytelling was going to have to be reduced to prevent players listening to voiceovers for long periods. TCR had also initially underestimated the size of environments that would be necessary to allow such an amount of voiced storytelling to comfortably fit while still allowing the player to move around freely. While small sections of the voiced script were cut, much of it ended up being moved across to written notes that are found throughout the game, thus the overall script itself is largely unchanged from the original version in terms of its content.
These written notes however are intended to support the story suggested by the game world through the design and contents of the different environments that the player travels through. For example, the hidden corridors and rooms in the game's early levels are not explicitly explained by the game, although the script may allude to them at points. The player is left to determine their own interpretation of what they were used for. This same approach applies throughout the game, and it is rewarding to see many different interpretations of the game's overarching narrative, as well as specific objects or characters, appearing across discussion boards online. This individual interpretation was also the reasoning behind the removal of voice acting for the written notes. With a voice actor, it is much harder to leave ambiguity intact as emphasis and intonation will always suggest a "correct" interpretation. Suggesting such definitive interpretations of plot elements would have unraveled the image that the game builds up of Mandus' questionable mental state.
The ambiguity of the storytelling itself has achieved its aim of encouraging thought and extended discussion amongst players. In many cases TCR have achieved some powerful and emotional responses as well. The game's use of music and sound was pivotal in creating these emotional responses and has been cited in a number of critical and player reviews as one of the game's strongest components. Its quality is testament to the tireless work and attention to detail of the small audio team working on the game.
5. Streamlining Gameplay Experience
As previously mentioned, Pigs has clearly proven to be a divisive game amongst players. For many, the streamlining of the gameplay itself may well be more suited to the "What Went Wrong" section. However, for delivering the type of experience that TCR were aiming to deliver, streamlining the gameplay itself was important, and from this perspective the decisions made to achieve such streamlined gameplay were predominantly successful. The removal of the sanity system, and later the infection system, has already been discussed, as has the shift of voiced narrative to text-based narrative. However further mechanical alterations contributed to the streamlining of Pigs' gameplay.
A sprint limiter was implemented for a while during development, intended to emphasize Mandus' age and level of fitness as well as making enemy encounters more dangerous by reducing the player's ability to run long distances if spotted. This was removed later on to provide a more consistent experience for players, as the limiter was more of an unnecessary annoyance than it was an interesting tactical addition in the parts of the game that did not contain enemies. This was especially noticeable in the game's larger environments where artificially limiting the player's movement speed provided no experiential benefit.
The most obvious streamlining decision, and again a decision that TCR recognized would likely be controversial was the removal of the inventory. A number of possibilities were considered regarding the inventory with the overarching aim being to keep the player within active gameplay at all times. Breaking out of active gameplay into a separate, static inventory screen not only breaks game flow, it more critically damages the building of tension, suspense and anxiety that is so vital in horror.
Games such as Dead Space and System Shock 2 successfully integrate inventory systems in ways that keep players within active gameplay as much as possible. Dead Space makes the inventory screen part of the diegetic game environment while System Shock 2 allows the player to decide how much of the inventory screen to view, while keeping the game running in the background and leaving the player open to attack. For Pigs TCR discussed inventory solutions such as a quick access item bar on the bottom of the screen (similar to Neverwinter Nights' Quick Bar) that would appear on a key press, and a minimalist inventory that would only be available to carry and use a small selection of important items, such as keys. However, in line with the aim to keep players engaged in the game world as much as possible during gameplay, there were only a small number of scenarios in which these inventory solutions would really be necessary. Most of the planned scenarios were designed to allow the physical movement of objects through picking up and carrying items around the game environments.
With this in mind, the complete removal of the inventory was decided to be the best solution, as the inclusion of one that would then only be used in a handful of situations in the game seemed unnecessary. This streamlined the gameplay during puzzle scenarios, removing the need to move between screens, and making it possible to implement a range of different, in-game scenarios for players to interact with and solve. The streamlining of gameplay in this way achieved its purpose – however, these in-game puzzle scenarios failed to reach the potential that the game's industrial, mechanical setting provided.
What Went Wrong
1. Rapid Prototyping and Project Scheduling
The game's puzzle scenario design and indeed all of the main issues that are discussed in this part of the postmortem stem from poor project scheduling and a mishandled prototyping phase of the project.
While FG provided TCR with a high degree of creative freedom in terms of the game's content and design direction, the deliverable milestones requested were much less flexible. The first deliverable FG requested was a near-complete version of the game's Cellar level (the third level in the final game), which would demonstrate all of the major components of the game, such as puzzle design, enemy encounters, art direction, the infection system and narrative delivery.
Meeting this first milestone prevented TCR from grey-boxing the full game at this critical early stage. Moreover, because the entire game had not been grey-boxed and considered as one complete entity, the version of Cellar that was created for this first deliverable was eventually changed into an almost entirely different level, thus rendering much of the time and effort spent on the first version wasted.
Whether the decision to request a completed level rather than a complete grey-boxed version of the game as the first milestone stems from FG's lack of prior experience acting in a production role is difficult to say. However, it is likely that having a full grey-boxed version of the game early on in development would have made later decisions much simpler and quicker to make, as well as giving TCR a much better idea of the pacing of the game from start to finish. Critically, this complete version of the full game would have allowed much easier mapping of key events, such as enemy encounters, rather than attempting to implement such events while levels were in the process of being fully built, or worse, after they had been built.
The lack of a full grey-boxing process, and thus no rapid prototyping of the game's core systems meant that even 6 to 7 months into development, the mechanics of the game (such as the infection system) had not been signed off, nor were they in a state to be signed off. While the game's narrative and environments were predominantly confirmed at this stage, the mechanical core of the game suffered severely from mistakes in the early stages of development. This noticeably followed through to the final released game, which is much weaker mechanically than it is in terms of aesthetics and narrative. Lastly, a full grey-box of the entire game would have highlighted very early on the issues that were encountered later regarding frame rate drops linked to the number of physics objects being used in a level. This would have allowed design work to be carried out with this limitation in mind from the start, avoiding the need to implement the workaround of making a high number of previously interactive objects static -- something that been criticized in a high number of critical and player reviews.
While FG's milestone requests were detrimental, the development also suffered from TCR's lack of detailed project schedule. While the team were fully aware of the major tasks that needed completing at any given time, and were adept at prioritizing appropriately, there was no central documentation that kept track of tasks, internal milestones or game bugs. This led to a lot of additional communication being required in order to discuss tasks that needed completing, as well as some less critical tasks consistently being overlooked. The lack of a centralized bug database meant that the final testing phase before release needed more time as there was no record of outstanding bugs or of those previously identified and fixed.
This combination of no real prototyping phase of development and lack of detailed schedule and documentation can be pointed to as one of the root causes of many of the other smaller problems throughout development.
2. Collaborative Working and Compromising the Creative Vision
There was a level of naivety on both sides of the collaboration between TCR and FG, as neither company had worked in such a collaborative scenario previously. While the creative freedom provided was welcomed, the hands-off approach taken by FG may also have caused some of the apparent misunderstandings and contradictory feedback that TCR received on deliverables. Many areas of the game were reworked two, three, or even more times based on different and often conflicting feedback on deliverables. Some of these reworked areas are much stronger because of this back and forth between TCR and FG, however in some situations it is evident that TCR should have been firmer when defending their initial design decisions.
One of the notable decisions impacted was removing the game's equivalent of The Dark Descent's mementos -- hints located in the journal that assist players in completing tasks. The initial design of Pigs removed these entirely, requiring players to rely on the game environments and diegetic information within them to solve the game's various challenges. TCR felt this made the game more cognitively challenging (something that had been raised in multiple threads on The Dark Descent's discussion forum as a desired consideration in future games), and more rewarding for players. FG were not responsive to this however and thus the final release of Pigs includes frequent additions to the journal of these hints. The differing opinions of TCR and FG on the ability of the player were clearly apparent in this instance, and TCR should in retrospect have been stronger in defending the initial decision to remove the hints.
The lack of consistent communication between TCR and FG also meant that when TCR handed over the final build to FG for the final phase of testing, optimization, and polish before the game's release, some fixes for critical issues were removed and thus didn't make the initial release version. For example, the color grading process carried out by the TCR art team had drastically changed the look and feel of the game's lighting. However, as discovered later, the calibration on the monitor used during the color grading process was corrupted and thus the version initially sent to FG was graphically compromised -- the blue "fog" that was noted by a number of players in the initial days following release. TCR implemented fixes for this mistake resulting in the color grading being as intended.
Side-by-side comparison of fixed color grading and the release color grading.
However, because these changes were not well communicated between the two companies, changes made by FG during the final stages of development resulted in these fixes being reverted and the game shipping with a visual "Class A" bug. The results compared to a fixed build are readily apparent when placed sid