TIC-80: a fantasy computer for tiny games, and how to build one

What TIC-80 solves, and who ends up using it

TIC-80 is a fantasy computer: a simulated machine with fixed hardware limits and a complete set of authoring tools inside it. The README lists the constraints directly: a 240x136 pixel display, a 16 color palette, 256 8x8 color sprites and 4 channel sound. You are not configuring a renderer or wiring an asset pipeline. You are writing code against a small, known machine.

The people this suits are hobbyist game makers, jam participants, and anyone teaching programming through something visible. The package matters more than any single feature: the code, sprite, map, sound and music editors all live in the same program, and the result is a cartridge file that can be distributed and played wherever TIC-80 runs. That removes the usual gap between making a thing and shipping it. The README states that your cartridge can be played on any device TIC-80 supports, which is the whole pitch in one line.

It is also a deliberate restriction machine. Nine languages are listed for authoring: Lua, Moonscript, Javascript, Ruby, Wren, Fennel, Squirrel, Janet and Python. That range is unusual for a console-style environment, and it means the language you already know is probably available.

How a cartridge, the editors and the memory banks fit together

The unit of work is the cartridge. Games are packaged into a cartridge file, and that file holds the code and the assets the game needs. The built-in editors write into it: the code editor for the script, the sprite editor for the 256 sprites, the map editor for the world, and the sound and music editors for the 4 channel audio.

There is a second layer worth understanding before you start, because it shapes how you structure a game. The README describes an additional memory bank: load different assets from your cartridge while your game is executing. Assets do not all have to be resident at once. The PRO build extends this to 8 memory banks instead of 1, along with text format cartridges and exporting without editors. If you are planning a game with more art than fits the default single bank, that difference is the practical reason to look at the PRO build rather than a cosmetic one.

Input is handled the way you would expect from a console. The README states games can have mouse and keyboard as input, and up to 4 controllers with up to 8 buttons each. A local multiplayer game is within the design, not bolted on.

Installing TIC-80 and making a first cartridge

The README points to compiled binaries for the major operating systems on the Releases page. That is the shortest path and the one to try first. Nightly builds are published through the official nightly.link page and the GitHub Actions page, and there is a separate nightly.link page for unofficial Linux arm64 builds maintained by aliceisjustplaying, tested on Raspberry Pi OS 64-bit (Bookworm), Asahi Linux (Fedora Remix), Ubuntu 22.04 and Fedora 40.

If you would rather build from source, the repository has a CMakeLists.txt at the top level and the README gives per-platform instructions. The Windows MSVC path for 64-bit systems is the one documented in most detail. The sequence below is the one the README gives for Windows XP and Windows 7 32-bit, using the v141_xp toolset:

git clone --recursive https://github.com/nesbox/TIC-80 && cd .\TIC-80\build
copy /y .\build\janet\janetconf.h .\vendor\janet\src\conf\janetconf.h
cmake -G "Visual Studio 16 2019" -A Win32 -T v141_xp -DCMAKE_BUILD_TYPE=Release -DBUILD_WITH_ALL=On ..
cmake --build . --parallel

After that, the README says you will find tic80.exe in TIC-80\build\bin. Note the recursive clone: the repository has a .gitmodules file and a vendor directory, so a plain clone will leave you with missing submodules.

The PRO build is not a separate repository. The README states that users who cannot afford it can build the pro version from source with this flag:

cmake .. -DBUILD_PRO=On

Once the binary runs, the first real use is to open the code editor, write a short script in one of the nine supported languages, and run it. The README does not walk through a first script, so the wiki, which the contributing section describes as holding documentation, code snippets and game development tutorials, is where to look for a worked example. When you have something you like, save it as a cartridge and share it at tic80.com/play.

Where TIC-80 is the wrong tool

The fixed hardware profile is the product, and it is also the limitation. A 240x136 pixel display with a 16 color palette and 256 sprites is not a starting point you can raise later. If your design needs a larger viewport, a wider palette, or per-pixel shader work, TIC-80 will fight you the entire way, and no amount of code will change the machine.

The single default memory bank is a real constraint too, and the README is explicit that the PRO build is what raises it to 8. If your game carries a lot of art or audio, the free build may not hold it, and the answer is either to build the PRO variant from source or to design smaller. The README does not document how assets are paged in and out of a bank, so plan on reading the wiki rather than the README for that.

There is also a licensing boundary that is easy to miss. The repository carries a LICENSE file at the top level, plus LICENSES/ and THIRD_PARTY_LICENSES.md. The project itself is MIT, but TIC-80 bundles vendored third-party code, and the README does not explain what those terms mean for a cartridge you distribute. Anyone shipping a commercial game should read those files rather than assume the MIT label covers everything in the binary.

TIC-80 against PICO-8

The comparison people reach for is PICO-8, and the honest difference is not quality but posture. TIC-80 is free and open source, MIT licensed, with the source in this repository and a documented build process for Windows, Linux, macOS, FreeBSD, Raspberry Pi and more. PICO-8 is a commercial product. If your requirement is to read, modify or rebuild the machine itself, or to run it on hardware the vendor does not ship a binary for, that distinction decides the question before any feature comparison starts.

The second difference is language choice. TIC-80 lists nine authoring languages, including Javascript, Ruby, Python and Janet alongside Lua. PICO-8's scripting language is its own Lua dialect. If you want to write a cartridge in Python or Javascript, TIC-80 is the one that offers it.

The third is the PRO tier. TIC-80's paid version adds text format cartridges for version control, 8 memory banks instead of 1, and editor-free export for app store publishing. That is a narrower paid upgrade than a full commercial licence, and the README notes you can build it yourself with cmake .. -DBUILD_PRO=On. Which of the two you want depends on whether you value an open, rebuildable machine or a single supported commercial product.

Maintenance, releases and what upgrading costs you

The repository is not archived, and the last push was on 2026-09-21. Release v1.2.0 is dated 2026-09-16. The two releases before it, v1.1.2837 and v1.1.2736, are dated 2023-10-22 and 2023-08-27, so the gap between 1.1 and 1.2 was roughly three years. That pattern matters if you are building on it: expect long stretches between tagged stable releases, with nightly builds filling the space.

Practically, that means pinning to a tagged release if you want reproducibility, and treating the nightly.link builds as a way to test whether a fix you need has landed rather than as something to ship. The README does not document a migration path between cartridge format versions, so before upgrading a project you care about, keep the old binary around and confirm your cartridge still loads.

The licence is MIT for the project. The repository also carries LICENSES/ and THIRD_PARTY_LICENSES.md for vendored dependencies, and those are the files to read if you redistribute binaries or ship a game commercially. This is not legal advice; the point is that the MIT label on the repository root is not the whole picture.

Editorial conclusion

Adopt TIC-80 if you want a self-contained toolchain for small retro games, a jam, or teaching, and you accept the 240x136 pixel display, the 16 color palette and the 256 sprite limit as the design. Do not adopt it if you need a modern renderer or a general purpose engine. Before committing, check the Releases page for a build for your platform, confirm the licence file in LICENSES/ and THIRD_PARTY_LICENSES.md if you plan to redistribute a cartridge, and decide whether the text cartridge format and the extra memory banks in the PRO build are worth building with cmake .. -DBUILD_PRO=On.

Frequently asked questions

Official sources

1. License: MIT
2. nesbox/TIC-80 on GitHub
3. Project website
4. README
5. Releases