Spatial, Control and not graphic objects (design question)


I’m a new user of JMonkeyEngine, and I need some explanation in order to build the architecture of my project.

Let me explain you what I have today.

I have one class called World which is a manager of entities. His biggest job is to dispatch events between entities.


public class World extends AbstractAppState{

int mID = 0;

Map<Integer, Entity> mEntities = …;

Set<Event> mPendingEvents = …;

public Entity createEntity(String Name) {…}


public void update(float elapsedTime){

// Dispatch events




What I call Entity can be a graphical or non-graphical thing in my game. For example, an entity can be a trigger, the player character, a non-player character, a light, or a set of data not linked to something displayed. So, it isn’t a Spatial (ie:a set of data) and sometime can contain a Spatial (ie: the player character).

As you can understand today my node hierarchy (only graphics entities) is different from my world hierarchy (all entities).

I want to introduce the component design in my game (fyi: this approach involves that all entities contain a set of components and update them). I discovered that JME offers something very similar called control but this is dedicated to Spatials. Extends Node for each Entity seems stupid because some of my entities aren’t graphical, so what is the solution ? I think it will be stupid to update my World hierarchy first (component approach) and then my Node hierarchy (logical state + render). Twice traversals, twice the job…

Any idea ?!

An entity just needs to be a number and no actual class doing or storing much stuff really. If you use controls and dont want to have them attached to a Spatial, you can have some other class that holds them. However whats the problem using Spatials, Controls and UserData for this? Read the wiki on best practices, especially the areas on AppStates, Controls and maybe Multithreading.

I carefully read appStates, controls and Multithreading, but I think that my question is project specific.

For the solution 1, I was thinking about it.

And for the second solution my only objection is that I will push on the scene graph “object” that aren’t graphical and that doesn’t need to have a localisation, a rotation and a scale. Maybe, I’m inventing my own problem because if I don’t take care of localisation and rendering methods Spatial class suits my need.

Why dont you just assign non-graphical entities to non-spatial controls and attach these into a global collection.

So you let the spatial-bound controls update themselfs and update the non-spatial controls manually by iterating through the collection?

I found the answer to my design question in this awesome book : Game Engine Architecture By Jason Gregory, Jeff Lander

Click here to read the chapter dedicated to my issue (Google Books)