Game Development Reference
In-Depth Information
Death in the Kingdom
The death code in The Sims Medieval works more or less like it did in The
Sims 3, but we had a number of new systems that had to respond to a sim
dying. There was a quest system, for example, that had to ensure the sim was
properly removed from the quest and potentially fail the quest if this was an
important NPC (or the player). We also had to ensure that the role system
knew about the death. If it was a town guard, blacksmith
'
s apprentice, or
some other
that died, the role system had to generate a new one
to replace the dead sim. This could have been a major hassle if it weren
role sim
t for
the event system. When a sim died, the death system sent an event. All we
had to do was make our new systems handle this event appropriately. The
death system didn
'
'
t have to know anything about the new systems, and the
new systems didn
t have to know anything about the death system. They just
knew that Garvin the Town Crier was dead.
'
The game event system is organized into three basic parts:
n Events and event data
n Event handler delegates
n Event Manager
Events and event data are generated by authoritative systems when an action of any
significance occurs, and they are sent into the Event Manager, sometimes also called
a listener registry. The Event Manager matches each event with all the subsystems
that have subscribed to the event and calls each event listener delegate function in
turn so it can handle the event in its own way.
Events and Event Data
A classic problem in computer games is how to define types of data or objects. The
easiest way to define different types of elements, such as event types, is to put them
all into a single enumeration like this:
Enum EventType
{
Event_Object_Moved,
Event_Object_Created,
Event_Object Destroyed,
Event_Guard_Picked_Nose,
// and on and on
.
};
 
 
Search WWH ::




Custom Search