[Moeng-cvs] Mamura/doc network.tex,1.1,1.2

[<b_l...@us...>]

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.