An ape-like creature goes on a journey to destroy the core of a horrible disease which infected his girlfriend who joins him in the form of a ghost.
Plokoth is an atmospheric 2D platforming game for Windows and Nintendo Switch and plays in a mysterious jungle.
As the teams only programmer, I was responsible for everything code-wise.
Also, I was the only game designer in the team, so I took care of everything from game design to level design to user testing.
Additionally, I managed a team of four using JIRA and Confluence.
Plokoth is built in an iterated version of Mission:EOS'
s custom engine-in-engine solution.
I decided to got with this solution for the following reasons:
Many features of Unity are great for prototyping, for instance the scene graph and its easy rendering capabilities.
On the flip side, some of its systems are not suited for situations where you want to be able to control every single bit of information like in a movement system.
A Unity-physics based approach would yield too unpredictable results here.
As well as that, there are a lot of performance issues with Unity Callbacks such as those that MonoBehaviours react to.
My approach here is to use only few of those and instead create a manager structure
that ticks all objects it needs to tick, and can decide on its own when which objects need to be updated.
Not only brings this performance benefits, it also offers more control over timing between different systems and makes managers a true source of truth.
This manager structure also allows to easily implement binary serialization, as every manager gets a serialize call and can propagate it to all its members.
For asset management, I went with a custom solution where every game feature has a scriptable object in which it can define all data that it needs.
Via the asset manager, it is easy to load and unload asset bundles including these scriptable objects and to access the data for a certain feature.
See the graphic for a small overview of how the camera manager retrieves the data for the camera feature to move the camera correctly.
The big benefit of a system like this is that it is easily extendable, has all important data in one place and allows every system to access all data for every feature. As well as that, it is also easy to only load the features and levels that are currently needed, allowing the game to run smoothly even on the Nintendo Switch.
The engine in engine approach also supports a custom debug drawing system that allows for one-line-fire-and-forget calls like DebugDrawingInterface.DrawArrow(origin, direction, colour, numberOfFrames)
. This is especially useful for debugging systems that work a lot with vectors and radians-angles that are not easily imaginable when only logged.
Another engine feature is scripting support for LUA. I can tag any static function with an [ExposeToLUA] attribute and access that function via runtime LUA-code, allowing me to use it for cheats, alternative configurations and faster debugging times. In theory, it would even be suited to programme some logic, for instance, the movement logic, inside it, during runtime, without having to restart.
The core principle of Plokoth was to be a fast and fluid game with a low iteration time.
This of course also affected pretty much all systems, including the movement system.
As movement is the core mechanic of the game, Plokoth features a variety of options for the player.
The system I created features ...
- Movement on slopes
- Jumping in different heights (via longer or shorter button presses)
- 8-Directional dashing
- Wave Dashing
- A lot of ways to reset your dash cooldown
- Some smaller mechanics aimed at speedrunning
Dynamic Scene Management
To allow the player to perform continuous gameplay without loading screens
Plokoth features a dynamic loading system that loads new levels asynchronously.
For nicer visuals, Plokoth features a parallax system.
The system features a freely configurable, artist-friendly way to add a variable amount of parallax sprites.
For each sprite, the artist can define how much world space it should use up, compared to either the camera size or the area size.
All sprites automatically are scaled to fit the defined space in y-Direction and tile in x-Direction.
Technically, I automatically calculate bounding boxes for each level in the game.
Then, for each area, I can calculate another bounding box which then gets mapped to a progress value ranging from 0 to 1.
Using that value, the system can decide how scrolled each parallax layer should be.
I also needed to create a camera system that could handle fast player movement, vertical & horizontal movement, zooming and camera anchor zones where the camera needs to show a special part of the screen as long as the player does not leave them.
I accomplished those design goals by a multitude of things, through many iterations.
The final result works a bit like this:
There is a rectangle in the middle of the screen.
The camera will always move to fit the focus point
(black box at the left of the player) to be inside the rectangle. The only restriction here are colliders inside the ground of a level, that ensure that the camera does not show too much from under the level.
The focus point moves with the player but predicts player movement based on previous player movement. This allows the player to see more in the direction that they are actively moving in.
Genre: 2D Hardcore Plattformer
Playtime: 45 Minutes
Engine: Unity/Own Engine Mixture
Produced: Q4 2019 - Q1 2020, 3 months