After finals though, I did put a bit of work into fine tuning WynterStorm. I've found that when programming in C++ I tend to prefer references over pointers where available. For some reason I had believed that references didn't call virtual functions where pointers did. I used to find this very odd, but apparently never actually tested this belief I had. Well as it turns out, references can and will call virtual functions just fine; I'm just retarded. So I began migrating some of the code from transferring pointers to transferring references. One area that I did this in was the Event system. It used to be that I would have to 'new' an event when sending it. This seemed like bad style to me and I could see this leading to quite a few memory leaks unless I didn't manage this properly. Switching this over to using constant references should fix this, and also reduce time spent typing (By two whole keystrokes per event access. Oh yeah!).
So I believe I've briefly mentioned Signals before. If not, I'll explain here. In WynterStorm I currently have two systems that pretty much achieve the same process in a different way, Signals and Events. I've been debating with myself over whether to keep or remove Signals. As it stands, the two systems have distinct purposes. Signals are used specifically for properties. When a property is updated, a signal is called to notify that this specific property has changed. This allows me to extend class functionality to have the class update itself based on the property change. I believe I mentioned before that this is used in the Shard::Window class, which has the property 'title'. When title is assigned a Crystal::String, which is just a typedef of std::string for the time being, the signal 'sigTitle()' is called that instantly calls the 'setTitle()' function, instantly updating the window's title. In this case the benefit is more about coding style as opposed to functionality but it could also have benefits when used in gameplay.
The second system, Events, is used to send updates to other objects and systems. This will be used more for sending events between entities and between the game systems. I've also been thinking about expanding the event system to allow some sort of serializability to allow for easy expansion to some sort of NetworkedEvent system. I'm imagining this wouldn't be all that hard to achieve given that my event system currently relies on my own RTTI implementation. The one thing that I'm lacking right now in achieving this goal is a sort of NetworkedObjectID class for automatically managing objects between clients. This is one thing to add to my research list.
Well it's 2:30 AM as I finish this and I have somewhere to be in less than 8 hours so I better get some sleep.
Any thoughts, criticisms, concerns, or possible improvements to any of the ideas I have mentioned would be well appreciated.
-Wynter Woods
