Re: Modeling events that occur in a game world
- From: "H. S. Lahman" <h.lahman@xxxxxxxxxxx>
- Date: Sun, 22 Apr 2007 15:28:57 GMT
Responding to M....
Basically I agree with Sanford AND Kazakov...
I need a way of representing and tracking different events that occur
in a game I'm working on. I have a world composed of one or more
Maps. Each Map location (coordinate) may or may not have a Creature.
A Creature is controlled by an AI, which may also be the player's UI,
though the Creatures themselves are not necessarily aware of their
AIs. Creatures may move to different coordinates or attack other
Creatures.
Right now the two events I know I'll want to keep track of is when a Creature attacks another Creature and when a Creature dies, and I see
myself coming up with new events as my game grows more intricate.
Different parts of my game would be interested in different kinds of
events. The graphical display would be interested in all events so
that it may display an appropriate animation. More importantly, the
different AIs would need to observe recent events to modify their
behaviour. If a Creature is attacked, the AI controlling it has a vested interest in knowing about it.
These are events but the thing I would push back on is why you need to "keep track" of them. Normally events are just messages that announce that somebody did something that somehow changes the state of the application solution. That message needs to be routed to someone who cares what happened and has an appropriate response to it. That response changes the state of the application, a message is issued to announce it, and someone who cares about it responds, and so on...
So once the event is consumed (received by someone who cares and has an appropriate response) it essentially ceases to exist.
Games usually have some degree of concurrency (e.g., the Physics subsystem is figuring out current movement while the Rendering subsystem is throwing stuff on the display for the last movement). Concurrency is usually handled with asynchronous messaging. Asynchronous messaging is best managed with object state machines that capture sequencing rules as transitions. Object state machines come full circle to events and event queues.
So your event might persist temporarily on the event queue between the time it is generated and the time it is consumed. But there it is simply a message {event ID, <data packet>}. Whoever generates the event knows how to encode any data packet and whoever receives the event will know how to decode the data packet. All such dispatching is done based on the event ID through a state transition table.
I'm having trouble modeling this because the different kinds of
events would keep potentially arbitrary information, making it hard
to generalize. An attack event would know the attacking Creature, the
target Creature, and the amount of damage done. A death event would
just know the Creature that died. I might also implement Creatures
grabbing and throwing other Creatures, so a throw event would need to
know the throwing Creature, the thrown Creature, and where the thrown
Creature landed. For this reason I can't really make them subclasses
of a single Event class, since they hold such different information.
The event doesn't do anything; it is just a message. The receiver of the event does something in response to the condition raised in the event sender. The event ID tells the receiver which behavior to map to the event. That behavior will decode the data packet for parametric values.
Since that is a matter of private method implementation, one /could/ define an event as simply:
class Event
{
public:
EventID id;
Buffer* dataPacket; // just contiguous bytes on the heap
}
and let individual senders/receivers encode/decode the buffer. However, to preserve the developer's sanity in an elaboration environment, you probably need some more explicit definition of data packet in terms of types. One way to do that is to subclass Buffer. Another is to make Buffer an XML string. Yet another is to provide a specification object whose attributes provide parametric values that drive the encode/decode. (The category on Invariants and Parametric Polymorphism on my blog provide some examples of this.)
The real issue here is that when a Creature grabs another that changes the state of the application and other objects need to know that happened. So the grabbing Creature would send messages to whoever that is -- the other Creature, the AI, the Physics subsystem, the Rendering subsystem, etc..
Note that throwing the Creature is another change in the application state that is different than grabbing it. That will yield another set of messages that may or may not go to the same objects (i.e., different objects may care about throwing than about grabbing).
The bottom line here is that an OO application consists of a passle of logically indivisible behaviors owned by a gaggle of objects or subsystems. The flow of control is defined by connecting the dots of atomic behaviors with messages on a peer-to-peer basis (i.e., a direct collaboration between the object that triggered the new application state and the object that has a response to that new condition).
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
hsl@xxxxxxxxxxxxxxxxx
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
info@xxxxxxxxxxxxxxxxx for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
.
- References:
- Modeling events that occur in a game world
- From: Aaron J. M.
- Modeling events that occur in a game world
- Prev by Date: Re: Modeling events that occur in a game world
- Next by Date: Re: Modeling events that occur in a game world
- Previous by thread: Re: Modeling events that occur in a game world
- Next by thread: Re: Modeling events that occur in a game world
- Index(es):
Relevant Pages
|
