fbpx
#Devlogs

Visceral: The Tech Making of HENOSIS™

Share
FavoriteLoadingAdd to favorites

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

Henosis Sketch Figure 1: 'HENOSIS™ Sketch' by Andrew Gavin Taylor

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.

Henosis: World Concept Figure 2: 'HENOSIS™: World Concept' by Andrew Gavin Taylor

Henosis: Boss Concept Figure 3: 'HENOSIS™: Boss Concept' by Andrew Gavin Taylor

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.

Visual Test Figure 4: 'Visual Test' by Andrew Gavin Taylor

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.

Screen shot of <a href=World 1" width="616" height="347" /> Figure 5: 'Screen shot of World 1'

 

Screen shot of World 1 Figure 6: 'Screen shot of World 1' 

 

Screen shot of World 3 with Time Slow enabled Figure 7: 'Screen shot of World 3 with Time Slow enabled.'

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.

Henosis: Prototype using Construct 2 Figure 6: 'Prototype' - a very early prototype made in Construct 2

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 Test Figure 7: Prototyping for the Blob physics and movement.

Player Movement

Player Movement: Raycasting

Figure 8.1: Player Movement: Raycasting

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].

Player Movement: Raycasting Detection Sweep Figure 8.1: Player Movement: Raycasting Detection Sweep

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!

Assigning physics to the Player Sprite

Figure 9.1: Assigning physics to the Player Sprite

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

Warping the Player sprite with physics - deformed Figure 9.2: Warping the Player sprite with physics - deformed

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].

Player Sprite - Final Result

Figure 9.3: Player Sprite - Final Result

 

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

Zippity-doo-dah!

Performing the 'Zip' Figure 10: Performing the 'Zip'

[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.

'Slug Patroller' enemy roaming around a Sprite Shape platform Figure 14: 'Slug Patroller' enemy roaming around a Sprite Shape platform

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.

Standard PNG asset from Photoshop with colliders applied. Figure 11: Standard PNG asset from Photoshop with colliders applied.

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.

Using Sprite Shapes Figure 16: Sprite Shape with a universal diffuse, normal and animated emission map applied to the Fill slot. This not only allowed levels to be designed faster but it also negated any collision errors and allowed for much smoother movement.

Player abilities:

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

Time Slow abilityThe 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.

 

BombThe 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

 

Join us!


How about writing your own piece for IndieWatch?


Andrew

Andrew Taylor is Creative Director for Odd Critter Games and works as a freelance designer and online tutor in Perth, Australia.

Leave a Reply

Your email address will not be published.

Back to top button