Post Mortem

The goals Trust in Me was thought to achieve were quite high. It is therefore no wonder that in the end, it failed rather remarkably.

Nevertheless, the lessons it provided were valuable on their own.

Technology

Game Design is a tricky thing. Although it completely depends on technology, it is that very technology that vanishes in the completed product.

Clearly, it might be true that I have written a complete backend to retrieve strings and audio files from an XML file in order to provide an easy way to make a game multilingual. This took me easily a week until everything worked and all methods have been properly overloaded. For the enduser, however, this all does not matter: he sees the same strings and hears the same audio files if I just hardcoded them into the scripts. As a matter of fact, at the exhibition, it had not been me who was able to present a completely bilingual game, but another student, who made it all without the fuss and simple if-causes ...

But then again, it is also true that this same system also enabled me to translate the whole game into English in approximately less than three hours (most of which were used to actually translate the strings) – and allowed me to send the XML to a friend of mine for proofreading and then simply dropping her corrected file back into the directory, without the need for a lengthy copy-and-paste orgy. So yes, it may be invisible to the player – but it also might pay off later on. But you must have the time to make it.

The same goes with my tracking system: although completely invisible to the player, it did allow me in the end to analyse how the visitors played my game and correct some details of my level design for the IGF submission. Yet again, it to way too long to implement. And yet again, I learned a lot about dealing with XML in Unity and C# in the process, so the time was not lost at all; in fact at the start of the next semester I was able to cobble together a system to write save data into an XML file and reading it out again in practically no time¹.

So, while I spent most of my time on rather minor aspects of the code – mostly aspects that do not affect the player at all, I suddenly had no time to spend on one of the most important parts: level design.

Level Design

If the game's main target was to get people to explore the level on their own, it failed to do so mostly because there was no incentive to do so: the level was simply not big enough to be explored, and it featured no special treat for those who ventured out.

Even so, I would stand by my choice of sketching out the level with post-it notes on brown paper in order to rapidly change it. But yes, I should have enough time to actually produce it and test it out thoroughly – something, which was clearly lacking in this case. Of course, failures in the level design are the ones that are the most visible to the player. Therefore, they have the most influence on the reception of the game.

Reception

Considering just the reception of the game, it must be considered a failure, since it failed to connect with any of the possible target group at the exhibition.

The visitors without any game literacy would try to play it, but they would fail to understand the tropes that were used: the guiding voice, the side-scroller as a genre, the bonus items placed in order to lead the player through the level. Obviously, without that background knowledge, they would miss the point.

They would miss it, as a matter of fact, as the visitors with the necessary game literacy. While those players might understand all those concepts and their implications, their conclusion would usually be: this game does not work, it is broken. Some people even refused to play the game at all based on the knowledge that they would not be able to win: why would you want to play a game when you know you cannot win it?

As such, it is doubtful that the game met its goal of changing the players' perception on railroading in games and their attitude towards repurposing games for their own enjoyment, apart from the ideas of a game designer.

Maybe such a shift in perspective is not even necessary. After all, many of the most successful games are successful exactly because they allow players to turn them into their own playgrounds with their own rules.