Mental Anchor

Overview

Mental Anchor is set in a future society overrun by AI. The player takes the role of a Debugger, exploring a cyber world and solving its puzzles. The art style is oppressive and realistic, and the gameplay centres on exploration paired with serious knowledge about the AI era.

On a five-person team I wore three hats: Lead Programmer (owning the underlying architecture and the global systems), Unity Handler (integrating art and code into playable scenes), and Project Manager (version control, Kanban, and the module delivery process).

Motivation & Goals

The goal I set with the team was to leverage everyone's strengths into one unique, smoothly running 3D exploration game. Two consequences followed from that sentence and shaped nearly every technical decision below.

First, "everyone's strengths" meant the codebase had to be authored by programmers but operated by designers, UI designers and artists. Systems therefore needed zero-code configuration surfaces rather than hard-coded behaviour.

Second, "smoothly running" was interpreted as a process guarantee, not a performance one: the project should hold a playable build at all times, which pushed the branching model and Kanban flow described later.

The serious-game intent is delivered through collectibles. Each collected object carries a piece of "serious lore" — the Gear item, for instance, unfolds into Algorithmic Determinism: human behaviour can be predicted and even pre-structured through data analysis and machine learning models, thereby undermining individual autonomy. The inventory is the vehicle for the game's actual argument, which is why I took ownership of it personally.

Program Architecture

I built the game's underlying code as a three-tier structure: manager, gameplay, data, split into a Global System and a Local System.

Communication was deliberately split by scope:

• Within a module — dependency injection and direct references via GetComponent. Cheap to write, minimal ceremony.
• Between modules — a loosely coupled, adaptive architecture shared by an Event Bus and a ServiceHub.

The reasoning is that decoupling has a cost, so it should be paid only where it returns something. Inside a module, extra indirection buys nothing and slows development; across module boundaries, it buys independent iteration and easy maintenance. Game events live as ScriptableObjects, so a designer can wire a trigger to a target in the scene without touching code.

UI, Inventory and Collectible Systems

To serve the game's need for seriousness, I took on the UI, backpack and collectible systems — a relatively complex multi-module global system. This meant continuous communication with the UI designer, and the result realised essentially all of their interaction concept: hovering highlights an item frame and expands its description, B opens and closes the backpack, picking an item up plays a pop-up carrying its lore.

Rather than hand-authoring each item, I built the collectible system on a unified ScriptableObject template. This improved code reuse and, just as importantly, gave the UI designer and level designers a zero-code window in which to author items: icon, name, description, message name and serious lore are all data fields.

Level Systems

I wrote the code for the Rotating Tower and the Grid Puzzle, and did part of the level design for the spider levels.

• Rotating Tower — activate pedals from bottom to top to rotate each floor (90 degrees, four orientations, each with a different pattern) until the patterns connect into a single surface. Because the tower is a one-to-one object trigger within the scene, I replaced the original index-recording mode with a reuse of the EventBus, which let designers configure it with zero code.
• Grid Puzzle — early concept called for this puzzle in many places, so I wrote a Grid Puzzle Generator to make it reusable in later development rather than rebuilding it per instance.
• Spider levels — the designers' prototype contained only one set of mechanism prototypes, which would have been monotonous used directly. I adapted the spider generator and the ViewAlign puzzles to the scene so players move back and forth between multiple ViewAligns. This increased play length and, because the level appears late in the game, gave it a smoother difficulty curve.

Difficulties & Solutions

The weekly development logs record the problems as they surfaced and the solution adopted for each.

Manager load order. Enabling singleton mode on every manager created a loading-order problem. Rather than fight initialisation sequence, I introduced the ServiceHub and registered all managers through it, so dependencies resolve by lookup instead of by construction order.

Cross-module coupling. Direct references between systems would have made the modules inseparable. I used an EventBus with Event Listeners backed by ScriptableObjects, attached to trigger and target objects, which allowed convenient event communication within a scene while keeping modules independent.

Designer prototypes that did not fit the framework. To integrate the level prototypes the designers created, I adaptively refactored their code, reorganising the original move / damage / spawner logic into the Hierarchy. Two decisions came out of that work: after discussion with the designers we removed the health system that existed only in that one level, because a level-local state model broke the consistency of the global game state; and I standardised interaction on the IInteractable interface so every interactive object answered the same contract.

Interaction that felt inconsistent. I added a pointer-based interaction scheme in which the interaction channel only triggers when the mouse points at the object, plus a universal scheme where entering an object's interaction area and pressing the interaction key fires the matching callback event.

Art iteration cost. Integrating art assets and scripts by hand would have made every art revision expensive. I made extensive use of prefabs, so iterations propagated instead of being re-integrated.

Accumulated defects before the final test. Rather than fixing opportunistically, defects were batched and cleared in a single dedicated pass (the 04/29 fix list: rotating tower exit teleport and pattern alignment, level 1 finishing move, level 2 teleport placement and collectibles, subtitle appearance, collectible display, rotating tower speed, and more), followed by level optimisation in the last test week.

Project Management

Version control. Art and programming were developed on separate branches (Dev-Art, Dev-Gameplay), with the latest runnable version synced to main. This model guarantees the project always has a current playable build, which matters more than a tidy history when a team is integrating art continuously.

Kanban and modular delivery. We used a Kanban board for modular team development. Each module moved as a whole through prototype design, initial art and programming drafts, art and programming refinement, and finally integration, only then being assembled into the overall game. Keeping a module intact through that pipeline is what kept a working version available, and is the agile model applied in practice.

Asset ownership. To spread development responsibility and reduce collision risk inside the Unity project, folders were created per team member, so each person owned their assigned script modules and art assets. Shared assets were categorised separately at the root, making the latest version easy to find during scene integration.

Hierarchy conventions. The scene Hierarchy was categorised the same way, separating the work of artists, programmers and UI designers so that integration late in the project stayed predictable.

Reflection

On game system design, I came to understand that game development is an art in which code serves design, and the priorities cannot be reversed. Early on I repeatedly fell into over-designing the architecture and chasing global reusability, at the expense of the game's own design sensibility. After a friend's reminder I adopted a different model: start from the GDD and storyboards, break the game into a handful of core systems, prioritise the most important ones, and then reproduce the experience described in the storyboard inside Unity by calling that infrastructure. The architecture becomes something the design consumes, rather than something the design has to fit.

As Project Manager I also learned by omission — I sometimes forgot to update the Kanban board. Task breakdown turns out to be the crucial artefact in modular game development: it reflects real progress, and it determines both the testing phase of a game unit and the testing phase of the next iteration. Without a properly practised agile process, a project accumulates half-finished programs and half-finished art, which is a disaster to manage.

Credits

Third-party asset: DOTween (HOTween v2) by Demigiant.