Game Object Component System

Game Play & Game Design
#21

Reading your post, I think that maybe the adapter design pattern could be exactly what you need.

The usual implementation for this pattern is to have a factory in charge for creating adapters for objects.
It gives you something like this ;


ComponentInterface componentInterface = componentFactory.adapt(gameObject, ComponentInterface.class)

For your example, it gives :
Shooting shooting = shootingFactory.adapt(entity, Shooting.class);
if (shooting == null) {
  // entity is not able to shoot so skip
} else {
}

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).

Vincent
#22

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:


interface Weapon {
	void fire();
}

interface Movement {
	void move(Moveable m);
}

interface Moveable {

	void setLocation(float x, float y);
	float getX();
	float getY();
}

abstract class Entity {

	abstract void tick();

}

class Tank extends Entity {

	float xPos, yPos;
	
	Moveable moveable = new Moveable() {
		void setLocation(float x, float y) {
			xPos = x;
			yPos = y;
		}
		float getX() {
			return xPos;
		}
		float getY() {
			return yPos;
		}
	});
	Movement movement = new SpecialTankMovementRoutine();
	Weapon cannon = new Cannon();
	
	void tick() {
		movement.move(moveable);
		cannon.fire();
	}
}

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.

Cas :slight_smile:

#23

Isn’t that exactly what I said!? 8)

#24

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.

#25

It all sounds, er, overcomplicated. Games, when you get right down to the fiddly stuff, really aren’t very complex, unless you overcomplexify them yourself.

Cas :slight_smile:

#26

Unless you’re making a RTS game that has FOUR races, and each race having something like 8 unit types, it helps having reusable components, and defining these guys in an external data file.

#27

This is an interesting conversation.

Why not include a scripting language and then you can just have each unit implement multiple scripts to define their behavior? :stuck_out_tongue:

#28

See, I’d see that simply as 32 classes. Not exactly a lot of complexity. I expect that the inheritance heirarchy would be pretty simple too.

Cas :slight_smile:

#29

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?

#30

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.

This is a nice enough article:

Evolve Your Hierarchy
http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

#31

Thank you for the explanation and link, I was certain I’d heard the term somewhere before but couldn’t remember where - turns out it was that article.

I guess I’d question whether or not this type of thing is necessary for smaller games. For AAA stuff where you might have thousands of different types of “thing” in your world, the constraints are very different, and one of the most important things is to be able to make sure that the designers can create new “things” without consulting with the programmers at all. Components will facilitate that much better than inheritance, definitely.

I’d guess that for most of the types of games people are working on here, the complexity threshold where it matters is never crossed. As mentioned in that link, the problem that component systems are intended to solve is the so-called “blob anti-pattern,” where you end up with a very unbalanced inheritance hierarchy, with too much functionality either a) living in the root of the tree, or b) copy-pasted to the leaves as needed. Unless you’re seeing that happen, or designing a system large enough where it’s to be expected eventually (RPG or virtual world or something like that), I don’t know that the effort spent avoiding typical OO stuff is going to really pay off.

I’d leave it to a matter of taste, though. There are situations where I could see something like this being appropriate.

Anyone ever implemented something like this before? I didn’t really see any specifics, and I don’t have access to that Game Programming Gems article.

#32

You’ll probably never have thousands of different types of thing though, not even in AAA games. I hate OOP sometimes. It breeds this sort of programming brain-freeze.

Cas :slight_smile:

#33

Have you read the article? It is certainly an improvement over their previous design, which was based on inheritance.

#34

The article’s not all that great at giving any concrete evidence of tangible benefits. The number of entity types he’s got in the example there isn’t even half the size of what’s in Alien Flux. All that wasted time refactoring and introducing new bugs for what benefit? Bugger all as far as I can see. The thing is, they didn’t really have a problem to begin with. I see this a lot with software engineers. They just like to fiddle around with the “elegance” of the code for weeks on end trying to make it “feel pretty”, often because they can’t be arsed to bite the bullet and type a bit of code twice. In the end progress is ultimately usually slower and the end result is usually just as complicated, if not more so.

That’s not to say that composition isn’t a completely valid way of doing things - but really, you need a bit of smart thinking and use both techniques. In Alien Flux for example, the movement of some aliens is factored out into a separate class so it could be reused in lots of different aliens but without having to try and inherit from some alien type that moved in a particular way. But there’s still a 4-deep hierarchy in there.

Cas :slight_smile:

#35

I’m right there with you, I have no particular love for OOP in general (or at least for the crippled approximation of OOP that Java allows), for exactly this reason - way too much effort is spent thinking about and implementing (not to mention talking about :slight_smile: ) patterns to achieve what might take one line in a language with just a little more power, and oftentimes all this work only benefits the “OO-ness” of the overall design and makes the programmer feel like he’s doing “the right thing.” In a scripting or functional language the problem that this is trying to solve would never have been a problem in the first place.

I don’t know whether or not this approach helped the Tony Hawk team or not; I’m hesitant to disregard the claim, because the author appears to have a good amount of experience and I’d like to think that he wouldn’t claim tangible benefits if they weren’t there, but you’re absolutely right that the article lacks real detail. It does strike me as a little odd that a skating game would have the type of object proliferation where this would be necessary; if this was WoW, I’d understand it in a heartbeat. The one tangible benefit I can see is that non-programmers can now design new objects without passing requests to the programming team, but there are a million ways to achieve that, so I don’t know that this is the best.

I still think it’s moot for the rest of us, though - if I ever notice the “blob anti-pattern” in my code and it starts to cause problems, I’ll keep this in the back of my mind as a potential solution, but thus far it hasn’t been an issue, and I don’t have a hundred person team working on any projects with me, so decoupling design from programming is not an issue I have to contend with.

Also, I’m still a bit unclear, so let me ask again: isn’t this just the properties pattern, rediscovered and given a new name?

#36

I also see a future benefit from using a component based game object system, whereas you can reuse components between games. Not only are the components entity-independent within the same game but they are game-independent.

You could easily create a library containing a set of standard components, and people could get their games going with fully functional game objects in a heartbeat. All they need to do is to define certain parameters in a XML file. If they need more, they can easily extend some component or create a totally new one. Honestly, I’m getting a bit tired of writing that darn Movement and Shooting functionality over and over again :slight_smile:

My short experience with the component system (compared to the entity-inheritance way) is that there are almost no obstacles, no programmers-block when you get stuck on “hm, should MovementEntity inherit from ShootingEntity or reversed?”.

Yes, it requires a little more time to create the system, but eventually it will lead to much more productive and enjoyable game programming.

I don’t really know what the debate is here. Is it OOP vs. procedural? Wasn’t that settled back in the 20th century? Over-designing vs. working asap? It all depends on what you’re doing, of course. Let’s not forget that this is JavaGaming.org, so pointing to another language that can do the trick just for “winning” the argument doesn’t count.

#37

I’m not entirely sure, to be honest. I think it’s something along the lines of “Is there actually a problem here in need of a solution?” My answer: maybe, depending on what you’re doing. I get the sense that Cas thinks it’s more a solution in need of a problem.

Re: programming paradigm, no, it’s not (IMO) between OOP vs. procedural, I’d personally argue that the sweet spot is OOP with the ability to dip into functional style when you need to (which is why I like Scala). Nouns should be nouns, verbs should be verbs, and we shouldn’t try to pretend otherwise if we can help it. But I wouldn’t go all the way towards functional zealotry - I think state can be very useful, and a lot of the efforts to create state-free code in languages like Haskell end up massively convoluted, in the same way that overly designed OO can be ridiculous.

[quote]Let’s not forget that this is JavaGaming.org, so pointing to another language that can do the trick just for “winning” the argument doesn’t count.
[/quote]
Hehe, fair enough. :slight_smile:

I’d still suggest that Scala integrates well enough with Java that it’s worth checking out, though, especially if you’re feeling a lot of pain over not being able to have implementations in your interfaces. (/plug)

#38

I suspect that the people on the “I don’t get it” camp don’t appreciate the complexity that the component system is trying to solve. I don’t think it’s unfair to say that most of the games worked on here are very simple compared to something like Tony Hawk. A rendering component for a simple j2d game might be a single draw() call, which will obviously leave you thinking that the whole thing is an over-engineered waste of time. It becomes trivial to just rewrite the draw call in every object that needs it. But when your rendering component is setting up multiple models, skins and animations and has to work across three different console platforms then you really don’t want to be duplicating that for every object. The same applies for physics, animation, sound, scripting, etc. etc.

To a certain extent you can push that duplication into helper classes but you’ll still end up with a lot of error-prone boilerplate to stick things together, and without the snap-together approach of components any new entity will likely require a certain amount of tweeking of exiting helper code to make it suitable for re-use.

#39

Some like to get something done fast, some others like to develop abstractions and patterns. So what? (I now the latter type rarely get anything done in their free time, but it’s a hobby anyway…)

As long as it “feels” pretty, I am happy :wink:

#40

Here are great articles from this guy Adam Martin at T=Machines.

He calls his system a Entity System. It’s similar to what we’ve discussed here, but goes much further. It’s more oriented for MMOG games. Gives me some good ideas.

Entity Systems are the future of MMOG development
http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/