Gamasutra: The Art & Business of Making Gamesspacer
Postmortem: The Chinese Room's Amnesia: A Machine for Pigs
View All     RSS
October 21, 2014
arrowPress Releases
October 21, 2014
PR Newswire
View All





If you enjoy reading this site, you might also want to check out these UBM Tech sites:


 
Postmortem: The Chinese Room's Amnesia: A Machine for Pigs

May 23, 2014 Article Start Previous Page 4 of 7 Next
 

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.


Article Start Previous Page 4 of 7 Next

Related Jobs

Filament Games LLC
Filament Games LLC — Madison, Wisconsin, United States
[10.20.14]

Quality Assurance Associate
InnoGames GmbH
InnoGames GmbH — Hamburg, Germany
[10.20.14]

Team Lead Online Marketing - TV (m/f)
Yoh
Yoh — Vancouver, British Columbia, Canada
[10.17.14]

Build & Test Engineer
Nix Hydra
Nix Hydra — Los Angeles, California, United States
[10.16.14]

Programmer






Comments


Dane MacMahon
profile image
I think with sequels you always have to keep in mind the perception of loss and change. Removing things like the sanity meter might make perfect sense for the game you wanted to make, but the consumer, the existing fan, will always feel like he lost something. They will ignore improvements and new gameplay paradigms if they think they were swindled out of something they had in the series previously.

Deus Ex: Invisible War was a decent game with decent review scores but it will always be known as the "horrible sequel to Deus Ex." Sequels are funny things. Taking on a sequel with the intent of changing a lot of what it was and removing features seems like asking for consumer anger.

Arthur Khvorostyanyy
profile image
It is not the problem of sequel. You destroyed the core gameplay and didn't offer any other. If the game would be released without name Amnesia it anyway would be bad game.

James Margaris
profile image
"The issues with the game's difficulty were compounded by the game's design too clearly telegraphing transitions between "enemy" areas and "non-enemy" areas."

Breaking down games into separate pillars that rarely overlap is a huge problem in modern game design. It's extremely common for games to have traversal, combat and puzzle sections that remain fairly distinct throughout the whole game, whereas in old games these things all happen at the same time using common verbs.

Tobias Horak
profile image
"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."

A noble goal, however I fear that this shows a misunderstanding of why the sanity mechanic was useful. The sanity mechanic, above all else, generated fear through uncertainty. It forced players to look away, and only catch glimpses of the horrors in the game.

Replacing the original game's mechanic makes sense; a large portion of it was a direct extension of the character's fear of the dark. Doing so by adding some other resource to manage is to miss half of what made sanity so compelling. As the goal is likely to retain the same aesthetic, due to player expectations from a sequel, one should be looking for mechanics that can fulfill the core dynamics*. The original amnesia forced two dynamics onto the player in particular: the struggle of staying in the light for sanity retention (with the drawback of being more easily discovered), and disallowing the player to confront danger.

I feel AAMFP would have had much more success had it incorporated an ever-present something for the players to balance. Something to give the feeling of "I really shouldn't be doing this" that we all had playing the original.

My two cents on the "controversial" topic! ^^

*Paper about mechanics, dynamics and aesthetics: http://www.cs.northwestern.edu/~hunicke/MDA.pdf

Kevin Fishburne
profile image
It seems based on the comments here that the fans have a much better understanding of what made the original successful than the developers. If that's generally true, it's something we developers should keep at the forefront when developing a sequel. Perhaps something like exit polls would be useful.

Dane MacMahon
profile image
Browsing fan forums is a good way to distill exactly what made a game loved by it's biggest fans. If you're making an RPG sequel for example and aren't reading what the people at RPG Watch, RPG Codex and similar sites wrote about your first game you probably should be.

Alex Van de Weyer
profile image
There's no doubt fans "think" they have a better understanding. Whether they do or not, or how much they should be pandered to, is a much more complicated subject I think. At one extreme, just delivering what fans think they want is both impossible, and potentially damaging to innovation and artistic intentions.

Dan Felder
profile image
If game design was so easy that a game's fans can normally tell you exactly why a game is successful, to the point that they have a better understanding than the developers, then life would definitely be a lot easier.

I'm all for browsing fan forums, it's great feedback and utterly invaluable, but they're not experienced designers or developers. Their reactions are great to get, but their suggested solutions aren't quite as useful.

Dane MacMahon
profile image
No one said to take fan reaction and plug it right into the code. If you're not listening to them though, I think you're making a mistake. A lot of developers think they know way better what people actually want and then watch their sequels plummet in public opinion.

Scott Lavigne
profile image
You'd have to have something built into whatever distribution platform you're using (which is a big middle finger to DRM-free games, I guess) since most games end up never being finished. I imagine there are plenty of people who enjoy (and would buy the sequel to) many games but do not finish them. Of course, some games can't be finished either, so there's that.

Dan Felder
profile image
It seems my extended comment clarifying things, as well as many other peoples' comments, has been deleted. I don't feel the urge to write another.

David Konkol
profile image
So wait a minute.

At first you talk about one of the great things was the amount of freedom FG gave you, then later in the article, you talk about one of the cons was FG stepping on your creative freedom.

So which is it?

Anthony Stewart
profile image
This article was great!


none
 
Comment: