Proper OOP class tree implementation

I’ve been messing around more with OOP recently and I’ve been wondering what the most ideal implementation for a class tree structure would be. This is the first thing that comes to mind:

> SubClass
> SubClass2
  > SubSubClass

Would you just chain a bunch of ModuleScripts together? What would the structure of the code look like as opposed to standard Roblox OOP practices?

Outside of the class tree itself, how would this change what item data lists look like?


Yeah the first instinct is to use inheritance to expand on the behavior of the baseclass but keep in mind that it’s not always optimal as you may run into the diamond problem pretty soon where you may want to combine something from subclass and subclass2 like I did.

For that you can use composition instead as I found out from @minhnormal you can research it from the article in the post.

The component based system is actually very similar to certain aspects of ECS so I suggest checking it out.

Also this stack exchange question puts it into perspective of an oop tree and an example with an RTS game, perhaps it’ll help with structuring your oop as well.

1 Like

Going into researching this, I did have in the back of my head that these large class trees can be organized at first then just become a mess. Personally, I get annoyed at repeated code so I often put a bunch of functions in modules so they can be shared. This same concept I like to apply to the creation of a game’s systems but in practice the class tree can be limiting, as you’ve pointed out.

It’s a shame because it seems so logical until some edge case comes up and at that point it becomes tricky to add it without questioning the whole system you spent probably way too long creating.

In my games I get around that issue with utilizing OOP for things like creating a “building” in my game. The way that given object is created varies depending on the data associated with the building that the build class is trying to create. While there is a decent amount of copy and pasted data structures to represent what an building should do, adding new features to specific buildings can become really easy: just add a value to that specific data table and have whatever part of the codebase check for that value and run some other code.

While that part is a bit unorganized and annoys me, it allows a lot of control over how the game functions and what new features it has.

I’ll probably hold off on looking more into this because of these issues, but thanks for the information!

1 Like

Whoa, that actually sounds like ECS,

In ECS you would add a component to an single object instance --called entity


Then the system would check for that additional component and do stuff from there. Some implementations do this every frame.

I swear the lines get blurry I’ll just stick to the if it works, it works and avoid thinking about the differences between OOP and ECS and just do it.

1 Like

Agreed, couldn’t have said it any better.

1 Like