A basic game mechanic I came up with to practice prototyping in Unity, and that eventually could be further developed into a mobile game.

Far away at a distribution center of an online alien pet shop located between Jupiter and the asteroid belt, the player takes the role of a seasonal worker tasked with organizing the ordered pet aliens for shipping.

The objective is to align the alien animals (represented as different colored spheres in this prototype) with their corresponding pipes through which they’ll be sucked by swiping the cube in the according direction.

Different animals will devour directly inferior ones on the surfaces next to them while taking their place.

With each move, a new animal will spawn at the end of the queuing pipe and the first one will drop onto the center cube’s empty top surface to which it’s linked. As the queuing pipe above shows the alien types that will be dropped next, the player can aim to reach a higher score by planning their moves ahead an trying to create longer cascading chains of animals devouring each other.

However, if the top surface happens to be taken by another animal, a new one won’t spawn, causing a debuff within the queue. If the debuff exceeds a certain threshold, the queuing pipe will clog, causing the player to lose the game.

Following mechanisms are implemented in this version:

– rotation of the sorting cube and the player’s controls (touch gestures on iPad)
– function that checks and verifies the sphere with its matching pipe
– function that checks each neighboring cube surface carrying “edible” spheres
– animation of spheres devouring each other

The queuing pipe and a high score tracker are planned to be added.

As the order in which the spheres devour each other is strictly linear, it may be reworked and replaced with a more elaborate value system in order to add more depth to the game.

Unlike the statemachine for our 3D-game project, I tried to directly prototype the idea straight out of my head this time, and ended up decentralizing the code by strictly splitting it up into different scripts according to the functions of each game object.

As for the better, I somehow found myself forced to exactly remember which variable was assigned to which function.
On the down side, clicking through many different game objects and their scripts can get confusing, especially after taking a break from coding and then trying to pick it up again.

As for the future, I’m sure that centralizing most of it into one script would be the approach of choice, even more so as a lesson to become a better coder and handling over 300 lines of code. But as for creating a quick and basic prototype, this way just seems like a more natural one.