[charlotte-fyi]

> There is definitely need for an OOP engine in Rust

Is there a need for an OOP engine in Rust?

I don't want to be too negative here — the developer of Fyrox seems like an incredibly talented and productive engineer and they can work on whatever they please, more options in the ecosystem is always a net good — but in my experience attempting to model OOP patterns in Rust is almost always the wrong decision.

[mcjerry]

It's a mixed approach in the end. Bevy is 100% ECS from what I gather. Fyrox is doing a pragmatic approach of taking what's good from different engines. I'm sure as it evolves it will abandon the things that don't work in a Rust context. So to rephrase: there is definitely a need for a game engine in Rust that's not 100% ECS.

[pcwalton]

Bevy has actually moved away from the ECS for performance-critical lookups in the renderer where the ECS doesn't carry its weight. The engine isn't dogmatic about ECS use.

[mcjerry]

Thanks for the info. That's good to know.

[CooCooCaCha]

> Fyrox is doing a pragmatic approach of taking what's good from different engines.

And bevy isn't taking what's good from different engines? Bevy gets inspiration from everywhere. Just because it uses an ECS doesn't mean it's all developed in a bubble.

[martin-t]

It's not _that_ OOP. I keep telling people not to use OOP to refer to fyrox because people associate it with java but there maybe isn't a better commonly known word.

OOP in fyrox means composition and message passing.