Actors, cues, event based logic.

Okay, lets take a step away from engine programming, architecture, implementation, you get my point, lets talk more about game logic, and how to program it. Event based logic has recently sparked my interest and I'd like to implement it (even if in a text based RPG).

I've done some googling and havn't come up with much, through talking to a friend on AIM (one of the lead programmers for Visual3D (www.visual3d.net), he told me that an event based logic system would lend itself well to almost any game engine.

So maybe we'll have an actor class, a class that has a list of possible response functions, and also a list of possible cues... Each actor will listen for cues in the "event handler" class, if an event happens in the event handler loop and a certain actor is listening at the time, he will have recieved his cue and respond accordingly.

To put it into a less arbitrary sense, think of winning your space invaders level, you're at the boss, and successfully defeating him will end the level. So you kill the big bad boss, a cue is sent to the level actor, level actor is like oh, you killed the boss, you win! Congratulations, level is over.

Is there anyone out there who can try to unmuddle this concept in my brain, in terms of code I mean, what kind of arbitrary base classes do I need to implement? ETC ETC ETC :).

Thanks.

You seam to have allready got it figured out. Create an Actor class that will be the base class for all actors and give it a virtual EventHandler function. In the EventHandler use a switch statement to compare the value of the event with values that the actor can respond to.

Have an event dispatcher which iterates thru a vector of Actor pointers calling their HandleEvent function, you make an actor listen by adding it to the vector.

It all depends on how you wish to design your system.

My dev team and I have come up with our own version of a WndProc, called ScriptProc, which responds to messages. The base ScriptProc will push the new message onto the object's queue and also pop the most recent one off for processing. It then responds to the message.

The script class is reponsible for turning script ID's into actual objects, filling in the Message structure according the script command being used, and then call the object's ScriptProc. Every object can respond to messages or can pass the message on to default handling. If the object does not respond, the message is not executed. This allows the script class to be a simple mediator between the actual script and the objects. It does not directly call any specific functions to execute script commands. This is handled in the object's ScriptProc. So essentially the response to the message is inherit to how the object implements the function for the message being issued. This is where I feel the bulk of the processing should lie anyways - inside of the object class.

This is very similar to how Windows works and it is complex, but it is extremely flexible and extremely powerful.

The engine also has a ScriptProc so it is reponsible for executing script commands that relate to engine-specific functions.

So far we have Object Messages (OM_xxx), Engine messages (EM_xxx), and Script Messages (SM_xxx).

Later on when we release the game the text scripts will be compiled into our own proprietary format similar to opcodes in assembly. This will make them harder, but not impossible, to hack.