Postmortem: The Chinese Room's Amnesia: A Machine for Pigs
May 23, 2014 Page 4 of 7
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.
Page 4 of 7