A design idea for High User Network Game
by FruitBatInShades · in Technical Issues · 05/18/2004 (1:54 pm) · 15 replies
OK, It seems I am trying to push torque in the same direction as everyone else. I am a professional developer (not games) and have been thinking about the best way to save bandwidth for Multi User games.
I see the problem areas as follows:-
1. Having to recieve data packets for each item in the zone/area
2. Having to have the server create and parse those packets based on client feedback.
3. Having to route this info to multiple targets.
I have a schematic idea:-
1. The client initially only feeds back its location and action (x,y,z,action) which will be passed as a string based word (cos torque likes strings), the client then renders 'Peter at 120,0,500, Walking away to 180,0,500'
2. The server sends back the detailed datablock(including client IP) of other clients in the action area (speed/user defined) based on nearest first. If latency gets too high, clients datablocks are dropped based on distance from the player (step 1 is still valid).
3. If interaction (speech, combat, trading) is required with a target, The client then uses p2p to connect to other clients to request that characters full datablock.
4. Each client sends updates back after interaction is complete specifying changes.
5. goto 1
What do you think of this as an idea? Any more idea? Any obvious flaws?
I see the problem areas as follows:-
1. Having to recieve data packets for each item in the zone/area
2. Having to have the server create and parse those packets based on client feedback.
3. Having to route this info to multiple targets.
I have a schematic idea:-
1. The client initially only feeds back its location and action (x,y,z,action) which will be passed as a string based word (cos torque likes strings), the client then renders 'Peter at 120,0,500, Walking away to 180,0,500'
2. The server sends back the detailed datablock(including client IP) of other clients in the action area (speed/user defined) based on nearest first. If latency gets too high, clients datablocks are dropped based on distance from the player (step 1 is still valid).
3. If interaction (speech, combat, trading) is required with a target, The client then uses p2p to connect to other clients to request that characters full datablock.
4. Each client sends updates back after interaction is complete specifying changes.
5. goto 1
What do you think of this as an idea? Any more idea? Any obvious flaws?
#2
1. By datablocks I mean instance information i.e. Data.
2. Cool
3. The bandwidth would be tiny. But add that together for all client-client transactions and you've just halved the server load. CRC the packets and use a limited time frame for response.
By interaction I mean Sales, exchanges, chatting etc.
4. This already happens. How does torque know the status of clients?
05/19/2004 (3:37 am)
In case you haven't guessed, I have signed up for the source code yet :) 1. By datablocks I mean instance information i.e. Data.
2. Cool
3. The bandwidth would be tiny. But add that together for all client-client transactions and you've just halved the server load. CRC the packets and use a limited time frame for response.
By interaction I mean Sales, exchanges, chatting etc.
4. This already happens. How does torque know the status of clients?
#3
If you allow the clients to tell the server what happened about ANYTHING in game then you will get hackers exploiting it.
05/19/2004 (4:38 am)
Clients send move and trigger (shoot, jump) commands (as well as some others based on what you set up in scripts, such as use weapon, use healthpack etc. They don't actually do any game logic (aside from a bit of prediction, but that is overruled by the server packets). The server takes all these actions and things in and then spits out a new game state.If you allow the clients to tell the server what happened about ANYTHING in game then you will get hackers exploiting it.
#4
I'm just looking for inspiration.
05/19/2004 (6:22 am)
OK what about this for a simple idea, usng the same selection mechanics as described, could we get torque to root the clients based on distance again. Then you would able to have a 1000 players but only be sending 100 to a client, those that are nearest?I'm just looking for inspiration.
#5
don't use the term Datablock as a general term, in the Torque world it means a very specific thing ( which is definately NOT instance level information ).
The server knows all and tells all the (dumb untrusted)clients what the "world" looks like, the definative source of where and what things are doing is the server, there is no other way.
as I stated before, Torque supports scoping and prioritization, you just have to write the code to tell it what should be considered in scope.
05/19/2004 (6:55 am)
You are trying to solve problems that have already been solved or that do not exist. don't use the term Datablock as a general term, in the Torque world it means a very specific thing ( which is definately NOT instance level information ).
The server knows all and tells all the (dumb untrusted)clients what the "world" looks like, the definative source of where and what things are doing is the server, there is no other way.
as I stated before, Torque supports scoping and prioritization, you just have to write the code to tell it what should be considered in scope.
#6
05/19/2004 (9:01 am)
Read the whitepaper, Lee. :)
#7
05/21/2004 (8:58 am)
I'm trying to save the money to buy torque and will do so as soon as I can :) I'm disabled so don't get much money. I'm just playing with the demo at the moment so apologies for asking silly questions. 
#8
But yeah, Torque's networking rocks, as has been pointed out it has sophisticated support for scoping and prioritization. That said, there's always room to try to think of new ways to improve things.
Good luck on getting enough saved up for a license. Being able to dig in and try your ideas out is fun.
05/21/2004 (11:32 am)
No prob Lee, we all start somewhere.But yeah, Torque's networking rocks, as has been pointed out it has sophisticated support for scoping and prioritization. That said, there's always room to try to think of new ways to improve things.
Good luck on getting enough saved up for a license. Being able to dig in and try your ideas out is fun.
#9
Or you can look at the TNL.
05/21/2004 (8:15 pm)
Lee, do you have a link to the whitepaper? It's publicly available and it will explain a LOT about Torque's networking.Or you can look at the TNL.
#10
05/22/2004 (7:07 am)
Can't find a link, probably overlooking it! can someone paste in a message for me :o)
#11
Also, as Ben says, check out OpenTNL.org for even more info.
05/22/2004 (9:31 pm)
I think Ben is referring to the paper on How to Make the Internet Rock For Multiplayer Games, written by Mark and Tim and presented at the Game Developer's Conference in 2000, I believe.Also, as Ben says, check out OpenTNL.org for even more info.
#12
05/25/2004 (11:27 am)
Thanks guys :) 
#13
05/25/2004 (11:37 am)
OpenTNL is so very cool. I hope some kind soul adds support for standard web tech to it. Like, XML-RPC and the bunch. Servers talking to each other is something I hope to get back into in a couple years.
#14
Obviously, you can pass messages/ghosts between two servers just as easily as you can between a client and a server.
05/25/2004 (9:54 pm)
But TNL is based on a lightweight and efficient UDP-based protocol. If you want XML-RPC and such, why not... you know... use one of the many high quality open source implementations available?Obviously, you can pass messages/ghosts between two servers just as easily as you can between a client and a server.
#15
05/26/2004 (10:14 am)
This is no need for TNL to "support" XML-RPC for a couple of reasons, you already have HTTP to do that with dozens of implementatins in ever language imaginable and another reason is TNL is designed for effiency first and formost, XML-PRC and the like are designed for flexiblity with peformance a teriary concern at best. 
Torque Owner Jarrod Roberson
2. unavoidable
3. unavoidable
your ideas . . .
1. your solution is way less effient that just letting the netcode bit compress state changes on objects, with the right bitmasking you can't get any better than it does right now. especially not with verbose strings like you propose. Bad idea.
2. this is already available with scoping and priorties just needed to be coded by you to pick what is and is not in scope and what the priorites are.
3. this is a BAD idea! for the reasons below.
4. BAD IDEA clients are never to be trusted . . .
5. goto 4
you don't understand what Datablocks are in torque, they are STATIC initializers NOT state for each individual instance of a class. they affect EVERY instance of a class.
anything that is on the client is untrusted, doing direct connections to multiple peers will NOT be secure, be prone to DOS attacks and absolutely KILL the clients upstream bandwidth ( which on symetricall connects will kill their downstream bandwith as well ( Charter.net is this way in Atlanta ) upstream data steals about 1.5x the amount of downstream bandwith.
you are not going to do much better than the networking in Torque as it stands now. Not unless the rules of reality change. ( such as ip-multicast being supported and turned on by every router and switch on every ISP )