# 2048.c is one C file that turns your terminal into a sliding tile board > mevdschee's 2048.c is a console version of the 2048 puzzle for GNU/Linux, written as a single C source file with no dependencies, installable from a distribution package or compiled with one gcc command. It ships with a built in test mode and colour schemes that fall back to black and white. **mevdschee/2048.c** — Console version of the game "2048" for GNU/Linux - Repository: https://github.com/mevdschee/2048.c - Stars: 672 · Forks: 217 - Language: C - License: MIT - Published: 2026-10-21 · Updated: 2026-10-21 · Language: en - Canonical page: https://hysenlabs.com/projects/mevdschee-2048-c ## A whole game in one C source file The repository is unusually small, and the size is the point. The entire game lives in a single file called 2048.c, and the README describes it as a console version of the game 2048 for GNU/Linux. The primary language is C, and the only requirement listed is a C compiler. That is the entire dependency story. There is no library to install, no runtime, no package to fetch, and nothing that ties the program to a desktop environment. The repository topics say as much: cli, command line, ansi colors, c, game, linux, and the clone nature of the project is tagged too. The reason to care about a program this small is that it is genuinely portable and genuinely inspectable. The README lists where it has been tested: GNU/Linux, FreeBSD and OpenBSD. Since the only dependency is a C compiler and the only external facility used is ANSI terminal colours, that is a short list of requirements rather than a long one. The repository also carries a 2048.desktop file, a Makefile, a palette.sh script, a screenshot.png, a debian_2048.png used for the Debian package, a Spanish README in README_es.md, and a LICENSE. The Makefile is where the Debian packaging comes from, and it is four targets long, which is the right size for a project of this kind. ## The rules, spelled out in the README The README describes the gameplay in enough detail to play without reading the source, which is worth having for a project with no manual beyond the readme file. You move the tiles in four directions using the arrow keys, up, down, left and right. All numbers on the board slide in that direction until they hit the wall, and if they bump into each other, two numbers with the same value are combined into one. Each number is only combined once per move, which is the rule that makes the game strategic rather than mechanical, since a row of two twos and a two becomes a four and a two rather than an eight. Every move a new number, a two or a four, appears on the board. You win when you have a 2048 on the board, and you lose once the board is full and you cannot make a move. That last condition is the whole game loop. The board fills, and the only way to keep playing is to keep a corner free, which means the interesting decisions happen several moves before the loss, not at it. A clone that gets the merge rules subtly wrong feels completely different, so this is the part of the implementation worth reading if you are studying the code. There is no mention of scoring, of a save file, of a high score table, or of any other persistence. The program is a board and a key reader, and it is a good example of a small program whose difficulty comes from the game design rather than from the code volume. ## Install from Debian or compile the one file Two install paths are given, and the README marks the second one as recommended. On Debian based systems the package manager route is: ```bash sudo apt install 2048 ``` The recommended route is compiling from source, which is three commands: ```bash wget https://raw.githubusercontent.com/mevdschee/2048.c/master/2048.c gcc -o 2048 2048.c ./2048 ``` The first command fetches the raw source file, the second compiles it into an executable named 2048, and the third starts the game. The URL points at the master branch, so the file you get is whatever is on that branch at the moment you run it, which is worth knowing if you intend to keep the binary around. There is a Makefile as well, with a default target that builds the 2048 binary, a test target, an install target that copies the binary into the bin directory under a PREFIX that defaults to /usr, and a clean target that removes it. The install target creates the destination directory with mkdir and copies the binary with cp, and it honours DESTDIR, so packaging into a staged root works the way you would expect. The README also notes that the code style is C99 with extra warnings, and gives the compiler invocation for that: ```bash gcc -std=c99 -Wextra -o 2048 2048.c ``` The Makefile applies the same flags through a CFLAGS line, so a make build is warning clean by default, which is a reasonable baseline for new C code. ## Colour schemes that fall back when the terminal cannot keep up The visual layer is where a console game shows its personality, and this one is adjustable. The game supports different colour schemes, and the choice depends on ANSI support for 88 or 256 colours. If the terminal does not have enough colours, the game falls back to black and white, which the README says is still very much playable. That fallback is the right design decision. Most terminal programs that assume rich colour produce unreadable output on a limited terminal, and the alternative of refusing to run is worse. Here, the worst case is a monochrome board that still works. Four schemes are documented. Running the binary with no argument uses the original colour scheme, and there are three named variants, each requiring 256 colour support: ```bash ./2048 ``` ```bash ./2048 blackwhite ``` ```bash ./2048 whiteblack ``` ```bash ./2048 bluered ``` The naming is a gradient direction, so blackwhite is black to white and whiteblack is the reverse, and bluered is the blue to red one. A palette.sh script in the repository root sits alongside these, which is presumably where the colour definitions live. The binary also handles the two conventional command line flags. Running the game with --version shows the version information, and running it with --help shows a help message with all supported command line options. ## The test suite is a mode of the game binary This is the detail that separates a serious small project from a weekend one. The game binary has a test mode, and the README asks contributors to run it before committing: ```bash $ ./2048 test All 13 tests executed successfully ``` Thirteen tests, run from the same executable you play with, and the Makefile has a test target that depends on the built binary and runs the same command. There is no separate test harness, no framework, no dependency. The assertion logic lives inside the program. That design has an obvious upside and an obvious limit. The upside is that there is nothing to install and nothing to configure, so the test path cannot rot the way a separate harness can. The limit is that the tests are only as good as the internal structure they exercise, and there is no coverage report, no external test framework to catch regressions in the harness itself, and no CI configuration described in the README. The Makefile keeps the three entry points consistent. The default target builds the 2048 binary, the test target runs the binary in test mode, and clean removes the binary. A contributor's loop is make, then make test, then commit. The recent release history shows this is still being worked on. v1.0.5 on 2026-10-07 was titled Black text on 8 tile, v1.0.4 on 2026-10-06 was Black text on 128 tile, and v1.0.3 on 2025-01-27 was a general fixes release. Two releases in two days for tile contrast suggests the author was tuning the palette for readability on specific tile values, which is exactly the kind of fix you get when people test the game on a real terminal rather than an emulator. ## What it is not, and when to reach for something else The honest limits of this project are the limits of the category. There is no network play, no leaderboard, no save state, no undo, no statistics, and no configuration beyond the colour scheme argument. The game resets when you exit, and the README does not describe any way to persist a board or a score. That is not a criticism of the implementation, it is a description of the scope. What the project is for is a terminal user who wants the puzzle and nothing else, and a C programmer who wants a small, readable, dependency free program to read. The alternative is a browser based 2048, and the difference in approach is straightforward. A browser version needs a modern browser and nothing else, which is the lowest friction option of all and gives you a persistent high score in local storage without any of it being written down anywhere. What you give up is the terminal-native feel, the arrow key control without a browser, and the fact that the browser game is a page you load rather than a binary you compile. The alternative that is closer to a real comparison is a different terminal implementation, either another 2048 clone in C or a game with a graphical interface such as a TUI or an ncurses application. Those bring mouse support, colours that do not depend on ANSI mode detection, and larger boards, at the cost of dependencies and a heavier build. For a programmer, the other alternative is simply to write your own. The rules fit in a paragraph, the state is a grid of integers, and the entire program in this repository is a single file you can read in one sitting. If you want to learn by doing, 2048.c is a reasonable starting point precisely because it is small enough to finish. ## Conclusion Adopt 2048.c if you want a puzzle that runs in a terminal on a machine with no package manager fuss, if you are compiling things anyway, or if you want a readable C program of a few hundred lines to study. Do not adopt it for anything else, since it is a single player puzzle with no network features, no scoring persistence and no mobile support, and a browser based 2048 will serve a casual player better. Before you build, check that your compiler is available, prefer compiling from source over the distribution package as the README recommends, and run the built in tests with the test argument before you play. ## FAQ ### How do I install and run 2048.c on Debian? You can install the distribution package with `sudo apt install 2048`, or compile from source as the README recommends, by downloading 2048.c with wget and running `gcc -o 2048 2048.c` before starting it with `./2048`. ### What are the requirements for 2048.c? A C compiler is the only listed requirement. The README says the game has been tested on GNU/Linux, FreeBSD and OpenBSD, and the terminal colour support determines whether the colour schemes or the black and white fallback are used. ### How do I change the colour scheme in 2048.c? Pass one of the documented arguments to the binary: `blackwhite`, `whiteblack` or `bluered`, each of which requires 256 colour support. With no argument you get the original scheme, and on a terminal without enough colours the game falls back to black and white. ### Does 2048.c have tests? Yes. The binary has a built in test mode, run with `./2048 test`, which the README reports as executing 13 tests successfully, and the Makefile has a test target that runs the same command. Contributions are asked to run the tests before committing. ## Sources - [Issues](https://github.com/mevdschee/2048.c/issues) - [License: MIT](https://github.com/mevdschee/2048.c/blob/main/LICENSE) - [mevdschee/2048.c on GitHub](https://github.com/mevdschee/2048.c) - [README](https://github.com/mevdschee/2048.c/blob/main/README.md) - [Releases](https://github.com/mevdschee/2048.c/releases) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mevdschee-2048-c