Prowl: a Unity-like C# engine in 1.0 preview, with the runtime split out

What 1.0-preview means, and why there is no migration path

Prowl is an open source, MIT licensed game engine developed in pure C# in the latest .NET, and it aims to provide a seamless transition for developers familiar with Unity by maintaining a similar API while also following KISS and staying as small and customizable as possible. The ideal stated is that Unity projects can port over with as little resistance as possible.

That ambition is the whole pitch, and the feature list backs it up in detail. There is a GameObject and Component architecture, a Unity-like Editor and Scripting API, C# scripting with .NET 10, a Scene View, Hierarchy, Inspector, Project Browser, Console and Game View in the editor, and custom component editors, property editors and scene view editors, with transform gizmos for move, rotate and scale, an undo and redo system, dockable and resizable panels with layout persistence, drag and drop for assets, game objects and components, multi-select and search filtering in the editor panels, asset thumbnail generation and 3D previews, animation curve and gradient editors, a rebindable shortcut and hotkey system, editor theming with customizable colour palettes and sizing, playtest directly in the editor, hot-reloading scripts, and managed and native plugins with assembly definitions.

The status is where the caution goes. Prowl is currently in 1.0-preview, following a complete rewrite of the editor, renderer, physics, audio and UI. Projects made with older versions of Prowl are not compatible with 1.0-preview, there is no migration path. Until the final 1.0 release, further breaking changes are still possible.

That is three separate statements and each one matters. A complete rewrite of the editor, renderer, physics, audio and UI is not an incremental change, it is a new engine with the old name. No migration path means you cannot port an existing project by upgrading, you have to port it by hand. And further breaking changes are possible means the API you write today may not compile in a month.

The release history reflects a project in that phase. The three most recent tags are v1.0-preview-4 on 2026-08-30, v1.0-preview-3 on 2026-08-07 and v1.0-preview-2 on 2026-07-15, so the preview line is producing releases every few weeks. The last push was on 2026-10-15 and the repository is not archived.

The runtime and editor split, and the Anthology libraries

The most consequential design decision in the feature list is one line: Prowl.Runtime works fully standalone from the Editor, you reference it directly and ship a game with zero editor dependency.

That is not a small architectural point. It means the runtime assembly is the thing your game links against and the editor is a tool that happens to use the same runtime. The consequences are real ones. Your exported build does not carry the editor, so its size and its dependency set are smaller. The runtime can be referenced from a server, a tool or a test harness that has no editor in the picture at all. And the boundary between what ships and what is development tooling is a real one rather than a convention.

The repository layout shows the split. There is Prowl.Runtime/ and Prowl.Editor/, with Prowl.Runtime.Test/ and Prowl.Editor.Test/ as their test projects, and the solution file is Prowl.slnx, the newer XML solution format. The separation is clean at the directory level, and the two test projects being separate confirms the two halves are separately consumable.

Almost everything the engine needs comes from a collection of libraries under a single organisation, ProwlEngine, hosted in a repository called Anthology. The feature list names them and their roles.

Paper is the custom immediate mode UI, and the editor is built on top of Origami, also from Anthology. Quill provides vector graphics and text rendering. Prowl.Echo handles serialization. Prowl.Vector provides the math, with matrices as Float4x4, quaternions, Transform2D, and shapes including AABB, Bounds, Frustum, Cone, Ray, Plane, LineSegment and Rect. Prowl.Unwrapper does UV unwrapping, and Prowl.Photonic is the progressive lightmapper.

So the engine is more a set of focused libraries around a runtime and an editor than a monolith, and the same author owns the whole stack. That is a coherent thing for a project to be, and it has an obvious advantage: the editor can be written against the same UI library the runtime uses, which is why the editor is described as built on top of Origami rather than as a separate application with its own widget set.

The other top level directories are conventional. Design/ is presumably design notes. External/ is vendored third party code, and Libraries/ is likely the native side, given that the platform topic tags include Vulkan, Metal, OpenGL and DirectX. Players/ is the platform player implementations, Prowl.Cli/ is the command line tool, Prowl.Analyzers/ is a Roslyn analyzer project, and Samples/Runtime/ holds the sample code. There is a Directory.Build.props for shared MSBuild properties, a .editorconfig, and a Run.md.

The systems a game actually needs, and how complete they are

The feature list is long, and the way to read it is by subsystem, because the depth in each one tells you where the engine has invested.

Physics uses Jitter Physics 2, and the list of colliders is comprehensive: box, sphere, capsule, cylinder, cone, convex hull, mesh, model and terrain. There is a raycast-based wheel collider for vehicles with suspension and slip-based grip, and a long list of joints and constraints including ball socket, hinge, hinge angle, fixed angle, cone limit, distance limit, twist angle, prismatic, universal, point on line, point on plane, angular motor and linear motor. There is a character controller, trigger volumes in box, sphere and capsule shapes, collision layers and filtering through LayerMask, and a raycasting and shape query API. That is a physics feature set a real game would need, not a demo.

Audio is via MiniAudio, with spatial 3D audio including attenuation and Doppler, support for WAV, MP3, OGG and FLAC, and an effect chain of delay, distortion, biquad filter, reverb and phaser plus a custom IAudioEffect interface. A custom effect interface is the detail that matters, because it is what lets a project add its own processing rather than being limited to the five built in.

The input system is described in Unity terms and is one of the more complete parts of the list. There is an input action system with composites and processors, .inputactions assets with a dedicated editor, action phases covering disabled, started, performed and cancelled, and composite bindings such as WASD mapping to a Float2, D-pad and others for keyboard, mouse and gamepad. That is the Unity Input System model, implemented in the engine.

The UI is GameObject-based including world space UI, with RectTransform-driven layout, buttons, sliders, layout groups and drag and drop event handlers. There is also Prowl Actions, described as persistent, inspector-configurable event callbacks, which is a different model from the GameObject one and appears to be the engine's own answer to the question of how a button should invoke something.

The scene system has fog and ambient lighting, and there are prefabs with nested prefab support, with apply, revert, break instance and override tracking. The build system produces standalone applications with packed asset files in a .prowlpak format, exports only used assets, has per-platform build profiles, and supports Windows, Mac and Linux.

And the quality signal: unit tested, 450+ tests across the runtime and the editor, with the two test projects visible in the repository listing.

Where the Unity shape actually shows up in the API

The stated goal is that Unity projects can port over with as little resistance as possible, and that goal shows up in specific, checkable places rather than as a general claim.

The component model is the obvious one. A GameObject and Component architecture with a Transform, and the editor panels named after Unity's, so a scene view, a hierarchy, an inspector and a project browser behave the way a Unity user expects. Inside the panels there are Unity-shaped operations: transform gizmos for move, rotate and scale, an undo and redo system, and drag and drop for assets, game objects and components, with multi-select and search filtering in the editor panels.

Some of it is a naming coincidence, some of it is a deliberate port. The input system is the clearest case, because Unity's newer Input System model is distinctive: an action map with bindings, action phases covering disabled, started, performed and cancelled, and composite bindings that turn a WASD into a single Float2 value. A project written against Unity's Input System will find the same concepts here, and the .inputactions asset format with a dedicated editor means the asset files themselves are recognisable.

The UI side follows the same pattern. RectTransform-driven layout, buttons, sliders, layout groups and drag and drop event handlers are Unity's UI vocabulary, and world space UI is explicitly supported, so a 3D in-world interface works the way it does in Unity.

Then there is the convention that will not port directly. Prowl Actions are described as persistent, inspector-configurable event callbacks, which is a different model from the GameObject one, so a Unity project that wired every button to a component method will need rethinking, and that is the kind of difference that the smooth port claim quietly contains.

The build pipeline is the other place where the shapes differ. Unity's asset pipeline and its .prowlpak format are not compatible, and Prowl exports only used assets with per-platform build profiles, so the shipped build will be leaner but the project files are not Unity project files. The reality is that the API is designed to be familiar, not that the projects are interchangeable, and anyone planning an actual port should assume they will be editing project settings, replacing assets and rewriting the parts of the code that touch Unity specific asset conventions.

Graphics: a forward pipeline with a thin G-buffer and several backends

The graphics section is where the rendering decisions are visible, and it starts with a constraint that is unusual to see in an engine built to be small.

The OpenGL backend comes via Silk.NET, and the topic tags name vulkan, metal, opengl and directx, so the intent is a multi backend renderer. There is a dedicated render thread, and an extensible render pipeline with custom pipelines supported.

The default path is a forward-lit pipeline with a thin G-buffer pre-pass, and the contents of that G-buffer are listed: depth, normals, motion, roughness and metallic. Calling it thin is accurate and it is the interesting part of the design. A full deferred renderer needs a position buffer, several render targets and a lighting pass that reads them, which is a lot of bandwidth and a lot of memory. A thin G-buffer with a forward lighting pass instead keeps most of the per-object state in a small set of targets and lights the scene forward, which is a reasonable trade for a forward-leaning engine that wants to be small and to run on modest hardware.

The G-buffer contents also tell you what the renderer can do. Normals are there, so there is normal mapping. Roughness and metallic are there, so the materials are metallic-roughness rather than specular-gloss. Motion is there, so there is motion vectors, which is what temporal anti-aliasing and any temporal upscaling need. The feature list confirms TAA is supported, and there is also a simple upscaling ability.

Lighting is progressive rather than baked only. There is a progressive lightmapper via Prowl.Photonic, baked light probes, and a radiance cache. The list of graphics features is cut off partway through, so there is more beyond it, and the earlier mention of a forward-lit pipeline with the thin G-buffer pre-pass sits alongside a Custom Render Pipeline feature further down the same list.

The rest of the rendering features that are visible are the standard post-processing set: bloom, depth of field, auto exposure, TAA and tonemapping, plus chromatic aberration, saturation and coloured vignette. And there is a texture concern worth noting, because a modern engine that supports bindless or virtual texturing changes the memory model for assets, and the topic tags include jitter, which is the temporal offset technique used to sample many sub-pixel positions across frames, and that is what you need for either.

The samples directory at the top level, with Samples/Runtime/, is where a new user would look to see what a Prowl project looks like in practice, and it is the natural companion to the editor screenshots in the README.

Editorial conclusion

Prowl fits a C# team that wants Unity-shaped tooling and an MIT licensed engine they can read and modify, and that can live with preview software and its breaking changes. It is the wrong choice if you need a stable API, since the project states there is no migration path and further breaking changes are possible before 1.0, and the wrong choice if you need the breadth of a mature engine's asset store and third party ecosystem. Before adopting, read the licensing terms of the components it uses, since several are separate projects by the same author, and check the platform and graphics backend list against your target, because the feature list is where the actual coverage is described.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. ProwlEngine/Prowl on GitHub
4. README
5. Releases