Game Tools & Architectures

Circuit Editor

The Circuit Editor is a complete level editor tailor-made for creating Circuits, made completely within the Unity game Editor.

Circuits are Game-Specific levels for the Tactical Turn-based Hacking game Control Shift, thus making the Circuit Editor highly specific to this particular game and technical context.

The goal for the Circuit Editor was to go far beyond making it solely possible to create Circuits, and have a dedicated UI functioning as a full-fledge Workspace optimised for the Circuit-making process.

It was achieved by working in close collaboration with the designer who was going to spend the most time with it, as we decided on the interface and features together.

As a Game-Specific Tool, the Circuit Editor was always meant to scale with the game and gain features along the way. It's most recent version has the following features :

 ◉ A dedicated interface and control scheme to "paint" a Circuit and configure its elements
 ◉ Game and admin-related metadatas associated with each Circuit, used to streamline the creation process
 ◉ A complete admin system, with the ability to save/load/export and search through hundreds of Circuits
 ◉ The ability to draft and save uncompleted Circuits with comments and colored drafting elements
 ◉ A "Template" feature, used to save a Circuit structure and load it as a starting point
 ◉ A "Snapshot" feature capable of saving a thumbnail wihing the metadatas, and a large png Image on disk

Overridable System

The Overridables System is one of my favorite work architecture-wise. Unfortunately, I cannot share its code on GitHub (because some of its core utilities are dependant on proprietary code ).

I started working on this system during my 2023 internship at PocketKnife interactive, while forethinking the architecture of Moonrunner, a cancelled match-3 games featuring Teammates.

Because I could not fine a satisfying, (meaning practical, reusable, elegant) way to model the bonuses and maluses affecting Teammates, I drafted my own before going back to my studies. I then reflected upon it for some time, and implemented it a year later for Control Shift, another game by PocketKnife.

The Overridable System is a handmade solution to a very common concept in video-games : buffs and debuffs.
Simply put, sometimes during gameplay, we want to have some value (for example, the attack value of a skill) impacted by some sort of modifier (for example, a curse decreasing the attack value by a fixed amount).

Enter the Overridables System ! It makes it possible to designates most of code values as "Overridables", meaning that they can consequently be affected by a numbers of "Modifiers" that will influence a final value.
Modifiers works as a pile of modifiers stacked upon an Overridable value.

As of now, the system has a ton of really neat design specifications, like (in my opinion) thoughtful integration within Unity ecosystem, as well as some bad ones like a painfully error-prone initialisation procedure. Despite some flaws, The Overridable System works exactly as intended, and packs useful features expanding on the original idea.

Maybe sometimes I'll revisit it as an external tool, with the goal of making it more usable by less experienced developers and non-coders.

Animation Clip Rebinder

Created For :

Unity Engine

Date :

May 2025

Purpose :

Improving Unity AnimationClip workflow

The Animation Clip Rebinder is a non-game specific utility made for Unity Engine's Animations Clips, Unity's Animation assets. It is a simple, straightforward tool, but in order to understand what it does, one need to understand how animation-related data is stored in Unity.

In Unity, the animation of an object is represented by keyframes on a timeline, relating to a specific object, which is the animation target.

Animation targets lives in a hierarchy of possible targets, all being objects that can be animated (for example, a Character is comprised of a head, a torso and hopefully four members, all targets of their own).
The keyframes, containing information related to what the motion will look like, are stored alongside their bindings, a piece of data linking keyframes to their target within the hierarchy. As an exemple, keyframes representing a wave motion may be bound to a target which is the arm of the Character.

And bindings, in Unity, tend to blow up, causing the animations to (simply put) not work.

With that said, the Animation Clip Rebinder is a just a simple tool that helps a user rebind the motion to the target and restore the animation by automating this otherwise manual and tedious process.
It provides the user with some options regarding the rebinding, as well as informations and safeguards about the bindings themselves.

This tool was made in one afternoon, who would've otherwise be dedicated to manually rebinding a bunch of animations. I deemed it a better use of my time.

Command Package

During my Final Year graduation project, I was responsible for putting together the game Architecture, and came up with a solution that I call the "Command Package". This solution was designed around the capabilities of the Unity game engine

The project it was made for was called Shared Lands, a 4X multiplayer Versus strategy-game where two players fights on a map where a Titan Unit wanders.

As stated earlier, Shared Lands is a multiplayer game, therefore it had networking requirements that informed its architecture design choices.
Thus, the Command Package (which is misnamed) is actually a merged implementation of two popular game patterns : The Command Pattern (of course) and the Observer Pattern. It also encompasses a Networking solution.

You can browse a breakdown of its implementation here.

Because this architecture would have such an impact on the way we'd develop the game later on, it was conceptualized early in production, and tried and tested thoroughly before committing to it.
I also made a User Manual for it, which I thought was thoroughly put together at the time (and so I won't include it).

Bills of Specifications

During the development of Control Shift, I was tasked with formalizing processes and writing several bills of specifications in an effort aimed at improving development quality. Control Shift is a game project with significant complexity, and a untertwined game systems.

As such, it was paramount to ensure that any new feature met quality and conformity criterias when shipped. Writing detailed bills of specifications for each upcoming feature was one way of doing that. As an exemple, here is one of those bills as a standalone document (in French).

I was personally responsible for formalizing these document into a process, and ensuring we'd write the bill before starting the development of any upcoming feature.

Each Bill is a several pages long (~6 to 10) document, and includes a summary of its content, broken down in versions. Although writing those bill was quite time consuming, developing without it costs way more in debugging effort in the end.

Also, writing all those bills greatly improved my ability to write technical documentation, and my prociciency with Office suite.