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.
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.
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.