Update of /cvsroot/moeng/Mamura/doc
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv30587
Modified Files:
network.tex
Log Message:
An alternative to druby
Index: network.tex
===================================================================
RCS file: /cvsroot/moeng/Mamura/doc/network.tex,v
retrieving revision 1.1
retrieving revision 1.2
diff -C2 -d -r1.1 -r1.2
*** network.tex 16 Feb 2004 23:59:57 -0000 1.1
--- network.tex 17 Feb 2004 19:28:47 -0000 1.2
***************
*** 61,65 ****
now. It should get the idea across.
! Below is a fracment based on a bit of UnrealScript. It is just I don't
know if this is at all a convenient and efficient way to go about
things.
--- 61,65 ----
now. It should get the idea across.
! Below is a fragment based on a bit of UnrealScript. It is just I don't
know if this is at all a convenient and efficient way to go about
things.
***************
*** 72,79 ****
function Move(destination)
function ServerMove(destination)
! var destX, destY;
! var weapon;
client_to_server(:ServerChangeWeapon, :ServerMove)
--- 72,84 ----
function Move(destination)
+ {
+ if (role < ROLE_Authority) {
+ ServerMove(destination)
+ }
+ }
function ServerMove(destination)
! var destX, destY
! var weapon
client_to_server(:ServerChangeWeapon, :ServerMove)
***************
*** 82,85 ****
--- 87,187 ----
\end{verbatim}
+ In the above model we try to describe both the object on the server
+ and the object on the client with the same code, transparently doing
+ remote function calls and synchronizing variables in the
+ background. This is the way Unreal Tournament works.
+
+ Now I'll try to discuss an alternative, without transparent function
+ calls but using explicit server and client versions of the
+ objects. This is based on ClanLib's network code.
+
+ \begin{verbatim}
+ class ServerPawn
+ {
+ ServerPawn(NetObject_Controller noc, Comp owner) {
+ this->netobj = new NetObj(noc)
+ this->owner = owner
+ }
+
+ OnReceivePacket(comp, packet)
+ {
+ // Only allow object owner to change destination/weapon.
+ // Maybe better to check transparently, when would you want a
+ // non-owner to send a packet to an object?
+ if (comp != owner) return
+
+ // packet is array of values, packet[0] determines type
+ switch (packet[0]) {
+ case NEW_DESTINATION: destX = packet[1]; destY = packet[2]
+ case NEW_WEAPON: weapon = packet[1]
+ }
+
+ // TODO:
+ // When to update all clients?
+ // Tell them only about reached places?
+ // Don't allow network spamming by changing weapon all the
+ // time?
+ }
+
+ var netobj
+ var owner
+ var destX, destY
+ var weapon
+ }
+
+ class ClientPawn
+ {
+ ClientPawn(netobj, packet)
+ {
+ // Use packet to initialize ourself (should have been checked
+ // to be of type CREATE first?)
+ }
+
+ OnReceivePacket(packet)
+ {
+ // Basically the same as on the server, might be a different
+ // set of messages.
+
+ // No Comp as parameter, because the message will always be
+ // from the server of our netobj (possibility of multliple servers
+ // comes to mind).
+ }
+
+ Move(destination)
+ {
+ packet = Array(NEW_DESTINATION, destination.x, destination.y)
+ netobj.send(packet)
+ }
+
+ ChangeWeapon(weapon)
+ {
+ netobj.send(Array(NEW_WEAPON, weapon))
+ }
+
+ var destX, destY
+ var weapon
+ var netobj
+ }
+ \end{verbatim}
+
+ Some object will need to be network-enabled while others (or even
+ most) won't need this. Static objects implied by the map don't need
+ any communication and neither will any dynamic object implied by
+ casting a spell or walking through a splash of water.
+
+ Two things might be interesting to consider. One is to get rid of the
+ netobj variable and have the ServerPawn and ClientPawn itself be this
+ netobj either by inheritance or mix-in (something Ruby
+ offers). Another thing is to try and keep the server and client code
+ within one class as done in Unreal Tournament. A lot of code will be
+ the same and it might be tedious to write two classes for each
+ network-enabled object.
+
+ On a final note, it might be nice to get rid of the switch statement
+ checking packet type. An alternative would be to allow binding
+ different functions to different packet types. This would make it
+ closer to the Distributed Ruby case described earlier.
+
+ TODO: Write about creation of new objects.
|
