(Re)Charge [Unity3D: PC/Android]

A project exploring procedural content generation using Unity3D, (Re)Charge is about rushing to each level’s exit while picking up as many energy units as possible, and dodging enemy clouds. Single-space horizontal/vertical movement is the only agency the player has. Powerups are of two kinds: regular, that add one energy unit, and supers, that can add anywhere between 5 and 10 energy units, to the player’s total. The game is over when the player exhausts all their energy, or collides with an enemy.

Click here to download the latest PC executable, or get it on the Play Store.

Code hosted on Github.


Most of the methodology is simple, based on Generate and Test. There are various controllers, managers, and two singleton objects: the game manager and input manager. Although most of the inter-class communication happens via static events, static delegates, and interface methods, there still exists some tight coupling which is in the process of being refactored. As this is my first “publishable” game, all algorithms are presently simplistic/minimalist and are being made more elaborate step-by-step.

Board Manager:

A tile set is provided to the game’s board generator, using which it generates a tile map based on Perlin noise values. Each level has a different sampling range. The current version uses three distinct tiles, one of which is “unpassable”, and a separate exit tile. Perlin noise ensures smooth maps and clumps unpassable tiles together. The player object sends the board requests to move to a desired next tile, which can be denied for boundaries and unpassables. As the board is being initialised, powerups, supers and enemies are instantiated according to their specific probabilities, which increase/decrease contextually as the levels increase, along with the speed of the player, thus establishing a rudimentary ramp-up design.

Input Layer:

This module simply records received input and correspondingly fires off static delegates for other controllers to subscribe to.

Player Controller:

Player movements are quantised along each tile and restricted to one tile at a time. An input buffer is implemented to cache one look-ahead request, based on playtesting feedback.

Game Manager:

Responsible for changing the state of the game among: running, game-over, restarting. Secondary responsibilities include enabling/disabling the player controller (e.g.: during level transitions, on request by the board manager).

Enemy Controller:

The state machine alternates between chasing and wandering. Time duration for each state is a fuzzed value, to enable basic variety of behaviour for multiple enemies in a scene.