Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

An Introduction to Data Oriented Design with Rust

jamesmcm.github.io

Post reply on HN
Print view View original

131–140 of 161 posts

Re: An Introduction to Data Oriented Design with Rust

#131

Post by meheleventyone »

square_usual wrote: post #128
Hammershaft wrote: post #84

Earlier quoted context omitted.

That is changing over time as post launch support grows and some games shift to games as a service

Are the "games as a service" games adding significant code after launch? I think most of the performance critical stuff is in the engine and core game loops. Content packs and seasons aren't likely to change those core bits, and instead be more assets and scripting intensive.

Yes they do quite often. A certain amount of maintainance (bugfixing and optimisation) is required but also you are improving core systems to enable new capabilities and increase other developers productivity.

Re: An Introduction to Data Oriented Design with Rust

#132

Post by pjmlp »

munificent wrote: post #112
lukebitts wrote: post #110

Earlier quoted context omitted.

Most of what I see about ECS is how much easier it is to have dynamic behaviors without inheritance, and it is, so I don’t see why it would be bad for newcomers to use it or to have an ecs lib written in js.

> how much easier it is to have dynamic behaviors without inheritance I think you're getting at the idea that instead of having objects differ in their behavior by overriding methods, you have them differ by having fields bound to objects that implement different behavior. Assuming I understand you right, that's an excellent insight, but it's just the classic principle: Favor object composition over class inheritance…

Not only that, it is incredible how it gets trumped as a new idea, when stuff like COM, Objective-C protocols and plenty of other component based architectures were already a subject in OOP related papers during the late 90's.

But that is how cargo cult usually goes.

Re: An Introduction to Data Oriented Design with Rust

#133

Post by pjmlp »

lukebitts wrote: post #113
munificent wrote: post #112

Earlier quoted context omitted.

> how much easier it is to have dynamic behaviors without inheritance I think you're getting at the idea that instead of having objects differ in their behavior by overriding methods, you have them differ by having fields bound to objects that implement different behavior. Assuming I understand you right, that's an excellent insight, but it's just the classic principle: Favor object composition over class inheritance…

> I think you're getting at the idea that instead of having objects differ in their behavior by overriding methods, you have them differ by having fields bound to objects that implement different behavior. I guess I'm more getting at the idea of changing the game design at any point by adding or removing components, a way to make it easier for devs to cope with changing requirements (and they are always changing ofc)…

Just like VBX, COM, SOM and Obj-C Protocols/Categories based architectures, now that is something incredibly new.

Re: An Introduction to Data Oriented Design with Rust

#134

Post by Skeime »

dragontamer wrote: post #69
Jtsummers wrote: post #60

Earlier quoted context omitted.

So your OOP version creates many layers which impedes understanding and extension as well. DRY is also not a law which must always be followed. You often don't even know when you're repeating yourself until you do, and the first time you see a repetition is not when you should eliminate it (in most cases). You often see people reference the rule of three here. The first repetition should make you pay attention. The s…

If you don't care about DRY in this case, that's fine. There's more than one problem with your proposed DOD solution. Your proposed solution violates the open-closed principle. Which means you have to modify "old working code" to get anything done. If your "solutions" to fixing code issues is "rewrite and extend the old code to cover the new case", then it becomes impossible to build libraries. ---------- Lets say Ap…

> Your solution forces you to rewrite Point2D, which therefore creates a change in ApplicationFoo.

I don’t see how this is the case. You don’t change Point2D at all, you simply add a second type Point3D. ApplicationFoo can happily continue to use Point2D from your library while you use Point3D.

I think the example of Point2D and Point3D is not very well chosen. Your proposed solution of Point3D = { xy : Point2D, z : Float } is also leads to lots of duplication in the sense that (for example) to add two of these points you would have to do

    { xy = add2D(xy1, xy2), z = z1 + z2 }
where the computation of `z` is a copy of the computations of `x` and `y` in Point2D. So should you detect an error in Point2D you might still have to manually port it to Point3D.

For more complicated operations on points, the maths is mostly completely different in 2D and 3D (the same concepts might not even make sense, especially if you don’t generalize to n dimension right away), so sharing of code between the two points seems difficult.

The main problem with this solution, I think, is that you picked one specific projection from 3D space to 2D space. It might line up with a projection that is relevant to your domain but it probably won’t. So if you use inheritance and call a function requiring a Point2D with one of your Point3D’s you secretly project the point to the xy-plane which seems like something that should be explicit in the code.

Re: An Introduction to Data Oriented Design with Rust

#135

Post by meheleventyone »

setr wrote: post #115
cogman10 wrote: post #78

Earlier quoted context omitted.

From what I've seen in DOD systems, there are generally common structures that hold data for the entire application. The entire application has to know about these structures in order to function. Take ECS [1] as an example. In order to create a new entity on the system you might need to talk to a location component, a health component, a velocity component all to register a brand new entity on the system. Now, you m…

I don't know about DOD in general, but something seems fundamentally wrong with your understanding of ECS -- it conflicts with almost all of the reading I've done on it so far (though I can't say much about it in practice) > But you need to make sure as you are talking to each of the component you are doing the right thing. I'm not clear on "doing the right thing". If you're looking at eg specs, at creation-time the…

Entities aren’t coupled because they exist as a concept one level higher. Similarly in the GameObject and MonoBehavior model from Unity the GameObject isn’t much more concrete than an ID since it’s really just a container.

The trouble ECS can get into is where you want a set of components to relate to an Entity but don’t want one or more of the Systems that update that set to run. You end up with more complex System definitions that need to exclude Entities based on extra Component criteria. It gets quite messy to work out looking at the Components that make up an Entity what Systems will run on it.

Re: An Introduction to Data Oriented Design with Rust

#136

Post by HelloNurse »

Rusky wrote: post #61
dragontamer wrote: post #47

Earlier quoted context omitted.

Lets say you have "struct Point {int x; int y;};", and all things are fine and dandy. You write your OOP as such (or your DOD version), and things are going great. Suddenly, you want "struct Point3D {int x; int y; int z;}". How would you change the code? In OOP, maybe you'd compose a Point3D as such: struct Point3D { Point xy; int z; }; You can now "capture" all of the Point xy; functionality, and extended it to a 3r…

DOD has simple solutions for this, too. A popular one is to group your entities by "archetype"- you have two arrays of Point2Ds, one for those without a Z coordinate and one for those with a Z coordinate. Now if you want all Point2Ds, you loop over both arrays; if you want all Point3Ds, you just loop over one. (This generalizes cleanly to larger numbers of "components.") In some ways, this is actually quite a bit eas…

Excuse me? If it's called Point2D, it must have two coordinates. The type should be called Point and it should have an arbitrary number of coordinates (which seems a bit silly, since a Point2D and a Point3D are different types, as are points and vectors that have exactly the same representation)

Re: An Introduction to Data Oriented Design with Rust

#137

Post by barrkel »

munificent wrote: post #109
barrkel wrote: post #99

Earlier quoted context omitted.

I wouldn't dismiss the JS ECS frameworks without measurement. Polymorphism has costs, and while dynamic languages work hard to remove them, they still work best when they're able to monomorphize the call site, because that enables inlining without combinatoric explosion from chained polymorphic calls. Having a single type in your array means field accesses, method calls etc. have the potential to be monomorphized. Th…

> I wouldn't dismiss the JS ECS frameworks without measurement. I think the burden of proof is on the part of JS ECS frameworks to show they do have better performance by virtue of DoD and, if so, why. JS engine programmers have been optimizing object-oriented code for literally forty years, all the way back to when they were making Smalltalk VMs. If somehow a couple of folks hacking on ECS frameworks have managed to…

Modern JS engines won't use a hash table for the object state, they'll use a hidden class, and member accesses will be fixed offset indirect loads guarded by a type check. Initialize your objects carefully in a deterministic order, and I'd expect you can control field order and adjacency.

I'd expect the wins from reworking your JS so that your target JS engine lays out data out better would often be larger than the wins in C++, simply because the worst case is so bad.

I'd add a third option to your pair: iterating over several arrays of properties - especially numeric properties - rather than an array of objects which each have numeric properties. That can get you substantial wins in Java, never mind JS.

Re: An Introduction to Data Oriented Design with Rust

#138

Post by pjmlp »

FullyFunctional wrote: post #101
meheleventyone wrote: post #63

Earlier quoted context omitted.

Likewise the focus on ECS architecture as being the one true DoD pattern when it’s not necessarily data oriented at all and the unfounded assumption it’s used everywhere in game development when it isn’t . And somehow the idea that DoD is a replacement for OOP when it’s really an orthogonal concern. DoD is about recognising data use patterns in your software and organising your software architecture around them in a…

It took me a fair amount of searching to establish that ESC refers to https://en.wikipedia.org/wiki/Entity_component_system

Basically it boils down to making use of Objective-C protocols or multiple inheritance, with data separated from behavior in regards to implementation.

So a 1986 concept rediscovered by game developers and cargo culted ever since, although it has its roots on the OOP they love to hate.

Re: An Introduction to Data Oriented Design with Rust

#139

Post by pjmlp »

narwally wrote: post #77

I find it interesting, and somewhat amusing, that we're seeing Data-Oriented-Design becoming popular in C++ and Rust while Data-Oriented-Programming/Data-Driven-Design[1] is being promoted in languages like Clojure and Elm. Both have similar names, and seem to have arisen out of frustrations with OOP. However, their solutions went in completely opposite, though not unrelated, directions. Seems like DOD is about impro…

It has its roots in CLOS / Objective-C protocols / Smalltalk traits / Eiffel multiple inheritance, but somehow it got twisted as not being OOP.

Re: An Introduction to Data Oriented Design with Rust

#140

Post by discreteevent »

throwaway894345 wrote: post #127
meheleventyone wrote: post #100

Earlier quoted context omitted.

Whilst it’s impressive you’ve managed to hold an argument with yourself I think it’s more the case that anything as broad as a programming paradigm will naturally hold multiple approaches. Is immutability a defining feature of FP? Let the battles commence. Likewise critics might focus heavily on inheritance or some other feature of OOP that is easy to critique. And whilst I’m not particularly interested in defending…

> Whilst it’s impressive you’ve managed to hold an argument with yourself I like to address the boringly predictable responses up front so we can avoid rehashing the same silly arguments over and over. I apologize if that spoiled your fun. > Is immutability a defining feature of FP? Let the battles commence. I think most would agree that immutability is more prevalent in FP even if struct immutability isn’t required.…

alankay on June 20, 2016

Object oriented to me has always been about encapsulation, sending messages, and late-binding.

https://news.ycombinator.com/item?id=11940050

Post reply on HN