Thanx guys, I've just come back and saw alot of replies, so I guess the competition is between TNL and RAK :)

Once again, thanx for your time.

Best regards,
Ejaz.

is your game open source? if not, then RakNet is probably a better choice unless your willing to drop 250$ for a licence for TNL. if your game is open source, then just check out the docs to each lib and decide for yourself which is best for you. IMO, you probably cant go wrong using either of them.

Actually, I created a wrapper at DirectPlay (about 15-20 APIs) and I just want to eliminate underlying DirectPlay with something more suitable, so that it can be used by other team members as they are using it right now, without any particular knowledge that what is happening underneath.

As far as 250$ or even more, I would happily go for it, if it is highly tested and good support is available. That is why I'm looking for something with which I can live for sometime, I did all the DirectPlay part a year back (approx.) and now I've to change it again, I don't want to make it an annual excersize that at every winter, when the rest of the world is enjoying new year and I'm searching for another network library. :(

i personally prefer RakNet, but like i said, just check out each library and decide which you like best.

this thread in the RakNet forums is an awesome comparison between RakNet and OpenTNL, with Rakkar and one of the OpenTNL guys both participating in the discussion. hopefully this will help you make your decision.

Dear graveyard filla,

I appriciate your help. It is just what I'm looking for. Thanx for your time and efforts.

Best regards,
Ejaz.

Quote:

Original post by graveyard filla Quote: Original post by Anonymous Poster Raknet doesn't have many of the high level networking features and bandwidth optimizations that TNL has. could you maybe back this up with some proof? even just quoting the docs would be fine.

In particular I would look at the object state and partial state replication mechanisms of TNL, as well as state update ordering (see http://opentnl.sourceforge.net/doxydocs/fundamentals.html). Also, TNL's RPC support is substantially more useful than RakNet's -- given that it encodes the parameters passed in the RPC as well as just the function invocation.

If your game doesn't require absolutely optimal use of available bandwidth, it probably doesn't matter which library you use, but if bandwidth is going to be an issue, TNL's focus on maximizing the available bandwidth will make a difference.

Disclaimer -- I wrote most of TNL.

Quote:

Original post by markf_gg In particular I would look at the object state and partial state replication mechanisms of TNL, as well as state update ordering (see http://opentnl.sourceforge.net/doxydocs/fundamentals.html). Also, TNL's RPC support is substantially more useful than RakNet's -- given that it encodes the parameters passed in the RPC as well as just the function invocation. If your game doesn't require absolutely optimal use of available bandwidth, it probably doesn't matter which library you use, but if bandwidth is going to be an issue, TNL's focus on maximizing the available bandwidth will make a difference. Disclaimer -- I wrote most of TNL.

well, realistically, if you are worried about bandwith, you would hand-carve your packets anyway, and not use the "auto syncing" tools these high level libs provide. at least, i dont use them because i am cautious of bandwith..

also, arguably RPC's dont really have that much of a place in networked games..

discalimer -- im relatively new to all this [smile].

Quote:

Original post by graveyard filla well, realistically, if you are worried about bandwith, you would hand-carve your packets anyway, and not use the "auto syncing" tools these high level libs provide. at least, i dont use them because i am cautious of bandwith.. also, arguably RPC's dont really have that much of a place in networked games.. discalimer -- im relatively new to all this [smile].

What do you mean "hand-carve" your packets?

And why don't you think RPCs have a place in networked games? RPCs seem to me to be just a more elegant form of networked event -- you can use them to notify clients of everything from player joins and exits to chat to level changes. In Zap (www.zapthegame.com) we use RPCs for all these functions and more. Making a seperate packet definition for each of these events would be tedious and error-prone.

For reference purposes on bandwidth, a Tribes 1 (distant ancestor to TNL) server would send 10 200 byte packets per second to each connected client -- for a fully simulated outdoor FPS action game with vehicles, projectiles, etc. We designed that game in the day when 28.8 modems were common, so bandwidth was our #1 priority. Even today, with games hosted on a DSL, optimizing for bandwidth is very important. Even if you don't think TNL is useful for your project, I would highly recommend reading the introductory documentation (http://opentnl.sourceforge.net/doxydocs/), as it summarizes many years of networked game programming lessons.

hi Mark,

by "hand carve", i meant synchronize the objects yourself, and not use these high level schemes these libraries provide.

also, like i said, im relatively new to all this. i did consider using RPC's for every message call, but then i thought that it would just get confusing when trying to add lots of messages (and people had recommended me to not do it). so you actually use them for every message then? thats pretty interesting. what advantages exactly does this have over sending strait byte streams?

RPCs just make the syntax of sending networked events much simpler. Suppose, for example you have a server system message that is to show up on the chat display for each client. With the TNL you might do:

void sendSysMessageToClients(const char *message, int colorIndex){  for(GameConnection *conn = GameConnection::getList(); conn != NULL; conn = conn->getNextConnection)    conn->sendMessage(message, colorIndex);}

where sendMessage is declared like so:

TNL_DECLARE_RPC(GameConnection, sendMessage, (const char *message, int colorIndex), RPCGuaranteedOrdered, RPCServerToClient, blah){  ClientUserInterface.addMessage(message, colorIndex);}

Versus (in the case without rpc)

void sendSysMessageToClients(const char *message, int colorIndex){   BitStream packet;   packet.writeInt(MsgSysMessage);   packet.writeString(message);   packet.writeInt(colorIndex);   for(GameConnection *walk = GameConnection::getList(); walk != NULL; walk = walk->getNext())      walk->sendPacket(packet);}void GameConnection::processPacket(BitStream &packet){  switch(packet.readInt())  {     ...     case MsgSysMessage:        packet.readString(msg);        packet.readInt(color);        ClientUserInterface.addMessage(msg,color);        break;     ...  }}

The RPC case is easier to read, and saves you the error-prone process of manually marshalling and unmarshalling all the arguments to the functions. Though some RPC systems just make the function call for you and don't actually marshall the function's arguments (this is the case with RakNet).