0% found this document useful (0 votes)
256 views17 pages

Tribes Networking Model

This document summarizes the TRIBES Engine Networking Model developed to support multiplayer online gaming over the internet. The key aspects of the model are: 1) Classifying data into different delivery requirement categories; 2) Using multiple stream managers to handle different data types and ensure delivery requirements are met; and 3) A connection layer that notifies the stream layer when packets are delivered or dropped without retransmitting packets.

Uploaded by

WWQQ
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
256 views17 pages

Tribes Networking Model

This document summarizes the TRIBES Engine Networking Model developed to support multiplayer online gaming over the internet. The key aspects of the model are: 1) Classifying data into different delivery requirement categories; 2) Using multiple stream managers to handle different data types and ensure delivery requirements are met; and 3) A connection layer that notifies the stream layer when packets are delivered or dropped without retransmitting packets.

Uploaded by

WWQQ
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 17

TheTRIBESEngineNetworkingModel

orHowtoMaketheInternetRockforMultiplayerGames
by
MarkFrohnmayerandTimGift
[email protected]@Dynamix.com

Abstract
Thispaperdiscussesthenetworkingmodeldevelopedtosupporta
"realtime"multiplayergamingenvironment.Thismodelisbeing
developedforTRIBESII,andwasfirstimplementedinStarsiege
TRIBES,amultiplayeronlineteamgamepublishedinDecember
'98.Thethreemajorfeaturesofthismodelare:supportfor
multipledatadeliveryrequirements,partialobjectstateupdates
andapacketdeliverynotificationprotocol.
Overview
StarsiegeTRIBESsupportstwomodesofplay:singleplayeror
multiplayeroveraLANortheInternet.Themultiplayermode
supportsupto128humanorAIcontrolledplayersinasingle
game.PerformanceovertheInternetdrovethedesignofthe
networkingmodel.Themodelsupportslowendmodemconnections
andisdesignedtodealwithlowbandwidth,highlatencyand
intermittentpacketloss.
Themodeldealsprimarilywiththedeliveryofdataandakey
conceptistheclassificationofdeliveryrequirements.
Alldataisclassifiedintooneofseveralrequirementcategories
andthedesignofeachcomponentinthemodelcentersaround
meetingthoserequirements.Weorganizetransmitteddataas
follows:
1.
2.
3.

Nonguaranteeddataisdatathatisneverretransmittedif
lost.
Guaranteeddataisdatathatmustberetransmittediflost,
anddeliveredtotheclientintheorderitwassent.
MostRecentStatedataisvolatiledataofwhichonlythe
latestversionisofinterest.

4.

GuaranteedQuickestdataisdatathatneedstobedeliveredin
thequickestpossiblemanner.

Thenetworkingmodelisdividedintothreemajorcomponentsas
showninFigure1:
1.

AConnectionLayerthatdealswithnotificationanddelivery
ofpacketsbetweenclientandserver.Thefeaturesofthis
layeralongwithastreamclassprovidethegeneral
infrastructureonwhichtheotherlayersarebuilt.

2.

AStreamLayerwhichprovidespacketstreammanagement.This
layeremploysfivestreammanagerstodealwithevents,object
mirroring,inputmovemanagement,staticdataandstring
compression.Eachofthefivestreammanagersprovides
differentdatadeliveryguarantees.

3.

ASimulationLayerwhichmanagesallobjectsinthe
simulation.Afulldescriptionofthislayerisoutsidethe
scopeofthisarticlebutseveralitemsarerelevant:the
advancementoftime,objectscopingandclientprediction.

ThoughStarsiegeTRIBESemploysaclientserverconnectionmodel,
onlyafewofthestreammanagersareasymmetrical.Nothing
preventsthismodelfrombeingusedinpeertopeerormulti
serverarchitectures.

SimulationLayer
Ghost
Manager

Move
Manager

Datablock
Manager
EventManager

String
Manager
StreamLayer

StreamManager
ConnectionManager

ConnectionLayer

PlatformPacketModule
Figure1

PersistentObjects
Thoughpolymorphicobjectpersistenceisnotanintegralpartof
thenetworkingmodel,itisafeaturethatisusedextensively.A
largepercentageofdatatransmissionisdoneusingpersistent
objectsandthepolymorphicnatureoftheobjectsusedtohide
thetypeandcontentofthedatafromthenetworkingcode.

Eachclassthatisdeclaredpersistentregistersa"class
representative"(ClassRep)objectwiththePersistmanagerandis
assignedauniqueClassID.TheClassRepisusedbythePersist
managertoconstructobjectsofthetypeitrepresents.By
mappingassignedClassIDstoClassRepsthePersistmanagercan
constructanypersistentobjectgivenitsclassID.This
constructionbyClassIDalongwithvirtualreadandwrite
methodsprovidesbasicpolymorphicIO.
Writinganobjectintoastreamisatwostepprocess.Firstits
classIDiswritten,thentheobject'svirtualwritemethodis
invoked.ReadinganobjectinvolvesreadingtheClassID,
constructingtheobjectusingthePersistmanager,andthen
invokingitsvirtualreadmethod.Inthiswayboththeobject's
class,andthedataitreadsandwritesarehiddenfromthe
streammanagers.
ConnectionLayer
TheConnectionlayerprovidestransmissionofpacketsbetween
hostmachinesandisdividedintotwomodules,aplatformpacket
moduleandtheConnectionmanager.Theplatformpacketmodule
providesbasicconnectionlessunreliablepacketdelivery,
currentlyimplementedusingstandardUDPsockets.TheConnection
managerprovidesavirtualconnectionbetweentwohostsandwhile
itdoesnotprovidedeliveryguarantees,itdoesprovidepacket
deliverystatusnotifications.
Thisnotificationguaranteeisveryimportanttothe
architecture;apacketlayerthatsupportsonlyguaranteedor
nonguaranteedpacketswouldnotbesufficienttosupportthe
fourbasicdatadeliverymodalitiesoutlinedabove.Howeach
deliverymodeishandledisdelegatedtoahigherlevelthe
connectionmanageronlyguaranteesthecorrectnotificationofa
sentpacket'sstatus.I.e.,ifapacketisnotifiedasdroppedit
waseitherdroppedordeliveredoutoforder(andsubsequently
dropped),andifapacketisnotifiedasdelivered,ithasbeen
delivered.
TheConnectionmanagernotifiestheStreamlayerofthestatusof
eachpacketintheorderthattheyweresent.Anoverviewofthis
relationshipisshowninFigure2.Droppedpacketsareneverre
transmittedbytheConnectionmanager;theStreamlayer,andits
associatedmanagers,handlealldataguaranteemechanisms.Since
packetsareneverretransmitted,theyarefreedimmediatelyafter
transmission.

StreamManager

Packet
Data

PacketNotifyEvent
DeliveryStatus

Packet
Data

ConnectionManager

Packet
Address
Data

Packet
Address
Data

ConnectionLayer

PlatformPacketModule
Figure2

TheConnectionmanageremploysaslidingwindowprotocolinorder
totrackthedeliveryofpackets.Whenthewindowisfull,
transmissionstopsuntilanAcknowledgmentisreceived.
Acknowledgmentofpacketsisonlyusedtoadvancethewindowand
generatenotificationevents.Thisprotocolimposesanaverage
overheadof3bytesperpacket.
Thoughnotpartoftheprotocol,animportantfeatureofthe
architectureisbitpackingprovidedbyacustombitstream
class.Thisclassprovidesbitlevelreadandwritefunctions,
includingread/writefunctionsfor:asinglebit,variablelength
integers,variablelengthnormalizedfloats,andHuffman
compressedstrings.Allpacketdata,includingtheheaderandthe
slidingwindowprotocol,areaccessedthroughthisstream.These
packingfeaturesareusedextensivelyandvirtuallyalldatais
transmittedusingthesmallestnumberofbitspossible.
Examplesofbitpackingusingthebitstream.
Writingintothepacket:
if(stream>writeBool(updateDamage)){
//Uses1bit
stream>writeInt(mDamageState,2); //Uses2bits
if(mDamageState!=Dead)
stream>writeInt(mDamageLevel,6);
if(stream>writeBool(mRepairActive))

stream>writeInt(mRepairRate,4);
}
Thematchingreadmethod:
if(stream>readBool()){
mDamageState=stream>readInt(2);
if(mDamageState!=Dead)
mDamageLevel=stream>readInt(6);
mRepairActive=stream>readBool();
if(mRepairActive)
mRepairRate=stream>readInt(4);
}
StreamLayer
TheStreamlayeriscomprisedofaStreammanagerandtheEvent,
Ghost,Move,DatablockandStringmanagers.TheConnection
managerdealswiththefrequencyofpackettransmissionaswell
aspacketsizeandstreammanagerordering.Theindividual
streammanagersdealwiththepackinganddeliveringofdata
includingthevariousguaranteemechanisms.TheStringmanager,
dealingprimarilywiththecompressionofstringdata,isnot
coveredinthisarticle.
TheStreammanagerallocatesandtransmitspacketstoits
counterpartonaremotehost.Tocontrolbandwidth,eachStream
managerhasapacketupdaterateandsize.Theseparametersare
setbytheremotehostsStreammanagerandrepresenttheamount
ofdataitscapableofreceiving.Clientsconnectingtoa
dedicatedserversetthesevaluestorepresentthebandwidthof
theirInternetconnection.IfaclientisconnectingtoanISP
witha28.8modemthenitcouldsetarateof10packetsper
secondwithasizeof200toproduceabout2Kofdatapersecond.
Theclientmaychangetheseparametersontheflyinresponseto
changesinlinequality.Tocontrolitsownoutgoingbandwidth,
theserverimposesamaximumbandwidthperclientbasedonits
ownconnectionquality.
PacketsareallocatedbytheStreammanagerandfilledbythe
Move,Event,andGhostmanagers.Sincetheopportunitytowrite
intothestreamisgiventothemanagersinafixedorder,this
orderformsafixedpriorityamongthem.Oncetherequested
packetsizeisexceededorallthemanagersaredone,thepacket
ishandedofftotheConnectionmanagerfortransmission.Figure
3showsanexamplepacket.

Header

StreamManagerData

Move

MoveManagerData

Packet1
Event1
Event2

EventManagerData

Event3
GhostState1

GhostManagerData

GhostState2
Figure3:ExamplePacket
WhenapacketisdeliveredtotheStreamlayerforreading,it
simplyhandsoffthepackettoeachstreammanagerinthesame
fixedorderandeachmanagerisresponsibleforreadingthedata
writtenbyitscounterpart.
TheStreammanageralsoprovidesaTransmissionRecordforeach
packetthatitconstructs(showninFigure4).Whenastream
managerstoresdataintoapacket,itstoresinformation
regardingthatdataintheTransmissionRecord.Whena
ConnectionmanagerNotifyEventoccursforapacket,the
TransmissionRecordforthatpacketisprocessedbytheStream,
EventandGhostmanagers,andisusedtoprovidedelivery
guarantees.SincetheConnectionmanageralwaysproducesNotify
Eventsforeachpacketintheordertheyweresent,the
TransmissionRecordsarestoredinasimpleFIFO.
EventStreamManager
TheEventStreammanagerisresponsibleforprovidingguaranteed
andnonguaranteeddeliveryofeventobjectsfromonehostto
another.Guaranteedeventsarealsoguaranteedtoprocessinthe
ordertheyweresent.Aslidingwindowisusedtotrackthe
statusofevents.Allwindowmanagementisperformedusingthe
TransmissionRecords.
WhentheEventmanagerisgivenapackettowriteinto,itpops
eventsoffitsoutgoingqueueandwritesthemintothestream
untileitherthepacketsizeisexceeded,thequeueisempty,or
theeventwindowisfull.Eventsarepersistentobjectsandare
writtenusingthemethodsdiscussedearlier.
Onceeventsarewrittenintoastream,theyarelinkedtogether
andattachedtotheStreammanagersTransmissionRecord.When

theStreammanagerisnotifiedofapacketsstatus,the
TransmissionRecordforthatpacketispassedtotheEvent
manager.IftheConnectionmanagersignalsthesuccessful
deliveryofthepacketthentheeventsattachedtotherecordare
deletedandtheslidingwindowupdated.IftheConnectionmanager
signalsnondeliverythentheeventsassociatedwiththelost
packetaresimplypushedontotheheadoftheeventqueueforre
transmission.

Transmission
Record1
NextRecord
EventList
GhostList

Event1
NextEvent

Event2
NextEvent

TR2

TR3

Event3
NextEvent

Figure4:Transmissionqueueincludingrecordwith
events
Whenthemanagerisgivenapacketstreamtoread,itunpacksand
constructsalltheevents.Iftheeventismarkedasguaranteed,
itisaddedtoanorderedqueueusedtoprovideordered
processing.Processingeitherhappensimmediatelyuponreceipt
(fornonguaranteedevents)orastheorderedqueueisadvanced.
SinceneitherthetransmittingnorthereceivingEventmanagers
storedeliverystatusinformationintothepacketstream,this
protocolimposesverylittleoverheadabovethatalreadyimposed
bytheConnectionmanager,normally3bitsperpacketand1bit
perevent.Ifapacketisdroppedanadditional714bitsper
packetmaybewritten.
Inpacking,deliveringandguaranteeingEventobjects,theEvent
managerprovidesafundamentalserviceusedbymanyother
subsystemsintheTRIBESIIengine.Sinceeventsarepacked,
unpackedandprocessedusingvirtualfunctionsandthePersist
manager,theEventmanageritselfhasnoknowledgeofthetypeor
contentsoftheseevents.
Anexampleofasimpleevent:
classSignal:publicEvent{
enum{

SignalBits=4,
};
U8signal;
public:
Signal(U8s){
guaranteed=true;
signal=s;
}
voidpackData(Bitstream*stream){
stream>writeInt(signal,SignalBits);
}
voidunpackData(Bitsream*stream){
signal=stream>readInt(SignalBits);
}
voidprocess(NetConnection*ps){
printf("Recievedsignal%dfromhost%s",
signal,ps>getObjectName());
}
};
GhostStreamManager
TheGhostmanagerprovidestwokeyfunctions:the"ghosting"of
objectsfromonehosttoanother,andthetransferringofstate
informationbetweentheoriginalobjectanditsghost.Aghost
isacopyofanobjectpersistedandtransmittedtoaremote
host.AnobjectmayonlyhaveoneghostperGhostmanager(and
thusperremotehost),butmaybeghostedbyseveralGhost
managersatonce(todifferentclients,forexample).Ghostsare
createdusingaformofguaranteeddeliveryalsousedtosupport
partialstateupdatesbetweenanobjectanditsghost.State
dataisconsideredvolatileandtransferredusinga"MostRecent
State"algorithm.
Sinceghostinganobjectinvolvesnetworkoverhead,theghost
managerdoesnotghostallobjectsinthesimulation,butinstead
hasaconceptof"scope."Objectsmaycomeinandoutofscope
foramanagerforanumberofdifferentreasons(thisprocessis
managedintheSimulationlayer).Whenanobjectcomesinto
scope,itsghostistransferredtotheremotehost;whenan
objectgoesoutofscopeitsghostisdeleted.Whileanobject
isinscope,statedataistransferredbetweentheobjectandits
ghostandisupdatedataratebasedonitspriorityandstate
mask.Themanageralsosupportsthenotionof"ghostalways"
objects,whicharealwaysinscope.
Whenanewobjectcomesintoscope,theobjectistaggedwitha
GhostRecordcontainingaGhostIDandaStateMask.TheGhostID
isassignedfromalimitedrangeandisusedbythelocalmanager
toaddressghostobjectsontheremotehost.TheremoteGhost
managermaintainsadictionary,whichtranslatesGhostIDsinto
localghostobjects.Whenthemanagertransfersinformationfrom
anobjecttoitsghost,itsGhostIDisembeddedinthestreamso
thattheremotemanagercanproperlydeliverthedata.TheGhost

RecordsStateMaskrepresentsstatedatathatanobjectis
interestedintransferringandistheheartofthe"MostRecent
State"algorithm.EachbitintheStateMaskrepresentsaclass
dependantsetofrelateddata,orstate,thatwillbe
transferred.Anobjectmayrepresentitspositionandvelocityas
onestatebit,changesinrotationasanother,andpossiblya
changeinanimationstateasathird.(TRIBESsimulationobjects
typicallyhaveupwardsof20stateflags.)Eachstateistracked
andtransferredindependentlyoftheothers,providingthe
abilitytoperformpartialupdatesofanobjectstotalstate.
Whentheghostmanagerisgivenapackettofillbythestream
manager,itperformstwobasicactions.First,itbuildsan
updatelistwhichincludeseveryobjectwithastatuschangeor
nonzeroStateMask.Thisupdatelistisorderedfirstbystatus
change,thenbyobjectpriority.Statuschangesincludethe
transferringordeletingofghostsfromtheremotehost;an
object'spriorityisavalueassignedbytheSimulationlayeras
partofthescopingprocess.Next,theupdatelististraversed
inorderwritingtheGhostID,statusandobjectstate
informationintothepacketuntilthepacketisfilledorthe
listisempty.Foreachobjectthatcontainsdatainthestream,
atransmissionstructureisconstructedcontainingthestatus
changerequestedandtheStateMask.Thisstructureisattached
totheTransmissionRecordforthepacketasshowninFigure5.
TheStateMaskbitsintheTransmissionstructurerepresentthe
statedatawrittenintothestreambytheobject.

Transmission
Record1
NextRecord
EventList
GhostList
TR2

Object1GTR1
NextRecord
StateMask[111]
NextObjectTR

Object2GTR2
NextRecord
StateMask[101]
NextObjectTR

Object1GTR3
NextRecord
StateMask[010]
NextObjectTR

TR3

Figure5:Transmissionqueueincludingghosttransmissionrecordsfor
objects1&2

Whenaghostmanagerreceivesapacket,itreadseachsetof
GhostIDandstatusflagsinorder.Ifastatusindicatesanew
ghost,thePersistmanageriscalledtoconstructtheobjectand
thenewghostisenteredintotheGhostIDdictionary.Ifthe
statuschangeisadeletionrequest,theghostobjectisobtained

fromthedictionaryanddeleted.Ifthereisnostatuschange,
thepacketcontainsonlystatedata.Theghostobjectis
obtainedfromtheIDdictionaryanditsunpackmethodiscalled
withthecurrentpacketbitstream.Whichstatemaskbitswere
usedbythesourceobjecttopackdataisnottransmittedtothe
ghost.Theobjectisresponsibleforencodingsuchinformation
intothebitstream.
Theguaranteeofobjectstateinformationhappensasfollows;
StateMaskbitsrepresentstatechanges,soifanobject's
positionchanges,itsetsits"positionstate"bitintheState
Mask.Iftherearemultiplemanagersghostingthisobject,the
bitissetintheGhostRecordrelatedtoeachmanager.Thisset
bitnowrepresentsstatedatathattheGhostmanagerneedsto
transfertotheobject'sghost.Whenthemanagerisfillinga
packet,objectswithanonzeroStateMasksareaskedtowrite
intothepacketstreamgiventhecurrentmaskforthatGhost
manager.Intheexampleofthe"positionstate",theobject
writesitscurrentposition.AtthispointtheStateMask
representswhichstateswerewrittenintothepacket,andthe
maskisstoredinatransmissionstructurewhichislinkedtothe
TransmissionRecord.Oncethisisdone,theStateMaskis
cleared.Ifthepacketisnotifiedaslost,thentheStateMask
foreachobjectwhichhaddatainthatpacketisupdatedto
includelostbits.Statebitsareonlyconsideredlostifno
subsequentlysentpacketcontainedthesamestatebitforthat
object.Sinceweguaranteeonlythelateststate,ifalater
packethasalreadybeensentwithalaterversionofthatstate,
thenthisrequirementhasbeenmetandnootheractiontakes
place.
InFigure5,ifthepacketforTransmissionRecord1islostthen
bits[101]forobject1and2areconsideredlost;whereasbit
[010]forobject1isnot,becauseGTR3,alaterupdate,has
thatbitset.Ifalostbitisaddedtoanobject'sStateMask,
thenthatstatewillgetretransmittedatthenextopportunity.
Statuschanges,suchasobjectconstructionanddeletion,are
handledinasimilarfashion.
Exampleofstatemasks:
Anobject'spositionchangesanditsetsitsPositionState
bittotrue.Theghostmanagerdecidestopacktheobject's
stateandcallstheobjectspackmethodwiththestate
mask.Theobjectseesthatthemanagerwantstotransmit
itspositionandwritesitscurrentpositionintothe
packetbitstream.Themanagerstoresthestatemask
containingthePositionStatebitinthenotification
structureforthatpacketandtheStateMaskisthen
cleared.
Firstpossibility:thepacketisdeliveredandthestate
hasbeensuccessfullytransferred.Theobject'sposition
hasnotchangedsincethepacketwassentandtheState
Maskisstill0sonofurtheractiontakesplace.

Secondpossibility:thepacketisnotdeliveredandinthe
meantimetheobject'spositionhasnotchanged.Thepacket
isnotifiedaslost.Sincenopacketshavebeensentwith
newPositionStatedatafortheobject,thePositionState
bitissetintheobjectsStateMask.Inthiscasethe
samepositionwillgetresentthenexttimetheobjectis
packed.
Thirdpossibility:thepacketisnotdelivered,butinthe
meantime,theobject'spositionhaschanged.Before
notificationofnondelivery,anotherpacketwasalready
sentwiththelatestposition.Inthiscase,themanager
knowsthatPositionStatedatahasalreadybeen
retransmittedandthelossofthestateisignored.Thisis
possiblebecausetheGhostmanageronlyguaranteesthatthe
latestversionofthestatedataistransferredandnotany
particularversionorcopyofthatstate.Inthisexample,
thisisexactlythebehaviorwewanttheposition
informationcontainedinthelostpacketisstaleandwe
don'twanttoretransmitit.Unlessthesecondpacketis
notifiedaslost,wealsodon'twanttoretransmitthe
currentposition,asithasn'tchangedsincethesecond
packetwassent.
Fourthpossibility:thepacketisnotdelivered,andinthe
meantime,theobject'spositionhaschanged.Butthe
positionchangewasrecentandnosecondpackethasbeen
sentyet.Sincenonewpacketshavebeensentwith
PositionStatedatafortheobject,theobject'sPosition
StatebitissetbytheGhostmanager.Theobjectwill
havealreadysetthebititself,sothiswillnotchange
theobjectsbehavior.Thenexttimetheobjectispacked
itwillwriteitscurrentposition,notthepositionsent
inthelostpacket.Similartothethirdpossibility,the
positiondatalostinthedroppedpacketisneverresent.
LiketheConnectionmanager,Event,andotherstreammanagers,a
serverwillhaveaGhostmanagerforeachclientconnectedtoit.
IfthereareseveralGhostmanagersghostinganobject,the
objectwillhaveaGhostRecordforeachmanager.Eachmanager
willhaveadifferentGhostIDandStateMaskforthatobject
representingthestateofthatobjectonitsremotehost.When
anobjectsetsoneofitsstatebits,itupdatestheStateMask
foreveryGhostmanagercurrentlyghostingitandeachmanager
tracksandupdatesstateinformationindependently.
Thisprocessoftrackingstatemasksandguaranteeingthe
deliveryofstateinformationbetweenobjectandtheirghostsis
akeyfeatureofTRIBESnetworking.Gamesimulationobjectsrely
almostexclusivelyonthismechanismtotransferinformation.

MoveStreamManager
TheMovemanagerguarantees"soonestpossible"deliveryofclient
inputmovestotheserverand"soonestpossible"deliveryof
controlobjectstatedata.Aslidingwindowisusedtotrackthe
deliveryofmovesandalsotosynchronizemoveprocessingbetween
controlobjectsandtheirghosts.Thismanagerisasymmetricalin
thatmovesareonlysentfroma"client"connectiontoa"server"
connectionandControlObjectstatedatafromserverobjectto
clientghost.
Inputmovesareusedtocontrolsimulationobjectssuchas
vehicles,cameras,andplayers.Inputisgatheredontheclient
byanInputManager,whichcollectsamoveevery32milliseconds.
Movesconsistofx,yandztranslations,yaw,pitchandroll
rotationsaswellasanarrayoftriggerstates.Thesemovesare
deliveredtoobjectsbytheMovemanagerandarethesolemeansof
usercontrolledobjectmovement.
TheMovemanager,similartotheEventandGhostmanagers,writes
informationintoeverypacketstreamallocatedbytheStream
manager.Unliketheothermanagers,itmakesnouseofthe
TransmissionRecordortheConnectionmanager'snotification
system.Instead,theMovemanagerprovides"soonestpossible"
deliveryofmovestotheserverbywritingmovesintoeverypacket
sent.Eachmoveistransmittedthreetimesinconsecutive
packets.Eachpackettransmittedfromtheservercontainsthe
lastmovereceived,whichtheclientusestoadvanceasliding
windowofoutstandingmoves.Ifthewindowbecomesfull,the
clientsimulationishalteduntiltheserveradvancesthewindow.
If3packetsaredroppedinarowthenanymovesuniquetothose
packetsarelost.
InStarsiegeTRIBES,everymoveinthecurrentwindowwas
transmittedineverypacketguaranteeing100%deliveryofall
moves,butthiswassometimesthecauseofanegativefeedback
loop.Adroppedpacketwouldincreasethesizeofthenextpacket
bywideningtheslidingwindowandcausingmoremovestobe
transmitted.OnlowbandwidthInternetconnectionstheincreased
packetsizecouldexceedtheconnection'sbandwidth,causingmore
packetstobedropped.Thoughthismeansmovesarenolonger
guaranteeddelivery,theclientrespondsbetterwhenlargenumbers
ofpacketsaredropped.Losingmovescancausetheclientand
servercontrolobjecttogetoutofsyncwhichmayproducea
momentarywarpingfortheclient.
TheControlObjectforaclientistheobjectthatreceivesthe
currentmovebeingproduced.BoththeControlObjectonthe
serveranditsghostontheclientreceiveeverymove.Control
Objectshavetwomajorrequirementsthatdifferentiatethemfrom
otherobjects.Thefirstisthedeterministicprocessingof
moves.Boththeoriginalserverobjectanditsghostaregiven
movesgeneratedbytheplayerandboth,giventhesamestarting
state,mustproducethesameendstate.Thesecondisthatthe
controlobjectmustbeabletotransferitscurrentstateon

demand.ThoughControlObjectsareghosted,andthuscantransfer
informationusingtheghostStateMask,theMovemanagerprovides
aseparate"Soonestpossible"deliveryofaControlObject'sstate
toitsghost.Thisstateinformationissimilarbutnotidentical
toinformationtransmittedthroughtheGhostmanager.State
informationsenttoaghostisnormallylimitedtothatneededto
rendertheobject,ortoreasonablypredictitsmotion.Control
Objectstateinformationmustincludeeverythingneededto
deterministicallyprocessinputmoves."Soonestpossible"
deliveryofthiscontrolstateinformationisachievedbyhaving
theControlObjectwriteitscurrentstateintoeverypacketsent
fromtheserver.Thiscombinationofstatetransferand
deterministicmoveprocessingisusedtokeeptheControlObject
anditsghostsynchronized,andtoallowtheclienttopredictthe
motionofthecontrolobjectaheadofserverupdates.
DeliveringmovesandControlObjectstateupdatesassoonas
possiblealongwithclientpredictionofmoveprocessingallows
smoothandimmediateresponsetoplayerinput,whileproviding
fullvalidationofallplayermovesbytheserver.
DatablockStreamManager
TheDatablockmanagerprovides"lateststate"deliveryof
datablocksfromtheservertotheclient.Datablocksareobjects
whichcontainrelativelystaticdataandthemanagerguarantees
deliveryonlyofthelateststateataverylowfrequency.Like
theGhostmanager,theDatablockmanagerisasymmetric,and
datablocksareonlytransmittedfromservertoclient.Themost
commonuseofdatablocksistotransmitinitializationor
referencedataforghosts.
Datablocksarecopiedtotheclientinastreamofguaranteed
events.Sincedatablocksareconsideredstatictheyarenot
updatedduringthenormalcourseofasession,butonlyatfixed
timessuchaswhenfirstconnectingtoaserverorduringamap
change.Agloballastmodifiedkeyisusedtotrackchangesto
datablocks.Eachtimeadatablockismodifieditisassignedthe
currentvalueofthiskey,afterwhichthekeyisincremented.
Themanagerkeepsthehighestkeyvaluetransmittedtoitsremote
host.Sincethemanageronlyguarantees"lateststate",ifa
Datablockismodifiedseveraltimesbetweenupdates,this
informationislosttotheclient.Further,sincethechangesto
datablocksarelowinfrequency,theGhostmanagersoverheadof
partialstateupdatesisnotnecessaryachangeddatablockis
retransmittedinitsentirety.
UnliketheotherConnectionstreammanagers,theDatablock
managerdoesnotwriteinto,orreadfromthepacketbitstream
producedbytheStreammanager.Updatesareinvokeddirectly
fromthescriptinglanguageandinvolveloopingthroughallthe
existingdatablocksandtransmittingeverydatablockwitha
modifiedkeygreaterthanmanager'skey.Theactualtransferof
datablocksisperformedbysendingguaranteedDatablockEvents

usingtheEventmanager.ADatablockEventcontainsthedatablock
objecttotransmit,andthedatablockispackedaspartofthe
event.
Asanexample,theVehicleclasshasanassociatedVehicleData
Datablockclass.TheDatablockclasscontainsnumerousvehicle
propertyattributessuchasshape,maximumspeed,maximum
acceleration,suspensionpropertiesforwheels,etc.Whena
Vehicleobjectisconstructed,itisassignedaninstanceofthe
VehicleDataDatablock.EachinstanceoftheVehicleData
Datablockrepresentsadifferentsetofattributesdescribinga
differenttypeofvehiclesuchasatank,scout,transport,etc.
TheVehicleclassitselfrepresentstheinstanceofthatvehicle
typeinthesimulationandprovidesallthecodeanddynamic
attributesnecessarytosimulatethevehicle.

VehicleDataDatablock
Instancewithstatic
vehicleattributes
Server

VehicleDataDatablock
Copyofstaticvehicle
attributes
Client

VehicleClassObject
Datablock
Dynamicvehicle
attributes

VehicleClassGhost
Datablock
Dynamicvehicle
attributes

Figure5:VehicleDatablockrelationshipmirroredonclient

Theadvantageofthisseparationofstaticattributedataand
instancedataisthatDatablocksarenormallyonlytransmittedto
theclientonceatconnecttime.WhenaVehicleobjectis
ghostedtotheclient(aprocessthatcanhappenoften)itsends
onlyitsdatablock'sIDalongwithotherdynamicdatarelevantto
theghost.Thisresultsinhugesavingsinbandwidth,whilestill
providingtheflexibilityofdefiningstaticattributedataon
theserver.AsshowninFigure5,theclientwillmirrorthe
samerelationshipofVehicleinstancetoVehicleDatadatablock.
Sincedatablocksareonlytransferredattimeswhenthe
simulationiseffectivelystopped,morebandwidthisavailable
anddatablockscancontainmoreinformationthanwouldnormally
bepossible.ThisalsomeanstheDatablockmanagerimposesno
extraoverheadtothebitstreamduringthenormalcourseof
simulation.

SimulationLayer
TheSimulationlayerperformsanumberoffunctionsofwhichonly
afewarerelevanttoadiscussionofthenetworkingmodel.
Thesearetheadvancementoftime,scopingfortheGhostmanager,
andclientsideprediction.
Advancementofsimulationtimeiscenteredontheprocessingof
moves.Movesaregatheredevery32milliseconds,andthe
simulationisadvancedin32millisecondincrementswithamove
foreachincrementortick.Allobjectsontheclientandserver
areadvancedinthesamemannerandifaMovemanagerisnot
controllinganobject,thenitispassedNULLmoves.
Thoughclientobjectsareadvancedinfixedincrements,the
elapsedtimebetweenframesmaynotfallonevenincrements.To
presentasmoothview,especiallyonamachinewithahighframe
rate,timeisalwaysadvancedtothebeginningofthenext
interval,andghostobjectsmaintainbackwardsinterpolation
informationwhichisusedto"tween"framesbetweenticks.
Objectsontheserverareneverrenderedsotheydonothaveto
performthisfunction.
Simulationobjectsmustbescopedandprioritizedfortheghost
manager.Scopingistheprocessofdeterminingwhichobjectson
theserverarerelevanttoaparticularclient.Inthesimplest
sense,thismeansallobjectsthatarepotentiallyvisibletoa
clientfromthatclient'scurrentcontrolobject.Thisformof
scopingisperformedusingaspatialdatabasemaintainedbythe
simulation.Whenanobjectisdeterminedtobeinscope,the
objectitselfdeterminesitsownprioritybasedoninformation
suchascurrentghoststatemask,distancefromthescoping
object,projectedradius(usingthescopingobjectsview
frustrumparameters),relativevelocity,animationstateand
interestmodifiers(projectilesthataremovingtowardsthe
clientaremoreinterestingthanvehicles,vehiclesaremore
interestingthanitems,etc.).
Therearetwoformsofclientsidepredictioninthismodel.
FirstistheControlObjectmovepredictionperformedbytheMove
manager.Thisisbyfarthemorecomplicatedandprovidesthe
foundationforcontrollingandpredictingobjectssuchas
players,vehicles,turretsandcameras.Theotherisprediction
performedbynoncontrolledghostobjectssuchasprojectiles,
items,etc.Thislevelofpredictionisleftentirelytothe
objectsthemselvesandnosupportingstructureisprovided.
AnexampleofapredictionstrategyisthatprovidedbytheItem
class,oneofthesimplerobjects.Thisobjectisdriven
entirelybythephysicsoftheenvironmentanddoesnotprocess
inputmoves.Bysimplysimulatingnormallytheghostwill
correctlypredictinteractionwithallstaticobjects.Ifa
dynamicobjectishitontheserver,thenitsghoststatemaskis
settotransferitslatestpositionandvelocity.Whenthe

clientghostreceivesanupdatefromtheserver,itinterpolates
itscurrentpositionsmoothlytotheserver'supdatedposition
andcontinuesfromthere.Morecomplexstrategiesareusedby
thevehicleandplayerclasses,whichhavetodealwith
predictingmovementfromotherclients.
Summary
Byclassifyingdataaccordingtoitsdeliveryrequirementsand
organizingthestreammanagerstoefficientlymeetthose
requirements,theTribesIInetworkingmodelattemptstomake
optimaluseofavailablebandwidth.Incombinationwithdynamic
objectscopingandprioritizationofpartialobjectstate
updates,theTRIBESIIengineallowssmoothvisualizationof
largevirtualenvironmentsoverlowbandwidthconnections,even
whenasubstantialnumberofobjectsarevisibletoaclient.
Thoughthemodelprovidesasolidfoundationfornetworktraffic,
itisnotsufficienttosimplyprovideafastreliableconnection
betweenhosts;therewillalwaysbebandwidthandlatencyissues
tocontendwith.Notcoveredinthisarticleare:choicesmade
whendecidingwhichobjectbehaviorshouldbemanagedbythe
serverandwhichbytheclients,whichobjectstateinformation
totransfer,howtoorganizeobjectpartialstates,howto
prioritizeobjectstatechangesrelativetoeachother,which
compressionalgorithmtouse,andhowtoperformclientside
predictionofControlObjects.Allofthesecanhaveadramatic
effectonperceivednetworkperformance.
ThismodelwasfirstimplementedinStarsiegeTRIBES,which
shippedinDecemberof98.TheupdatedimplementationinTRIBES
IIhasthefollowingimprovements:
1. ReorganizationandsimplificationoftheConnectionandStream
layers.
2. BetterpacketheadercompressionfortheConnectionmanagers
notificationprotocol.
3. Areductioninthenumberoftimesmovesareretransmittedto
avoidnegativefeedbackloopsduetoincreasedpacketsize.
4. Betterdatacompressionbyindividualobjects.
5. TheadditionoftheStringmanager,whichprovideshighorder
compressionforrepeatedlytransmittedcharacterstrings(not
discussedinthisarticle).
Severalmodificationstothemodelhavebeenconsidered,and
thoughtheywillnotbeimplementedforTRIBESII,areworth
exploring.Theseinclude:
1. VariableproductionofpacketsbytheStreammanager.Updates
arecurrentlyproducedataconstantratedictatedbythe
Streammanagersbandwidthsettings.Packetscouldbe
producedassoonasdataisavailablefortransmissionordata
priorityreachesagiventhreshold.
2. AsynchronousConnectionprocessingontheserver.All

Connectionmanagersarecurrentlyprocessedatthesametime
ontheserverinasinglethread.Theserverarchitecture
couldbechangedtosupportaprimarysimulationthreadwitha
separatethreadforeachclient.Thiswouldprovidethe
ConnectionandStreammanagerswithlowerlatency
communicationwiththeirremotehostaswellasprovidebetter
supportformultiprocessorhardware.
3. Theadditionofnewstreammanagers,includingamultiplexing
audiostreammanager.TRIBESIIwillsupportvoiceusinga
simplerapproach.
4. Dynamicallocationofserverbandwidth.Bandwidthonthe
serveriscurrentlysetatafixedperclient.Theserver
couldbemodifiedtoadjustitsperclientbandwidthbasedon
thenumberofconnectedclients.
5. Determineamethodofautomaticallyandeffectively
calculatingtheavailablebandwidthonaconnection.
Bandwidthsettingsarecurrentlysetmanuallybyaclient.
Acknowledgments
ThoughseveraloftheideaspresentedhereareuniquetoTRIBES,
othershavebeenassimilatedfromothersourcesovercountless
yearsofreadingandtheauthors,beingtoolazytoresearch
theirsources,wouldliketothankeveryoneinonesentence.

You might also like