Gem Eater

My first mobile game

It took me long enough, but last year I finally decided to make a mobile game.
The main reason being that I felt I should make a smaller game for once, and fully finish it, rather than the heap of unfinished (bigger) game projects I have.
I also wanted it to be accessible to most people, so a mobile game seemed like the best choice then.

I have to admit that mobile games, and casual games, are actually a bit out of my comfort zone. But that only makes it more of an interesting challenge to design such a game.
I didn’t have to make it a casual game, but I felt like I should make it as easy to get into as I could (to a degree), and IMO that seems like one of the key-aspects of a casual game.
(This because I noticed that the games I made before often required me to explain to people how to play, rather than people understanding it immediately themselves.)

The game

In Gem Eater you play as an underground gem-eating snake. Just drag the snake’s head to move him around.
You eat your way through a screen filled with dirt, stones(blocks) and gems; trying to eat as much gems while making big combos, without getting stuck.

You gain points by eating gems, these come in 3 colors, red, yellow and blue.
Each time you eat the same color as the last, you increase your gem combo, earning you more and more points each time. But eat a different colored gem, and the combo ends.

At first the screen is only filled with dirt and gems, you’re free to move around carelessly, but as you eat your way through, stone-blocks will fall down among the dirt and gems. These stone blocks are impassable, and slowly but surely the screen will fill up with these, making it harder for you to get around, until eventually, you get stuck. That is, unless you reach the target score first.

Designing the mechanics

Comming up with the game concept and designing the mechanics was actually rather easy. I knew I wanted to make something similar to old arcade games, which quickly made me think about games like Tetris, Snake and Bejeweled. And it didn’t take long for me to come up with a bunch of ideas involving falling blocks and snakes eating gems.

Now don’t get me wrong, my idea wasn’t to copy existing games, I always want to make fully original games, I just wanted something with a simple concept, structure and controls as these games.

I had the main game mechanics pretty much entirely worked out in my head before even making the first prototype.
After making the prototype however, finalizing the entire game took a lot more time to figure out.
I had expected to finish the game in a couple of weeks in my spare time, but it ended up taking months.

Finalizing the game and adding extra content

At first it was just gonna be like Tetris; no stages, you just play until you get stuck, and that’s it. But I realized it would be more fun to have to try to reach a target score, which clears the solid blocks and makes you advance to the next stage, which has a higher target score.
I also felt (And still do) like it would be best to have every stage continue from the last (as in: keep all tiles with dirt and gems the same), rather than have you move to a new screen as you go to the next stage. Because this way you can save gems for later, and it just makes all the stages feel like one big level rather than a bunch of small ones.

However I felt like the game was a bit too short and lacked reason to play the game over and over, and it took me long to decide what to do against that.
Eventually I came up with a bunch of variations of the snake, each with a different power that could help you. And I decided to make the player unlock these one by one.
But it wasn’t clear to me what would be the best way to unlock these.
At first I made it so you needed to reach a certain highscore for each to unlock. But I eventually made it so you earn coins for completing stages, and more coins the higher the stage. And you could then use these coins to unlock the next snake.
The benefit this has over unlocking through highscore, is that every game you play brings you closer to your goal of unlocking the next snake, even when you don’t play as well as before. And since the main purpose of it was to give the player a reason to keep playing, I went with this approach.

All the snakes

I also added in achievements and a leaderboard through google play.

After having played the game myself a bunch, and becoming very good at it, I found that starting at stage 1 each time was a bit tiresome. (Even though that was actually one of the core aspects of the game I wanted, like old arcade games)
So I thought about having the player be able to start a game at a higher stage, but I didn’t know how to make that work exactly. With how many points would he start? Making it too low and it’s pointless to do when you’re trying to beat a highscore, and making it too high would be unfair as well.
So I thought about making the player able to set checkpoints at a stage while playing, and when you start from that checkpoint (CP for short) later, you’ll have exactly the same points and everything as when you initially set it. But I didn’t want the player to just be able to start from a CP as soon as he got there for the first time. Because that would cause the player to set the CP as high as he could, and would ruin the fun of the game. I kindof wanted the player to only be able to set a CP at stage 10 when he is able to get to stage 20, for example. But I couldn’t think of a good way to do this without making it all too complex.
In the end I made it so you can only set (and start from) a CP by spending coins, and the cost increases exponentially the higher the stage. This ensured that it is only beneficial to set a CP at least about 5-10 stages lower than the highest stage you can get to. (Because when you set it higher, it would cost more coins to start from the CP than you could make back)
Honestly, I’m still not entirely sure if that was the best approach, but I think it’s good enough.


Most people were really positive, and I know a couple of people that really loved it and played it a ton. And I’m really happy for that.
But In the end though, the game went pretty much unnoticed, most of the people that played it are people I know personally.
I also added in (optional) rewarding ads, more as an experiment than anything else, but I’m not even close to reaching the minimum number of views to even have the chance of making any money on it.
I didn’t expect it to become a huge success or anything, especially since I spent no money on advertising the game, I just posted about it on facebook and the Unity forums and that’s about it.
But still, when I compare it to years ago when I posted flash games on Kongregate, every game there was easily played a couple hundreds of times after just a single day without telling anyone about it. In the grand scheme of things, that’s still not much, but at least it’s something. Now on the play store, I think not even a single person encountered my game without being directed there by me (either in person or through a post of mine).
But it shouldn’t really be news to anyone that if you post a game on the play store, without advertising it in one way or another, it’s (most likely) never going to reach anyone.

One problem with my game, is that it’s visual style isn’t really attracting anyone I think. I mean I don’t think it looks awful or anything, but it does look rather generic. And I don’t really think any screenshot or video of the game will ever make anyone think “wow, I want to play that!”.

If I wanted more people to play this game, I should have advertised this game better, and made some better promotional images (or have these made) at the very least.


Although it’s ofcourse a rather small game, I’m rather proud of the it. The game mechanics are truly original. And I honestly feel like they are simple but deceptively deep. The way everything influences everything else; every tile you eat causes the tiles above to fall down, changing the shape of the level. The way you eat around the solid blocks defines the wall, rooms, tunnels of the level.

It’s easy to start playing the game, but the more you play the better you get at it because you start to understand the consequences of your every action and you start to see the strategic aspects of the game.

The game is available for free on the Play Store:
Google Play Link


Shoot ‘Em Up! (experimental flash game)


I never play much casual or web based games,
but I do visit Kongregate every so often (though it has been a while),
because they tend to have more original games than the average flash games site.
(or atleast they used to)

I also made some small games available there, mostly fairly rough, not-quite-finished games, like Warmada for example.
But an other one is Shoot ‘Em Up, which this post is obviously about.

One thing I liked about making games for use on Kongregate, are the APIs.
(To be honest though, I’ve never uploaded my games anywhere else, so I don’t know what it’s like on other sites)

One of the APIs is the “Shared Content API”, which allowed users to save content they made in a game, and let others load it.
Mostly used for sharing save games and creating custom levels.

But I started thinking of ways to use the API for more direct gameplay mechanics, for creating a more cooperative gaming experience.

The Concept

I got the idea to make a 2 player co-op game, where instead of 2 players playing simultaniously, only 1 player playes at a time, and the other is a recorded run of someone else.
And after finishing a level, the player could then save his run, and share it with others so they could then play co-op with it.

The idea was to see if this concept could allow for a new interesting experience, given the advantages and disadvantages that come with it.
The main advantages beeing that it allowed players to play together without having to play at the same time, and that any single run could be used for any number of different players, both friends and strangers.
(and smaller advantages beeing the impossibility of there beeing server or connection problems)


Since it was gonna be an experiment, I decided it should be a fairly simple game, not too big and easily accessible.
A 2D Shoot-em-up with pixel graphics seemed to be a good chose, as that’s one of the more easy games to make (seeing as how Warmada was made quite fast).

Well that turned out quite differently.

seu2 seu3 seu4 seu14

The Development

I liked making different ennemies, bosses and weapons too much, so it caused me to make the game at lot bigger and complexer than originally planned.
The graphics style was indeed fairly easy to make, but that only caused me to make more and more content.
Other than that, it also proved very difficult to explain the game mechanics in simple and clear ways to the player.

I wanted to emphasise the co-op element of the game, so I tried to make it really about cooperation.
I didn’t want it to be just 2 players shooting trough enemy waves, ignoring each other, I wanted them to help each other and work together.
Now how do you do that when 1 of them is a predetermined recorded run?

Well the biggest ellement I added for that purpose was the gates and gate switches;
some levels where devided in 2 parts, 1 for each player, with gates blocking their paths and gate switches that opened the gate when shot, but the key beeing that the switches for Player1’s gates where in Player2’s part and vica versa.

Gates Gates2

And another was a weapon, the helix cannon.
It shoots a beam of red and blue particles, that can move through walls, in a sin-like wave.
But when both players had this weapon equipped, their beams would be drawn towards and spiral around each other. Beacuse of this the players really had to keep track of each other and act in accordance.

helix1 helix2 helix3 helix6 helix7

The Problems

Having one player beeing completely predetermined causes some issues ofcourse, I anticipated this, but the gravity of it was still much bigger than expected.

Simply put, everything that makes a playthrough different from the playthrough of the recorded run, can cause the recorded player to behave illogically.

For one, this means nothing should happen, even partially, at random. Everything must happen exactly the same each time (except for the active player), otherwise the recorded run would make no sense.
And all the enemies that target a player, always have to target either player1 or player2, they can’t change this based on whoever is closest, cause this would further differentiate it from the recorded run, this unfortunately limits the enemy behaviour.
An issue that can’t be helped, is that when the active player kills an enemy (that wasn’t killed in the recorded version), the recorded player might still try to shoot it down,
and worse, when the active player fails to kill en enemy fast enough (that was killed in the recorded version), the recorded player might fly into it (causing massive damage to the player).

The designs of the levels, and the gates and gate switches, had to be severly simplified,
because originally there where gate switches that both closed gates and opened others, but the problem with this was that it could cause the recorded player to fly straight into a gate, killing him instantly.
And the gate HAS to kill him instantly, as it is a recorded run, and so the only alternative would be making him fly through the gate.

The Result

All in all, I like how the game ended up, though I do not consider it a succes.
The concept has it’s plus sides, but IMO they don’t really outweight the downsides.

The problem basically comes down this:
It’s supposed to be a cooperative game, and that really requires interaction between the 2 players,
but there can’t be interaction when one is prerecorded, there can only be reaction.

It was an experiment, and although it wasn’t a great succes, an experiment is only a failure when you fail to learn from it.

seu5 seu7 seu15 seu23 seu20 seu21 seu22 seu16

You can play the game here:

But make sure to read the instructions before you start.

You can only save your run and share it when you have a Kongregate account (don’t worry, it’s free)

Warmade (old flash game WIP)

A couple years ago I started making small flash games for fun, mostly just for trying out ideas.

1 Game I was making was Warmada, a side scrolling shootemup, where you can exit your ship, run around, and take over hostile ships.
Sort of a combination between a shootemup, GTA and Super Mario Bros.

I started working on it a short time before I started my current job, and so I stopped working on it then.
So unfortunately it never got to a decent state.

But I like the concept, and so I wouldn’t want it to just disapear, so I decided to upload it on Kongregate some time ago.

You can play it here: (if you want, but read along first)

or watch me play it:

Keep in mind though that it was far from finished, not even a prototype.
It’s got only 1 level, temporary graphics, and no real instructions.

So read this first:

The goal is to get to the end of the level alive, stealing and blowing up ships scores you points.

The green bar is your HP, the blue bar is the HP of the ship you’re in/on.
When the ship you’re in/on is destroyed, it explodes, but this doesn’t kill you necessarily, it just damages you a bit.
When you die (no more HP, fall into a pit), the level restarts.

-Arrow keys to move and jump, or to pilote your ship
-Z/W to enter or exit a ship (use Z for qwerty, W for azerty)
-X to shoot (when in a ship)

How to take over a ship:
-jump on it
-press Z/W
-do the displayed combo (before the ship flies out of the screen)

important tip!:
keep X pressed when exitting a ship, and it will keep shooting afterwards (same counts for the arrow keys, but that’s less usefull).
That way you can have a bunch of ships at the same time shooting at the enemy.

Alright, now go play it.