A Vision for Nu 2.

[bryanedds]

I've recently had a chance to look at GameMaker 2 in action and its design tooling seems tremendous. I think that Nu 2 (tentatively titled) should go from being just a programmer's engine to something much more designer-centric like GameMaker 2. This includes treating code as collections of assets instead of as a monolithic plug-in (as described #252) and having highly interactive Prefabs (as in #186).

Ideally, Nu 2 would want to be a highly productive design studio like GameMaker 2. This is a lot of time to develop, however, and might impact Nu's structure in some non-trivial ways. However, Nu's current design is compatible with this vision, so it's really just a matter of extending the engine and writing new tooling can reach this end goal.

Perhaps on the day some funding can be achieved, Nu's next stage of evolution can get under way! Until then, we'll just improve Nu in the context of being a programmer's engine in less impactful ways.

[dallinbeutler]

I'm quite interested in this vision you share! I was curious as to what you thought about the Aardvark team/community and what they're doing. They're more aimed at performant visualization than realtime games, but they promote some interesting ideas, like converting the ELM model to something more performant via a domain compiler in Aardvark.Media. They also leverage skia and cef to provide robust UI option. and in Aardvark.Rendering they use F# for writing shaders, as well as making a dynamic flexible scene graph. I was just curious as to what you thought of the platform, and whether or not some of those ideas translate to the Nu vision? and be able to leverage that GMS2 simplicity? Anyways, keep up the good work!

[bryanedds]

This is an interesting project :)

Thank you for your e-mail and let me know if there's anything else I make look at in more detail!

• Bryan

[bryanedds]

Oh, one more thing -

One thing in particular that Nu MIGHT be able to leverage is their incremental renderer - https://www.vrvis.at/publications/pdfs/PB-VRVis-2015-015.pdf

Hopefully their system is sufficiently modular that I can use it without too much modification once I decided to go 3D with Nu.

Cheers!

On Tue, Oct 8, 2019 at 12:19 PM Bryan Edds bryanedds@gmail.com wrote:

This is an interesting project :)

There doesn't seem to be a lot of common ground between our two projects in practice. Nu's Elmish implementation is already quite efficient because it's based on a more low-level approach called iFRP - https://github.com/bryanedds/Nu/blob/master/Nu/Nu.Documentation/Iterative%20Functional%20Reactive%20Programming%20with%20the%20Nu%20Game%20Engine.pdf. And when we want to reach more toward AAA performance, we'll have be implementing a data-oriented 'ECS' model like the one I prototyped in C++ here - https://github.com/bryanedds/ax/blob/master/src/hpp/ax/impl/system.hpp

I think the reason their initial Elmish implementation was slow was because they use a dependency graph to propagate changes (they call it Adaptive Functional Programming - https://www.cs.cmu.edu/~blelloch/papers/popl02.pdf). This fundamental approach might be right for their domain, but I think it's inappropriate for games. That might be why they had to implement an additional compilation step to get their stuff moving at an acceptable speed whereas Nu's Elmish performance is acceptable out of the box.

iFRP and Adaptive Functional Programming are two different paradigms, so I think that we ultimately are heading down two very different roads. Will be great to watch them progress, however, and I'll continue to see what ideas of their I can steal - I mean, borrow :)

Thank you for your e-mail and let me know if there's anything else I make look at in more detail!

• Bryan

On Tue, Oct 8, 2019 at 10:04 AM Dallin Beutler notifications@github.com wrote:

I'm quite interested in this vision you share! I was curious as to what you thought about the Aardvark https://aardvarkians.com/ team/community and what they're doing. They're more aimed at performant visualization than realtime games, but they promote some interesting ideas, like converting the ELM model to something more performant via a domain compiler in Aardvark.Media. They also leverage skia and cef to provide robust UI option. and in Aardvark.Rendering they use F# for writing shaders, as well as making a dynamic flexible scene graph. I was just curious as to what you thought of the platform, and whether or not some of those ideas translate to the Nu vision? and be able to leverage that GMS2 simplicity? Anyways, keep up the good work!

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/bryanedds/Nu/issues/255?email_source=notifications&email_token=AAMM3WH5CSK3KIQ534OR4T3QNSHO3A5CNFSM4IFN2HSKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEAUJCVY#issuecomment-539529559, or mute the thread https://github.com/notifications/unsubscribe-auth/AAMM3WCUCSRISE3R3EYKNVLQNSHO3ANCNFSM4IFN2HSA .

[bryanedds]

So, after doing some development with the new Elmish API, I realize there are some performance limitations. I was initially hoping to get a good 1000 live Elmish entities bound and simultaneously transforming, but it's looking not too promising. While I haven't yet written a proper test case like Metrics, I think we're going to fall a bit short here. For bound non-ticking entities, the performance seems to be fine due to many optimizations along the way.

The problem seems to be Nu's reliance on its event system to drive the Elmish bindings. Despite numerous optimizations, the event system is slow in contrast to something like FSharp.Data.Adaptive.

One possible alternative is to use something like FSharp.Data.Adaptive for all backing fields and have a separate type of binding that doesn't use the event system.

However, this may contradict the other idea we have of using Data-Oriented Design to speed up other programming scenarios. There will be no benefit to using data-orientated design if all of the backing fields use adaptive abstractions which are themselves reference types.

Initially, when I started this thread, I thought it was safe to presume that the future of Nu will be driven by tooling. But on further reflection, it will more likely be driven by performance concerns - which will then drive the tooling design decisions.

[bryanedds]

As it turns out, I can get about 800 with multithreading in the latest Metrics program.

Looks like we're just one more decent optimization away from hitting 1000!

Let's find it!

[bryanedds]

Now 850.

Getting there!

[dallinbeutler]

I've been watching the conversation you've been having over at the Aardvark discord channel. It's a bit over my head, but enjoyable to follow nevertheless! I definitely want to see what marriage between ECS, MVU, and Adaptive would look like and perform. Best of luck with whatever you settle on!

[bryanedds]

Hey bud, good to hear from you!

Ya, it's been a multi-day convo and I'm learning a lot about their alternative approaches. I think I've somewhat settled on the following conclusions -

Nu, as it is, is definitely adequately performant for 2D games. It has certainly exceeded my goals for usability. But in order to get performance at the scale needed for modern 3D and AAA game, we'd have to formulate something rather different. Quoting myself from the Aardvark convo -

"I'm starting to think a more appropriate design for AAA games is to have a separation between a scene graph and the MVU similar to how you (Aardvark) guys do it, and have the ECS exist purely on the scene graph side.

"The scene graph side will only allow for 'dumber' (less sophisticated) types of programmability such as for which ECS is great.

"The sophisticated programmability will be on the MVU side and then propagated to the ECS-based scene graph.

"I think that's likely the only structure that would give us the best of both worlds - a two tiered API with one for ECS programming at the scene graph level and one for MVU programming at the top-level. However, that approach is not compatible with Nu's design, so something new would have to be developed."

[dallinbeutler]

Definitely an interesting problem! Not sure where exactly to draw the line on what is MVU vs what is ECS. I dream of a way tag types and have the compiler automatically shove them into an ECS efficient structure/execution loop, similar to how Aardvark/Adaptify transform their MVU to mutable tree. So I'm just curious, are you planning on making/maintaining two different versions of Nu? or still researching options?

[bryanedds]

If I find resources to do this more performance-centric engine, I'm not sure if it can be derived from Nu. Nu was built on a foundation to support maximal usability. This new idea would be built on an opposing foundation of maximal scalability. They would both offer an Elmish programming model, but I think there would be some non-trivial usability compromises to come out of this other project. I think the usability test would be a port of OmniBlade to the new system to see how much expressiveness is preserved in the translation.

So I don't know if you could call it another version of Nu as it might be sufficiently different. This is still very early research phase, so it's hard to say for sure. I'd love to just be able to take Nu's API and retrofit this new foundation underneath it, but I don't think it's likely possible. Nu, however, works well now, performs great for 2D games, and so as a product, it stands on its own into the future - meeting its initial goal of proving that, yes, functional programming does work for games.

[bryanedds]

Due to the introduction of Elm / MVU programming layer and the new ECS programming API, I think the original vision statement here is too far afield from what Nu is becoming in practice. Also, Aardvark, while an interesting technology, is too orthogonal to really be relevant to what Nu is doing. For those reasons, I'll close this discussion.