Ouroboros


Summary

The gameplay of Ouroboros consists of typing messages into a text box in order to make progress in the game. If the player was unable to guess what he or she was supposed to type, he or she can type "hint" into the text box which will bring up hints for the player.


The story centers around a robot whose sole purpose is to commit genocide over and over until the end of time, in order to prevent life from evolving and growing. In the end, the player gets to choose whether or not he or she wants to commit genocide and, based on that choice, the player will get to see one out of two possible endings.

Specifications

  • Text Adventure Game
  • Created in 8 weeks using Alan
  • Created by two level designers, four programmers and three artists

My Contributions

  • Level Design
  • Puzzle Design
  • White Boxing in MAYA
  • Writing

The Team

Design Philosophy

Early on, we challenged ourselves to make the best game we could using the assets and functionality we had. Our goal was to keep the player entertained throughout the whole experience using only images, text based puzzles and well timed humouristic segments. Since the gameplay part of many text adventures tends to be quite tedious, we felt rewarding the player as often as possible was a necessity and humour was just one way of keeping the player interested.


We pushed ourselves to design puzzles which would require very little resources from the programmers and the graphical artists, but in the end would provide the game with reusable and engaging gameplay. For instance, puzzles where you combined things in order to create something were very prominent in the game, so we used clever phrasing of the text as well as the beautiful images from the graphical artists to make each puzzle feel unique, while still maintaining a sense of familiarity for the player.


After all, the graphical artists produced over eighty hand painted images over the course of eight weeks, just to meet the requirements given to us, so we didn’t want them to add more images than necessary.

One of the scenes featured in the final version of the game

First Things First

Once we started working on the project, we created various top down maps of different parts of the game and then we showed these to the rest of the team in order to get feedback. Using top down maps as a way to convey layouts to the rest of the group worked fine for the programmers, but this approach turned out to be far too unspecific for the graphical artists. They wanted to see what the player was supposed to be looking at, so they needed to know what the different "camera angles" were supposed to be.


In order for us to fully explain what we wanted the player to experience, as well as how we would go about leading the player towards certain locations, we started to create the different rooms of the game in MAYA as a form of white boxing for the game. This gave the graphical artists a base from which they could paint on in Photoshop, which in turn speeded up the workflow drastically.

The basic blockout in MAYA...

...and the final art in the game

An early sketch of the end of the game

Scoping with the Team in Mind

Once we had established how we would go about creating content, we created as many levels as we could. First of all, we designed the beginning and the end of the game and then we created various levels to fill out the space in between.


This enabled us to continually add more and more levels without pressuring the artists or the programmers since we knew we could cut middle sections of the game at any time if needed, without affecting the overall story of the game too much.

The Giant Pigeon On Fire

Early on in the project our group as a whole decided what different parts of the game experience each discipline was responsible for. We level designers were responsible for creating top down layouts, blocking them out in MAYA and creating puzzles in those environments. The graphical artists were responsible for painting every single one of those environments and filling them with props. The programmers were responsible for showing the player the right picture at the right time.


Since we didn’t want to restrict the graphical artists' creative freedom, we merely suggested what the different environments could contain. For instance, we wrote things like “obstacle which blocks the player's path” instead of “plants that block the player's path”, so that they could feel free to create what they wanted.


In one of these cases, we level designers wrote “something flammable which blocks a doorway”. This resulted in one of the graphical artists, Simon Stenström, creating a giant combustible pigeon in front of the door which the player had to fry in order to progress in the game. The group found this bird to be too hilarious to remove and so it was kept in the final release of the game. It went on to become one of the most memorable parts of Ouroboros, with many playtesters referring to the game as “the one where you have to set a pigeon on fire”.

What a nice pigeon!

Oh.

Closing Thoughts

This was the very first game I had ever created and, according to playtesters and gamers, the final result was a success. Balancing challenging puzzles with elements of fun can be difficult but, since we asked multiple people to test our game during the development process, the game became a lot more fun to play.


Had I been asked to make a similar game today, I would probably start out by telling a simpler story and then gradually adding to that as the game progressed in order to further remove pressure from the team members. All in all though, I learned so much from this project and I am proud of the final result.


Screenshots


contact@erikleiram.com