0
\$\begingroup\$

So, I recently started making a small game from scratch, with no engine used(I'm a beginner at this) and I want to create an event system of my own. I want to check if my general idea for it is okay(any suggestions to improve it will be nice too). For reference(if this helps) I'm coding this in C++.

My idea:

We have a class named NewEvent, which holds several virtual functions for setting event flags, getting the name, etc.

For more specification, we have a function getting the name of the event, a function setting the flag of it, another function getting the flag, another function finding which 'category' of event it is.

Outside of this class, we also have an enumeration of events that I will detect for so that we don't record everything, just the specific ones we want. Examples would be keypresses, key releases, mouse clicks, window movement, window closing, window scaling, and mouse movement. Not exhaustive, just a few.

We have derived classes from NewEvent that share the enumeration names, like 'class KeyPress: public NewEvent', 'class KeyRelease : public NewEvent', and so forth.

Then we have an event dispatcher class, which compiles these new events that have been detected into a static queue so that we don't create a queue every time we create another dispatcher. This is then fed into a static dispatch function which will run on a different thread and then the resulting information on what to do will be fed back into the main thread, which will then run what we want it to. The threading is mostly so that if events buffer and slow down for some reason, it won't slow down the actual main application.

I'll try to answer clarifying questions as best as I can, and if anyone has any suggestions on making this idea more robust or expandable, that'll be greatly appreciated as well.

\$\endgroup\$

1 Answer 1

2
\$\begingroup\$

First of all, there is no "right" or "wrong" in software development. Only "works for you" or "doesn't work for you". So any advise about your software architecture that is only about one part of it in isolation without having access to the big picture or the exact requirements for your engine should always be taken with a grain of salt.

But a few things I notice here:

  • Why is the base-class for your events called "New" Event? That's a weird naming convention. I would rather call it something like EventBase to communicate that it is a base-class for all events or something like AEvent to communicate that it is abstract. I would also find it a lot more orderly if all the specific event classes would either have "Event" in their name or be in a event:: namespace, so they can be immediately recognized as events. But there are only two difficult problems in software development: Cache invalidation and naming things. So this isn't something we should argue about.
  • Are you sure you want only one global, static event queue? It can often make sense to have separate event queues for sub-systems that are isolated from the global event queue. If you still want the convenience of accessing these statically, you can create a bunch of static getter-functions on your EventQueue class to retrieve a specific event queue.
  • This is then fed into a static dispatch function which will run on a different thread [...] The threading is mostly so that if events buffer and slow down for some reason, it won't slow down the actual main application. Are you sure this is a good idea? First of all, the mere dispatching of events without reacting to them is rarely going to become a performance bottleneck. If you generate so many events that it does, then either something is going very wrong resulting in unnecessary event spam or you are communicating stuff via events that probably shouldn't be an event at all. And when it does, it's going to become a big issue. The possibility that the delivery of certain events could be delayed by a couple frames for unpredictable reasons sounds like a great generator for impossible to reproduce bugs.
  • "the resulting information on what to do will be fed back into the main thread" I just hope that what you actually mean with that is that the events will be stored in thread-safe buffers, which the main thread will then process at designated points within the game loop. And not that you are just having the dispatcher thread write into the data model without any concerns for thread safety. Because one thread changing data while another thread operates on that data is another great generator of impossible to reproduce bugs.
\$\endgroup\$
3
  • \$\begingroup\$ Thank you for the reply! Regarding your second point, that's a good idea. I suppose(correct me if I'm wrong about this) that we have one queue collecting player input(key, mouse), and another queue handling something like window events, and another queue for handling game events, and so forth. I can see the logic behind this, so thank you for the idea! \$\endgroup\$
    – HavocKid
    Mar 5 at 4:06
  • \$\begingroup\$ And regarding your third point, I can see why a simple dispatch itself won't be a bottleneck since it isn't actually doing much by itself. However, I can see possible performance bottlenecks by running the corresponding event functions on the same thread. In this case, I would think that it's better to run the actual event CallBacks on a different thread. Finally, regarding your last point, yes I did mean that. I suppose I should've made my post more specific about how the data gets fed back into the Main Loop. Thank you for pointing it out! \$\endgroup\$
    – HavocKid
    Mar 5 at 4:07
  • \$\begingroup\$ @HavocKid "I would think that it's better to run the actual event CallBacks on a different thread. -> You mean the event callback functions that actually causes stuff to change in the game state while the main game loop is processing the very same data on a different thread? That's a really bad idea. I can guarantee you that this will lead to a ton of weird bugs that will be impossible for you to reproduce. \$\endgroup\$
    – Philipp
    Mar 5 at 9:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .