Why Figment Game Studios is using TypeScript inside Godot, and what that could mean for the way the project grows.
One of the more unusual technical choices in our first game is also one of the most natural choices for me: the gameplay code is being written in TypeScript.
That is not because TypeScript is the default answer for game development. It is not. Most game development conversations orbit C++, C#, GDScript, Lua, or engine-specific scripting languages long before they get to TypeScript.
But TypeScript is where I have spent many years building real software, solving real production problems, and developing the instincts that only come from long-term use of a language. That matters.
A game project is already full of unknowns: design unknowns, production unknowns, tooling unknowns, performance unknowns, art pipeline unknowns. Choosing a language where I already have deep professional experience means I can spend more of my uncertainty budget on the game itself, rather than on learning how to express every idea from first principles.
That does not make TypeScript the obvious choice for every game. It makes it the right choice to explore for this one.
The current stack is Godot with TypeScript through godot-js. Godot gives the project a real editor, scene system, physics integration, and a practical path toward building an actual game rather than a custom engine project. TypeScript gives the gameplay layer a mature language, strong editor support, refactoring tools, familiar package workflows, and a testing ecosystem that is unusually good for fast iteration.
That combination is the experiment.
The hope is not just “can TypeScript run in a game engine?” It can. The more interesting question is whether TypeScript can make certain kinds of game code easier to grow, test, and maintain.
So far, the answer is promising.
The early codebase has already gone through the kind of cleanup that every real project eventually needs. Large player and sandbox scripts started to accumulate too much responsibility, so the work shifted toward smaller modules, focused helper functions, and runtime controllers for areas like locomotion, traversal, and ladder interaction.
That kind of refactor is where TypeScript feels strong to me. Not in an abstract “types are good” way, but in the practical day-to-day sense that I know how to shape a TypeScript codebase so it can survive change.
You get types around data shape. You get fast feedback when a boundary changes. You get familiar testing with Vitest. You get code navigation that makes a growing project feel less opaque. You get a workflow where renaming something, extracting something, or tightening an interface does not feel like a gamble.
Most importantly, you can move parts of the gameplay logic toward units that are understandable outside the editor.
Not everything belongs in a unit test. A game is not a spreadsheet. Feel, timing, animation, camera behaviour, and physical interaction still need to be played, watched, and tuned in context.
But plenty of decisions can be tested:
- How should a landing be classified?
- When is traversal available?
- What state should a controller enter after an interaction?
- Which inputs should be ignored during a constrained movement state?
- How should persistent runtime state transition from one mode to another?
Those are not purely visual problems. They are logic problems that affect feel. Having tests around them means the project can keep changing without every cleanup pass becoming an act of faith.
There is also a broader hope here.
TypeScript has become a mainstream language for serious application development because it offers a useful middle ground: expressive enough to move quickly, structured enough to support large systems, and familiar to a large number of working developers.
I would like to see more of that energy in game development.
Not as a replacement for every engine language. Not as a claim that TypeScript is secretly the best tool for every game. And not because web development practices should be copied blindly into games.
But as a legitimate option for people who think in systems, want modern tooling, and are building games where gameplay code benefits from the same maintainability practices we expect elsewhere in software.
For me, that is the real appeal. TypeScript is not just a comfortable choice because I know it well. It is a productive choice because the habits I have built with it over many years map directly onto the kinds of problems this project is already facing: state, interaction, refactoring, boundaries, tests, and the slow pressure of a codebase getting bigger.
That is the thread I want to keep pulling on with this project.
The first game still has a long way to go. The technical bet may change shape as the project runs into harder problems. There may be places where TypeScript feels excellent, and places where the engine boundary pushes back.
But right now, TypeScript is doing what I hoped it would do: giving the project a language and workflow that make the foundation easier to reason about, easier to reshape, and easier to keep alive as the design grows.