I'd like to open a discussion thread about a Game Object Component System, aka. Component Based Entity System.

There isn't much discussion about this.

I've recently adopted this technique from Game Programming Gems 6, and I find it's far superior to the old inheritance way. The headache of deciding if MovementEntity should inherit from ShootingEntity or the opposite is gone.

As I continue to use this technique the questions accumulate. These are mostly trivial questions, design and architecture questions, and also some fundamental questions, e.g. what should the game object know, component dependencies, etc.

Hopefully some masters of this technique can come forth and explain their way of using it.

What about distinctive game objects such as a Tank and a Defense Tower? Both require the Shooting and Selecting ability, but not Moving. Or Helicopter and Soldier, Dog and Rocket.

This method has an inheritance "stink" in my opinion.

A component based system allows you to define new entity types in a data file, XML. That is a big plus. Then you only have a set of specialized components that may or may not interact, and then you can define all the more concrete classes of entities in a XML file.

So I think I chatted to appel about this in irc, but I've been interested in trying a component-based design for a while. Rescue Squad gets away with doing things in a very simple way (lots of interfaces like cylab's example), which works but leads to quite a bit of tedious boilerplate and duplication.

When/if I move on and do RS3 I've got ideas for a much more complex simulation with lots of different vehicles and props the interface-heavy approach just isn't going to scale and component-based looks like being a good alternative.

In some ways this reminds me of behaviour trees, in that you end up writing small chunks of functionality (walk_to, search_area) and then using an xml structure to plug them together. Individually the components are stupid/simple, it's only when assembled that they become bigger than the sum of their parts.

With behaviour trees I had similar problems when components had to interact. I ended up with a certain amount of instanceof and some annoying implicit dependencies (like certain behaviours expected to be next to another type of behaviour). I'm still not certain how this is best solved.

You're just trying to get around inherent deficiencies in the Java language here. It just doesn't have the constructs to do what you want in a nice elegant way. Mostly you'll end up with a ton of boilerplate code (delegating interface methods to concrete instances inside some class), a bunch of instanceofs because there's no dynamic class creation easily made, or something that can't be reliably checked at compile time for sense. Bah.

Why do you need the concrete TankShooter class? It implies you have a Tank unit in your game.

The TankShooter was just an example. I think you should use an interface as component specification, so you can implement a component different _if_ needed. Nothing stops you from providing a default implementation that covers 90% of the cases. But an interface is mandatory in my opinion.

That would be a good example for a default implementation, but setShootingInterval() should not be part of the Shooter interface, since you may want to implement a shooter with random or accellerating shooting interval.

The TankShooter was just an example. I think you should use an interface as component specification, so you can implement a component different _if_ needed. Nothing stops you from providing a default implementation that covers 90% of the cases. But an interface is mandatory in my opinion.

That would be a good example for a default implementation, but setShootingInterval() should not be part of the Shooter interface, since you may want to implement a shooter with random or accellerating shooting interval.

An easy way to implement all this is to use a simple modeling framework like Eclipse's EMF. it seems to not be that much in the habits of game developpers but I still find it very usefull and efficient since it will provide you with the code for adapting objects as well with a notifier system for keeping your adapters up to date (which is way trickier and error prone).

Everyone's problem here is that you are attempting to expose the behaviour of the Tank (or whatever) by adding interfaces to say what it can do. However its public interface should be only what is required for it to interact with its world. Typically that'll be quite a brief selection of methods, like init(), think(), damage().

The shooting and moving stuff - that's basically private stuff. By all means break that code out into specialist classes that take private implementations of, say, a Moveable or Armed interface - but don't expose these at the top level. For example:

A bit of a manufactured example but not too far off what I'm getting at. Just try to keep the public interfaces of the classes restricted to that which is needed to communicate with as few other classes as possible.

All kinda pointless in the grand scheme of things. You're writing a game. Just make it work.

Everyone's problem here is that you are attempting to expose the behaviour of the Tank (or whatever) by adding interfaces to say what it can do. However its public interface should be only what is required for it to interact with its world. Typically that'll be quite a brief selection of methods, like init(), think(), damage().

The shooting and moving stuff - that's basically private stuff. By all means break that code out into specialist classes that take private implementations of, say, a Moveable or Armed interface - but don't expose these at the top level.

You're absolutely right!

However, I'm not trying to expose a component to the "outside world", but rather expose their interface to each other.

E.g., SelectComponent needs to be able to look up the VisualsComponent within the same gameobject in order to render a selection rectangle of the correct size around the selected game object.

All GameObject instances contain a list of component instances for that object, and all components have a reference to it's gameObject owner. That way they can look up other components within the same gameObject, e.g. owner.getComponent("Visuals"), and communicate with it.

You might have a MovementComponent called SlowWhenDamagedMovementComponent, which has a dependency on HealthComponent, which has a public method "getHealth()". You get the idea.

All gameObjects reside in some gameObjects collection, which gets iterated, e.g.:

for(GameObject gameObject : gameObjects) gameObject.update(delta);

and

for(GameObject gameObject : gameObjects) gameObject.render(g);

The gameObject instance would then iterate all it's components and perform the same update() and render() on it's components.

That's just about the only communication to the outside world, in theory. Otherwise they manage themselves independently.

For the topics under discussion currently, I'd just use Scala traits. Scala cross compiles with Java with no problem, and after Proguard cuts the Scala libs down you're only adding a few kb to your game size anyways.

What is this "Game Object Component System" thing, though? Is that just fancy language for the properties pattern, or is there something else going on there? Anyone care to give a paragraph summary of what we're discussing here?

What is this "Game Object Component System" thing, though? Is that just fancy language for the properties pattern, or is there something else going on there? Anyone care to give a paragraph summary of what we're discussing here?

Basically, instead of having a concrete entity class that extends other classes to inherit their functionality, you rather have multiple components for each independent functionality (like movement, shooting, visuals, selecting, etc.). Those components are then binded together in a gameobject/entity container class, that does nothing but to contain the components of that certain gameobject.

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