CS and RakNet

[maharaja]

Hi,

I could'nt find a better forum to start this thread, so here it is.

Networking support in CS is probably an issue for many games/applications being developed.
I intend to use RakNet for networking and would like to know how many other projects (if any) are using or have used RakNet.

If you could provide any advice, helpful hints, code samples, tutorials etc. I'd be greatful and this thread would then help all others in future to implement RakNet.

As I go through implementing RakNet, I'd also continue updating this thread with my experience so others could get a quick-start.

/regards

[maharaja]

Conceptually, if you want to syncronize the position of a player, the position is the relevant state, and it is irrelevant to the synchronisation part how this state is updated. In case of a keypress, it is the new position of the object that is send to the server, and not the keypress.

you could define a function tick() that is called in the CS ProcessFrame() method of the csApplicationFramework based application.

Code:

tick()
{
  p = rakPeer->Receive();
  if (p)
  {
   ...
    rakPeer->DeallocatePacket(p);
  }
}

In this way RakNet execution occurs once per frame.

This does not seem to be right. Suppose if I have 100 FPS this would mean I am sending 100 packets per second. Moreover, besides sending packets I also need to read input from network etc, so doing anything each frame is generally a bad idea and would quickly hang up my application.

Looking at the iPcLinearMovement interface in CEL API you'd see that it exposes UpdateDR() for DeadReckoning. I am wondering if this can somehow be used ?
Any ideas?

The Raknet::ReplicaConstructor based class is responsible for ghost object creation.
When the position of a player has changed as result of a keypress, this has to be told to the RakNet::ReplicaManager:

Code:

replicaManager.SignalSerializeNeeded(player, UNASSIGNED_SYSTEM_ADDRESS, true); // UNASSIGNED_SYSTEM_ADDRESS, true means everybody

Yes, but again, "where" and "when" in the code should we send the packets to ReplicaManager? Sending in ProcessFrame() is not right so it has to be done someplace else.

/regards

P.S. BTW, do you know that Sun has now released the source for SGS/DarkStar server and client. I downloaded and went through the manuals, but as its all Java-based it does not suit me.

[rvhaasen]

i do agree that it is not acceptable to needlessly send packets with the framerate of the application. However, the function that is called at each iteration is merely a check if something needs to be synchronised. If none of the synchronised objects change state, the "poll" doesn't waste  network/CPU resources (at least not much). Decoupling the "local object update" and serialisation (which would trigger deserialisation at the ghosts) in combination with dead reckoning would be a way to both control/limit the network traffic and having good visual apearance. Seen as such, the "once per frame" activity would be a combination of receiving network updates when available and predicting the new state (position/orientation etc).
For my current application this is not a problem, meaning that i serialise the object position (using a method of the ReplicaManager)  as soon it is localy updated. In case of a local player update this is done in the event handling method of the application. In case of CEL, this should be done somewhere in the property classes.

P.S. BTW, do you know that Sun has now released the source for SGS/DarkStar server and client. I downloaded and went through the manuals, but as its all Java-based it does not suit me.

Darkstar is indeed mainly java, and as such looks not suited. Using it from C++ would involve 2 parts that have to be written

1-  java part, that is plugged into the (java) server-framework
2- C++ client that uses the C++ library (present in the SGS SDK)

For a CS plugin, these parts would make "part" of the plugin.
The point is that i don't know any C/C++ opensource solution if you want to create robust scalable MMORG applications....
On the speed issue: i think that the network will be the bottleneck and not the (slower than C++) java processing.....