To Component, or not to Component. That is the quest ion.

General Discussions
#1

(yeah I had to put a space in question so it would let me post the topic).

There are two projects I’ve been spending lots of time on recently, an Entity-Component-View-Controller library for games, and a game engine.

My current debate is whether I should refactor my game engine into an entity-component architecture (use my entity library essentially).

Pros:

  • It would greatly simplify my code and my user’s code when it comes to: particle systems, sprites, steering behaviors, networking, spatial database, animation, sound, the list goes on.

Cons:

  • The overhead of get/set methods for an Entity-Component design is more compared to using interfaces. I’m all about efficiency, and when I think about someone having 100,000 particles on their screen… it will be twice as fast when it’s interfaces compared to Entity-Component (I strongly suspect - I should actually do a test).

You may be thinking THIS ISN’T EVEN DEBATABLE FOOL! But just the thought of refactoring it and having it end up being a little bit slower makes me resistant.

Help me JGO, you’re my only hope!

#2

Don’t do it. Entity systems are best for when you’re dealing with 100k+ entities in MMOs. You are undoubtedly not dealing with that.

Cas :slight_smile:

#3

But but but… people could use my engine to make MMOs.

And it makes the code look soooo much nicer.

I am torn.

#4

Make MMOs with it?

Very very few people make MMOs, and the very few who do. Are typically large teams who are likely rolling a lot more of their own stuff. ??? :emo: :point: :persecutioncomplex:

#5

I think a component system is a nice idea, but I don’t like the Java implementations I saw until now that much.
I’m thinking about how one could do a nicer/better implementation with HLists and because I use scala now if macros could help.

HList would give one a type checked component system. The only problem I have with this is that there are some problem with the type systems which needs to be resolved.

#6

Mine is type safe. The Java version is basically done, I just need to finish documentation and make some examples. Check the bottom of the readme for a code example.


Component<Vector> POSITION = EntityCore.newComponent( "position", new Vector() );
Component<Vector> VELOCITY = EntityCore.newComponent( "velocity", new Vector() );
Component<String> NAME = EntityCore.newComponent( "name" );

Template EXAMPLE = EntityCore.newTemplate( "example", POSITION, VELOCITY, NAME );

Entity e = new Entity( EXAMPLE );
Vector p = e.get( POSITION );
Vector v = e.get( VELOCITY );
e.set( NAME, "ClickerMonkey" );
#7

your entities are not typed in the way as that the type signature does not tell what components the entity has.

#8

Hmm what would be an example of that? Not sure I follow

#9

The primary argument against using OOP inheritance over the Entity Component Model is that with inheritance you usually get very large inhertiance graph. (There are other arguments, i.e performance optimizations that can be done with them etc but I’m assuming you don’t have that many entities)

Think (This is actually a poor way to inherit things, but its just an example…) GiantSpider inherits Enemy inherits Character inherits PhysicsBody inherits Entity (the problem therei s that Entity has a physics body, it isn’t a physics body itself)

However, a lot of people who argue this are ignorant (not all of them.) Before I posted here I saw a couple arguments which clearly did inheritance wrong to argue their point. One article had Car inherit Engine – which makes no sense at all. I think too many people are blindly using the model with little justification.

If you’re careful with inheritance you won’t need to use an Entity Component Model unless you are finding your inheritance graphs are growing to an absurd size or you are looking for an incredibly flexible system.

Ther are a lot of arguments for and against the Entity Component Model, I would research them and make the decision yourself.

java typically optimizes getters\setters if they recieve a lot of traffic, so it may not be an issue for you - it is definitely worth a shot if you want to use the model.

#10

First off all, don’t get me wrong your systems seems really nice and it is probably the bust one get hope for with a Java implementation.
I will try to show you in a code sample what I’m thinking about, but know that this is a unfinished thought of mine so there are still things missing.

The following is valid scala code


class Position
class Velocity
class Name
class Weapon

type Person = Position :: Velocity :: Name :: HNil

val entity : Person = new Position() :: new Velocity() :: new Name() :: HNil
val extraEntity = new Weapon() :: entity //add some component
val subPerson = entity.tail //only  Velocity :: Name :: HNil now

def printName[T <: HList](en: T)(implicit ev : Person isSuperOf T){
  val name : Name = en.select[Name]
  println(name)
}

printName(entity) //compiles
printName(extraEntity)//compiles
printName(subPerson)//does not compile
#11

What is the benefit in wrapping core properties like these in components as opposed to place them directly in entity classes ?

#12

Here are the several scenarios to which components would simplify my game engine, and would get ride of tons of interfaces:

  1. You could add a PhysicController to any entity that has position, velocity, acceleration, etc. it could also check “if this entity has angle, and has angular velocity, update it”. It would enable many things to be made into controllers that can be shared between entities of different types but similar characteristics.

  2. There are several systems in my game engine that require you to have an object with a specific interface. For example: Networking, Spatial Databases, Steering Behaviors, Particle Systems, etc. This leads to many many methods (getSpatialPosition(), getSteeringPosition(), getPosition()) that often all return the same vector. But sometimes this won’t be true. My Particle interface currently has the following methods: location, velocity, acceleration, size, scale, scaleVelocity, scaleAcceleration, angle, angleVelocity, angleAcceleration, color, tile, lifetime, age. So all particle implementations have to have these methods, whether it’s a particle type that has an angle or not (to which point angle returns null). I need these methods there because I have several classes which update different parts of a particle over time (like angle by angleVelocity).

  3. My networking library would be greatly simplified. You pass into a NetworkEntity class the components you want sent across the wire (as well as information about how often and the priority of each one). This makes it super simple to network an entity, you don’t need to use code that wraps your networkable attributes then pass them to the networking code (if that makes any sense). You just tell it which components, and it handles calling get and set!

I’m still torn, I think of all the simplified code it would take (and a lot less code), and I think of the small amount of overhead it adds.

#13

Maybe give a more verbose example of the mentioned code simplification.

#14

Ok, here are some examples.

Particle System Simplification


public interface Particle extends Entity {
	public void reset( float lifetime );
	public Vec2f location();
	public Vec2f velocity();
	public Vec2f acceleration();
	public Vec2f size();
	public Vec2f scale();
	public Vec2f scaleVelocity();
	public Vec2f scaleAcceleration();
	public Scalarf angle();
	public Scalarf angleVelocity();
	public Scalarf angleAcceleration();
	public Color color();
	public Tile tile();
	public void tile( Tile tile );
	public float lifetime();
	public float age();
}

And here’s an example of something I call a ParticleInfluence. It’s something that gets called every frame for every particle in the system which has this influence.


public class InfluenceAngle extends InfluencePath<Scalarf> {	
	public InfluenceAngle( Path<Scalarf> path ) {
		super( path );
	}
	protected void onInfluence( Particle p, float elapsed ) {
		path.set( p.angle(), p.age() / p.lifetime() ); // path determines what the angle is depending on a delta [0, 1]
	}
}

As you see this one is for the angle. I ALSO have one for color, acceleration, scale, size, tile, and velocity. Now If I used components, it would look like this:


public class InfluencePath<T> extends ParticleInfluence {
	public Path<T> path;
	public Component<T> component;
	public InfluencePath( Component<T> component, Path<T> path ) {
		...
	}
	protected void onInfluence( Particle p, float elapsed ) {
		path.set( p.get( component ), p.age() / p.lifetime() );
	}
}

So instead of doing…


ParticleEmitter emitter = new ParticleEmitter();
emitter.addInfluence( new InfluenceAngle( new Tween<Scalarf>( Scalarf.ONE, new Scalarf( 2.0f ) ) );
emitter.addInfluence( new InfluenceScale( new Tween<Vec2f>( Vec2f.ONE, new Vec2f( 1.4f ) ) );
emitter.addInfluence( new InfluenceVelocity( new Tween<Vec2f>( Vec2f.ZERO, new Vec2f( 200f ) ) );

It would be:


ParticleEmitter emitter = new ParticleEmitter();
emitter.addInfluence( new InfluencePath( Particle.ANGLE, new Tween<Scalarf>( Scalarf.ONE, new Scalarf( 2.0f ) ) );
emitter.addInfluence( new InfluencePath( Particle.SCALE, new Tween<Vec2f>( Vec2f.ONE, new Vec2f( 1.4f ) ) );
emitter.addInfluence( new InfluencePath( Particle.VELOCITY, new Tween<Vec2f>( Vec2f.ZERO, new Vec2f( 200f ) ) );

And I could also add:


public class InfluenceAdding<T> extends ParticleInfluence {
	public Component<T> subject;
	public Component<T> addend;
	protected void onInfluence( Particle p, float elapsed ) {
                p.get( subject ).add( p.get( addend ), elapsed );
	}
}

So I can do things like:


emitter.addInfluence( new InfluenceAdding<Vec2f>( Particle.VELOCITY, Particle.ACCELERATION ) );
emitter.addInfluence( new InfluenceAdding<Vec2f>( Particle.POSITION, Particle.VELOCITY ) );
emitter.addInfluence( new InfluenceAdding<Scalarf>( Particle.ANGLE, Particle.ANGULAR_VELOCITY) );

Which stuff like this enables the user to add their own update logic, instead of having this fixed in the ParticleSystem code:


Particle p = ...
if (p.velocity() != null) {
  if (p.acceleration() != null) {
     p.velocity().add( p.acceleration(), elapsed );
  }
  p.position().add( p.velocity(), elapsed);
}
// do the same for angle and size velocity & acceleration

I hope it’s clearer now.

#15

Thanks for the example. It is clearer now.
But, let me be the ignorant potential user of your game engine: I am still not convinced. I see no simplification, but the opposite. Every added abstraction and indirection makes things more complicated first of all.
If it is to avoid bloated interfaces due to many different implementations, then you can as well turn the direction flow: Let particle implementations be the master. Let them look for interesting game attributes and let them modify their own properties. Or turn them into event listeners and notify them about interesting events.

#16

Okay, I think I’ve been convinced to stay away from using them in my game engine.

For now at least…