1
\$\begingroup\$

I decided I would develop a game engine in c++, so I was thinking about different ways of handling objects. I also have experience with ROBLOX, so I know that it uses an object-oriented design as opposed to an entity component system.

Here's a simplified example of how ROBLOX's system works: there's a base class called Instance that all objects in a place (a DataModel instance) inherit from. Instances representing a physical object inherit from the BasePart class, static Instances which only provide services inherit from ServiceProvider, and instances which exist solely to modify or contain their parent or child instances inherit from the Instance class itself. For example. if you add a SpecialMesh instance as a child of a Part instance, the part will be rendered using the appearance of the mesh. (there are probably some other examples I'm missing as well).

ROBLOX also allows you to modify the properties of instances directly, with the user interface grouping properties together by what things they affect, rather than providing them as traditional components. For example, a Part instance would have an Appearance section in the GUI properties window which shows properties like Color, Material, Opacity, etc.

In addition, I've worked on code for the GoldSrc and Source engines (for modding, of course), and they appear to use a very similar system.

This seems to go against a lot of what I've learned about designing systems like it, with most developers preferring to take the ECS route instead. Why did ROBLOX decide to use this object-oriented design rather than the more conventional entity component system?

Improve this question
\$\endgroup\$
5
  • 1
    \$\begingroup\$ We usually can't answer "why did other developer X do Y" - you'd have to ask X directly. But I think you may have been misled about how universal ECS is in games. It's been trendy in recent years, but there's still a great deal of more conventional OOP in game tech too. Sometimes it just comes down to developer preference. \$\endgroup\$
    – DMGregory ♦
    Nov 19 at 12:40
  • \$\begingroup\$ @DMGregory I'd also like to add that (from what I know) most games who use ECS also use OOP as well. \$\endgroup\$
    – JorensM
    Nov 19 at 12:58
  • 1
    \$\begingroup\$ Yeah, usually ECS is a subset of OOP - when folks present them as a dichotomy, they mostly mean "Using OOP in an ECS style with buffers of plain-old-data-structures" vs "Using OOP in a 'classic' style with inheritance, V-tables, and trees." A lot of game tech does a little of both - even an engine that's heavily classic OOP will look very ECS when you look at its particle system code. And even ECS heavy engines tend to look more classic OOP when it comes to UI widgets. \$\endgroup\$
    – DMGregory ♦
    Nov 19 at 13:03
  • 3
    \$\begingroup\$ I’m voting to close this question. Questions about design intent of existing products can't be answered here, because we can only guess what the original Roblox developers thought when they built their architecture. \$\endgroup\$
    – Philipp
    Nov 21 at 9:47
  • \$\begingroup\$ Object-oriented is easier. Much easier: one thing in the game = one object. System-oriented programming requires you to think about all the things in the game at once. \$\endgroup\$
    – user253751
    Dec 2 at 14:08

0

Reset to default