Game Development Reference
In-Depth Information
void HumanView::VOnUpdate( int deltaMilliseconds )
{
m_pProcessManager->UpdateProcesses(deltaMilliseconds);
for(ScreenElementList::iterator i=m_ScreenElements.begin();
i!=m_ScreenElements.end(); ++i)
{
(*i)->VOnUpdate(deltaMilliseconds);
}
}
This code deserves a little clarity, perhaps, since there are a number of potentially
confusing things about it. A game object that exists in the game universe and is
affected by game rules, like physics, belongs to the game logic. Whenever the game object
moves or changes state, events are generated that eventually make their way to the game
views, where they update their internal representations of these objects. A good example
of this are the ever-present crates in games like Thief: Deadly Shadows
you can knock
them downstairs and break them open.
There is a different set of objects that only exist visually and have no real effect on
the world themselves, such as particle effects. The VOnUpdate() that belongs to the
human view is what updates these objects. Since the game logic knows nothing about
them, they are completely contained in the human view and need some way to be
updated if they are animating.
Another example of something the human perceives but the game logic does not is
the audio system. Background music and ambient sound effects have no effect on the
game logic per se and therefore can safely belong to the human view. The audio system
is actually managed as a Process object that is attached to the ProcessManager
contained in the human view.
But wait
'
t Thief: Deadly Shadows have systems that allowed the
AI characters to respond to sounds? Well, yes and no. The AI in Thief didn ' t respond
directly to what was being sent out of the sound card, but rather it responded to col-
lision events detected by the game logic. These collision events were sent by the game
logic and were separately consumed by both the sound manager and the AI manager.
The sound manager looked at the type of collision and determined which sound
effect was most suitable. The AI manager looked at the proximity and severity of
the collision to determine if it was inside the AI
you might ask, didn
s motivational threshold. So the
AIs actually responded to collision events, not sounds.
The real meat of the human view is processing device messages from the application
layer. Somewhere in the application layer of all Windows games is the main message
processor, where you get WM_CHAR , WM_MOUSEMOVE , and all those messages. Any
'
Search WWH ::




Custom Search