Get in line buddy!

HEY GUYS

So, story time! I was on the bus home yesterday after hanging out with a few friends. And it was a loooong ass bus ride. So my first thought was to whip out my notebook and start working. After 30 minutes of that, and at the point where my wrist was sore, I had an epiphany, I was a workaholic. I spent 6 hours a day sleeping, the other 18 hours are spent between my full time job, and writing notes for the game. My whole life had been going from one phase of slacking to another. And for the first time in my life, I found enjoyment and maybe even addiction to work. Getting into game making was definitely a great choice. Life is good.

And now on to the real reason you’re here. Today’s post is going to be a doozey; it’s going to hit a bunch of areas. Let’s start with how I’m going to implement the event handlers.

My plan for the event handler system is to have each class of event have its own handler. There’d be a collision detection handler, movement handler, etc. Each of these handlers would need to inherit from an interface class. If for nothing but for me to practice using interfaces lol. Inside each event handler, will be a queue item. There would be an add event method that would be public and could be called by other actors. Each handler will also have a transfer event method. The event handler inside the main logic thread will act as a hub and all other event handlers are simply nodes accessed by the hub. There may be further transfers depending on if some event causes chain reactions or something. There will also be use of delegates in event calling. For things like collisions where logic, graphics, and audio all need to be called.

In the game architecture where there is a huge separation between the various actors, I cannot implement a central event handling center, which could just be a single thread. Splitting it into multiple threads that run all the event handlers for each actor, is way too resource consuming. So instead of having individually threaded event handlers, the event handlers would get the illusion of threading. In each cycle of the outer thread that they’re all running in, I would allow each of them to run for a certain number of inner cycles, depending on importance. For example, I would let the collision detection handler run maybe 10 times and take 10 items off the queue, but I would run the player input handler 20 times. I want a much more emphasis on responding to player actions than the collisions. Missing a collision here and there is fine in a game like this, but missing fine adjustments by the player due to bad threading is not acceptable.

Objects get a timestamp of the time that they’re added into a queue. The top entry in the queues should be checked by the event hander that takes items off the queue before handling it, it is discarded and moves onto the next item if the top item is say older than 1 second. If it’s older than 1 second, clearly something has gone wrong and that event is now irrelevant.

There are also the events handlers that only run at specified times. Mainly, the pause menu event handler. When a pause menu is called, the thread that calls it passes control of the player input queue to the new handler. I was originally going to say, that the queue should be cleared out once the new handler is called, so it only processes new commands, but any commands sent by the player after he hits the pause menu button is clearly in anticipation of that menu being there. The player input queue isn’t going to get nearly as many events as the other handlers anyway so meh. The queue system isn’t even necessary in this case.