The Case for Message Passing Architectures Dave Weinstein Red Storm Entertainment Ubisoft

The Case for Message Passing Architectures

Dave Weinstein

Red Storm Entertainment

Ubisoft

Introduction

Message passing architectures have been used in game development for over a decade, and while many developers assume that networking needs drive this style, it is my contention that the benefits in terms of overall code clarity, and reduction of critical path dependencies make message passing architectures useful even for single player games.

Message Passing for Network Traffic

Message passing architectures lend themselves particularly well to network games.

One of the biggest risks for any multiplayer game is the degree to which the single player component and the multiplayer component differ. The more the code paths diverge, the more likely it is that fixes in one area will break another, and the less benefit either gets from QA testing.

Message Passing for Network Traffic: Dividing Logical TasksIn single player games, it has been common for the code that determines whether an action is desired, whether an action is valid, and what the results are to be intertwined. These are three discreet steps that any networked game requires separated, and message passing architectures are no different. However, if the game messages are divided into request, confirm, and report steps, the code path of the single player game and the code path of the multiplayer game can be almost identical.

Message Passing for Network Traffic: Fail Soft Solutions

If game flow is broken up into multiplayer friendly discreet steps, however, multiplayer gameplay for new features becomes almost automatic.

A generic “fail soft” enables any new feature to work by default in a multiplayer environment, even if the network traffic involved is higher than optimal. By keeping the networking engineers from having to play catch-up with the rest of the engineering team, the amount of time that new features during development breaks the multiplayer

component is greatly reduced.

Message Passing for Network Traffic: Optimizations

The generic case for any message (regardless of implementation) will almost always be less efficient in terms of bandwidth than a specialized version. The more that can be assumed about the contents of a message, the tighter the actual network traffic can be.

Message Passing for Network Traffic: Example, Tom Clancy’s Ghost Recon

voidIkeMsg_GunshotMissed::WriteBin( std::ostream& outStream )const{ ASSERT( mGameMessage ); mGameMessage->WritePayloadWithoutType( 0, outStream ); // GameObjectID mGameMessage->WritePayloadWithoutType( 1, outStream ); // InventoryItemIndex

// compress direction vector RSFloat2* compVec = RSFloat2::Create(); RSPayloadUtils::CompressUnitVector( (RSFloat3*)mGameMessage->GetPayloadObject( 2 ), compVec ); compVec->WriteBin( outStream );

compVec->Release();}

Source, Tom Clancy’s Ghost Recon, copyright Red Storm Entertainment/Ubisoft, used with permission

Message Passing as Abstraction Layer

With the introduction of Object Oriented programming methodologies, developers became used to deferring the actual implementation of a logical concept.

Message passing architectures allow us to use the same basic principles for the flow of the application.

Message Passing as Abstraction Layer: Genericity

pUnit = gObjectManager.GetObject( unitID );

if( pUnit )

{

pUnit->ApplyDamage( damageAmount );

}

Example: C++ object oriented application

Send( kMsgID_UnitDamaged, unitID, damageAmount );

Example: Message passing interface


Note that these two approaches are not contradictory. It would be entirely reasonable to see the object oriented approach as the implementation of the response to the damage message at the simulation level.


The message passing system works, even in a single player architecture, for the same reasons that we use virtual function interfaces at the class level.

It provides a generic interface that provides a significant abstraction layer between modules, and from a project management standpoint, between

developers.


In the following example source code, taken from Force 21, the User Interface is handling the damage message, and using the information in it to adjust the display.

case kDamageMsg:{ for( int i=0; i < Unit::kMaxVehicles; i++ ) { SetVehicleDamage( i ); }

// Find unit damaged and blink that button. GameObject* obj = NULL;

if ( target.Type() == MessageArg::kMAObject ) { obj = target; } else if ( target.Type() == MessageArg::kMAUnsignedLong ) { obj = theGame.mObjDB->FindObject( ObjId(target) ); }

if ( obj && ISA(obj, Actor) ) { ObjId unitId = ((Actor*)obj)->GetUnitId();

Unit *pU = theGame.mObjDB->FindUnit( unitId );

Force* force = theGame.mRulesEngine->GetForce( theGame.mRulesEngine->WhoDoIControl() );

if ( pU && force && unitId == force->mUnits[ (int)pU->GetForceIndex() ] ) {

if ( pU == theGame.mArbiter->GetDisplayedUnit() ){ int damagedVehicle = (int)pU->GetVehicleIndex( obj->GetId() );

if ( mVehicles[ damagedVehicle ] ) mVehicles[ damagedVehicle ]->Blink();}

}}

Source, Force 21, copyright Red Storm Entertainment/Ubisoft, used with permission

Message Passing as Abstraction Layer: Example, Force 21


By using messages as a generic abstract interface between modules, the architecture allows for:• Removal of other modules from the critical

path

• Clean separation of implementation from semantics

• Easier integration of automated testbeds

Mechanisms of Message Passing

Message passing mechanisms vary, ranging from a limited number of arguments (possibly with type information inferred entirely from the message type), to flexible and extensible systems with an almost unlimited set of possible arguments (including the ability to change type from message call to message call).

Mechanisms of Message Passing: Example, Tom Clancy’s Ghost Recon

// compose and send a message to the servernewMsg = RSGameMessage::Create( kMsgID_GunshotMissed );

newMsg->AddPayload( id ); // game object idnewMsg->AddPayload( index ); // inventory item that firednewMsg->AddPayload( direction ); // direction for tracer

IRSGameMessageMgr::SendMaster( kSystemChannel_Sim, newMsg );newMsg->Release(); // note: we have to release it since we 'Create' it here

Source, Tom Clancy’s Ghost Recon, copyright Red Storm Entertainment/Ubisoft, used with permission

Mechanisms of Message Passing: Example, Force 21

voidClientRouter::SendMessage( F21MessageTarget targetType,

const MessageArg& target, F21MessageType message, const MessageArg& arg1, const MessageArg& arg2 )

{// Now, handle anything for which we do default networkingif( ShouldSendToNetwork( targetType, target, message, arg1, arg2 ) ){

TransmitMessage( targetType, target, message, arg1, arg2 );}

// And finally, do any processing which we need to do on this// machine.if( ShouldSendToRecipient( targetType, target, message ) ){

ProcessMessage( targetType, target, message, arg1, arg2 );}

}

Source, Force 21, copyright Red Storm Entertainment/Ubisoft, used with permission

Mechanisms of Message Passing: Tradeoffs

Rules based systems like Force 21 provide a simple and effective mechanism, and guarantee that the same message is always handled in the same way.

Use based systems like Tom Clancy’s Ghost Recon allow for more flexibility in how a message is used, and allow for the reuse of the same message, at the cost of increased code complexity and the risk of human error.

Mechanisms of Message Passing: Tradeoffs

Fixed argument systems allow for a simpler calling convention and for smaller base cases, subject to the limitations of the fixed number of arguments.

Variable argument systems increase the complexity of the calling convention (although varargs like helpers can help mask this), and

require more complex message handlers.

Summary: Message Passing Architecture Benefits

• Basic networking as the normal case, rather than a special case

• Journaling/Replays as the normal case, rather than a special case

• Obvious integration point for unit testing or automated test beds

• Reduction of critical-path conflicts and inter-module dependencies

Message Passing Architectures Risks: Performance

• There is no such thing as an “inline message”. There is an overhead to any message traffic.

• Increased function calls result in greater stack depth and complexity

• Optimal network usage will require special cases for the most used messages, however, once those cases exist, any change to a message needs to be duplicated in the optimized version.

Message Passing Architectures Risks: Team Management

• Team understanding and “buy-in”. If the team does not understand the message passing heuristics, or is not convinced of the efficacy, the result will likely be code that is only partly message based, resulting in the worst of both worlds.

Message Passing Architectures Risks: Team Management

• Lack of documented heuristics on what should be sent as a message, how messages should be broken up, and, depending on the architecture, what options for sending messages are valid when. Many of the strengths of the system are lost if it is used inconsistently, and bugs will result if it is used improperly.

Message Passing Architectures Risks: Engineering

• Sending a message should be as lightweight as a function call to the programmer. The more difficult it is to construct and send a message, the more likely it is that an engineer will construct helper functions to build the message, obscuring the use of messages and making the code more difficult to follow.


• Over-engineering can be a significant risk. If there are too many possible options, especially if they are incompletely understood by the team, it can cause confusion and result in the wrong options being used (or more likely, an engineer using the options they are familiar with regardless of how appropriate the option is for the task at hand)


• Because messages act as virtualized functions, it is often necessary for an engineer to search the code base to find all the places that use a message to determine the full semantics of the message.


• The order in which different components react to messages may need to vary based on the message. This presents risks as to timing issues on a message by message basis, and can remove many of the benefits of message passing systems as far as removing dependencies on other modules, depending on how message priorities are handled.

Message Passing Architectures: Next Generation

Based on the categorized risks, and in order to maximize the benefits we get from moving to a message passing system, we can set some requirements for what we want out of the next generation of message passing systems.

Message Passing Architectures: Next Generation Requirements

• The full semantics of a message, including information on message payload, and the order of processing, must be in a single location, such that any use of the message will always use the same logic.

• Heuristics for what should be sent as a message, how messages should be broken up, and how the rules for messages should be determined must be

set and documented at the project level.


• Searchable documentation should be kept synchronized with the source code, to enable any engineer to determine how a message should be used and why.

• Enforcement of message semantics should be performed, as much as possible, by the compiler, and otherwise at run time by the code, rather than being enforced by manual programming.


• Sending a message must be as simple as a normal function call.

• The engineer using a message must be able to assume that the message definition and messaging engine will determine how the message should be sent and handled, regardless of single player or multiplayer

game mode.

Message Passing Architectures: The Next Generation

One approach to meeting the requirements of a next generation system is to draw heavily from Bertrand Meyer’s DesignByContract™, and apply that model to our messaging core.

Additionally, we know that it is highly unlikely, even if messages were fully documented before creation, that the documentation will be manually kept in sync throughout the development life of a project. To meet our documentation requirements, we will want to draw off the source/view model used in Eiffel.

Message Passing Architectures: The Next Generation

What follows is a sketch of what a next generation message definition could look like. There is currently no code to take the hypothetical .m file and turn it into the combination of source code, documentation, and database needed, nor is there a messaging engine to use that information.

The example, however, is real. The sequence of a claiming a gunshot, displaying a gunshot, and reporting the effects, is drawn from the way in which Red Storm has traditionally built tactical shooters.

Message Passing Architectures: RequestFireGunshot.m

// A human (either AI or player) has requested to fire their gun

Message: RequestFireGunshot

Descriptors: Combat, Simulation, Action, Request, Input, AI

Modes: Action::Action

Order: Simulation > DontCare

Payload:

UInt32 mShooterID is ActorID

UInt8 mWeaponID is WeaponIndex

IsValid:

Reception:

{ return false; }

IsNotValid:

Processing:

{ return( !SystemRulesManager::IsOwnedByLocalSystem( mShooterID ) ); }

Perform:

Transmission:

{ return false; }

Message Passing Architectures: ClaimGunshot.m

// Claim a gunshot, and associated results.

Message: ClaimGunshot

Descriptors: Combat, Simulation, Action, Claim


Order: Simulation > DontCare

Payload:



ImpactType mImpactType is [kImpactNone,kImpactHuman,kImpactObject,kImpactWorld]

UInt32 mImpactID is ActorID if ((mImpactType == kImpactHuman) || (mImpactType == kImpactObject))

otherwise is ObjectManager::kInvalidActorID

Vector3 mImpactPoint is WorldCoordinate if (mImpactType == kImpactWorld)

is LocalCoordinate if ((mImpactType == kImpactHuman) || (mImpactType == kImpactObject))

otherwise is NullCoordinate

Vector3 mImpactNormal is NullVector if (mImpactType == kImpactNone)

otherwise is NormalizedVector

IsValid:

Reception:

{ return( SystemRulesManager::IsOwnedBySystem( SenderID(), mShooterID ); }

IsNotValid:

Reception:

{ return( !SystemRulesManager::IsMaster() ); }

Perform:

Transmission:

{ return( SystemRulesManager::IsOwnedByLocalSystem( mShooterID ) ); }

Processing:

{ return( SystemRulesManager::IsMaster() ); }


DoNotPerform:

Transmission:


Message Passing Architectures: ReportGunshot.m

// Report that a gunshot has been fired by the specified player with the specified weapon.

Message: ReportGunshot

Descriptors: Combat, Simulation, Action, Report


Order: Simulation > DontCare > Sound > UI

Payload:



Valid:

Reception:

{ return( SenderID() == SystemRulesManager::kMasterSystemID ); }

IsNotValid:

Reception:



Perform:

Transmission:

{ return( SystemRulesManager::IsMaster(); }

Processing:



DoNotPerform:

Transmission:

{ return( SystemRulesManager::IsOwnedBySystem( RecipientID(), mShooterID ); }

Message Passing Architectures: ReportGunshotHitWorld.m

// Report a bullet impact with the world geometry.

Message: ReportGunshotHitWorld

Descriptors: Combat, Simulation, Action, Report


Order: DontCare > Sound > UI

Payload:

WeaponClass mWeaponClass

Vector3 mImpactPoint is WorldCoordinate

Vector3 mImpactNormal is NormalizedVector

IsValid:

Reception:


Perform:

Transmission:

{ return( SystemRulesManager::IsMaster(); }

Processing:


Message Passing Architectures: Example Uses

void

Simulation::FireWeapon( const SimHuman& shooter )

{

...

[Combat calculations]

...

switch( impactType )

{

case kImpactNone:

Send( ClaimGunshotMsg( shooter.GetID(), shooter.GetActiveWeaponIndex(), impactType ) );

break;

case kImpactHuman:

case kImpactObject:

Send( ClaimGunshotMsg( shooter.GetID(), shooter.GetActiveWeaponIndex(), impactType,

impactObject, impactPoint, impactNormal ) );

break;

case kImpactWorld:

Send( ClaimGunshotMsg( shooter.GetID(), shooter.GetActiveWeaponIndex(), impactType,

impactPoint, impactNormal ) );

break;

default

ASSERT( false && "Invalid impact type returned by CalculateGunshotImpact()" );

}

}

Message Passing Architectures: Example Uses

HANDLER( Simulation, ClaimGunshotMsg )

{

// If the shooter isn’t in a position to fire this weapon, nothing will happen anyway

if( CanShoot( msg.mShooterID, msg.mWeaponID ) )

{

// Ok, they could fire, so let’s report that

Send( ReportGunshotMsg( msg.mShooterID, msg.mWeaponID ) );

// And then let’s see if we believe the results, and report those as well

if( ValidateGunshot( msg.mShooterID,

msg.mWeaponID,

msg.mImpactType,

msg.mImpactPoint,

msg.mImpactNormal ) )

{

...

[Results Calculations

...

case kImpactWorld:

Send( ReportGunshotHitWorldMsg( GetWeaponClass( msg.mShooterID, msg.mShooterWeaponID ),

msg.mImpactPoint,

msg.mImpactNormal );

break;

...

[More Results Processing

...

}

}

}

Questions?

Documents

The Case for Message Passing Architectures Dave Weinstein Red Storm Entertainment Ubisoft