4

Don't shove all the events into one type. You are using C++, a language that supports Abstract Data Types. Use them! Inheritance/Interfaces struct Event { TYPE type; virtual void Handle() = 0; }; struct DamageEvent : Event { float damage; int target; void Handle() final { FindTarget(target).TakeDamage(damage); } }; void ...


4

Blackboard systems started in AI programming. Their context in Entity systems is less of a problem solving role, and more of a "place to exchange information" role. The implementation of the blackboard system can very a lot. Even to the point that you wouldn't be able to tell the difference between that and a message que. It's just a known place to put ...


4

Create a separate message class for each type of message (to a degree). In your entities, make a different method for each type of message. eg. class CollisionMessage; class DamageMessage; class Entity { public: virtual void onCollision(CollisionMessage&); virtual void onDamage(DamageMessage&); }; You can now use a form of double-dispatch to ...


2

First of all: Don't just block user input as done by some games. It creates bad user experiences. One popular example: "What a horrible night to have a curse." (Castlevania II - Simon's Quest if you didn't know it. Lookup the Angry Video Game Nerd's review on YouTube. You'll get what I'm talking about.) For dialog/story elements or tutorials the user should ...


2

In a comment you said that every message is only valid for one scope. When that's the case, you actually have three separate message systems here and should have separated infrastructures for them. Create separate enum's for GameObjectMessageId, SceneMessageId and CoreMessageId. Also create three separate methods ReceiveGameObjectMessage(GameObjectMessageId,...


2

Usually messaging systems work by having a message receiving interface that other classes can implement if they want to receive messages. It can be something simple like this: class MessageHandler { public: MessageHandler(); ~MessageHandler(); virtual void MessageHandler::handleMessage(MessageType msg, MessageSender* msgSender, ...


2

There's a lot to balance in practical game development. Generic event system vs domain-specific: One doesn't preclude the other. You can use a generic queue system: audioQueue.SendEvent("PlaySound", deathSoundID); And wrap it in a convenient function: void playSound(ID_TYPE soundID) { audioQueue.SendEvent("PlaySound", soundID); } //... playSound(...


2

This sounds like a pretty simple task. First of all, you need a database to store your messages; presumably you already have one for your user accounts, but if you want recommendations, MySQL, PostgreSQL and SQLite are all common choices and should do fine. Next, you'll need a table to store the messages. A typical message table should probably contain at ...


1

There are two possible approaches to what you are describing, one wrong and the other useful. The wrong approach is to simply delay the user input from activating the command. Assuming you know the other clients can be informed 99.9% of the time in half a second, delay the command for half a second and send it to the other clients as the pair <command, ...


1

If you go with enums, you could just make an array of function pointers to call for each value instead of a map. Something like this: typedef enum { Delete_HP = 0, Pause_Game, //... etc. } MessageID; Then the array of function pointers: typedef void* function(Message*) messageF; messageF msgHandlers[] = { deleteHearth, showPauseIcon, ...


1

You didn't specify language, but there's some options that should work regardless. The first question to ask yourself is if this is a problem that actually needs solving, though; is this a hypothetical problem you have with your code or are you wasting considerable time/money by frequently sending events to the wrong places? Signals and Slots One is to ...


1

Supposing your OnUpdate function always either find or search, you can print your searching message when you don't print your Found the cube message: if (Vector3.SqrMagnitude (transform.position - target.Value.position) < 0.1f && !pietje) { PrintMessage ("Found the cube."); pietje = true; return TaskStatus.Success; } if (pietje) ...


1

I figured it out! All I needed to do was add a in.readUTF() for each out.writeUTF() I used.


1

The syntax of your code snippets is Java, but this answer is from the perspective of C++ as that's what most game engines are written in. Message Objects Pros Usability. Message objects are flexible and easy to debug. Since message objects names are known at runtime, you can easily print them, assert on them, etc. without having to write any reflection or ...


1

Another way you could go about it by using a "generic" map for your parameters: int HashStringToInt(const std::string& aStringToHash) { // Hash your string here } union Value { int _int; double _double; bool _bool; }; struc Event { int _id; std::map<int, Value> _parameters; }; void boom() { static const int EVENT_EXPLOSION = ...


1

One way to make this easier to use is to let a user emit message types. Check out some example implementation (see Messenger.h and .cpp). The idea is to let a user do something like this: // Subscribe to a particular message type as a user messenger.Subscribe( MSG_type, CallThisFunction ); // Notify the client messenger.Emit( MSG_type ) // calls ...


1

Put this functionality wherever you want. Sure strict and "pure" ECS says don't put things in your components in order to avoid OOP. This usually just hinders everyone still learning from thinking about how to write useful code. You clearly understand how to implement a form of messaging, so just use it and don't waste time trying to adhere to some ...


1

Using callbacks can be one way to decouple parts of a program. They're often used in GUI interaction because this interaction is generally sporadic and not something that happens excessively. So the caveats and downsides to callbacks don't out weigh the benefits of them. If you intend to use callbacks for event handling, be mindful that emitting function ...


1

The "best" is hard to say, you should test different technologies. I my case, I used C++ to create the server and js for client: The client comunicate by ajax with the server, but never close the socket. To allow that, it should expect steaming data. The server is made with C++, using a very fast http/https sub-set. When a client send a chat text, the ...


1

Separate queues per data type to end casting. (I like this one better as it is simple, flexible, and allows for explicit ordering of types of operations) class SpawnEntityEvent { public: std::string resource; double x,y,z; }; class MoveEntityEvent { public: Entity* ent; double x,y,z; }; class ChangeEntityPropEvent { public: Entity* ent; ...


1

A good way of keeping users from making a dialogue choice or skipping by accident is to not allow the choice for a period after it has appeared. Depending on the seriousness of making the mistake you should choose a time somewhere in the 2 to 5 seconds range. Having a visual cue about what is going on is usually best as it informs the user that your ...


Only top voted, non community-wiki answers of a minimum length are eligible