The Nu Game Engine is a practical demonstration of research ideas applied to modern game development. It sits in the applied research zone - a hybrid of research and practical application that bridges innovative academic concepts with real-world applicability.

Nu is built on advanced concepts from declarative programming, particularly with its immediate-mode ImSim API and its model-driven MMCC API.

Nu uses F# to deliver its most cutting-edge features like gameplay undo and redo, live code reloading, and comprehensive testability. These are hallmarks of research-inspired experimentation, showing that cutting-edge theoretical ideas can simplify the traditionally convoluted world of game development.

Other game engines tend to favor established, often imperative or object-oriented paradigms that are battle-tested in commercial game development. Unlike those, Nu Game Engine bucks industry norms by adopting a functional and declarative approach that not only pushes the envelope in game engine design but also delivers a tool that’s usable in real-world environments. Its demos and even commercial projects like Omni Blade attest to this. Yet while Nu is steeped in concepts that might typically reside in academic research, it has matured into a full-fledged, production-ready game engine.

The Nu Game Engine is not merely an academic toy or a hobbyist experiment. It is a robust, battle-tested artifact that offers proof that research ideas - especially those rooted in modern programming methodologies - can be successfully harnessed to create a practical, high-quality engine. It straddles the line by being both a platform for experimentation and a tool for actual development, placing it firmly in the applied research niche rather than on the far ends of pure research.

This blend makes Nu particularly exciting for developers who are looking for innovative methods to overcome conventional game development challenges, while also desiring a tool that works today and has a real, tangible impact on production quality.

Let's expand on each of those terms –

Mature

Nu is mature and exposes multiple levels of programmability depending on your performance needs. For high-level programming, there’s the ImGui-inspired declarative ImSim API. Alternatively, there's the MVU-like declarative MMCC programming API. Below that, there's the classic Nu API where everything is done with manual world and entity transformations, with fine-grained render calls exposed directly.

There is a 2D tile map system that utilizes Tiled#, a 3D terrain system, 2D physics via Aether Physics, and 3D physics via Jolt. 2D and deferred physically-based 3D rendering are done with cross-platform OpenGL 4.6. Audio and other IO systems are handled in a cross-platform way with SDL2. There is also an asset management system via AssetGraph to make sure your game can run on memory-constrained devices such as mobile. There is a declarative special effects system called, appropriately enough, EffectSystem, as well as an efficient ParticleSystem, and a threaded 3D model animation system. On top of everything, there is a built-in WYSIWYG editor with live content and hot code reloading called Gaia which can undo and redo gameplay for advanced development and debugging scenarios.

Functional (w/ Imperative Configuration)

By default in the editor, Nu is configured to run in an immutable mode. In this mode, all of the simulation backing data encapsulated behind the World API is implemented with functional data structures that can be snapshotted and arbitrarily restored. This snapshotting is how Nu's editor, Gaia, implements its Undo and Redo operations. However, for optimal performance, Nu is configured to use mutating data structures under the hood instead when outside of the editor. Nu can be configured to run either way in both contexts, however.

2D and 3D Game Engine

Nu is not a code library. It is a game software framework. Thus, it sets up specific ways of approaching the design of 2D and 3D games. But because Nu is intended to be a broadly generic toolkit for 2D and 3D game development, it is made available via an engine source forking model rather than as a black-box NuGet library.

F#

We know what F# is, so why use it? First, because of its cross-platform nature. Nu runs on .Net, which runs on all the major platforms today. Beyond that, F# is probably the best mainstream language available for writing a cross-platform functional game engine. Unlike Clojure, F#’s static type system makes the code easier to reason about and potentially more efficient. Unlike Scala, F# offers a simple and easy-to-use semantic model. Unlike Haskell, you get an intuitive and well-tooled debugging experience, with no need to babysit effects / monads / etc. Unlike JVM languages generally, F# allows us to code and debug with Visual Studio. Finally, game developers likely have more familiarity with the .NET ecosystem than the JVM, so that leverage is at hand.

We provide a high-level API called ImSim that provides a immediate-mode style of game development similar to ImGui - but without its many restrictions. Additionally, for turn-based games, our MMCC API provides a model-driven style of game development similar to MVU and The Elm Architecture. We provide more details for ImSim Immediate Mode for Games via ImSim and MMCC Model View Update for Games via MMCC.

Take a close look at the crispness of our rendering -

Preserving rendering clarity over the pursuit of extreme photo-realism has been our implicit guiding philosophy. So far, people are really liking the results - even tho there remains much more work / features left to do! Given these good initial results, this philosophy will continue to guide our default rendering approach. We will consciously select for rendering techniques that preserve clarity as a priority over photo-realism-at-all-costs. That includes decisions around adopting rendering techniques from the ray-tracing space that, in many ways, are not yet practical for producing renders that preserve sufficient clarity on mid-tier and lower deployment targets. Simple techniques used expertly have much better results than complex techniques used mediocrely.

Additionally, we're now guaranteeing a policy of merging master to mutable branch at every release. The mutable branch is a purely imperative branch of Nu that we maintain for a couple of reasons -

1. Risk Mitigation - even in 2025, we're still waiting for the games industry to start widely adopting functional programming. I guessed that this would start happening 5-10 years ago, but of all industries, the game industry remains a particularly stubborn holdout. If it remains as such, we still have a path toward relevancy with this branch.

2. Marginal Performance Increase over Nu in Imperative Mode - you don't need to use the mutable branch to get nearly all its performance benefits! Instead, you can just flip Nu's existing Imperative switch to true, and Nu's will internally (albeit dynamically via if expressions) utilize imperative semantics! However, when shipping your game, you can eliminate all of that runtime checking by shipping with the mutable branch.

Keeping the mutable branch up to date has little cost on our end but has upsides that more than pay for it. This makes mutable Nu now an officially supported API! One thing to note, however, is that Nu currently only supports Undo and Redo in the editor when Imperative = false outside the mutable branch. At some point, we'd like to implement imperative Undo / Redo.

In this talk, Platform as a Reflection of Values, some sample values were placed on the slides with some of them highlighted according to how a given platform prioritizes them. I thought it might be useful to do something similar for Nu -

Other than my research, here's a list of the people whose work most inspired Nu Game Engine.

DEV NOTE: Nu on Windows currently uses SDL2-2.28.5-win32-x64, SDL2_image-2.8.2-win32-x64, SDL2_ttf-2.22.0-win32-x64, and SDL2_mixer-2.8.0-win32-x64.