Prototype 4: Space Station Amadeus

In which a deadly crime is investigated in the far future…

Get it here

With Break the Bank in the… well bank I wanted to switch gears away from from 3D action based games. I also wanted to take on a prototype that would yield a greater passion within me than the zombie banker shooter that had instilled so much apathy within me. To that end I began work on Space Station Amadeus, a murder investigation set on a city sized space station far in the future.

I’ve had the idea of an adventure game on a space station kicking around for a number of years, albeit with a different plot entirely. The idea was to establish an awe inspiring locale and give the players a bit of a taste of what life on the station would be like. I opted not to tell the original tail I had in mind as I didn’t believe I would have time and writing talent (at the moment) to do it justice.

So was born a murder. With this game I wanted to start improving my writing acumen, and begin the process of personal asset creation (thus far all assets have been downloaded free of charge from the Unity store). As is often the case the games scope was initially the entire case, from crime scene to arrest, with the player travelling between multiple locations to gather all information and clues needed to arrest a suspect. As time went on and implementation of the various systems I needed dragged on I shrank back my aspirations, ending up with just an elevator conversation and the initial crime scene.

Still as an exercise in writing I am very pleased with my work. Character dialogue has always been a challenge for me, to the extent that I have never released any fiction containing dialogue in the past, but I think I did a decent job with Moira and Kastorn. I think the story of the crime scene is interesting and that the prototype acts as a good teaser for a larger story.

The Coding

(This one is going to be a deep dive into the creation of a conversation controller. Feel free to skip ahead to Design and Building where I’ll discuss narrative creation and game design.)

To my utter surprise SSA is right up there with Torch Lighter as the most code intensive of all my prototypes. The chief challenge with this game was to create a reusable conversation system. The aims of the system where as follows:

  • 1-n Participants in the conversation.
  • 1-n Lines in the conversation.
  • Trigger events during or at the end of the conversation.
  • Optionally load portraits for conversation participants.
  • Store conversations on disk as a JSON object.
  • Spell check the conversations at some point during the creation process!
  • Conversation assets should all be pre-loaded to prevent lag when a conversation starts.

The above aims provided me with both a work flow and a format. Each of the conversations was typed up in Evernote (could have used a Google Document as well, I just needed a document that was accessible over the internet, with spell check facilities). Once typed, edited and spellchecked the conversation was converted into a JSON object. The full spec for my conversation format can be found here.

Each of the conversations was stored in a separate file for ease of editing, and once finished I manually verified that the JSON objects were valid using JSON formatter. Finally I stored all of the conversations in a single resources folder called conversations (well duh). As part of the load process for the main game scene in unity a class called ConversationLibrary loads the contents of that entire folder. I created serialised Conversation, Line and Participant classes. One of the C# features available in Unity is JsonUtility. It parses JSON files and converts them into a class provided to it. As long as that class has all the potential parameters (including additional Serialisable classes if desired) it will automatically assign them all correctly from the JSON file.

With the conversations available in the ConversationLibrary I created another class called the ConversationController which manages displaying the conversations. In essence once a conversation is started it takes the current Line (some text, the id of the participant) and passes that information to the SSAUIConversationController (OK I admit it class names can get silly sometimes) for display. Whenever the player clicks it goes to the next line until there are no more at which point it exits (and triggers any required game flags to be set).

Each Element in a given location (something the player can click on or scan, I.E the blood) can have multiple conversations assigned to it and they will play out in turn. Finally I added a slight delay between one conversation finishing and another being able to start. This was done to prevent players accidentally clicking an element as they closed the last conversation (which would annoyingly trigger another conversation). These issues are the kind you probably don’t think about when you consider the things games developers have to deal with to make decent enough products!*

I also worked on my first implementation of game state flow. In torch lighter and Sunwalker progression was pretty much tied to your physical movement through the games and Break the Bank had none to talk of. In Space Station Amadeus I needed to track where the player was in the story to trigger certain events.

In essence the game checks through a list of true/false flags and triggers certain events once they are true. The most obvious example being the start of the game when we load into a scene (with just a single button, that you can see for a fraction of a second) then immediately load into the elevator and trigger the start conversation. A game flag called startGame is set to true indicating that the player is at the start of the game. The conversation is triggered and at the end sets the flag to false causing the game flow manager to load the player into the crime scene.

*Note that this fix in itself caused another bug in the original release of this game! Thanks to Steve for spotting that one!

Design and Building

My main challenge with Space Station Amadeus was constructing a believable setting. I was only going to be able to do much with free stock assets so I knew the writing of the game would have to do most of the heavy lifting to establish the setting. When I started the game I knew I wanted a huge space station, something completely impossible for modern society to build. All I really had in my head was a structure some sixty stories tall.

I opted to draw the whole station, planning initially on digitising the drawing and using it as the background for either an area select or main menu. In the end the drawing itself took three evenings of effort, and doing work to make it look good enough for the game would have taken another couple of days so I ended up using it more as a piece of concept art. As I drew it out I figured out why the station existed, what people did there for fun how different areas of the station would end up more wealthy than others and also how the planet below factored into day to day life. It was a wonderful discovery process and by the end of the drawing I was ready to start writing the conversations in the game.

I never sat down to write out every conversation in the game, mostly as I didn’t have a plan of what the flow of it would be. Instead I wrote conversations as I added elements in, developing the characters as I went so as to give each of them an individual voice. I had an overall plan for the whole case, including who the killer and victim was, what the motive was and what the killer was planning to do next. That gave me enough direction to begin building the crime scene, and allow the crime scene to lead to another location.

In terms of designing the flow of the game I initially aimed for something like the start of a Monkey Island game. The player could access multiple locations and would need to gather items (or in this case evidence) from each in order to eventually be able to progress. Sadly time was my enemy for this prototype. I was not code complete until the release day of the prototype (25th of February). As I was developing the features I had added content in that used them so I had about half of the crime scene ready on the morning of release.

I opted to focus on adding more conversations into that crime scene and refining the elements that I had in place. I could have tried to rush out another scene but it would have been of low quality and would have detracted from the prototype as a whole. I have instead ended up with most of the systems one would need to develop an adventure game (I did not build an inventory in the end, but have most of that built from the Sunwalker Omega prototype) and a really solid single scene. Down the line I will almost certainly make another adventure game prototype and it should have far more content in, as the majority of the code is in place already. Perhaps another case for Moira and Kastorn?

Learning Outcomes

Unity is a wonderful tool. It enables people of all skill levels to make games and facilitates rapid game development like no other game engine. There are a couple of features I have encountered thus far that took a lot of effort for me to learn. First was the animation system as I detailed at length in my Torch Lighter wrap up post. Another system that appears remarkably complex is the UI building system.

Going into this game I would only begrudgingly work on the UIs for my games, you need only look at the Main Menus for each of the prototypes for proof of that! The main outcome of Space Station Amadeus has been me getting very comfortable with the UI tools. I built the entire game as a series of UIs. The scenes that load up are Unity Canvases, the Elements that players can hover over are UI images. The scan window, conversation UI, the controls panel are all canvases. This prototype offered me a ton of practice building UIs which has removed that reluctance.

I’m now in a place where I can knock out feature rich UIs very quickly, something that should let me build better looking menus for my later games (instead of cramming them in a half hour before executing the final builds). I am a long, long way from building beautiful menus, all of mine have been spartan (though always symmetrical, I won’t abide a slightly out of place piece of text or button). I’m a long way from Persona or Panzer Dragoon Saga, but it’s a good start and a skill I’m grateful to have banked, and really that’s the entire point of this year long exercise (merciless self imposed suffering aside).

As I alluded to in the design section I also have added a full conversation system to my shared-scripts repository that should prove very, very useful in the prototypes to come. Additionally the game state flags and flow manager should be useful in later games as a way of gating player access to content and areas.

All in all I’m very well placed to make another adventure game and have most of the code I need to make all my games have some sort of plot elements going forward. Also I got a chance to release some fiction for the first time, something I’m happy to have done as I have long been reluctant to share my writing. I remain hesitant to share short stories but now feel quite comfortable with the idea of writing for my games, something I am very keen to continue to improve at.


Thank you, thank you, thank you for reading this and playing my prototypes. I hope you’ll continue to see a quality increase as I continue to build my skills and code base. This one was a bit of a passion project for me and represents the start of a project I’ve had kicking around in my mind since 2010 (more on that later). Up next is something a bit more game play focused that I’ll be announcing before the working week is out. (Touch wood).

Happy trails and I’ll see you down the road,


Show your support

Clapping shows how much you appreciated Matthew Tyas’s story.