MonoGame-Samples: a catalogue of small, complete games rather than code fragments

Each sample is a small project, not a snippet

The repository is described as a collection of cross-platform MonoGame samples and game projects that should compile on Windows, macOS, Linux, iOS and Android. Each sample demonstrates different game development concepts, features or genres, and the README says that for detailed information about each one you should look at the linked readme in its subdirectory.

That structure is the point. A sample in this tree is a project with its own content, its own readme and its own place in the table, rather than a fragment in a documentation page. The main readme is an index, and the index links out, which is a difference that matters when you are trying to work out whether a project will build on your machine.

The scale is visible in the directory listing. There are around seventy sample directories at the top level, from AdMob through Aiming, Audio3D and BloomEffect to PacMan, Shaders2D, StarWarrior and Particle3D, plus a solution file for the content builder, which is the shared asset pipeline the samples use.

The platform claim is the other thing to note. Should compile on five operating systems is a strong statement for a game sample, and it is the reason a build workflow badge sits at the top of the readme, wired to a workflow that builds the samples. The project is MIT licensed, the last push was on 2026-09-21, and the repository publishes no releases, since the samples are versioned by their source rather than by a tag.

The 2D table is really an index of engine features

The two dimensional samples are the bulk of the tree, and read as a list they form a reference for what an engine can do rather than a set of games.

The mechanics and input group is the most practical part. There is a sample for input handling across keyboard, mouse and gamepad, one that displays live input values for controllers, a multi-touch sample, and one for touch gestures and mouse support. Aiming covers aiming mechanics and input handling, and BouncingBox is a simple physics sample.

Detection and simulation have their own entries: collision detection techniques, rectangle collision detection, a physics engine integration sample, flocking AI behaviours, and a chase and evade AI sample. Navigation appears as a waypoint AI navigation sample.

The rendering side has custom 2D shader effects, particle systems and effects, drawing primitive shapes, render-to-texture techniques, sprite effects and a custom cursor rendering sample. Structure is covered by a sample for managing game states and screens, and a game components directory sits alongside.

Then the games begin. PacMan is a cross-platform Pac-Man clone, RockRain is an arcade-style falling rocks game, HoneycombRush is an arcade-style honeycomb collection game, StarWarrior is a classic space shooter, and RolePlayingGame is an RPG sample with a tile engine and menus.

One editorial observation: several of these appear twice, because the game samples table also lists PacMan, RockRain, HoneycombRush, StarWarrior and RolePlayingGame alongside the two dimensional table. A complete game shows up in both, which is a small sign that the tables were built at different times and never reconciled.

The 3D samples map onto the graphics pipeline

The three dimensional section is short, and every entry corresponds to a stage of the rendering pipeline rather than to a game.

Colored3DCube is the baseline, a coloured cube, which is the smallest thing that proves the 3D path works. Graphics3D is the advanced counterpart, with the techniques that do not fit in a cube. Audio3D covers 3D audio positioning and effects, which is the audio pipeline's answer to the same problem of placing a sound in a space.

Then there are the post-processing effects. BloomEffect is a bloom post-processing effect, LensFlare is a lens flare post-processing effect, and ShadowMapping demonstrates shadow mapping in 3D. ShatterEffect is a 3D shatter effect demonstration, which is the hardest of the set, since it means destroying geometry rather than lighting it.

ReachGraphicsDemo is the odd one out, and it is worth noticing. It demonstrates the Reach profile graphics features, which in the MonoGame world means the tier of hardware features a given console or handheld supports. A sample that exists to show a hardware capability tier is a different kind of artefact from one that shows a technique, and it is the kind of thing that ages badly, because hardware profiles move and the sample stays.

The pattern across the whole table is that each directory is named after the concept it teaches. A developer who needs a specific technique can find it by name, which is more useful than a curated list of recommended projects, and it is also the reason the tree has grown to seventy directories rather than a handful of polished ones.

The networking table admits what does not work

The networking section is the most honest part of the README, because it annotates the state of each project rather than describing it.

NetworkStateManagment is described as the project template for most of the networked games in the repository, the ones that use a lobby. Its name is misspelled in the table, which is a small indication that this is a community catalogue rather than a curated one.

NetworkPrediction is a sample of networked gameplay prediction and synchronisation. Peer2Peer is a peer to peer multiplayer tank demo. CatapultNetWars is the networked counterpart of the catapult game, single player and networked, and CatapultWars also appears in the game samples table.

Then the two qualifications. NetRumble, a networked multiplayer space shooter, is marked as not working yet. And MonoGame.Xna.Framework.Net, described as a networking API compatibility sample, is marked as partially implemented for peer to peer and LAN games.

Several of these entries also say they work on LAN, which is the honest qualifier. Networking in a game sample is the hardest thing to make work across five operating systems, and a sample that only talks to a machine on the same network is a real, useful thing, but it is not what a shipping game needs.

So the practical reading of this table is that it is a map of a project in progress. The template and the prediction sample are the parts to study, and the two flagged entries are the parts to try first if you want to help.

The XNA book samples are still here, and porting them is an invitation

One entry in the two dimensional table deserves its own paragraph, because it explains where the collection came from.

GameDevelopmentbyExample is described as four 2D samples from the XNA Game Development by Example book, and they are named individually in the table: AsteroidBeltAssault, FloodControl, GemstoneHunter and RobotRampage. Three of those four also appear in the game samples table, with GemstoneHunter appearing only in the book collection.

Those samples are the historical layer of the repository. XNA was the Microsoft framework MonoGame grew out of, and the book was a tutorial series for it, so a tree of game examples that starts from a book is a tree that has outlived its platform.

The contribution guide makes that explicit as a task rather than a sentiment. The fourth way to contribute is to share a MonoGame sample, and the alternative offered is to help port the older XNA samples, so that there is a centralised resource for all MonoGame game developers. That is a concrete piece of work with a defined scope, and it is the kind of contribution that a maintainer can review and merge without redesigning anything.

The other contribution routes are equally concrete. Report issues in the repository. Submit pull requests by forking, fixing bugs and modernising the samples, following the coding standards and describing the change in detail. Improve the documentation by editing the readme files. And donate to the MonoGame Foundation, which the readme ties to the idea of keeping the framework free for everyone.

What a reader should take from the catalogue

A few closing observations, given that this repository is a catalogue rather than a library.

The first is that the value is in the index. The readme is a table of concepts, and the concept names are the searchable part. Whether you are looking for how to do render-to-texture, how to handle a gamepad, or how to do a bloom effect, there is a directory named after the thing, and the per-project readme is where the detail is.

The second is that the completeness is uneven, and the table itself tells you where. The networking section flags two projects by name, and the miscellaneous section starts with samples of the unglamorous kind, an ad integration and a background thread tester, which tells you the collection also covers the parts of a project that nobody writes a tutorial about and everybody needs.

The third is that the project is a community effort with a maintainer rather than a company behind it. The contribution guide is written in the first person, it names a foundation to donate to, and the licence is permissive. The last push was in September 2026 and the build workflow runs on every push, so the tree is not abandoned, but it is a curated garden rather than a product with a release cadence.

For an engineer deciding whether to use it, the answer is simple. If you are learning MonoGame, take one sample that matches what you are building, read its readme, and build it. If you are looking for a shared content pipeline across a fleet of game projects, the content builder solution in the repository root is the part to look at, because that is the piece that gets reused.

Editorial conclusion

Adopt MonoGame-Samples if you are learning MonoGame or need a working reference for one engine feature, since each directory is a small project that should compile on every target rather than a fragment you have to assemble. Do not adopt it as a production codebase, because these are teaching samples with uneven completeness, which the networking table makes explicit when it marks one project as not working yet. Before you rely on a specific sample, read the readme in its own directory, since the summary table gives one line per project and the detail lives there, and check that the sample you care about is in the state you need, because a game sample that does not run is still useful as a reference but not as a starting point.

Frequently asked questions

Official sources

1. CartBlanche/MonoGame-Samples on GitHub
2. Issues
3. License: MIT
4. Project website
5. README