Skip to main content
Game Development

Return to Question

Bumped by Community user
Bumped by Community user
Bumped by Community user
Bumped by Community user
added 24 characters in body
Source Link
Tim
Tim
  • 191
  • 3
 

---EDIT---

EDIT

 

---EDIT---

added summary of read posts
Source Link
Tim
Tim
  • 191
  • 3

EDIT

So I've read a few other posts suggested by comments and got a general idea about possibilities, however each of them seems to have one major downside which makes them just not right. It's is very possible that I'm overseeing details that would solve these downsides so feel free to correct me. I'll try to give an overview as well as some answers to some questions.

I'm seeing three major options to 'share' data between spaces. Even though most posts are about sharing data between systems, I feel like the same can be applied to sharing data between systems.

1. Querying

Example: If the HUD world needs to know the current health of the player it can query another world and ask for the current health.

Downside: Worlds need to know about each other which is a major dependency issue and goes against decoupling.

2: Direct messaging (sync and async)

Example: If during combat the health of a player changes it can send messages (sync and async, whatever is needed) to other worlds that need to know about this change.

Downside: Still the decoupling issue: worlds need to know about eachother.

3: Indirect messaging (sync and async) <-- best option

Example: If during combat the health of a player changes it can send messages (sync and async, whatever is needed) to general message hub. Other worlds/systems that need to know about this change are subscribed to the particular message channel and read the messages.

Upside: Completely decoupled, easily manageable and extendable.

Downside/unclear: When does the message channel know that the messages need to be deleted? Or maybe the system that is subscribed marks (only for itself) the message as read and waits for new messages -> messagebox becomes enormous after a while. How do worlds/systems handle order? For example during a frame: if the HUD already polled the health message and after that the health changes, the next frame the HUD gets updated. For some applications this might not be the right way.

Q: A single game object can exists in multiple spaces

I'm using Artemis ECS framework which comes with build-in spaces (called worlds). Each entity (and with it, the data in the form of components) is created on a world and thus cannot be shared between worlds.

EDIT

So I've read a few other posts suggested by comments and got a general idea about possibilities, however each of them seems to have one major downside which makes them just not right. It's is very possible that I'm overseeing details that would solve these downsides so feel free to correct me. I'll try to give an overview as well as some answers to some questions.

I'm seeing three major options to 'share' data between spaces. Even though most posts are about sharing data between systems, I feel like the same can be applied to sharing data between systems.

1. Querying

Example: If the HUD world needs to know the current health of the player it can query another world and ask for the current health.

Downside: Worlds need to know about each other which is a major dependency issue and goes against decoupling.

2: Direct messaging (sync and async)

Example: If during combat the health of a player changes it can send messages (sync and async, whatever is needed) to other worlds that need to know about this change.

Downside: Still the decoupling issue: worlds need to know about eachother.

3: Indirect messaging (sync and async) <-- best option

Example: If during combat the health of a player changes it can send messages (sync and async, whatever is needed) to general message hub. Other worlds/systems that need to know about this change are subscribed to the particular message channel and read the messages.

Upside: Completely decoupled, easily manageable and extendable.

Downside/unclear: When does the message channel know that the messages need to be deleted? Or maybe the system that is subscribed marks (only for itself) the message as read and waits for new messages -> messagebox becomes enormous after a while. How do worlds/systems handle order? For example during a frame: if the HUD already polled the health message and after that the health changes, the next frame the HUD gets updated. For some applications this might not be the right way.

Q: A single game object can exists in multiple spaces

I'm using Artemis ECS framework which comes with build-in spaces (called worlds). Each entity (and with it, the data in the form of components) is created on a world and thus cannot be shared between worlds.

Tweeted twitter.com/StackGameDev/status/732223703564599297
Source Link
Tim
Tim
  • 191
  • 3

Entity component system - game progression

I'm quite new to game development (but not to programming) and I'm trying to figure out what would be the best way to handle inter-world communication. What I mean is this:

I've been reading about entity component systems (ECS) and how people suggest using different worlds/spaces (http://gamedevelopment.tutsplus.com/tutorials/spaces-useful-game-object-containers--gamedev-14091) for a subsection of a game. For example a HUD, inventory or combat/movement each get a seperate world/space (because they have different graphics and underlying logic.

However, I was wondering how the inventory, or the HUD knows about the health of a player when the health is handled by a different space/world, for example when in combat?

This also applies to game progression in general, for example dialog with NPC (a dialog would be a separate space since it's a popup screen) but how would you convey the choices made in (or the state of) the dialog to other spaces/worlds. Or basically any other type of event that influence the game progression in different spaces/worlds (health, mana, quests, dialog, combat, inventory, hud, etc)

How would one handle this kind of design? Does it need a (in implementation) singleton object that holds all this kind of information? That would be weird because then the components need to convey each change to this singleton object which feels like doing things twice (going against the main DRY of programming)...

I'm kind of at a loss here in terms of design, any pointers?