EEvent
At the time I'm writing this, there's absolutely no way the client can know what's really happening. Until now, the only thing that's different (from the client's view) between a harmless collapse and a base conquer is that it got a different message in English. That poses a great problem as soon as you want, for example, play a different sound depending on what happened. You can't just use the same sound for these both game events.
So here's my solution to this, having, the same way we separate content and presentation in webdesign, we'll separate the actual event and what to do when it happens. So at one side we have the server telling the client that event X happened, on the other side an event resource describing what to do when event X or Y is received.
Goals
- Get a working sound engine :)
- Modular approach, especially needed for event resources
- Future-Proof, as in, you can make up new kinds of event types
- Event description resources
- Client/Server AND Server/External service communication
Milestones
- Working sound
- Event resources
- Text events fully done via eEvents
- External communication (not very important for now)
General Concept Overview
You got 3 main classes:
- eEvent
- eEventType
- eEventHandler
The eEvent object is what is sent over the network. It's lifetime is short, it's used from the moment when the event is known to happen to the moment when we send it to everyone(or not). It wields an eEventType and a list of arguments, a bit like tOutputs that have a name string and a list of arguments.
The eEventType class defines an event type. Really. There is a big list of all eEventTypes so that you can name an eEventType using a string, but you don't have to worry about it anyway, the contructor's main role is to do that for you. So, an eEventType comports: a name string, which is used for transmission via eEvents and for naming; it also has serval eEventHandlers, which will be used when the event is received.
The eEventHandler class defines an action to be done when an event is received. It's some sort of strange class that wasn't designed properly. Uhm, not at all :) Main planned features include argument handling/wrapping, net state dependence and such. FIXME: do this
