An introduction to Data Oriented Design with Rust

(Erlend Sogge Heggen) #1

How does this match up with the Amethyst definition of Data Oriented Design?

(Nathan) #2

The blog post examines 4 comparisons:

  • Struct of arrays vs. array of structs
  • The cost of branching inside a hot loop
  • Linked List vs. Vector iteration
  • The cost of dynamic dispatch vs. monomorphisation

The author’s conclusions for the first three items roughly translates to “use an ECS – it’s faster”.

The conclusion for the fourth is “use monomorphisation, it’s faster”. That means do things like Vec<T> instead of Vec<Box<dyn T>>.

Amethyst obviously uses an ECS and monomorphisation, so the blog post fits in with that. Further, I would guess Amethyst would include hotloading and using external files for configs and prefabs and shaders in its idea of data-oriented design, but I can’t find any authoritative source of what data-oriented design specifically means for Amethyst, so :man_shrugging:

(Zicklag) #3

I think Data Oriented Design is a somewhat general term. To me it seems that Amethyst takes it as a pattern of “modify the data to control the world” kind of approach. That’s just my impression. So, like, instead of using “Objects” and calling methods on those objects to do things like play a sound, you would create data in the world that tells another system that you want a particular sound to be playing.

It’s kind of like the difference between declarative and imperative, don’t tell me what to do, tell me what you want.

There’s my vague thoughts. :slight_smile:

(Erlend Sogge Heggen) #4

Exactly. It has never been clearly determined in any formal document, but it really ought to be, seeing as our tag line is “Data-driven game engine written in Rust”.

I’m hoping this topic can be a first step towards such a document.