Irrlicht Engine

This is a technique I came across a couple months ago that helps solve the problem of huge trees of inheritance which inevitably lead to sloppy code.
Heres a post I made about it on my website, read it for more info/tutorial:
http://snakeinalake.com/index.php?cmd=tutorials&par1=10

It can make game development so much smoother, and I've experienced that first hand. I'm currently using it in one of my projects and in the first 2 days I already had a feature-full, working, game engine.

But I don't think efficient entity systems are on the minds of most developers since it seems inheritance is the way to go so to spread the word of this I want to make this competition:

Make a program showcasing that technique and its possibilities!

The winner will be chosen by public vote. Upload your application for others to download. Also, you are encouraged to upload the source as well to better show off the technique, but its up to you and wont affect your chances of winning

The only rule is that you have to use that technique. You can use the honesty system or upload your source code

Dates:
I think about a month should be enough time. Everyone has until October 10th to submit their applications/games. Voting will end on October 20th, thats when the winner will be chosen

Prizes:
I don't have much to offer, but I could review the winners application and make a post about it on my website, with a link to the winners own website/blog/profile page/anything else they wish to link to

I will not be entering the contest because I'm trying to finish my game before the IGF deadline and I'm already so far into development

------=====ENTRIES======------
nothing..





inspiration
modding
external-stuff
dynamic classes(variables and functions can be added to a class during runtime!)

With all due respect, I fail to see how inheritance can lead to sloppy code. Sure, bad inheritance can, but that's just bad programming, and it's no wonder that bad programming causes bad code. If used properly, inheritance is extremely powerful and flexible and leads to good code. A map system like the one you suggest has a few problems in my mind:

• Instead of a clean enum type field, you suggest using a string to hold the type. I don't understand why this is done - you'd know all the types possible, it's easy to store them all in an enum, and lookup time is way faster. Hell, with good inheritance, you can avoid a good number of type fields to begin with. Stroustrup promotes avoiding them altogether, but in a real-time environment that usually ends up being impossible (since dynamic_cast is sloooow.)
• With good inheritance, you can avoid avoid any kind of "hasComponent" call. Just pass the managers (be it AI manager, physics manager, whatever) the pointer to the class if it is an AI or physics object, respectively. There goes a lot of wasted time. Plus, if you end up needing some kind of isComponent() call, you can just use virtual functions to override the function for each subclass. A vtable lookup is way faster than a string comparison.

As for myself and the game I'm developing, I'm going with inheritance. To avoid the sloppy code you were talking about, some old-fashioned planning goes a long way.

slavik262 is kinda right. The component system introduces a completely new set of problems. And you will mostly see it when you go to dynamic entities and modding which are you inspiration for this system.

So think about it. Every component must be autake, first to mach the sense of component based programming and second so that the game will still work even if a entity is missing a component. So other components can't rely on each other. This introduces the problem of data sharing and authority. Where to store variables? in a table inside the entity or should every component store their own variables and communicate changes to the outside? This introduces the next problem, you will need intercomponent communication which musst be as flexible as possible so that you can crunch any type of data through to other components. And now try to make it multiplayer
You know i have actually put a lot of time into developing such a system. and i have 3 games and 1 demo that uses this system. all a little different getting better and better with time
So i actually came up with this flexible message system which overcame the problem of intercomponent and interentity communication.
If you didn't encounter any of the problems i discribed you are either making to many assumption about other present components which will kinda kill the modding and dynamic class idea. or you haven't gotten to he point yet.
Btw. slavik262 is also right with the getComponent and existComponent calls those shouldn't even exist. they don't in my component systems.

Here is my entry :
http://irrlicht.sourceforge.net/phpBB2/ ... highlight=

I made this since a week or two. It is fully extendible and fast to use. This is an overview :
-Irrklang is used for sound and Bullet for physics.
-There is a game machine system where you can toggle from game to menu with a transition effect.
-All the entity system relies on the ISceneNodeAnimator. This permits to pick nodes using the ISceneManager and the IEntityManager.
-The entity is characterised by the its physical aspect. So all the entity system is based on the type of rigidbody (ghost, bbox, static, kinematic, etc...).
-You can add entities quickly by calling AddEntityX in the EntityManager.
-You can parse and load files containing a serie of entities using TinyXML.
-To catch event, there is an event interface communicating with all entities that inherit of CEventDriven class. They can send or receive events.
-Cell space partitionning is used to quickly communicate the event to the targeted entities (not completed yet).
-The bot entity can walk and find his path using the A* algorithm, and also react to the received events. The path is loaded via the gamemachine and is a XML document.

I'm not saying inheritance shouldn't be used, its an imprtant part of every oop program and infact the components should inherit from a base component. I just think it can make code a lot more readable and easier to manage.

The components don't have to communicate, the game controller class(a class that handles game logic) uses the components in the entities to perform game related stuff. For example:
You have an entity called player and one called rock. The game controller class checks to see if they have a "InputComponent" component in their components list. Since the player is the only one with that component the game controller knows to only move and perform physics on the player. They both have an "RenderComp" component which contains info about how to draw both entities so the controller knows how to render them.

If every game class is inherited then they are usually left with a bunch of unnecessary functionality. Take the rock, for example, all it needs is render and transformation info since its only there to look pretty. It doesn't need an ID or bounding box information or an unused pointer to a physics body descriptor.

Another thing to note is that with inheritance each class is independent and handles its own update or step function. This means that the game logic is spread across a bunch of different classes, making it very hard to fix most bugs. With the component system each component just has its own set of variables which can be used by a class that handles the logic. this leads to every gameplay-specific part to be centralized in one place making it easier to manage and increasing productivity

Ofcourse anything possible in the component based system is possible in the inheritance based system. They are just different methods to achieving the same goal, I just think that this new method is cleaner and simpler.


also, string names don't have to be used for the components, enums can be used as well but strings make it easier to read especially if scripting since words r easier to remember than numbers.

*I'm not on my computer now I'm posting this from my phone, ill put your entry up when I get home*

grumpymonkey wrote: ------=====ENTRIES======------
nothing..

EPIC FAIL

grumpymonkey:
"also, string names don't have to be used for the components, enums can be used as well but strings make it easier to read especially if scripting since words r easier to remember than numbers. "

What's hard about reading an enumerator name?

The point of an enumerator is that you don't have to remember the number.

because if your scripting your going to have to remember the numbers or set up the enum assuming the scripting language supports it

EDIT:

one more cool thing about this is that you can set up classes in xml
example:
<Entity name="Player">
<Component name="InputComp">
<var name="up" val="KEY_UP"/>
<var name="down" val="KEY_DOWN"/>
<var name="left" val="KEY_LEFT"/>
<var name="right" val="KEY_RIGHT"/>
</Component>
</Entity>

There's absolutely no reason you can't incorporate XML into a nicely designed inheritance based system either. Your point is moot.

Another approach would be having entities for everything.
So you have GraphicEntity, a PhysicEntitity, ...
Now you can just link those entities together and you got the same without a central point like Over entity that contains them

Why have a bunch of inherited classes when its easier to have one generic class in which functionality can be added dynamically?

I always find myself having to cast a bunch of classes to get them to work together. With this system I don't have to worry about that.

Don't just argue for the sake of winning, argue for the sake of solving the issue otherwise it'll turn into a name game. Ofcourse the same results can be achieved with the inheritance system. A program is only as good as its programmer. The point of this method isn't to produce better applications, but to simplify and accelerate the process. Try using this method to see if its better and compare it to the inheritance one. Personally I found the component one made me a lot more productive.

There are also some articles online that explain this technique better than I, here are a few of them:
http://cowboyprogramming.com/2007/01/05 ... -heirachy/
http://www.purplepwny.com/blog/?p=215
http://t-machine.org/index.php/2007/09/ ... nt-part-1/

in my short experience I have used both approaches in code and have seen the advantages ad disadvantages depending on the projects (both game and software apps). I use profilers most of the times to test response times and memory usage

traditional inheritance system: I find it more programmer friendly

Pros:

• quicker response times.
  very little need for casting.
  Particular focus (your entity).

Cons:

• Larger memory space, even if the class contains a few lines of code
  not very stable as the scale of the project increases. your inheritance plan might change from time to time
  there is a risk of reinventing the wheel
  not friendly when you need to pass code from project to project

component system: I find it more designer friendly

Pros:

• Less memory space
  more scalable
  you can move code from project to project easily
  quicker development times
  allows to see the big picture clearer

Cons:

• Slower responses
  Need to use casting in some cases
  There are times when you need to create "controller" classes
  all objects behave differently, you need to know how to create good components that can work for each particular case

Hey whats going on with this contest?

Do I win...? Because I see no other submissions than mine...

Iyad wrote:Hey whats going on with this contest?

Do I win...? Because I see no other submissions than mine...

If you haven't won this contest yet, I think you have most of the chances to win!

uhh yeah you win, congratulations...The prizes are outta stock though sorry TT_TT