Getting started with ECS in NEZ/monogame

Hi everyone,
I asked this on stack overflow but haven’t really gained much traction there’s so I thought I’d ask here too.

I’m just starting out with Monogame after spending a fair amount of time working with LibGDX and decided I’d take a look at NEZ to get me up and running a bit quicker.

In playing with NEZ I’ve been exposed to entity component systems for the first time and after a fair amount of reading I feel that I have a decent enough grasp on how they should work however looking through the samples that come with NEZ has me a bit confused.

In the NEZ Ninja Adventure sample (Available here: there is a fairly basic setup of:

Ninja - Component (appears to act as an archetype)
Mover - Component (Handles movement and contains a collision detection component)
SpriteAnimator - Component
All input handling (i.e. keyboard etc) is handled within the Ninja component’s update method.

Likewise, the projectile that the ninja can fire has a FireballProjectileController attached to it and in its on update method it calculates the move, performs collision detection and destroys the entity if it hits something.

In the above two examples all the stuff that’s happening in the update methods feels like the sort of thing you’d put into a system not an individual component’s update. For example

Create an input system that loops through all entities with an Input component and update their position based on the keys pressed and the value in the velocity component
Create a collision detection system that loops through all entities with a physics component and perform collision detection
So my questions are:

Is this just a personal preference of the developer of NEZ?
Should components have any code in them aside from some basic setters/getters/convenience functions for calculating changes to their internal values?
Is there an advantage to performing all this logic within the components rather than pulling it out into a system?

Its an option to have your code in a Component (Like Unity 3D). You can move all the update codes to a System and it will work fine.

My strong preference is for the Component to hold data/set up only and Systems to have all the pertinent code. I’ve worked with NEZ for a while now.

You can find some of my examples at:

1 Like

Same boat as you - I think it is really important to devide between components and systems.

Looking at the Ninja example, what if we want to add another moving entity - why should I force myself to duplicate the moving logic? using a moving system, all I need is adding the data component to the new entity, and I get the movement logic for free.

1 Like