# Futile: a code-only 2D framework for Unity with no editor workflow

> Futile is a C# 2D framework for Unity aimed at developers who want to build their whole scene in code rather than in the editor, in the Cocos2D and Flash tradition. It is MIT licensed and has been used in shipped games, but it is described by its own author as in development and completely undocumented, and its last tagged release is from 2013.

**MattRix/Futile** — A super simple Unity 2D framework

- Repository: https://github.com/MattRix/Futile
- Website: http://struct.ca/futile
- Stars: 844 · Forks: 133
- Language: C#
- License: not declared
- Published: 2026-10-20 · Updated: 2026-10-20 · Language: en
- Canonical page: https://hysenlabs.com/projects/mattrix-futile

## The pitch is code instead of editor integration

Futile is described as a code-centric 2D framework for Unity, and the second sentence of the description tells you who it is for: those who want to do everything in code with as little editor integration as possible. The comparison offered is explicit, with people who have used Cocos2D or Flash said to feel at home.

That framing is the whole design brief. In Unity, the default way to build a 2D scene is to place objects in the editor, wire up components in the inspector, and let the scene live in a serialized scene file. A code-centric framework inverts that. The scene is constructed by running C#, which means the layout is a diffable text file rather than a binary or opaque asset, and it means the entire interface can be built and modified by someone who never opens the Unity editor window at all.

The consequences follow from that choice. There is no visual designer workflow, no drag and drop, and no inspector to configure. The cost is that you lose the editor conveniences and you inherit a hand written abstraction layer over Unity's own object model, which is work the framework author did once and you now depend on.

The project describes itself as in development and completely undocumented, but adds that it works. The author then adds a note from 2021 saying that Futile has not been updated a whole lot since the first release, but that it has been used, and continues to be used, in a bunch of real games. That combination is the honest summary of the project: not abandoned, not actively developed, and proven in the only way that matters for a framework, which is that shipping games depended on it.

The audience is a specific kind of Unity developer: someone who came from a code-driven 2D engine and wants that model inside Unity, or someone who wants their 2D interface to live in version control alongside the rest of the code.

## The demo project is the only documentation that exists

Given that the project is undocumented, the demo project carries the entire burden of teaching the framework. The README is explicit about how to try it, and the steps are short.

You grab the project from GitHub and put it somewhere, and there is a zip of the whole repository linked for the impatient. You need Unity installed. Then you go into FutileProject/Assets and open FutileScene.unity.

That is the whole onboarding. There is no package to add through the package manager, no version constraint to satisfy, and no setup step beyond having Unity on the machine. The top level of the repository is nearly empty, holding an .editorconfig, .gitattributes, .gitignore, the README and the FutileProject directory, which is consistent with a framework that is mostly a folder of C# files you drop into a Unity project.

The framework itself is distributed as Unity packages and instructional videos hosted at struct.ca/futile, which is the project homepage. The README is careful to separate the two things: the packages and the videos are what you get, and the README is the pointer to them rather than the manual.

For support there are three destinations. Questions and things you have made go to the subreddit at reddit.com/r/futile, bugs and feature requests go to the GitHub issues tracker, and the project states that it works great with all versions of Unity while inviting you to report any issues if you have them.

That last point is worth pausing on. A framework that works with all versions of Unity is convenient, but it also means the project is not tracking any particular Unity release, and there is no version compatibility matrix to consult. Combined with the absence of written documentation, it means you are going to learn the API by reading the demo project source.

## The third party ecosystem is small and clearly enumerated

Four third party addons are listed in the README, and listing them exhaustively is more informative than a general claim would be, because it shows the shape of the ecosystem around a code-driven 2D framework.

FSceneManager by ManaOrb provides a Futile Scene Manager and a Parallax Scrolling Layer, which tells you the framework had a real gap around scene handling and layering that the community filled.

FutileAdditionalClasses by mattfox12 adds animated sprites and TMX tilemaps, which covers the two things a 2D framework always needs and which a minimal core often leaves out.

Futile-SpineSprite by Grizzlage is for using animations made with Spine, the skeletal animation tool. That a Spine integration lives outside the core says something about where the author drew the line.

And a gist by jpsarda provides FDrawingSprite.cs, for drawing lines, which is a single file rather than a project, the smallest possible addon.

What this list tells you is that Futile is a core framework with a deliberately small surface, and the community added the pieces around it. There is no marketplace, no package registry, no version compatibility information. Each addon is a GitHub repository that you would evaluate on its own, and the README does not say which Unity versions or Futile versions they target.

The demo project also uses Prime31's GoKit tweening library, and the legal section credits Prime31's UIToolkit as the source of many of Futile's ideas. GoKit is worth knowing about because it is the tweening layer the sample leans on, and the README links to its own licence separately, which suggests it carries terms that are not the same as Futile's.

## The licence is MIT for code, but the assets are carved out

The legal section of the README is where a framework like this usually hides a surprise, and this one states it plainly. The code and the art assets can be used for anything, with the exception of the font. The sound effects and music are not to be used in anything else.

That is a narrower grant than it first looks. If you ship a Futile game, the sounds and the music in the demo project cannot be reused in your next project. The font is separately identified as Franchise, from Lost Type, and that is a font licence rather than an MIT grant, so the terms come from wherever the font came from.

The source code itself is MIT. The copyright is stated as 2019 Matt Rix and contributors, and the standard permission text is reproduced in full, including the warranty disclaimer and the condition that the copyright notice and permission notice must be included in all copies or substantial portions of the software.

Two other credits matter for provenance. Many of the ideas in Futile come from Prime31's UIToolkit, and the MiniJSON parser is credited to the darktable project. Both are named as sources, and if you are reviewing the codebase for a commercial title, knowing that a JSON parser and a UI toolkit design came from elsewhere is the kind of thing you want to know before shipping.

One caveat on reading the licence status: the repository listing at the top level does not include a separate LICENSE file, and the licence is reproduced inside the README instead. The project metadata records the licence as unknown for that reason. The MIT terms are plainly stated in the README text, but the practical difference between an MIT grant in a file you can point a lawyer at and one embedded in a README is worth resolving before a commercial release.

## Where Futile is the wrong tool

The first wrong-tool case is a team that needs documentation. Futile says it is completely undocumented, and the practical effect is that the only reference is the demo source and the hosted videos. For a solo developer reproducing a familiar Cocos2D pattern, that is workable. For a team of four where three people need to learn the API, it is a tax with no offsetting benefit, and the answer is the community addons, which are four small repositories with no stated version compatibility.

The second case is a project that needs the Unity editor workflow. Everything Futile is for depends on rejecting the editor. A project with designers placing prefabs, a scene composed of inspector-configured components, or a level pipeline built around Unity scenes will find that Futile is orthogonal to how the rest of the team works.

The third case is a project on a schedule that needs predictable upstream support. There is one tagged release, Futile 0.91.1, dated 2013-07-03. The last push to the repository was on 2026-07-25. That gap tells you what has been happening: the repository is being touched, but the release line has not moved in more than a decade, and the README itself is titled Futile (2021 Edition) with a 2021 note from the author saying the project has not been updated a whole lot since the first release.

There is also a scope limit that is easy to miss. This is a 2D framework. It is not a UI toolkit for editor work, not a physics layer, and not an asset pipeline. If the game needs 3D, or needs a physics integration, Futile is not the layer you build on.

And one practical risk deserves naming. A framework that constructs the scene graph itself is coupled to how Unity exposes its object model, and the project claims compatibility with all versions of Unity rather than tracking specific ones. Code written against an old Unity version may need revisiting when the engine's object lifecycle changes underneath it.

## Conclusion

Futile suits a Unity developer who wants the whole scene graph under version control in C# and who already knows the Cocos2D or Flash style of building an interface in code, since the framework assumes that background. It does not suit a team that needs written documentation, editor integration, or a maintained feature pipeline, because the project states plainly that it is undocumented and in development, and the only tagged release is Futile 0.91.1 from 2013. Before adopting, read the demo project in FutileProject/Assets and the instructional videos at struct.ca/futile, check that the third party addons you need exist in the listed list of four, and confirm that the MIT terms cover the assets, since the sound effects and music are explicitly excluded from reuse.

## FAQ

### What is Futile used for in Unity?

Futile is a code-centric 2D framework for Unity aimed at developers who want to build everything in code with as little editor integration as possible. The README says that people who have used Cocos2D or Flash should feel at home with it.

### How do I try the Futile demo project?

Download the project from GitHub, with a zip of the whole repository linked for convenience, make sure Unity is installed, then go into FutileProject/Assets and open FutileScene.unity. The Unity packages and instructional videos are hosted at struct.ca/futile.

### Is Futile actively maintained?

The last push to the repository was on 2026-07-25, but the only tagged release is Futile 0.91.1 from 2013-07-03. The README describes the project as in development and completely undocumented, and a 2021 note from the author says it has not been updated a whole lot since the first release while still being used in real games.

### Can I use the Futile art and sounds in my own game?

The code and the art assets can be used for anything, but the sound effects and music from the project are not to be used in anything else. The demo font is Franchise from Lost Type and carries its own terms, and GoKit, the tweening library the demo uses, has a separate licence.

### What license is Futile released under?

The source code is MIT licensed, with the copyright stated as 2019 Matt Rix and contributors and the standard permission and warranty text reproduced in the README. The repository does not carry a separate LICENSE file, which is why the project metadata records the licence as unknown.

## Sources

- [Issues](https://github.com/MattRix/Futile/issues)
- [MattRix/Futile on GitHub](https://github.com/MattRix/Futile)
- [Project website](http://struct.ca/futile)
- [README](https://github.com/MattRix/Futile/blob/master/README.md)
- [Releases](https://github.com/MattRix/Futile/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mattrix-futile