Introduction

This is a dev-log of the construction of the game, and it contains spoilers, please go and play the game if you did not yet : https://solroo.itch.io/mgj18-qa

If you are still reading, we are guessing that either you played the game, or you don’t care, so here it is:

QA is a game about finding bugs in a horror game, reporting them, and waiting for the updates to be able to move forward.
This takes the shape of an alternation between in-ingame levels and email communication with your colleagues.
There are some twists, too.

We were planning to do a post-mortem, but it is easier to just tell the story from beginning to the current state. 

Week before: what we wanted to do, and why the game is not that

(we started with a completely different gameplay idea, but it still helped narrative wise... you should skip to Week 2, friday if you are not interested in this)

The end result is far away from our original idea, as we originally wanted to do an Interactive Fiction game (read more here : http://brasslantern.org). We had several ideas to make it meta, all of them revolving around the notion of giving the player the responsibilities of the interpreter. For instance, we could do that by giving them a rule-book or a view from the in-ingame world that had to be described to the “player”. The first concept was an inverse “chinese room”, perhaps taking the shape of chatroom... we had many nice ideas, all impossible to implement. These first game ideas were also related to one of PAC's video game experience: following walkthrough while playing certain games (mostly RPG).

We decided against these (because it was crazy to think we could implement any of them in 2 weeks) and scaled down to Interactive Fiction with a visual layer. For the theme we went for a classic horror game (evil dead / resident evil), taking inspiration from graphic adventures and their real time successors (such as alone in the dark).

The first step was then to get familiarized with the Interactive Fiction mechanics (IF for short), a very interesting topic indeed. To test stuff, Sol built an IF parser in Unity3D: there are even official tutorials how to do it. Actually, Sol spent more time on the visual debug mode than in the interpreter. This was the week before the Gamejam, we don’t think this count as cheating as we threw all this code away.

The interactive fiction engine, and a debug mode showing the locations, objects and states.

We needed to build a 3D world, so we played around with MagicaVoxel (strongly recommended). The results were better than expected, and we could have scenes and assets in less than 30 min. The main issue was that the exported models looked bad in Unity3D. So, we added toon-shading and post-processing. Being the first time we used Post-processing, we went a little overboard... for instance, the game still looks blurry in some parts.

 
So, you were at your office interacting with Interactive fiction (left). The image at the right shows a bad Photoshop we did to test the "imagination concept". We don't own the cave image, it was a temp image taken from google (please don't sue us).

Week 1 (Mon-Wed): Debugging as a feature

The aesthetics of the office were nice, but having the computer screen at all times was taking too much space, so we had to drop that. So, we moved the character directly into the scene.

A paint draft of the first person version of the game (left), and its implementation (right). for the ones that played the game, this is the first time the game looked anything like the final version.

We were not really happy with the visual appearance, but since it looked cheap, we thought "maybe it is early access!". Interactive Fiction is very much like programming, so why not debugging the game while you play it? 

We decided to base the game mechanics on the notion of “bad coding”, with missing game elements that the player had to debug in order to be able to move forward. We wanted to leave code comments to guide the player towards the right answer (much like good IF and the in-world hints). That was interesting: fix the game to continue playing.

To improve the look and feel, we added two post-processing effects (both borrowed from Keijiro):  ASCII shader (because of IF), and glitchs (because of broken game).

 

The glitchy version of the game (left), and a draft on how to add debug information (right)

At this point, and following our new ideas, we found that the layout was extremely cluttered with the terminal text, so we moved it into the environment, as contextual information (e.g. replacing the narrator with a placeholder icon for voice-over). 

   
The narration moved from the terminal to contextual text (left), the inspect option became floating text too (right)

Week 1 (Wed-Fri): polishing something, then throwing it away

Even when the debugging concept was interesting, there were 2 key issues: it is hard to create good IF puzzles in a rush, and most people are not used to play these games (that require quite a lot of know-how), and they won’t be able to solve these puzzles.

We really wanted to make the game as little externally documented as possible. So, we replaced IF syntax with object oriented syntax (e.g., open door with key became door.open(key) ). This was fairly simple to implement, and allowed us to have an excuse to show information in screen (using a debug mode).

There was only a little problem: the game was not fun to play… we were afraid players would get frustrated and stop playing... one week into development (plus another week of conceptualization) had to be discarded, we had to kill the baby.

Continuing in part 2: https://solroo.itch.io/mgj18-qa/devlog/30233/quality-assurance-a-pseudo-post-mor...