Introduce a little FrameGraph - where data-oriented meets code-driven

I personally like the Dots very much. I believe it is the next generation Gameplay framework with high scalability.
But, after learning Dots for a while. I feel like the whole framework is missing something at higher level - A framework can be divided into two parts and one part is missing:

  • Memory Model (Object Model) - ECS, the benefits have been well discussed.
  • Coding Framework - ???(maybe System?)

And here I’d like to discuss my own views.
As far as I know, these’s already a JobComponentSystem whitch partly automates Job management, but this maybe not enough, I’d like to take one step furthur by build a new abstract layer : PlayGraph, whitch contains several concepts:

  • Resource : logical data resource
  • Job : data processor, with explict input and output
  • Graph : one or more Jobs and Resources connected together, and the Graph of full frame is called FrameGraph

To simplify the idea, this explanation is centered on a simpile visualized FrameGraph example.(the colored nodes represent Component, Pass and Transient Buffer)


The actual code flow is divided into three phases:

  • Setup - user code, setup the Graph
  • Compile - build the Graph
  • Execute - run the Graph

User code is divided into two parts:

  • Job - independent data processor, hidden in CalculateMove
  • Setup - declare transient Resources, connect Jobs, setup the Graph, every function in the picture is considerd as setup function.And it’s just simple procedural programming.

After Setup phase finished, let’s go to Compile, through the full knowlege of frame FrameGraph provided, we can achive a good deal of features:

  • Automaticly, safely parallel the code (DoMove and DoPlaySound)

  • Automatic transient resouce lifetime (newPos will automaticly release after DoMove finished.

  • High compatibility, with procedure-oriented code, with visual script and with visual debugging.

  • High scalability, by attaching meta info may automaticly generate netcode.

  • High dynamic, switch feature level at runtime, hotreload Job at runtime.

  • Etc.

As a summary, this is a DSL-like solution, one more abstract layer make life easier.
And this is a generic idea that can apply to not only gameplay but also rendering. for example, implementing RenderGraph with SRP will leads us to FrostBite Engine.

And, that’s all, look forward to your opinions !

3 Likes

Cool Stuff

The only addition from me is: FrameGraph must be not only like Visual Scripting but more like profiler viewer of actual frame. For any project and code :slight_smile:

1 Like

Yes that is a very interesting concept indeed. The ecs framework is going to allow for so many cool visualisation and generation tools. Real game changer for Unity. Oop is dead. Long live dod. :slight_smile:

1 Like

That’s it, actually a generic idea with pure function applying to any language.I’d like to say it’s more like a inline DSL(domain special language) or a Runtime CodeGen Framework.

1 Like

This is veray cool.

1 Like

No one???