Our First Game, From The Technical Perspective

The first Figment Game Studios project is still too early to talk about in full.

That is deliberate. Some ideas need time to become sturdy before they are named, explained, and put under the pressure of public expectation. The shape is there, but for now I would rather talk about the foundation than over-describe the game.

The short version is this: we are building an isometric survival sandbox with a strong interest in readable systems, tactile player control, and a world that should feel like it keeps moving when the player looks away.

That sentence is still broad on purpose. The details matter, but they are not ready to be the headline yet.

What is ready to talk about is the technical direction.

The game is being built in Godot, with gameplay code written in TypeScript through godot-js. The current work is not glamorous in the trailer-friendly sense. It is movement, traversal, stance handling, aiming, camera behavior, debugging tools, tests, and the slow process of turning early experiments into systems that can survive long-term iteration.

That foundation work matters because this kind of game can become messy very quickly. Survival sandboxes are not just a pile of features. They are a pile of features that all want to affect each other. Movement affects combat. Inventory affects mobility. Equipment affects risk. World simulation affects scarcity. Scarcity affects decisions. Decisions create consequences.

If the codebase cannot absorb that pressure, the game design eventually has to shrink to fit the code.

I do not want that.

So the early project has been as much about architecture as design. The goal is to keep Godot scenes as composition and orchestration layers, while moving reusable gameplay decisions into focused TypeScript modules and runtime controllers. The player should not become one enormous script that knows everything. The sandbox should not become a dumping ground for every test idea.

That sounds dry, but it is connected directly to the feel of the game. A clean architecture makes it easier to tune movement without breaking traversal, test decision logic without launching the editor, and add new systems without turning every change into a negotiation with a giant file.

This is also why tests are part of the foundation rather than an afterthought. The project already uses Vitest around extracted gameplay logic. Not because tests are exciting on their own, but because they make refactoring safer. They let small pieces of player behavior become understandable units instead of mysteries buried inside an update loop.

The first real work has been about finding the edges of responsibility:

• Godot owns the scene tree, runtime integration, and editor workflow.
• TypeScript owns gameplay structure, decision logic, and the pieces that benefit from strong tooling.
• Tests protect the parts of the game that can be reasoned about without a running scene.
• Controllers own persistent runtime state where plain helper functions start to become awkward.

That split is still evolving, but it already feels like the right direction.

For now, the project is still in foundation-building mode. The interesting part is not that everything is solved. It is that the early technical choices are being made with the future game in mind: a game where systems overlap, consequences matter, and the code needs to stay legible enough to keep pushing deeper.

More specific design posts will come later, when the ideas are ready to be talked about without giving too much away too early.