Using multiple Worlds as spaces?

[JesseTG]

I just read an interesting article on Tuts+ about spaces, which are analogous to layers on Photoshop or similar; a game object (an Entity, in Anax's case) occupies a space, and interacts only with other objects on that space. My question is this; do you think it's a good idea to use Worlds as spaces by having multiple Worlds exist at a time, each with their own Entitys, Components, and Systems? Or might that break something?

[jabza]

I'm also trying to use multiple World objects, one for every State. However I think I might be running into a problem with the library as running World::Clear, gives the error: 'System does not exist in world'. I think this may be because System relies on some static dependency (the id thing?), and within my engine one state can be 'paused' (still in memory) whilst another is active. So Systems belong to separate Worlds.

As for you question, personally, I think breaking your game down into separate 'worlds' is a good way to go. However it depends on the use case, going on your idea of Photoshop 'layers' - you might be better having a lightweight SceneGraph class, that represents a bunch of EntityIDs. 'Layers' can be created by having multiple EntityIDs parented to your 'root' entity. You could then pass this graph to systems which care about how entities relate to one another. Done correctly, you could have many small modular SceneGraphs.

[JesseTG]

Spaces aren't a rendering thing, they're an architecture thing (although in practice, as I understand, they do seem to be good for splitting up visual layers). Although they could be used for graphical layers (foreground, background, etc.) that's not necessarily the case. That's just an analogy the article provided.

As for giving Worlds state of some sort, I'm actually writing a WorldStateMachine and WorldState class for my own game, taking some cues from Ash. A WorldState would be a set of Systems. When you change WorldStates, Systems common to the old and new WorldStates (rendering, input, etc.) would stay, Systems in the new WorldState get added, and Systems in the old WorldState but not the new one get dropped (e.g. when going from the main menu to the game and back, a physics system might be added or removed, respectively). If I can get it working nicely, I might open up a pull request. No guarantees, though.

[jabza]

Interesting idea. The concept behind the lightweight SceneGraph was to use it for more than simply rendering. The SceneGraph is merely one representation of the entities (entity groups). I have multiple SceneGraphs, some that share the same entityIDs. In my engine I pass these graphs to different systems, with a SceneGraphSystem providing an interface to generate graphs from any branch or entity tag ect. Allowing for more granular control over entities.

However, I agree that 'spaces' (as described in that article) are a much more fundamental idea than glorified SceneGraphs as in my case. Very interesting read.

[miguelmartin75]

My question is this; do you think it's a good idea to use Worlds as spaces by having multiple Worlds exist at a time, each with their own Entitys, Components, and Systems? Or might that break something?

That should work.

However I think I might be running into a problem with the library as running World::Clear, gives the error: 'System does not exist in world'

Should have reported that issue. I think I must've made a simple mistake. Will get this fixed ASAP and add a unit test.

As for giving Worlds state of some sort, I'm actually writing a WorldStateMachine and WorldState class for my own game, taking some cues from Ash. A WorldState would be a set of Systems. When you change WorldStates, Systems common to the old and new WorldStates (rendering, input, etc.) would stay, Systems in the new WorldState get added, and Systems in the old WorldState but not the new one get dropped (e.g. when going from the main menu to the game and back, a physics system might be added or removed, respectively). If I can get it working nicely, I might open up a pull request. No guarantees, though.

Seems interesting, I'd like to see this in use practically (i.e. within a game).