Back to General and Gameplay Programming

Composition heavy OOP vs pure entity component systems?

Midori Ryuu · 2012-09-10T19:08:38

I admit, I have made the sin of overusing, and even abusing inheritance. The first (text) game project that I made when I was taking my OOP course went as far as "Locked door" and "unlocked door" from "Door" and "Room with one door", "Room with two doors", and so on from "Room". With the (graphical) game I worked on recently, I thought I had learned my lesson and put a limit on using inheritance. However I noticed the problems soon beginning to appear. My root class was beginning to bloat more and more, and my leaf classes were full of duplicate codes. I thought I was still doing things wrong, and after looking it up online I discovered that I wasn't the only one with this problem. It's how I ended up discovering Entity systems after some thorough research (read: googlefu) When I began reading on it, I was able to see how clearly it was able to solve the problems I was having with the traditional OOP hierarchy with components. These were in the first readings however. When I stumbled upon more… “radical” ES approaches, such as the one at T-machine. I began disagreeing with the methods they were using. A pure component system seemed either overkill, or rather, unintuitive, which is probably the strength of OOP. The author goes so far as to say that ES system is the opposite of OOP, and while it may be usable along OOP, it really shouldn’t. I'm not saying it's wrong, but I just didn't feel like a solution I would like to implement. It was then that I stumbled on Hodgman post, and it really made sense to me. I really didn’t see any conflict between OOP and composition; rather, the two seemed as one. So to me, and to solve the problems I was having at the beginning of the post, without going against my intuitions, is to still use a hierarchy, however it won’t be a monolithic hierarchy like the ones I used before, but rather a polylithic one (I couldn’t find a word opposite to monolithic), which consists of several, smaller trees. The following example shows what I mean (this is insipied by an example I found in Game Engine Architecture, Chapter 14). I would have a small tree for vehicles. The root vehicle class would have a rendering component, a collision component, position component etc.. Then a tank, a subclass of vehicle would inherit those components from it, and be given it's own "cannon" component. The same goes for the Characters. A character would have it's own components, then the Player Class would inherit it, and be given an Input controller, while other enemy classes would inherit from the Character class and be given an AI controller. I don't really see any problems with this design. Despite not using a pure Entity Controller System, the problem with the bubbling up effect, and the large root class is solved by using a multi-tree hierarchy, and the problem of the heavy, code duplicating leafs is gone since the leafs don't have any code to begin with, just components. If a change needs to be done to the leaf level, then it's as simple as changing a single component, instead of copy pasting the code everwhere. Of course, being as inexperienced as I am, I did not see any problems when I first started using the single hierarchy, inheritence heavy model, so if there are problems with the model that I'm currently thinking of implementing, I wouldn't be able to see it. Your opinions? P.S: I am using Java, so using multiple inheritance to implement this instead of using normal components is not possible. P.P.S: Intercomponent communications will be done by linking dependent components to each other. This will lead to coupling, but I think it's an ok trade off.

General and Gameplay Programming Programming

Started by Midori Ryuu August 20, 2012 06:00 AM

30 comments, last by Mito 11 years, 7 months ago

Midori Ryuu

177

Author

September 10, 2012 05:02 PM

Hey all~ I am back after a somewhat long absence, as I've been busy acclimating into my new job. I wanted to update you guys who took the time to help me with what happened! (And I might hope for a little feedback for how right (or how less wrong) I did things.)

So, after some more search, I fell upon the Apollo entity framework. It is built by the same folks who has made the Artemis entity framework, but is more 'object-oriented' in its thinking. I fiddle around with it in the past couple of weeks, and I must say I really do prefer it a lot over Artemis, which I wasn't planning on using.

This on the other, I loved! I'm not using the platform in its entirety (yet), and I have made some modifications of my own to suit my programming taste (to the builders, etc..)

I have made a small, small demo where I integrated it with LibGDX and Box2D, and I have the code up on Github for those who want to make me feel bad by telling me how bad it is.

My architecture is essentially having the Apollo world contain the Box2D world (though I keep a separate reference for the Box2D world for convenience).

I have a Renderable component, along with a collidable component. The collision component depends on the Renderable component, but for the time being only, and only for practicing/experimenting with things, but they should be completely independent, and only separately depend on the Transform component which holds the position.

I have a collision detection listener which doesn't itself act on the bodies, but triggers a flag in the Collidable component and forwards it the needed information to handle the collision (the other body, its type, etc..)

I haven't used the event listeners built into Apollo, so I cant' say anything about that, though I might use it later on. Sorry about that, Gabriel, but I hope I can still answer some of your questions in the code.

I'm using builders like Apollo recommends, though I have modified those to take several parameters. This broke the methods related to builders (which was rather convenient) but it's nothing fatal. (To those who made Apollo, my sincerest apologies for butchering your framework!!)

So yeah, that's pretty much it! Don't judge too harshly.~

I wonder if I should start my own game dev diary.. But I don't want to infect people with bad code. xD

Mito

855

September 10, 2012 07:08 PM

I wonder if I should start my own game dev diary.. But I don't want to infect people with bad code. xD

well, i think you SHOULD start one. this way you will learn much more. don't be shy. there's no such thing as bad code, only code that has not been polished yet

Composition heavy OOP vs pure entity component systems?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Composition heavy OOP vs pure entity component systems?

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines