pacman.c is one C file with a CMake build and a WASM target

The whole game is one file, and that is the point

pacman.c is described as a Pacman clone written in C99 with minimal dependencies for Windows, macOS, Linux and WASM.

The repository layout is where the design decision becomes obvious. The top level holds pacman.c itself, a CMakeLists.txt, a LICENSE, a README, a .gitignore, an .envrc, a flake.nix with a flake.lock, a pacman-dossier.pdf, a pacman.c.6 man page, and a sokol directory. There is no assets directory, no sprites directory and no level data files. Everything is in the source file.

That is unusual and it is the point of the project. The README says that for implementation details you should see the comments in the pacman.c source file, and adds that the author has tried to structure the source code so that it can be read from top to bottom. That is a teaching constraint, and it explains the whole repository: one file to read, a build system to produce it, and no scaffolding to distract from it.

The related project list has one entry, a Zig version of the same game at floooh/pacman.zig. That is a good hint about the intent as well, since porting the same single file design to another language is a natural exercise for someone reading the first one.

The build is CMake, and it works the same on three desktops

The clone, build and run instructions are the same on Linux, macOS and Windows, and they are the standard CMake out of source sequence:

git clone https://github.com/floooh/pacman.c
cd pacman.c
mkdir build
cd build
cmake ..
cmake --build .

There is one platform dependency note and it applies to Linux only. You need to install the OpenGL, X11 and ALSA development packages, with mesa-common-dev, libx11-dev and libasound2-dev given as examples. Those are the three legs the game stands on: OpenGL for rendering, X11 for the window, and ALSA for sound.

The result differs only in where the binary lands. On Mac and Linux the executable called pacman is created in the build directory, and you run it from there:

./pacman

On Windows the executable is in a subdirectory, at Debug/pacman.exe.

There is also a Nix path, which is a single command:

nix run github:floooh/pacman.c

The flake.nix and flake.lock in the repository root are what make that work, and the .envrc file is there for direnv users who want the environment set up automatically when entering the directory.

The WASM build is a different toolchain with a warning attached

The browser version is built through Emscripten, and the README is candid about the friction.

The first warning is about the host, not the game. You will run into various problems running the Emscripten SDK tools on Windows, and it might be better to run this stuff in WSL. That is a practical statement about a toolchain that is Unix shaped.

The setup is the standard Emscripten download and install procedure from the Emscripten documentation, and then a step that is easy to miss. After activating the SDK you have to run source ./emsdk_env.sh, and the README puts it in bold terms: don't forget.

The build itself is a CMake configure with a different generator and a different build type:

mkdir build
cd build
emcmake cmake -G"Unix Makefiles" -DCMAKE_BUILD_TYPE=MinSizeRel ..
cmake --build .

The MinSizeRel build type is the interesting choice here. For a game that ships to a browser as a page, binary size is part of the download cost, so the build is optimised for a small result rather than for speed.

To see the result in a browser, the Emscripten runtime helper is used:

> emrun pacman.html

There is also a hosted build at floooh.github.io/pacman.c/pacman.html, which is the quickest way to see what the project produces before installing anything.

IDE support is a first class path, not an afterthought

The README spends more space on editors than on the game itself, which tells you who the audience is.

On Windows with Visual Studio, CMake automatically creates a Visual Studio solution file that can be opened from the build directory:

cd build
cmake ..
cmake --open .

On macOS the Xcode generator produces an Xcode project in the same way:

cd build
cmake -GXcode ..
cmake --open .

And on every platform, opening the project root in Visual Studio Code with the Microsoft C/C++ and CMake Tools extensions is enough, because the CMake Tools extension detects the CMakeLists.txt file and takes over:

cd pacman.c
code .

Three platforms, three native IDEs, one build definition. That is a deliberate consequence of using CMake rather than a platform specific build script, and it is the kind of detail that a small project gets right when its author works across all three systems.

The sokol directory in the repository root is also worth noting. It suggests the platform specific work is delegated to a library rather than reimplemented, which is how a single file game gets a window, input and audio without a megabyte of engine code.

Where pacman.c is the wrong tool

Three situations rule it out.

The first is a shipping game project. A real engine gives you an asset pipeline, a level editor, input remapping, audio mixing, a build for every platform you ship on, and profiling tools. pacman.c gives you a game. If your goal is to make the next Pacman, you would rewrite it in whatever your studio uses, and reading this file is a good way to decide what to write.

The second is the browser version, unless you already have Emscripten. The WASM build is a real toolchain install, with its own version management, its own environment activation step and its own generator flag. If you wanted to look at the game in a browser, the hosted build already exists and there is nothing to install.

The third is modifying the game. Because the levels, the maze and the entity tables live in the source file with no external format, adding a level or changing the maze means editing C code rather than editing data. That is the flip side of the readability constraint, and it is a real cost if your interest is in extending the game rather than in reading it.

The alternatives split cleanly by purpose. For a playable Pacman, the original arcade release and the many existing reimplementations are what you want, and the hosted WASM build of this project is one of them. For learning, a game written in a language you already know, with an engine that has a level editor, is a better teacher than a C file you cannot easily change. And for reference implementations of OpenGL, there are dedicated tutorials, since pacman.c is a game that happens to use OpenGL rather than a tutorial that happens to be a game.

Editorial conclusion

pacman.c fits a reader who wants to read one complete C program end to end, and a graphics programmer who wants a small reference for how a tile based game loop, an entity system and a build are put together without a framework. It is the wrong choice for a shipping game project, where a real engine gives you asset pipelines, level editors and input handling you would otherwise write yourself, and it is the wrong choice if you want the browser version, since the Emscripten toolchain is a real setup cost. Before you build it, check three things: that your platform has the OpenGL, X11 and ALSA development packages on Linux, that you are comfortable with a game whose levels are in the source rather than in data files, and that the code is a teaching artifact rather than a base to extend, since the project explicitly does not describe a plugin, level or asset format.

Frequently asked questions

Official sources

1. floooh/pacman.c on GitHub
2. Issues
3. License: MIT
4. README