Versatree
Versatree is a major iteration of Traversée! The initial idea was to build a copy of its predecessor to learn Godot and cleaner code architecture. Surprisingly it evolved into an entirely new project: the prototype shifted away from survival mechanics toward a more offensive approach. Players still need to cross grid-based stages and the playable character is an overpowered spellcaster.
Role: Game Designer
Context: Personal prototype
Tools: Godot (GDScript), Blender, Figma
Platform: PC
win condition
Clear grid-based levels by reaching the exit tile. The goal is to bring a witch artifact to another village by completing all levels.
failure state
If HP reaches 0, the character is sent back to the starting village, where they can learn new attributes thanks to the collected items.
core loop
1/ Prepare
Equip passive Totems and attributes and start the run from the starting village.
2A/ Move
Step on biome tiles to feed attributes and unlock spell upgrades.
2B/ Cast spell
Cycle through AoE patterns to eliminate threats before they close the gap.
3/ Level exit
Reach the exit tile to advance to the next level.
design intent
The idea of switching genres and perspective came pretty early and demanded a complete redesign of some core mechanics of Traversée. Since the idea of survivability was being abandoned, the intent was no longer to make the player battle against the game's environment, but instead to make them play with it. Three new pillars emerged from this reflection:
Build progression must be satisfying and the changes induced by a level-up or a new attribute must be highly noticeable, both in terms of data scaling and VFX if possible.
The idea of survivability is no longer important and the player must adopt an aggressive playstyle to clear the board.
The general tempo of the game is significantly faster than Traversée, affecting movement speed, attack resolution, or even level transitions.
While the genre shifted, the game keeps a punitive aspect, targeting the same midcore audience as Traversée and runs are still designed to be short.
grid and turn-based mechanics
The game is played on a 2D grid (13x13 tiles). Versatree's grid spawn system is a lot lighter than Traversée's since there is no need for movement constraints anymore. Tiles are spawned at runtime using weighted distribution.
The main rules are :
The player has one action per turn (move or attack). After the player moves or attacks, all creatures move one tile toward them.
There is no defensive minigame anymore. If a creature reaches the player's tile, it gets destroyed and the player instantly loses 1 HP. Every turn requires anticipation: the player must eliminate threats before they close the gap.
If there is only 1 creature alive on the grid, 2 new creatures respawn to maintain some pressure on the player.
the board is the build
In Versatree, the environment is no longer the enemy, it is the progression system itself. Every tile hosts a specific biome and a point value:
Walking on a tile absorbs its points, which feed directly into a progress bar (attribute) located in the top-right corner. The tile's biome dictates which attribute receives the points.
Each attribute bar is divided into 5 sections. Reaching a new section pauses the game, offering a choice between 2 minor upgrades. Completing a full bar unlocks a choice between 2 major upgrades. All stats stack infinitely.
The prototype features 3 attributes:
Fire : All upgrades under this attribute affect offensive abilities
Water : All upgrades under this attribute affect defensive abilities
Cosmos : All upgrades under this attribute affect movement abilities
bonuses and meta-progression
In addition to point values, some tiles host collectible items that are instantly added to the inventory: These items act as consumables during the run. They can only be used once but the player can use as many items as they want in a single turn.
However, if the player keeps those items until a game over, they are secured and can be used to permanently upgrade attributes or craft Totems (starting equipment that grants passive bonuses like altering tile spawn probabilities or boosting max HP).
combat and areas of effect
Attacks are resolved through spatial targeting rather than timing:
The player can cycle through different AoE patterns (random tiles, diagonals, rows, columns…)
The number of schemes the player can cycle through is directly tied to an upgrade they unlock via the cosmos attribute.
Once the player aligns a scheme that covers enough targets, they launch the attack. By default, it depletes 1 HP from every affected creature, but damage can be scaled through fire upgrades.
solving distance and readability
Because attack patterns span across the entire board, spatial anticipation is critical: the camera slightly follows mouse movements, allowing the player to see a broader range of tiles. Zooming out accentuates this effect.
To counter the loss of tile readability at wide zoom levels, a contextual HUD pops up in the bottom right corner of the screen whenever a walkable tile is hovered over. A similar interface was implemented in the bottom left corner of the screen for inventory items.
solving messy architecture
Unlike Traversée there is a smarter use of signals and event buses to avoid spaghetti code :
Local signals are set for all data that can be passed directly from one node to another.
Event buses (Autoload) are used to pass global signals between nodes, scripts or scenes that are completely unrelated.
This is the script of the event bus. It is used to pass some signals between scenes (left screen) and also to keep some necessary data in memory, like new damage values or an enhanced distance of movement (right screen).
exposed parameters
A significant amount of data was exposed to rapidly change global parameters like grid size, number of creatures or spell ranges, without editing everything in the code.
The left view shows global parameters exposed directly inside the Godot Inspector. The right view shows the main script where variables are exposed. The first exposed variable (game_settings) contains every parameter shown on the left! It is set inside a custom resource file.
camera work
A lot more thought needed to be put into how the camera moves. In Traversée it was straightforward because the board was smaller and the need for anticipation less important. In Versatree if the player cannot see half of the board, it becomes a major issue in terms of progression.
The left view shows the input function that triggers everytime the player uses the mouse wheel to zoom in or zoom out. Max and min values are set at the end of the function to avoid infinite scrolls.
The right view shows the second part of the script and its process function. It allows the camera to slightly move with the mouse and the process is divided into 4 steps:
Get the screen size and mouse position (22-23)
Compute vector offset from screen center and clamp distance to keep the hero visible (24-27)
Smoothly interpolate position using
lerpwith a speed multiplier (28)Apply different offset limits and lookahead factors based on active zoom levels (30-38)
Versatree was initially scoped as a technical exercise to learn Godot and GDScript, but it rapidly became an interesting lesson in systemic design and iteration.
Key wins: Heavy iteration and UI work
Between Traversée and Versatree there are only a few differences in terms of mechanics, and yet it radically transform the prototype. It taught me how to find the fun by trusting in-engine testing and pivoting when a better idea emerges.
Linking the attribute progression system directly to the grid was a fun idea. It made navigating the board more engaging and it removed some of the frustration a player could feel in Traversée. On the flip side, there is some more work to do on the "juice" and how everything reacts when a bar progresses or when the player uses certain items.
The challenges: The action economy and player retention
Currently the player's turn is either moving or attacking, which is very limited in terms of strategic decisions. It sometimes create unavoidable hits or tedious retreats. Collectible items were initially one way of preventing this kind of issue, but they are not sufficient. An interesting idea would be to add additional action types (teleportation with a major drawback, blocking creatures etc…), and they could even depend on the crafted Totems!
The topic of player retention is also another challenge that would require extensive testing and balancing: One way of sustaining retention consists in allowing the player to constantly unlock new relevant skills or equipment. Relaunching a run becomes much more interesting in this context since it brings new strategic decisions and challenges to the player.