Overgrown

This page is about the Gameplay & Tool Development for the game. You can play the levels here and here.

Vines

The main mechanic of the game are the growing vines. The player is equipped with a "fertilizer gun", allowing them to place down or erase a fertilizing substance. When the substance is near a visible vine cluster, vines will grow over it.

These vines can have one of three colors, and they cannot cross each other. They will continuously grow while a connection to such a vine cluster persists, and die off from the back when that connection is severed.

As these vine-like plants have the ability to serve as a source of electrical power, the player must connect them to devices in the level, which are clearly marked.

Drawing the fertilizer

The fertilizer gun functions very simply and intuitively. It places (or erases) fertilizer "nodes" wherever you look. The "nodes" are oriented according to the surface they were placed on, and stick to it should it move.

Vine growth

The most complicated part certainly is the growth of the vines, a lot of thought was put into this. All the logic executes inside the individual nodes and its outgoing connections, though it should be noted that everything runs reactively, so nodes only have to execute anything when something changes around them - which is crucial for the performance.

Whether nodes are in range of other nodes is handled in a manager object which utilizes chunking. When nodes receive color - either by being a source or by incoming connection finishing their growth - they start checking whether they can grow to any nearby node. If so, a new connection is instantiated and continuously grows towards that node until it is reached. The speed of this growth is determined by the distance of the nodes and how strongly the connection must deviate from the node's "flow". The "flow" of a node is the average direction of its outgoing and incoming connections. This way, growth along the vine's current trajectory is encouraged.

When the "target" of a connection receives color before the connection has finished growing, it is removed and no connection will be formed. This ensures a tree-like structure at all times, and that colors cannot cross.

When a node loses color, all outgoing connections will start dying of. When a connection has died, its "target" will also lose color, starting a chain reaction. All following nodes will also register that they are not connected to a source anymore, stopping them from growing new connections - else it could lead to cycling growth.

This explanation is still simplified in places and not completely thorough, but it highlights the most important aspects of the growth logic.

Vine visuals

To make the vines look nice and smooth, I built a shader using the Unity Shader Graph which deforms a cylinder-like shape into a bezier curve, makes it grow and die along that curve and allows for a start- and end-thickness, interpolating in-between. This way they could seemlessly be chained one after another, using the nodes' flow for calculating the bezier curve tangents. Also Thickness animation was possible, allowing for a smooth growth-animation. A little cap was also put at the end of the connection mesh to make the unconnected ends look nicer.

By deforming the connections using a shader, every connection could use the same mesh and material, allowing for batching/instancing. This was important to have large amounts of connections still render fine, and allow for smooth animations without having to update any meshes.

Working with vines in the Editor

A goal was also to have the vine growth run in the editor and be able to draw and erase nodes there. This proved to be a lot harder than I thought, having to wrestle a lot with two big packages I used: Odin Inspector & Serializer (for extended inspector- and serialization-functionality) and Cysharp/R3 (for reactive programming). It works fine now, but I have definitely learned from this experience.

Writing triggers for when nodes change proved easy though, because of the reactive programming approach. Also, nodes dynamically react to any changes made to them, including any growth speed, flow weight or range parameters, or whether they have a color restriction ("sink nodes") or a source color ("source nodes"). Gizmos visualize the connections while working in the editor.

Credits

This game prototype was a three-person-project consisting of:

• go424 - Level Design & Creation; Development of early prototype for the vines-mechanic
• Arof1 - Level Design & Creation; Parts of the visuals (Fertilizer & Fertilizer Gun); Sound Design
• Knower - Vines (logic, interaction, visuals, editor utility)