What is Nu and What it Can Do - bryanedds/Nu GitHub Wiki

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 functional and declarative programming, particularly with its declarative Model-Message-Command-Content (MMCC) API and ImSim API. It uses of F# to deliver its most cutting edge features like gameplay undo and redo, live code reloading, 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 approaches 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 a 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.

Mature, Functional, 2D and 3D Game Engine written in F#

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 MVU-like declarative MMCC programming API. Alternatively, there's the ImGui-inspired declarative ImSim 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.1. 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 as well as Mono for portability to Linux and other platforms. 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 a well-tooled debugging experience, with no need 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.

Model-View-Update via MMCC

I have said many times that Model-View-Update (or MVU) is the 'killer app' of functional programming. Until MVU came along, most arguments about the benefits of functional programming resided primarily in the space of the theoretical. But when Elm introduced the world to MVU with its incredibly clean authoring form factor, the space of discussion changed forever.

With Nu's generalization of MVU via MMCC (Model-Message-Command-Content), it is the first and still only practical game engine positioned to bring the killer benefits of this declarative development form factor to game developers.

Immediate Mode Programming via ImSim

While MMCC might be better in a larger engineering team environment given its total game logic and simulation separation, smaller teams and individuals may prefer the new alternate high-level API called ImSim (formerly called ImNui). It provides for a more inline, procedural style of game development similar to ImGui but without its restrictions.

'Clarity is King' Rendering Philosophy

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 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 resolves that preserve sufficient clarity on mid-tier and lower deployment targets.

Nu's Value Systems

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 -

Research Inspiration

Other than my own 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.