Introduction
MicroEngine is a game engine that orchestrates subsystems and integrates existing technologies to offer one coherent
way of making 2D games in C# and .NET 10. It does not reinvent graphics APIs, multimedia libraries or the runtime:
SDL 3 draws, plays sound and reads input on Windows, Linux, macOS, Android and iOS, raylib does the same in browsers
(compiled to WebAssembly), and .NET runs the code. MicroEngine’s own work is choosing those technologies, coordinating
them behind one contract (IPlatform) and giving games a consistent model on top: the fixed-step loop, scenes,
input actions, procedural art and audio tools, saves and achievements.
A game is an ordinary .NET program that subclasses Game, pushes scenes onto a stack and draws pixel art into a small
virtual canvas. It never names a platform: the host picks one, so the same game assembly runs everywhere. MicroEngine is
code-first and has no visual editor; it is not a Godot or Unity, and not a thin wrapper over SDL or raylib either.
Who it is for
- Developers who prefer writing games in code over working in a visual editor. There is no editor: sprites, tiles, sounds and music can all be authored as C# (or loaded from files when a game wants them).
- Small pixel-art projects: platformers, top-down adventures, turn-based RPGs, run & guns, at a scale of a few hundred objects per scene.
- Teams that want deterministic, testable games: every game built with it so far is played end to end by headless tests and scripted input.
MicroEngine is open source under the MIT License and in Alpha (SDK status): it works and is checked on six platforms, but its APIs may still change between 0.x versions. There is no published package or template yet: games use the engine from its public repository; NuGet packages and templates are prepared for SDK-1 (see Getting MicroEngine and the roadmap).
The four games
Four complete games are built with the engine. Together they are the evidence for what it can build today, and all four can be played as demos in a desktop browser on the demos page.
| Game | Genre | Content approach | What it exercises |
|---|---|---|---|
| Meadow Run | Side-scrolling platformer | Fully procedural: every sprite, tile, sound and song is generated in code | Tile collision with one-way platforms, player feel, power-up forms, lighting, world map, boss |
| Courtyard Key | Top-down action adventure | Hybrid: procedural world and cast plus one imported CC0 enemy | Screen-by-screen rooms, combat, items, push blocks, dialogue, dungeon, boss |
| Trail Duel | Creature-collecting, turn-based RPG | Hybrid: CC0 creature and trainer sprites, procedural world and music | Menus, turn-based battles, capture, evolution, trainers, shop, large save state |
| Neon Rift | Run & gun | External CC0 sprite sheets, tilesets, WAV effects and OGG music | File loading, streamed music, parallax, eight-way aiming, weapons, three stages |
Each game ships five achievements, saves its progress, runs headlessly in its own test project and has input scripts used for tests and screenshots. All four also build into browser packages.
Design principles
| Principle | In practice | Record |
|---|---|---|
| Code-first content, files when wanted | PixelImage, palettes, noise and Synth build assets in code; ContentFolder loads PNG, WAV, OGG and MP3 |
ADR 0002, ADR 0004, ADR 0005 |
| Scenes on a stack | Pause menus, dialogue and inventories are overlay scenes; transitions swap scenes at their midpoint | ADR 0003 |
| Plain entities, not an ECS | Small classes with Update/Draw in an EntityList<T> with deferred add and remove |
ADR 0003 |
| Actions, never keys | Games ask for "jump" or "confirm"; scripts and tests force the same actions |
Architecture |
| Fixed-step simulation | 60 updates per second, rendering once per frame; headless runs are deterministic | Architecture |
| Integrate, do not reinvent | Platforms are profiles over existing libraries (SDL 3, raylib); the core references none of them, and a host can replace a subsystem or register its own platform | ADR 0016, ADR 0017 |
| The engine keeps score, the game decides | AchievementTracker owns progress and persistence; games call Unlock/AddProgress/SetProgress |
ADR 0006 |
| Genre-neutral engine | Game rules live in games/<Name>; code moves into the engine only when it is genre-neutral or used by two games |
Contributing |
What the engine provides
- Fixed-step runner, scene stack with overlays and transitions, coroutines and tweens.
- Action-based input (keyboard and gamepad bindings) and scripted input playback.
- Procedural pixel art (
PixelImage, palettes, noise, dithering), sprite atlases, animation, particles, camera, parallax layers, a light map and a built-in pixel font. - Managed PNG and WAV loading, grid sprite-sheet slicing, streamed OGG/MP3 music.
- Tile layers, swept tile collision with one-way platforms, autotiling, plain entities.
- A retro sound synthesizer, step-sequencer music and a mixer that fades between tracks.
- Dialogue boxes, selection menus, JSON saves, achievements with banners and a list screen.
- Platforms: SDL 3 (Windows, Linux, macOS, Android, iOS), raylib (browsers, desktop alternative), a headless platform for deterministic tests; named profiles, replaceable audio and input.
- Packaging of games as native downloads, as the four demos are (Downloads).
Planned work
The roadmap lists what is planned, without dates: distributing the SDK (NuGet packages, project templates, versioned releases), validation on real devices, engine robustness and research into the mobile experience. A visual editor and 3D appear there only as a long-term vision; they are neither available nor committed.
Where to go next
| If you want to | Read |
|---|---|
| Know how the engine is distributed | Getting MicroEngine |
| Write your first game | Hello Engine walkthrough, then Making a game |
| Learn each subsystem | Engine manual |
| Look up signatures | Contracts |
| Check where it runs | Platforms and Status and limitations |
| Understand the design | Architecture |