Unnecessarily Long Background Story About Making This Game So Far
How we started
In the early autumn of 2013, my friend and I decided to apply for the upcoming 2-month artist residency “Multimadeira” on the island of Madeira (Portugal), our project being point and click adventure game that we would (with the third friend working from Serbia) hopefully develop to the stage of playable pre-alpha demo in five weeks.
None of us have made any video games before, but we were proficient in all the separate skills needed to do this - or at least we thought we were. Ivan (the programmer) was experimenting with Python for some time and wanted to make the engine from scratch. We somehow convinced Jelena (the artist) to work with us from cold and and windy Belgrade (our hometown) while we swim in the ocean and sunbathe on this beautiful island (it was December, but the climate there is just amazing). We made the main concept together, and the rest fell to me - I had some previous experience with doing animations, and I have been making music all my life so it was only logical that I should do those.
Screenshot from the game back in those days
But it was the decision to let
me work on the puzzles, story, characters and world that led this project in the current direction… and I still can’t say for sure if it’s the best or the worst thing that could have happened to this game. One of the first advises you get (or should get) when you start working on your first game is to start by making small and simple games, and we knew that it was a good advice from the very beginning. So we decided to have a simple story of a nerd mechanic trying to repair a minor bug/damage in a huge machine (essential for the survival of the whole city) only to discover that repairing it somehow made another bug appear elsewhere, and repairing that one made the third one appear etc. The story would end
in his realization that the machine is imperfect by its nature, and the only right course of action (him being kind of asocial perfectionist) is of course to destroy the machine - which leaves the city without all the essential resources and as a result basically sentences all the people to die - including the mechanic himself. (This was only kind-of spoiler and it happens / is true only for some of the possible paths and endings in our current game, but I marked it anyway)
Messing with playing order of the chapters
This way, the story would end with an “apocalypse” (so it was not post-apocalyptic but pre-apocalyptic back then
). Soon we got the idea that it would be a cool narrative technique to play the ending
(destruction of the machine) first, and then advance backward through time. The player would start the game with this important event, but without knowing the reasons for it, and then gradually (until the end of the gameplay) uncover this chain of events, until he at last realizes it is more of a Kafkian story than an epic one.
We weren’t too happy with anti-climatic (gameplay) ending though, so the next step was to prolong the story
after the “apocalypse” (X symbol in the picture) and shuffle the playing order like this:
We would start in media res, and then alternate between going back (to explain the reasons for the apocalypse) and forward through time (to advance the story further). Later we abandoned the apocalypse as starting point completely (eventually, part of the story originally intended for the main character was given to an important NPC instead, and moved back to the past) - but this was one of the most important points in the structural development of our gameplay.
Branching of the story
It was still supposed to be a simple game though - a short poetic story with clever puzzles and the ending that people would think about and call it stupid or clever or interesting or whatever. Ivan and I both had ideas what does it mean, we talked a lot about it and why it’s the only ending that really make sense (and we both have MA in Philosophy so...yeah). Until one day it was not the only ending anymore. First we decided that the player should be able to choose if he will
destroy it or not. But
obviously, one of those choices would be
wrong. But then again, we didn’t want to have those “YOU WIN” and “YOU LOSE” ending screens, so it would stay up to the player to decide if it was the right decision. Then we decided it should be cool to have more than two endings, and also some of them should be “locked” depending on the other decisions made during the gameplay.... and while at it, why only change the endings? There should be different quests with different prerequisites, and player should frequently be in a position to advance the game in more than one way. Sort of like those “choose your adventure” books, but with a
very important twist of retro-causality (explained in the OP). Of course, the player is not explicitly asked to make the choice as in those books (and he’s usually not even aware that he is making one) but is doing so by solving some puzzle this instead of that way, or solving this puzzle instead of that puzzle, or even choosing this instead of that dialog option.
Expanding the world
Now, I am a retired table-talk RPG game master, fond of making my own systems and settings, and writing HUGE documents about the world and everything in it. I am also a fan of George R.R. Martin and his unbelievably complex system of seemingly unrelated stories that somehow come together and do (or will, I hope) make sense at the end. With the endless possibility that non-linear story and retro-causality gave me, I was FREE (bwahaha) to make this world huge and rich in details, and to strategically place little side-quests/stories in it so that they would not reveal the whole truth to the player unless he has played the game a few times and took different paths - but they would still give the player much needed flavour of the world surrounding the story even if he only played the game once. The idea of having this meta-knowledge only attainable by playing the game more than once (or reading about / watching others do it) intrigued me - it’s a state possible for you as a
player, but never for the
character you are playing. I realized that by using retro-causality we can do this without the player replaying the game: When you play chronologically earlier chapter
after you play chronologically later chapter, you as a player have some direct knowledge about the future of your character (and the world), and he does not, so if
your (player’s) decisions in his name are based on this knowledge then
his (character’s) actions could be seen as irrational in-world (because the character had no knowledge which would explain why he did what he did). This opened some very interesting possibilities for our story, namely
adding a possibility of real prophetic/mystic element - giving player the opportunity to act (or not!) as an invisible fate in some situations, and lead the character to make some decisions without him knowing exactly why at the time. But revealing those in more detail would be not just too spoilerish right now but also hard to explain without telling the whole story in detail.
Sane decisions
After Multimadeira, where we had successfully completed demo and held a presentation, for a year I worked almost only on the world and the story (or stories to be precise), and after some time decided to abandon the “book” format I was using (which was ~100 pages long at that time) and started writing it as a closed wiki (we use Google Sites for it, and there are currently around 200 articles in it - most of them several pages long). But, before you facepalm (or is it too late?) - the good thing was that I was aware from the beginning that the whole story would most probably be too large to implement in the game at the end. That’s why I made almost everything scalable - so we can just throw away whole paths, some parts of them or just a quest or two - without any additional work. Right now we are in a position that we have material for a huge game, but we can also decide to just implement 40% of the material (or somewhere in between) without having to adapt it. So we kind of fucked things up and planned a game that we will probably have no resources to pull out, but we also did leave an easy way to cut out parts of it.
The other practical thing that we did is abandon our Python engine and build a game from scratch in Unity3D. While it was fun and exciting building our own engine, it was really slowing us down. When we decided to switch it really seemed like we just decided to throw away a lot of work and start from the beginning but in a long run I am confident it was the only right thing to do.
In last few months we were joined by two more people, and now we are working faster than ever and are currently very enthusiastic about this!
tl;dr: we are small studio from Belgrade, Serbia. nice to meet you!
Community
