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.

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 inspired 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 everywhere.

Of course, being as inexperienced as I am, I did not see any problems when I first started using the single hierarchy, inheritance 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.

A few quick thoughts:I would not make game characters dependent to stuff like rendering, input or AI.If you elaborate further to a network model, there will be no rendering on server side, input events come pre-digested from clients and clients might not run any game AI.Event without network, rendering is rather a dedicated low level sub system as opposed to game characters. AI might need lots of overall game information and thus not be callable from a single character anyway.Generally, preventing (excessive) coupling is an important issue.Nothing wrong with small inheritance hierarchies you described.

Otherwise there are a number of "higher level" methods in programing. OOP is one of them, composition is another. Just because you use one is no reason you can't also use the other. Entity frameworks tend to get way to abstract and theoretical by a lot of people. Don't forget it is suppose to be a solution to a problem. So keep going back to the problem you are trying to solve rather than some debate about OO and composition.

I have no special talents. I am only passionately curious.--Albert Einstein

Otherwise there are a number of "higher level" methods in programing. OOP is one of them, composition is another. Just because you use one is no reason you can't also use the other. Entity frameworks tend to get way to abstract and theoretical by a lot of people. Don't forget it is suppose to be a solution to a problem. So keep going back to the problem you are trying to solve rather than some debate about OO and composition.

Of course I listened to Cas! In fact it was his post "Why entity systems suck" that made me want to post here.

Did the game work? Then your code is fine. Did some stuff annoy you when you were coding it? Tweak the ideas in your next game.

Cas

Hey, Cas!

Yes the game "worked" (read: I was able to move around, shoot stuff, jump, dodge bullets. But there weren't levels, quests, story, etc.. It was my second game so I didn't really intend to finish it from the start). But as you said, there are stuff that annoyed me when coding it which I mentioned in the post, and this is what I'm trying to fix.

I just don't want to end up having other problems which, due to my inexperience, I am unable to foresee, which is why I'm asking (much) more experienced people. (like you!)

A few quick thoughts:I would not make game characters dependent to stuff like rendering, input or AI.If you elaborate further to a network model, there will be no rendering on server side, input events come pre-digested from clients and clients might not run any game AI.Event without network, rendering is rather a dedicated low level sub system as opposed to game characters. AI might need lots of overall game information and thus not be callable from a single character anyway.Generally, preventing (excessive) coupling is an important issue.Nothing wrong with small inheritance hierarchies you described.

These are actually some of the things I'm trying to avoid end up having to fix actually! Thank you for the warning. On another forum where I asked this question (where I also mentioned that I asked this question on this forum and mentioned your answer ) I was (I think) given a way to solve problems like this. (Co-dependence of two classes)

Well... there is a saying that goes "experience is a dear school, but fools will learn at no other" and though it is nice to agree with it and feel all smug and wise I have subsequently amended it with, "...but you get what you pay for." Doing stuff "wrong" is a great way to figure out why something is wrong rather than just being told it's wrong. This is why we have endless parroted debates about statics, singletons, object pools, operator overloading, blah, blah, blah - a lot of the time it's an argument between people who have solved a problem in one way who think they're right versus people who haven't yet even come across that problem or don't currently have it or who have solved it in a different way.

Which in a rambly way of saying things is... try lots of different ways to do stuff and figure out what stuff works best for you, for your problems, don't go listening to everyone's advice or you'll never get anything done!

The gamelogic only picks the relevant information and filters outEntites it needs to process by observing one or several "flags".

Ok, this looks quite ugly in OOP eyes, but it helps me getting prototypesrunning very quickly.In fact I wrote a prototype once in 2 days, and the reimplemeted it using"propper" OOP Approach, taking me 1 week to reach the same gamestate.Adding features did not work faster in the end than with my "raw" approach.(pending that the project was not really huge or sharing development with others though)

In the end you at least see which part of OOP is really helping you, andnarrow down the most productive approach four yourself.

I created Artemis that is based on the T-Machine articles on entity systems. I also put together a more traditional composition based entity/component framework called Apollo that I personally prefer to use.

I've also tried inheritance, as most have, and that's just pure nightmare. Even a simple game turns ugly quite fast.

Personally I don't think doing entity/component composition like in Apollo is very difficult to do, compared to the nightmare of inheritance.

But it all depends on the nature and complexity of the game, and what you find most convenient to do.

Cas is definitely on target here. If you don't take the time to try out each system for your game, then you will never get anything done.

From my experience, inheritance gets very difficult to keep track of in your head if you use it a lot. I usually had a huge tree chart drawn out next to me so I can keep track of what, how, and where functions are being used. If not kept under control, you can lose control of your code rather quickly. However, there are good uses for inheritance, like forcing people to use classes in a specific way.

Entities are usually cleaner when it comes to games, because games are usually separated by object actions. It only "feels" better because you are working in an environment that promotes it. It doesn't mean that inheritance sucks. Each has its own advantages.

But, seriously, you have to try out these systems for yourself. Who knows, you might find out that inheritance is a better fit.

Well... there is a saying that goes "experience is a dear school, but fools will learn at no other" and though it is nice to agree with it and feel all smug and wise I have subsequently amended it with, "...but you get what you pay for." Doing stuff "wrong" is a great way to figure out why something is wrong rather than just being told it's wrong. This is why we have endless parroted debates about statics, singletons, object pools, operator overloading, blah, blah, blah - a lot of the time it's an argument between people who have solved a problem in one way who think they're right versus people who haven't yet even come across that problem or don't currently have it or who have solved it in a different way.

Which in a rambly way of saying things is... try lots of different ways to do stuff and figure out what stuff works best for you, for your problems, don't go listening to everyone's advice or you'll never get anything done!

Cas

I couldn't agree with you more on this. If I hadn't tried the things I did myself, I would probably have scoffed off most of these things as being unnecessary or just overdoing things for the sake of overdoing, or in other cases overdoing things when they could be done in a simple, elegant way. I'm really really stubborn like that.

The gamelogic only picks the relevant information and filters outEntites it needs to process by observing one or several "flags".

Ok, this looks quite ugly in OOP eyes, but it helps me getting prototypesrunning very quickly.In fact I wrote a prototype once in 2 days, and the reimplemeted it using"propper" OOP Approach, taking me 1 week to reach the same gamestate.Adding features did not work faster in the end than with my "raw" approach.(pending that the project was not really huge or sharing development with others though)

In the end you at least see which part of OOP is really helping you, andnarrow down the most productive approach four yourself.

This is what I'm thinking about implementing, but not using any inheritance at all is just as bad as over-using it.

Quote

An implementation of composition over inheritance typically begins with the creation of various interfaces representing the behaviors that the system must exhibit. The use of interfaces allows this technique to support the polymorphic behavior that is so valuable in object-oriented programming. Classes implementing the identified interfaces are built and added to business-domain classes as needed. Thus, system behaviors are realized without inheritance. In fact, business-domain classes may all be base classes without any inheritance at all. Alternative implementation of system behaviors are accomplished by providing another class that implements the desired behavior interface. Any business-domain class that contains a reference to the interface can easily support any implementation of that interface and the choice can even be delayed until run time.

I've found this great code over at Wikipedia (for once) and I'm thinking of using this style in my game.

I created Artemis that is based on the T-Machine articles on entity systems. I also put together a more traditional composition based entity/component framework called Apollo that I personally prefer to use.

I've also tried inheritance, as most have, and that's just pure nightmare. Even a simple game turns ugly quite fast.

Personally I don't think doing entity/component composition like in Apollo is very difficult to do, compared to the nightmare of inheritance. But I've yet to decide if I will go with pure components (as in, not even entities are used, just methods to duck type objects together) or use hardcoded, non hierarchical, composed entities. (I felt really smart writing that for some silly reason..)

But it all depends on the nature and complexity of the game, and what you find most convenient to do.

Ah, so you are the one who made Artemis! I checked it out a few days ago, and I must say it is quite amazing. However being a hybrid"hardcore" techie and "visionary" I dislike using too much of "high" level stuff. I like to start as low as possible, but without having to reinvent the wheel (at least not all of it). It's why I'd rather use a library a library like LibGDX.

Cas is definitely on target here. If you don't take the time to try out each system for your game, then you will never get anything done.

From my experience, inheritance gets very difficult to keep track of in your head if you use it a lot. I usually had a huge tree chart drawn out next to me so I can keep track of what, how, and where functions are being used. If not kept under control, you can lose control of your code rather quickly. However, there are good uses for inheritance, like forcing people to use classes in a specific way.

Entities are usually cleaner when it comes to games, because games are usually separated by object actions. It only "feels" better because you are working in an environment that promotes it. It doesn't mean that inheritance sucks. Each has its own advantages.

But, seriously, you have to try out these systems for yourself. Who knows, you might find out that inheritance is a better fit.

Yeah, this is what happened with me as well. I ended up getting lost every time I changed something, and started searching what/where to change, and then end up having to fix a dozen runtime exceptions.

Well when I wrote it I was under the impression that entity systems had nothing to do with OOP.. >_<

It's all a matter of perspective. You can choose to look at most abstractions in multiple ways. From the OOP perspective component-base is mimicking prototype based OO within some other major paradigm. In this case class-based OO.

Like Cas indicated, straight design by inheritance and/or interface will take you pretty far. A dash of data-driven design with or without basic composition (like pseudo-mixin for instance) should be more than sufficient in the vast majority of cases.

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org