Foster: a small C# 2D game framework over SDL3 and SDL_GPU

A thin 2D layer over SDL3 rather than a full engine

This framework describes itself in one sentence: a small cross-platform 2D-focused game framework in C#. The next sentence is the one that matters for an evaluator. The README flags the project as very much a work in progress, likely to have frequent breaking changes, to be used at one's own risk. That is a warning about the public surface, not about the code quality. Expect to write against a 0.x API where class shapes can move without a deprecation cycle. The package is published on NuGet under the name FosterFramework, and the source repository is a separate project file rather than a script or a plugin. So the scope is deliberately narrow: windowing, input, a rendering path and 2D drawing primitives, with no editor, no scene format and no asset pipeline described anywhere in the documentation.

SDL_GPU as the only rendering path

Rendering is implemented using SDL_GPU, the GPU abstraction that ships inside SDL3. This is the architectural choice with the widest consequences, because there is no second path. You can specify which graphics device to use when you run an application, so a machine with more than one adapter is a case the author thought about. Shaders are part of the contract rather than an implementation detail: shaders must follow the SDL_GPU shader resource requirements, and you must provide shaders for the resulting renderer, for example SPIR-V for Vulkan. The escape hatch is that built-in shaders for 2D rendering exist, so the shader requirement only matters if you write custom ones. The documentation does not describe a software rasteriser fallback, which means a headless build without a usable GPU device is a case the project leaves unaddressed, and CI machines usually need that answered before anything else.

XNA-style naming inherited from FNA

The API design takes a lot of inspiration from other frameworks and APIs, namely FNA, which is a reimplementation of Microsoft's XNA game stack. That lineage explains several things about how the surface reads. If you have written XNA-style C#, the naming and the shape of the object model will feel familiar rather than alien. If you have not, expect an unfamiliar vocabulary that looks legacy on paper even though the implementation is new. The project is also the second iteration of this library, and the first one is kept separately under the `NoelFB/fosterold` repository. Rebuilding rather than patching is a useful signal: the author was willing to abandon a structure that no longer worked instead of carrying compatibility forward, which is also why the version number is low.

Referencing the project from a solution or from source

There are two supported ways to consume the framework. The first is to add a reference to the NuGet package published as FosterFramework. The second is to clone the repository and reference the project file directly, which the README points at as `Foster/Framework/Foster.Framework.csproj`. The repository root holds a solution file named `Foster.slnx` and a `global.json`, though the README does not state what SDK version that file pins, so read it yourself before assuming a runtime. A separate Samples repository holds various demos and examples, and the README points to a Discussions page and a Discord server for getting involved. For a first real use, the Samples repository is the sensible starting point rather than the framework source, since it shows the intended API shape in complete, runnable form instead of as a library listing.

The contribution rule that keeps the dependency surface small

The README states that contributions are welcome, but that anything adding external dependencies or complicating the build process will not be accepted. This policy explains more of the design than any feature list. A framework that refuses new dependencies keeps its transitive surface to the .NET runtime plus SDL3, which in turn lets native binary distribution be a problem handled by the SDL project rather than by this one. The trade-off is equally plain. There is no room for a pluggable asset pipeline, no bundled physics library, no serialization format competing for inclusion, and no third-party ecosystem to lean on. If your game needs an existing open-source physics or content pipeline, you will be importing it into your game project and living with version alignment between that package and a framework surface that is still moving.

Release dates in 2026 and a permissive licence

The release history shows how quickly the surface is moving. Version v0.4.0 was published on 2026-08-21, v0.4.1 on the same day later in the evening, and v0.4.2 on 2026-08-27. Three tagged releases inside a week, all inside the same minor line, is the signature of a project iterating on its own API rather than shipping features against a stable contract. The last push to the repository was on 2026-10-21, so work continued after those releases even though no new version was cut. The licence field on the repository says MIT, so the code can be read, modified and vendored under permissive terms. The stated dependency requirements are dotnet 10.0 and C# 14, which means a current SDK rather than a long-term-support version. SDL3 itself has prebuilt binaries for various platforms through GitHub Actions, which is how the native layer is distributed.

Where this framework is the wrong choice

Several ordinary game projects should not start here. A production title with a fixed ship date cannot absorb breaking changes on a schedule the author sets, and the README asks you to accept that risk explicitly. A 3D project is out of scope, since the framework describes itself as 2D-focused and its rendering story is built around 2D shaders. A team that wants a visual editor, a scene format, an asset pipeline or a console export pipeline will find none of that described in the documentation, and the contribution policy closes the door on bringing it in from outside. Set against that, the FNA lineage is the honest alternative to weigh: it is a mature reimplementation of an established API, so a project that already speaks XNA-style C# has a lower-friction path there and a larger body of existing knowledge. The counter-argument is scope and transparency, since the whole framework is small enough to hold in your head and change yourself.

Editorial conclusion

Adopt this framework if you are writing a 2D game in C# and want a thin, permissive API over SDL3 that you can read end to end, and plan to patch it yourself. Do not adopt it for a title with a fixed ship date, because the README warns of frequent breaking changes and the version line is still 0.4.x. Verify first that your runtime satisfies the dotnet 10.0 and C# 14 requirements, then read the built-in shader set and the graphics device selection in the SDL_GPU path before writing a custom renderer.

Frequently asked questions

Official sources

1. FosterFramework/Foster on GitHub
2. Issues
3. License: MIT
4. README
5. Releases