Vole Digger

Vole Digger was our first game in university. It was developed as a mobile game, and is inspired by games like Flappy Bird.

My main tasks in this project was to create the random obstacles that came in from the side, and I also was behind the characters rotation and the trail behind it.

The game

Vole Digger is an endless, 2D mobile game, where you are a vole that is digging forward and avoiding obstacles in your way. Along the way you can collect powerups, which will help you with things such as slow down time or clear all obstacles in front of you, and worms, which you can shoot to destroy obstacles in your way.

The vole always digs down. When you press one finger, the vole digs up. When you press two fingers, the vole digs straight. See the trailer and screenshots below:

Vole Digger Screenshot

Vole Digger Screenshot

Vole Digger Screenshot

Vole Digger Screenshot


My work

My work in Vole Digger consisted mostly of doing the movement of the world and the vole, plus the spawning of obstacles. The movement of the Vole was straight forward, it’s only moving up and down depending on how you press, and the world is moving towards you with a specific speed. Making the slowdown power-up was very easy because of that, the only thing we had to do was to slow down the speed of the world.

One big thing I worked on was the trail behind the vole. I tried using a line renderer, trail renderer and such things, but nothing worked. So instead I opted into writing a custom script that simply spawned 150 sprites when the game was started, and then I pooled it so it could be used as a trail. I used a queue, so after a set amount of time, the sprite that’s been on the map the longest was placed on the same position as the vole. This was a very easy way to do it, and effective because of the pooling. No new trail-sprites where instantiated when the game had started.



Another big thing I worked on was the actual endless obstacles script. You want the obstacles to be random, but not impossible. A completely random approach would give you no control over the possibility that things would spawn that would make it random for you. So I did a “chunk”-system. First I spawned in as many chunks as needed to fill the screen (+ margins), then when a chunk has gone off-screen, I place that at its initial position again and tells it to request content. The content is different prefabs that all are tailor made to fit together, and the chunk requests to get a random one of those prefabs. Of course, if I had more time I could set more rules that some prefabs fit together and some don’t, but like it is right now works really well too!

Oh, I also made the trailer.




One of our main difficulties during this project was to keep the game difficult but not impossible. People complained about the controls being too difficult to use, and that they felt it was weird to press the screen to dig up instead of dig down. I learned that people have knowledge from prior experiences that may confuse them if done in other ways. We thought of changing our controls after that feedback, but then we realized that we thought the game was more fun if done the way we did it. But it is important to think about those things, because we didn’t at first.

The controls though, that we fixed. We also realized that sometimes we had tight gaps to fit through, so we implemented that “two-finger”-tap that made the vole go straight. After we added that, people started liking the game much more.

Randomize things.

It was hard coming up with good ways to randomize obstacles. When we started the project we though that it would be easy to make an endless runner, we don’t have to do too much. During the project we realized just how wrong we were. It is very hard to create a game with random elements, it’s almost harder than doing a normal, “scripted” game.


Team size: 6 people
Duration: 3 months
Roles: Programmer
Year: 2018
Engine: Unity Engine
Platform: Android
Scripting: C#