Innovate As You Want. A plugin-oriented game engine written in C#.
Build your game's rendering models, gameplay systems, and Editor tools on a shared foundation. InnoEngine provides backend-neutral mechanisms, explicit platform composition, and a common asset and plugin workflow.
Get started · Wiki · Architecture · Extend the engine
Active development. APIs and project data evolve together. See current validation and limitations before relying on a product path.
Requirements: Git, the native x64/ARM64 .NET SDK 10.0.402 (C# 14), and your host's C++ toolchain. Windows x64 requires MSVC C++ desktop tools, Windows SDK, and C++ CMake tools. macOS ARM64 requires Xcode command line tools and CMake on PATH. Host setup and first launch.
git clone --branch dotnet10 --recurse-submodules https://github.com/Wolfiora/InnoEngine.git
cd InnoEngineOpen InnoEngine.sln in a .NET 10-capable Rider or Visual Studio 2026. Choose one of two startup projects:
| Start | What it does |
|---|---|
| InnoEngine.Editor | Builds the current host Editor through project references and opens a project-folder picker. |
| InnoEngine.Build | Prepares host Editor support by default; editor builds the complete Editor. Successful root builds perform bounded cache maintenance; full cleaning is explicit. |
The same commands work from a terminal:
dotnet run --project "entry/InnoEngine.Editor/InnoEngine.Editor.csproj"Use the branch containing these changes; the command above selects dotnet10. BGCS 4.1.2 is restored from exact pinned NuGet packages, and third-party sources are submodules under extern/. The first build needs network access and prepares native support and bindings before opening a window. Subsequent builds compile changed C# dependencies and reuse valid support caches. No prior Build run, shared .run file, or Browser workload is required for a desktop Editor. Game scripts and assets use import and reload; game exports prepare their own Player support packs.
Have a project already? Pass its directory after --. To try FlappyBird, clone InnoEngine.Samples separately and select its FlappyBird folder.
Startup, advanced commands, and game exports → · Current acceptance
NuGet dependencies use standard project PackageReference declarations and SDK restore. Resolved assets remain in the selected intermediate output directory. See dependency updates and CI.
| Target | Products | Managed deployment |
|---|---|---|
| Windows x64 | Editor, Player | CoreCLR, NativeAOT |
| macOS ARM64 | Editor, Player | CoreCLR, NativeAOT |
| Browser Wasm32 / WebGL 2 | Player | Mono Wasm, Mono Wasm AOT |
Windows x64 acceptance covers the Editor and published players separately. Browser Mono and AOT products have passed bounded runtime checks with the official BGCS extension. macOS requires a native ARM64 host. See the current results and remaining checks. Visual, DPI, input, audio, and long-running device checks are recorded separately.
- Shared mechanisms. Identity, serialization, events, assets, scenes, rendering, audio, input, storage, and execution lifecycles.
- Replaceable implementations. SDL3, BGFX, MiniAudio, FreeType/HarfBuzz, RmlUi, and ImGui live in reusable backends. Platform integrations connect actual SDK differences.
- Explicit ownership. Sessions own resources; candidate publication, Missing recovery, and verified generation retirement support hot reload.
- Plugins shape the engine. Rendering models, components, importers, and Editor tools share the same discovery and authoring infrastructure.
Author under Assets/; install .iplugin packages under Plugins/. Installed plugin content enters the existing asset pipeline as read-only sources. Plugin workflow →
entry/ Two development launchers and host dispatch
src/ Shared foundation, content, services, runtime, and product hosting
backends/ Reusable adapters, native bindings, and component build recipes
platforms/ System/SDK integration, product entry points, and packaging
build/ Common pipelines, toolchains, and explicit distribution composition
tests/ Domain and cross-component contract tests
extern/ Third-party source dependencies
docs/ Architecture, workflows, and API Wiki
New platforms select backends and supply the required integrations. New backends implement domain contracts and join the explicit product/build composition. Extension guide →
| Start here | Find |
|---|---|
| API Wiki | Project pages and public contracts |
| Scripting | Game code and extension APIs |
| Build | CLI, native toolchains, and game exports |
| Architecture | Layers, dependencies, and ownership |
Apache License 2.0. Third-party dependencies retain their respective licenses.
Native ABI, SDK, link settings and deployment layout are owned by platform integrations. Shared backends keep one common binding definition. Native build ownership and file tree · Cache ownership and maintenance.