First, sorry guys for the late (and short) reply. I was (and still somewhat am) under the weather, and quite feverish. I know it's not an excuse, but I hope you guys can forgive me >_<
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.
How about you make an explorationary "diametral" test, making a small game (or reimplementation of one)
By using no inheritance at all.
Only using one single (or even none) Entity class, which gets its type identified with
one or several integers.
int myType = PLAYER; =1
..
int myType = TREE; =2
..
int mySubType = PALM_TREE; =1
boolean isMover = false;
boolean isPickup = true;
etc...
The gamelogic only picks the relevant information and filters out
Entites it needs to process by observing one or several "flags".
Ok, this looks quite ugly in OOP eyes, but it helps me getting prototypes
running 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, and
narrow 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.
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.
I think a major problem with complex class hirachies (me me) is loosing
oversight of the classes, and inheritance.
I use a mindmap (freemind as tool)
to quickly mark down the class structure, links and explanations
Its a great tool to hangle through a tree of information.
And also to design the class structure in the first place.
(much faster than writing an unnececaritly complex UML)
I never heard of it. I will check it out!
And yes, I would probably have ended up with a 2x complicated tree if I hadn't planned ahead..
Component based is composition heavy OOP. Where's the 'vs' come in?
Well when I wrote it I was under the impression that entity systems had nothing to do with OOP.. >_<
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.
Myself I've found that inheritance works fine for my games.
Cas
That is great to hear! I will try out the composition approach, and like ctomni and you said, I might end up liking inheritance more!
Thank you again everyone for all your great replies!
------
Edit: I just played one of your games Cas. Quite addicting! I must say it made really tempting to just start coding right away without any more research!
