Title: Versus
Platform: Android/iOS/PC
Genre: Casual


Versus is a simple split screen infinite runner game meant to be played by 2 players on the same phone/tablet. The goal of the game is to make your ball (in this case a placeholder) travel the furthest into the level. The player which is left behind loses the game.

The player would need to tap the raised ground in order to pass that tile, otherwise they are stuck until they remove the obstacle. When his ball reaches the bottom part of the screen it’s game over. When the raised tile is taped it lowers down, raising the opposite part on the other side of the screen where the second player advances. The following gif should give you a rough idea:

concept gif

Do note that the gif above represents the start of the game. The moment the balls reach the middle of the screen the “background” starts scrolling. At this point whenever a player gets stuck he ends up getting left behind until he taps the raised tile that stopped him. When he does that he starts moving again trying to regain terrain.

Extra elements: the moment a tile is lowered not only does it raise the opposite part but it also lowers and/or raises a second random tile from the opponent’s side of the screen. While the concepts and images I did are a sketch and could work out if the visual style is meant to be minimalist the game concept could reach a bigger audience if the game has for example 2 cats running upwards instead of the balls. The moment a cat hits a wall it starts scratching it until the player taps it and lowers it down for his cat to pass.

If we were to expand on this idea a little more, there could be ingame purchases of “skins”, or entities that would replace the cats. There could be dogs, penguins, heck, anything might work. The dog could start barking when it hits a wall, the penguin could start crying, a light bulb would crack or turn on and off. Try to think about Crossy Road and the vast skins they have.

The starting speed would be the same every time, the further the players advances the faster the game gets. Fine tuning and testing would be required. The game should be difficult from the beginning.

A PC version could work as well, making the game a coop or multiplayer game worthy of Steam itself.

SCREW IT [in development]

Title: Screw It
Platform: Android/iOS
Genre: Arcade
Status: Currently in development

Basic ilustration

Screw it is an arcade game meant to be played on a smartphone in portrait mode. The main goal of the game is to make the character, Keelan, a female mechanic wielding a giant wrench (somewhere along these lines), grab a bunch of screw heads from the background in order to propel herself upwards so as to avoid being caught by a wave of rust which keeps getting higher and higher from below. The action is meant to take place on an infinite level with the player having to grab as many bolts as possible which will count to the final score (1 bolt = 1 point). At the start of each level the character will automatically fall on a metal spring which will redirect her to the first bolt.

The character will use her wrench to grab onto each hexagonal bolt head at which point an animation will take place that will make her rotate around the point 3 times before tightly screwing the screw and making her drop. While these 3 full 360° swings take place Keelan is anchored onto the bolt with the help of her wrench. The only way the player can lose a game is to misplace a tap and miss the next bolt or let the wave catch the character from below.

Right, but where’s the fun in all that? Well, having a killer pool of rust underneath which keeps rising is not enough just as grabbing a bunch of bolts can be considered a simple, repetitive and eventually boring game-play mechanic. But here’s the element which will keep one in a constant alert: as I’ve mentioned before Keelan will only rotate around a bolt head 3 times before screwing it completely making her drop down in the pool of rust because she wasted her moments where she got a good enough grip on the bolt to throw herself up to the next one.

Imaginary lines

Imagine that each bolt is sitting on an imaginary line (drawn in a manner that will blend it in with the background image and make it look like a natural element). The difficulty of the game stands in the ability of the character to grab a certain bolt from above according to how many times she swung around the bolt she’s currently attached to. What this means is that if the player wants to grab the bolt on Line 1 he must tap it immediately during the animation of the first rotation. If he wants to grab the bolt on Line 2 he must tap that bolt during animation of the second rotation. Same thing for bolt on Line 3, tap it during the last rotation.

But now you wonder why not just tap the next bolt as soon as the characters starts the first rotation? Simply because many times bolts will be missing from the next lines in a random manner. The bolt from Line 1 might be missing, the one from Line 2 might be missing, or even both at the same time. There is also the chance for bolt on Line 3 to be missing case in which at least one bolt would have to be present on Line 1 or 2. The bolts will also appear randomly on the X line (horizontally), so there’s no fixed left, center or right position on the “lines”. And now you might wonder why not just grab the third bolt every time? Remember that the high score counts each bolt as one point and as I will further explain in the next paragraph the speed of the swing animation might just make the player miss the desired bolt according to how many times the character has swung around.

The speed of the swing animation will have to be calibrated as much as possible. If the speed is too slow the game would be sluggish, if the speed is too fast the player won’t be capable to synchronize his taps good enough based on his count of the swings required for a successful jump onto the next bolt. At the same time this brings forth the possibility of a difficulty option which may set the swing speed to a certain value before starting the level. As an extra, there might also be a second Mode which would make the high score count the height reached by the character before dying, instead of the number of bolts she grabbed.

There’s also the matter of how many bolts would be on the screen at the same time at a given moment. While the figures I included above have 5 bolts on the screen I believe it really depends on how big their sprites will be. I’d say 5 would be fine while 6 would make the game too easy even taking into account the maximum of 2 bolts that have a random chance to be missing from the visible screen at any given time.

The game would require 7 different sprites which should be self-explanatory:

(1) Character_still_position
(2) Character_bolt_grabbed
(3) Spring
(4) Spring_2
(5) Bolt
(6) Background
(7) Rust_wave

First one (1) is to be used while the character is dropped onto the Spring at the beginning of the game and during the seconds after she lets go of a bolt and grabs the next one. The second sprite (2) is drawn during the swing animation. Spring (3) is the sprite used before the character falls on it and Spring_2 (4) is used as soon as the character hits the Spring. I also want to mention that the wave of rust could be animated somehow, but in my mind it just contains a bunch of small metal scraps.

And that’s about it folks. Down below you can download the resource files I worked with. My next game concept will include an astronaut, pitch black rooms and some interesting game logic which I hope will offer you some inspiration for future projects. Stay tuned!

Download resource files: