ELIMINATION from Design to Analysis

This is a postmortem for our game ELIMINATION (you can try it here: http://akhalifa.com/elimination/ on Browser, Android, or iOS devices) talking about the different design decisions during creating the game and the level generator and validating some of these theories using players’ data. This post is an adapted version of our (Ahmed Khalifa, Dan Gopstein, and Julian Togeliuspaper that was submitted as a short paper for CoG conference.

Using procedural content generation (PCG) in games, especially for core game elements such as levels, is a bit of an art. When it is executed well, it enhances the player experience and keeps the player wanting to play again [1] but any mistake in the system and the game could feel boring, repetitive and might lead to disappointment [2]. Just like game design, PCG systems are designed using designers’ intuition and a trial and error process. Designers usually test the system on a group of players and based on the feedback they adjust the generator until it works as intended [3].


The Sky House Design – Part 1

Hello Everyone!
In the following post, I will be describing my process in designing my latest game, “The Sky House“.

First of all, I would like to thank Joni Kittaka, Ben Benal, Michael Cook, Chris DiMauro, Michael Fewkes, and Fernando Silva for their feedback that helped in improving the overall game and making it more accessible and less evil :D.

I will divide this topic into three separate blog posts because “The Sky House” consists of 42 scenes which would take too much time to write and too much space for just one. This series of posts contains a lot of spoilers, so please play the game first before reading.

The idea for this game started a long time ago after I finished a tiny game with Samer Abbas for the GameZanga (GameZanga is an Arabic game jam that happens every year in the MENA region) called “Loss“. I liked the idea of having a winged character with very precise controls that allows the player to avoid most of the traditional platform’s challenges (as I am not good with most platformers that utilize momentum). For a long time, I was trying to find the best environment to introduce this character until I remembered playing a game by “Roger Hicks” called, “Celestial Mechanica“. I remembered how much I was fascinated by the idea of the flying citadel (you can notice the similarity between that and my flying house). At that time, “PICO-8” was becoming very famous and I wanted to experiment with it before buying. As a PhD student, I have very little money in general. When I Googled “free alternatives,” I found “TIC-80” which is an fantastic open source fantasy console. I decided to build my game in TIC-80.

The above images show my first draft of the game’s main story, the challenges, and the overall map which has connections inspired by “The Legend of Zelda” and “Metroid” series. I wanted the player to be able to see the different locked branches from the beginning of the game. I also wanted to use the “soft locks” idea similar to the one used in the first “The Legend of Zelda” and the latest, “Breath of the Wild” for controlling the order of visiting the different dungeons. Locks in general are used to guide the player towards an optimal way to finish the game. Soft locks use very difficult challenges for the player’s current skill level. Soft locks provide the feeling of openness instead of having better guidance while hard locks are used to have a more carefully guided experience.

In the image above, you will see the final overall game map as represented in the TIC-80 editor. You can see the similarity of the connections between the initial map draft and this one, however, I changed a little bit of the idea of using soft locks. I only used the soft locks for secrets, hidden areas, and dead end areas. I made sure that there is always something to be done in any dead end path to give the player a sense of achievement and reward. The player can find collectible coins, shortcuts, or hints for the secrets in other rooms. I also made certain that any secret in the game is hinted to, somehow, either by using the art or the layout of the level. Doing so helps the players to find the secrets without spending time bumping into every wall in the game.

Most of my knowledge in designing this game came from reading Anna Anthropy‘s amazing book “A Game Design Vocabulary” and playing “REDDER” and “VVVVVV“. The images above are notes from my notebook after I got my first feedback on the game, and were used to redesign some of the challenges to make it more focused on the core verbs (mechanics). “The Sky House“‘s core verbs can be seen in the first page: Fly, Move, Jump, Drop Slowly (Gliding), and Drop Fast. Every challenge in the game revolves around these verbs – especially Fly and Glide as these are what make “The Sky House” stand out among similar games. You will also notice that I decided not to use any text inside the game either for story or for guiding the player, similar to the approach used in “REDDER“.

This image shows the game’s title screen. The game starts by pressing the “X” button twice instead of one time to give a hint to the player that pressing “X” twice is an essential element of the game.

To easily explain the rooms in the game, the overall map shows rooms with corresponding numbers beside them. The numbers are written in same order that I will explain the rooms. To jump to a specific room, click the links below:

Room1 Room2 Room3
Room4 Room5 Room6
Room7 Room8 Room9
Room10 Room11

I would like to note that the world of the game is divided into multiple regions – like in “Metroid” – with each region having a different set of challenges ramping from easy to hard as the player advances, ending with the player getting a key. In this first part of the blog series, you will notice that Room1 to Room5 are the first region while Room6 to Room11 are the second region. The first region helps the player to learn the basic verbs and uses spikes as the core challenge. The second region is more about precise control and timing, adding on laser challenges.
<!--, Room13, Room14, Room15, Room16, Room17, Room18, Room19, Room20, Room21, Room22, Room23, Room24, Room25, Room26, Room27, Room28, Room29, Room30, Room31, Room32, Room33, Room34, Room35, Room36, Room37, Room38, Room39, Room40,



Different Time Systems

Hello everyone,
I attended IRDC last weekend. There was a talk by Brett Gildersleeve (the developer of Rogue Space Marine and Helix). The talk is called Real Time Synchronous Turn Systems in Roguelikes. It’s about analyzing the current turn base systems in Roguelike and comparing it to his game Rogue Space Marine. This talk inspired me to write about different systems and which games use which. His talk was astonishing but missing lots of ideas that can be done (It just covered the classic stuff). Here is the ideas about the systems:


Asynchronous Turn Based System: The player plays and after it finished each enemy play its turn. This is the most classic technique used in lots of games (NetHack, Moria, Dungeon Dashers, and …etc).

Synchronous Turn Based System: The player plays at the same time of the enemy. The system resolve the collision by some precedence. Some games adds a speed parameter to have different enemies. Every enemy or npc move related to the player so if he is slower this means he might take more than 1 turn to move but if he is faster than the player he might be moving two tiles with every one player move. For example Cardinal Quest and Super-W-Hack!.

Real Time System: Everything runs at each frame. Everything is continuous and running smooth. The collision happens at each frame. For example Nuclear Throne, The Binding of Isaac, Spelunky, and …etc.

Real Time Synchronous System: This is the system he was talking about in his game. The player move in tile based and when he is moving everything else work in real time (enemy bullets can be avoided). For example Rogue Space Marine.

Bullet Time System: The game move in real time till enemies come near then the game goes in bullet time. Right now there is no roguelike use this system but it would be amazing if some one used it. The current game used it is SuperHot.

Physics Based Turn System: The player move with a speed and the turn ends when the physics stops simulation. For example Billiard Dungeon.

Real Time Pause System: Everything runs in real time and if the player didn’t move nothing move. For example The Spooky Cave.

Real Time Rhythm System: Everything moves on a rhythm if the player didn’t move enemies will move. Missing the rhythm make enemies move while player is still at same location. For example Crypt of the Necrodancer.

Real Time Slot Pause System: The game is totally paused where the player can make all his decisions then the game turns into real time for a fixed time slot. The only game that used that is not a roguelike but it would be cool in a Roguelike. The only game is The Random Encounter.

Time Accumulation Synchronous System: The game saves the amount of time the user not doing his turn and when he plays it repeat the action for the this amount of time. It seems weird and complicated but we might make maximum of the saved time. Its not done before and I would love to try doing it at one day. But if this system is used to penaltize the player it might be similar to Real Time Rhythm System (when not doing anything the game penaltize the player by moving the enemies).

These are all the systems I can think of that can be used in roguelike games. I think I need to organize it and make like 2D matrix for the different parameter that can be mixed.

Bye Bye