Mobile Game Dev

Share this post

Failed Prototype: Hole.io meets Survivor.io

www.rakibjahan.com

Discover more from Mobile Game Dev

Hyper-Hybrid Casual Game development
Continue reading
Sign in

Failed Prototype: Hole.io meets Survivor.io

Shooter Sinkhole

Rakib Jahan
Jul 31, 2023
Share this post

Failed Prototype: Hole.io meets Survivor.io

www.rakibjahan.com
Share

I thought I’d do a different type of blog where I’ll go through the development process of a failed prototype. This would show developers some things that do not work, and maybe some things that do. I can also spark constructive conversations in the comment section that can benefit everyone.

The idea behind this game was to use the hole mechanic which clearly had great marketability and combine it with survivor.io which of course had a great in-game. It made sense on paper but as developers we know, not everything ends up making sense after prototyping 😅

The timeline we decided for this would be 3 weeks to go to test. We started prototyping.

We started with a hole and a shooter. The initial idea is to test with 3 shooters around the hole. The shooters auto-shoot waves of enemies. The player controls the hole and collects the dead bodies around. If the live enemies get close to the hole, they damage the hole.

We have a loop! It is a story of killing enemies and protecting the hole. The aim is to survive as long as possible

For the next step, we need to create some sort of XP system that allows the player to unlock different abilities. In Survivor.io, we saw that the player collected green gems to increase XP, and then when XP reached a certain point, the ability selection UI popped up. We wanted to do something similar.

Our hole was already collecting dead bodies. We included the XP calculation in there. To increase satisfaction, we decided that when the enemies get shot, they will drop voxels randomly. The hole will collect the voxels along with the dead bodies.

At first sight, the XP bar seems linear, like you collect m value of times to max it. But as the enemy spawn frequency increases, the collection of m requires less and less time. After some experimentation, we concluded with an exponential curve of increasing m value.

We added a few abilities that we can use. The abilities need to have a visual impact to allow the player to have that satisfaction. It also needs to help the player to survive longer. So we started off with 2 abilities that were pretty fast to implement and also meaningful. We kept the code clean here so that adding more abilities would not require changing the core code.

  1. Vacuum blast: Blows wind outwards to push enemies

  2. Rocket: Shoots a rocket in the direction of densely packed enemies

We added a simple timer and a simple wave system. The wave system had the simplest of logic. It spawns enemies at a certain distance from the player at certain intervals. That ensured that the enemies would always remain close to the player. After the preset list of waves is complete, the system would repeat the last few waves gradually increasing its difficulty programmatically.

We had the working MVP. At this point, we were close to 2 weeks.

At this point, we did a playtest of the game internally. The most important feedback there we felt, was that the enemies attacking the hole did not make much sense and were hard to grasp. Another big feedback was that the game was too difficult as most of us could not get over 2-minute mark.

We kept ideating and trying new stuff to solve it. We ideated what if a drone was to hover over the hole and shoot enemies. And the enemies would try to attack the drone and not the hole. Eventually, though we did not get to try it. But we did solve the difficulty by balancing the wave

It was time to polish the core, add some upgrade options, and more abilities.

To keep things interesting, we added 2 more types of enemies. A fat type, moves slowly but has more health, and a fast type moves fast, but has low health. With those variations in place, things were looking a lot more busy and a lot more satisfying

We added a simple FTUE and went to release. It went a bit over 3 weeks. But we were happy with it so far. Ideally, of course, we would have loved to have more time to experiment with some design issues. But it was a good time to stop and send it to test.

Loading video

Unlike what we thought the marketability was not good. The in-game was not bad and it had scopes of improvements. But since the marketability showed no promise, we decided to drop it.

That’s the development story of a failed prototype. Hope you learned something and I would to hear your thoughts in the hope of me learning something new from you. Leave your thoughts, let’s discuss.✌️

Loading...

Thanks for reading Mobile Game Dev! Subscribe for free to receive new posts and support my work.

Share this post

Failed Prototype: Hole.io meets Survivor.io

www.rakibjahan.com
Share
Comments
Top
New
Community

No posts

Ready for more?

© 2023 Rakib Jahan
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing