Sorry for posting this so late. I posted it on my team’s website, but I forgot to also post it on my personal website. And not only that, but I really need to write my week 5 post, so you’ll be seeing that come up soon.

Week 4 was the last week of month 1 for my team and I. So I had to rush to get in features that we needed to have done; things pretty fundamental to the game. The most fundamental thing for our game is networking.

Networking is something Sam has been working on by herself while the rest of us were doing our other things. And networking is the most important thing for our game because it dictates how we should handle our code. This is because the server, the thing that hosts the game, is the only thing that should change any of the variables in the game. This means stuff like positions, score, collision detection, etc. The way we had our system wasn’t taking into consideration this, so I had to help Sam make the engine work correctly with networking.

This is how I spent the majority of the week because it’s a pretty big task. I had to send input to the server, so that the server could move any of the positions of the objects if it saw fit. I also had to make it where the only thing the client does is practically just render the objects and communicate with the server. Luckily, before I started helping Sam with networking, I made an event manager that could communicate with different things easily.

It may not be the best system—and I made some improvements to it week 5—but it works. I made three things to make the event system work: an event dispatcher, an event handler, and an event. An event is a specific thing that contains information about that specific event. This is meant to be an abstract class that will be inherited from, so I could make all types of events and use them as the base class in the event dispatcher and handler.

Now, the event handler is something that handles an event. To make this work, any object that I want to be able to handle an event inherits from event handler. Event handler has an abstract function that is called HandleEvent. This must be overriden, so the event handler can work with the event dispatcher. Inside the HandleEvet function, you must filter through all the types of events that you want that specific object to handle. Also, when an object that inherits from event handler is initialized, it needs to register itself with the event dispatcher.

The event dispatcher goes through all the event handlers that have been registered, and it calls their HandleEvent function while passing in any event you tell the event handler to send. Event handler is a singleton, so that we can use it in any class in our engine.

Because the event handler is a singleton, I can use it to send input between the client and the server. It will also be great to send events to pieces that really aren’t connected. Now, it’s a bit inefficient because every handler is sent the event even though you might only want one handler to receive it, but I did fix this up a bit in week 5.

As for Wwise, I got sound to play. I did this by loading in .wav files into the Wwise program and then making some events for them and exporting them as a soundbank file. Then on the Wwise library I made, I load in the bank, and then I can PostEvents to it from the engine to play sounds.

I was a little late with this post because of the switch from month 1 to month 2, so this means I’m already almost done with week 5. Lots of progress is being made because I have more hours this months because I don’t have another class. I can’t wait to talk about the new stuff coming into our game/engine.