HENOSIS™ Windows, Mac, Linux game

Andrew Taylor and Damien Rompapas share their story of developing and crafting Henosis™ using Unity.

HENOSIS™ is classed as an experimental platform-puzzler-survival game which uses unique player mechanics and abilities to traverse around other worldly platforms and environments.

Pre-production

The game has its humble beginnings from a quick form idea that lead designer, Andrew Taylor had back in 2016 when he began toying with the idea of Players controlling a viscous blob with a limited but unique mobility and small arsenal of innate abilities.

With just a small team working on a debut commercial game, the scope and design had to be fairly restricted while simultaneously offering something new to players. The approach here was to take the common or classic platform tropes but repurpose them using different player mechanics with a fresh premise and context but using a simple and non-verbal narrative.

Single Screen Vs Tower Platformer (or both?)

Originally, the intention was to design each level based on a fixed, single-screen format to keep the game play tight and restrictive. However, when considering the overall progression throughout each world, this opened up the opportunity to allow the game to evolve and become more of a tower-orientated platformer with each world gradually increasing in height and therefore exponentially adding more challenges and game time along the way. Players are pushed into more diverse territory while also introducing new environmental hazards specific to each world and allowing the blob to ascend.

Most notably, in World 01, there are areas around platforms which will impede on the Player’s speed. World 2 is shrouded in darkness with very few sources of light, leaving the Player to hunt down each token. While in World 3, the Player must take extra care as some of the platforms become temporarily engulfed in streams of lava in addition to freeing encased Tokens using bombs.

At a very early stage of the game, a basic prototype was created using Scirra’s Construct 2 2D game engine. While It provides intuitive features for particularly amateur game developers and non-coders, we quickly realised that the required visual style would be too intense for the engine to handle so to counteract the stress, it was decided to switch to Unity instead. However, Construct 2 itself became an invaluable tool for testing out ideas and helping to communicate the concept and mechanics to developers via relatively simple event sheets and pre-scripted actions.

Technical Challenges

Like all game development projects, HENOSIS™ had its fair share of complex technical challenges. One of the most critical mechanics to get right concerned the implementation of the Blob physics and Platform Colliders in addition to how the Time Slow ability would affect the Player properties and overall gameplay. Depending on the platform’s collider and shape, the Player would sometimes either phase right through or become completely stuck so we had to place certain limitations on corners, concave shapes, minimum jump space and the speed on rotating and moving platforms.

Player Movement

First, we calculate three vectors by ‘raycasting’ to the bottom left, bottom right, and directly down from our blob character. This allows us to know which direction the blob can move clockwise and anti-clockwise [Figure 8.1].

If we come across situations where we do not initially succeed from one of the two assumed raycasts, we ‘jitter’ the position of the blob, then do a 90 degree sweep in 10 degree estimates. If found, the given direction is the vector between the blob and the point of intersection. We then place the blob after performing required movement with the ‘up’ direction of the blob facing opposite the ‘downward’ raycast [Figure 8.2].

Bringing our Blob to Life!

Points are attached to physics spring joints allowing the 2D image to become warped [Figure 9.1].

Since we already have the 3 contact intersections calculated from earlier, we set the lower of the 3 points at the intersection locations [Figure 9.2].

This naturally warps the blob texture to appear ‘anchored’ to the ground [Figure 9.3].

Zippity-doo-dah!

[1] Simply put, we raycast from the blob’s position to its ‘Up’ facing vector. If we detect a platform and the distance for the raycast isn’t too short, we display a reticule, indicating a zip is possible.

[2] When the player performs the ‘zip’, the 3 anchored skeletal spring joints are temporarily detached from the body. The rest of the skeletal body is then moved towards the zip target. This provides a natural stretching of the sprite between the two target points.

[3] Once the zip is completed, the blob is then replaced and orientated according to the previously explained rules and the spring joints are reattached. We additionally play a sprite explosion to misdirect the Player’s gaze away from the stretched sprite coming back together.

Another unique aspect that required some investigation and constant tweaking was the handling of the ‘Slug Patroller’ enemy class which uses a detailed rig system. The bones then conform to the nearby collider of the desired platform through an IK rig, which follows the front of the slug patroller in a snake-like fashion, this causes the skin to conform to the platform’s shape.

PNG Assets vs Sprite Shapes

When we began designing the platforms for World 1 and importing them into Unity, a more efficient means was required if the process was going to be repeated over other worlds with varying textures. It was only until developing the next couple of worlds that we started harnessing the power of Sprite Shapes.

Sprite Shapes work perfectly by enabling the player to roam across ultra-smoothly while providing a good level of control over both fill and edge textures. World 1 however, leveraged individual pre-rendered sprites with collider scripts manually added to allow the collider to conform to the alpha channel set by the PNG graphic.

Some 20 or so separate sprites were generated for W01 specifically. This would often yield technical errors however, as the Player would often become stuck due to slight inconsistencies in the collider’s mesh points which required constant tweaking.

Player abilities:

Aside from the unique mobility that the player inherits, there are a couple of other major abilities at work.

The Time Slow ability allows the Player a 4 second buff where the game speed is halved to make it easier to evade enemies and notoriously tricky hazards. While this ability provides the Player with infinite charges, it comes with a cool down until they can use it once again.

The bomb itself was a particularly interesting mechanic as it initially started out as a weapon that would nullify all enemies that you encountered in addition to destroying weak platform areas. However, allowing the Player to essentially wreak havoc across each level by taking out all conceivable enemies, actually made the game far too easy and conflicted with the more survival-based nature of the game. The behaviour subsequently was restricted to taking out only Bosses and weak areas in order to better balance the game play.

Conclusion and Future Plans:

HENOSIS™ seeks to provide players with an innovative and experiential approach to the classic 2D platformer genre. Overall, this was a technically challenging but nonetheless rewarding experience for the team and we hoped to bring something fresh to the platformer genre.

We’re currently developing a true tower-based mobile version of the game which will reuse the same assets and physics but restructured to suit touch-based interactions.

The game is currently available on Steam for US$9.99

Visit Official Site