A game that only runs on your development machine isn't a finished game. We close out the course by packaging and distributing what you built.
In the previous lesson we decided when to migrate from C to C++. Now, with a mature engine, comes the last step of the cycle: letting someone who's never installed a compiler download your game and play it with a double-click. This means resolving dependencies (does the user have SDL2 installed?), compiling for each target platform, and organizing the files in a way the operating system recognizes as a valid application.
By default, your executable depends on SDL2 being installed as a dynamic library (`.dll`, `.so`, `.dylib`) on the user's computer. The simplest way to avoid asking the user to install anything is to distribute those dynamic libraries alongside your executable, or link statically where possible.
On Windows, the most practical approach is to copy the `SDL2.dll`, `SDL2_image.dll` files (and their dependencies) into the same folder as your `.exe` — Windows looks for DLLs in the executable's directory first.
To avoid maintaining three separate build systems, we keep using the same `CMakeLists.txt` from lesson 2, adding platform-specific rules where needed.
Compiling on each target platform (or using cross-compilation with MinGW from Linux to generate the Windows `.exe` without leaving your machine):
macOS expects graphical applications to come packaged as a `.app`, a folder with a specific structure that Finder recognizes as a single application.
For Linux, distributing a standalone binary forces the user to install dependencies manually. AppImage packages the executable together with all its libraries into a single executable file, no installation required.
With executables packaged for each platform, the most accessible options for an independent developer are:
- itch.io: no entry cost, ideal for publishing your first game and getting real feedback from players. - Steam (via Steamworks): requires a one-time registration fee, but gives access to the largest PC player base. - Your own website: the option with the most control, though it requires you to handle hosting the download files yourself.
For all these platforms, it's good practice to include a `README` with the minimum requirements (operating system, game controls) and a clear version number (`1.0.0`), which lets you communicate future updates unambiguously.
Before publishing, ask your AI assistant to review your entire project specifically looking for: absolute file paths (which only work on your machine and will break the game on a player's), debug messages (`printf`, `SDL_Log`) that were left active and shouldn't be in the final build, and any credentials or sensitive data that slipped into the source code if your game includes networking features like the ones from lessons 9 and 10. It's a quick review that avoids embarrassing mistakes at launch.
We started with the question of why combine C++ with an AI assistant, set up a complete environment, and built Pong from scratch. We added animated sprites, real physical collisions, persistent saving, a state machine organizing the game's overall flow, enemies with pathfinding, and finally took it to the network as a multiplayer game. We closed by optimizing its performance, deciding with judgment when to migrate from C to C++, and today we packaged it, ready for anyone to play.
That's the real point of this course: not to replace your judgment as a programmer with AI, but to use it to move faster without ever losing track of every line running in your game. What comes next is up to you — the next project, bigger or more ambitious, you'll build on your own, with your AI assistant as the co-pilot you already know how to direct.
Carlos Montiel is an enterprise AI solutions architect. He implements LLMs, Agents, RAG, and orchestrators for companies across Guatemala and Latin America. Reach out for a consultation.
Contact Carlos Montiel