Help implementing an Entity Component System

Started by
16 comments, last by Alundra 7 years ago

I did one in XNA several years ago, shouldn't be hard to convert to MonoGame - or at least be helpful to look at the source code:

https://www.gamedev.net/resources/_/technical/game-programming/case-study-bomberman-mechanics-in-an-entity-component-system-r3159

This actually looks really cool. I'll be sure to try this out this weekend! Thanks.


Just search around for a lib that already implements it. If its something proven (ie, it has a few games to showcase) then better. You'll spend too much time implementing it from scratch and it wont be a much more enlightening experience than just checking out the implementation of an existing lib.

Yeah I've looked into frameworks like Nez or the C# implementation of the Artemis framework, but I am interested in trying to implement one myself (tends to help me understand the systems more if I at least give it a shot myself).


You can implement your Entity Component System but you have to be very carefully to implement all the situations, and test the system correctly.
One example : if you add one component you have to check if the scene is valid to call "AddedInScene callback" same when you remove the component to call "RemovedFromScene".
Unreal Engine calls that Register/Unregister, but it's the same thing, only another names which is maybe less understanding directly.
The best test is of course to have the system for one game, if you write all that for nothing of course you will never know.

Can you elaborate on that a little bit? Still a bit confused about what you mean by that.


Advertisement

Your Entity has a pointer of the scene where it is registered. If the scene is not valid (nullptr) you don't call the AddedInScene callback on component, same kind for RemoveComponent function.
When you add the entity in the scene, the scene class call NotifyAddedInScene which is a for loop on all components to call AddedInScene.
For the Physics component which is linked to physx, you create the physics here, for the sound you create the sound and play the sound here for example.
Another win of doing like that : if the scene is an editor scene, you don't create the physics and sound, only in game scene.

Another thing : Add a "CanHaveMultipleInstance" virtual in component which return true or false.
For example the rigid body component can only have one instance listed in the entity.

Ahh I see. Thanks for clearing that up.

Once you have all the system working you can also have an Activated parameter with SetActivated/GetActivated functions and one callback "OnActivated".
For the physics component it enable/disable the simulation for example.

Oh that's a good point.

As I recall, XNA already has it's own ECS implemented if you wanted to use that? Check out a few of these MSDN entries.

https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.gamecomponent.aspx

https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.drawablegamecomponent.aspx

https://msdn.microsoft.com/en-us/library/microsoft.xna.framework.game.components.aspx
http://tinyurl.com/shewonyay - Thanks so much for those who voted on my GF's Competition Cosplay Entry for Cosplayzine. She won! I owe you all beers :)

Mutiny - Open-source C++ Unity re-implementation.
Defile of Eden 2 - FreeBSD and OpenBSD binaries of our latest game.

The GameComponent stuff in XNA is not an ECS at all. It's classic OOP "call Update() on a black box". It's mainly intended for large systems, where a GameComponent might be the GUI, or networking or something.

From what I see in MSDN, it's an ECS, you inherit GameComponent with what you need or use the existing, you add this component on one game object.

This topic is closed to new replies.

Advertisement