robot rage survivors rr2 rearmed
HomeRR ChatMemberlistUsergroupsRegisterLog in

Share | 

 Understanding Peer To Peer based games

Go down 
Chat Owner

Posts : 374

PostSubject: Understanding Peer To Peer based games   Mon Dec 05, 2011 5:12 pm

As we all know Robot Rage multi-player connection system is based on P2P, so I think it would allow us to undersand how we could improve it, if we understood how it works, here is an article I found on web, and important info I wrote down from it... article was made in 2004, same time when RR...

Online MMGs are traditionally supported by a clientserver architecture, where the server keeps both player
account information and handles game state.

Contains Non-player characters (NPCs) that are controlled by automated algorithms.

In general, a player is allowed three kinds of actions:
position change, player-object interaction, and playerplayer interaction
keep the
amount of data that the client handles small enough to fit in

The client-server architecture is the predominant paradigm
for implementing online MMGs. In this model, players
connect to a centralized server using their client software.
The server is typically responsible
for both maintaining and disseminating game state to the
players, as well as account management and player authentication.
A typical single machine
server can support 2000 to 6000 concurrent clients.
Player tolerance for network latency (a.k.a lag) varies
from game to game. (measured in milliseconds and seconds).

The system could also be used without a server for ad
hoc game sessions when hundreds or thousands of players
gather together to play a game for a few hours, and where
all game data is transient.

Player state: Player state is accessed in a singlewriter multiple-reader pattern. Each player updates his own
location as he moves around. Player-player interactions, such
as fighting and trading, only affect the states, e.g., life points,
of the players involved.
Because position change is the most common event in
a game, the position of each player is multicast at a fixed
interval to all other players. The interval is
determined during game design, based on the requirements
of the game.
An alternative to periodic updates is to multicast
the position only if it has changed or is significantly different
from what dead reckoning would predict. This approach
potentially reduces the network traffic, but incurs additional
overhead for detecting lost or delayed messages.

Player-player interaction often
involve multiple actions in quick succession, e.g. in a heated
battle, and often require fast responses. The increased
communication requirements are, however, limited to the
involved players and, possibly, the players in the immediate
vicinity (i.e. to allow them see a fight).

The Map: Graphic elements for the terrain and players
are typically installed as part of the game client software,
and can be updated using the normal software update mechanisms. A map is a non-graphical, abstract description of the
terrain of a region. Maps are considered read-only because
they remain unchanged during the game play. They can be
created offline and inserted into the system dynamically.
Dynamic map elements are handled as objects.

Data replication can be done in
the background, and allows the game to progress with no
noticeable delays for the client.

Distributed system can enjoy only two out
of three of the following properties: Consistency, Availability
and tolerance of network Partitions.

Each multicast message for position updates includes
player ID, the current location on the map, and a player
specific sequence number. The sequence number can be used
to detect re-ordered or missing packets.

Although region changes are
the most infrequent events in the system, due to the amount
of data involved in this event, they consume more bandwidth
than the rest of the operations.

Most existing MMGs
are based on a client/server model, and employ server
clusters to improve scalability.
Although the P2P
approach is more flexible, and lowers the deployment cost
of user designed games, it also incurs a higher security risk
because of the game state is distributed to the peers.

The average message
delay of 150ms can be easily tolerated by massively multiplayer games. The bandwidth requirement on a peer is
7.2KB/sec on average, and peaks at 22.34KB/sec.
This is
well within the capacity of consumer broadband services
like DSL.

P2P is also used for file sharing.

Furthermore, cheating is a serious problem in online games, and
the problem is exacerbated in the P2P architecture, because a
large portion of the game function are executed on untrusted

Back to top Go down
View user profile
Add mint

Posts : 2576

PostSubject: Re: Understanding Peer To Peer based games   Mon Dec 05, 2011 8:32 pm

hm... i pretty much new all of that. Im pretty sure that RR doesn't have any NPC's though XD
Back to top Go down
View user profile
Critique Extraordinaire

Posts : 3451

PostSubject: Re: Understanding Peer To Peer based games   Mon Dec 05, 2011 11:10 pm

Im going to have look into this when I have more energy. I allready lost track in the first part, as I don't know what an MMG is .. Thanks for posting

Back to top Go down
View user profile

Posts : 919

PostSubject: Re: Understanding Peer To Peer based games   Mon Dec 05, 2011 11:50 pm

massive multiplay games

Back to top Go down
View user profile
RR Pro

Posts : 374

PostSubject: Re: Understanding Peer To Peer based games   Wed Mar 14, 2012 5:42 am

Distroyer2 wrote:
Furthermore, cheating is a serious problem in online games, and
the problem is exacerbated in the P2P architecture, because a
large portion of the game function are executed on untrusted

Back again from a long break Smile

The vulnerable part of a multiplayer system like P2P is the part where the client sends information to the server, since that is the information that the user can intercept and change (because it is their computer, the client, that is sending the information).

This is why the most secure multiplayer system is one where the client sends only user input to the server. The server only accepts client data consisting of user input like keystrokes or mouse clicks, not any of the important data (money, weapons, player position, etc). This means the only thing the user could change would be the things that they are supposed to determine themselves anyway, such as keystrokes and mouse clicks. Users then cannot change important values like money, weapons, player position, etc. The server is the one that handles the important stuff.

receives important data from server
sends user input data to server

receives user input data from client (not important data)
sends important data to client

So even if the user changes the money value on their client computer from $50 to $999 to buy a $200 weapon, they won't be able to purchase the weapon from the store, because the server still 'believes' that the their money value is $50, not $999. Or if the player decides to change their z-value on their client to fly in the air, other players won't see a difference, because the server has the correct z-value. Moreover, the server will reset the client's z-value to the correct z-value the next time it sends information to the client.

Back to top Go down
View user profile
Sponsored content

PostSubject: Re: Understanding Peer To Peer based games   

Back to top Go down
Understanding Peer To Peer based games
Back to top 
Page 1 of 1

Permissions in this forum:You cannot reply to topics in this forum
Robot Rage Survivors Forums :: Robot Rage :: Robot Rage - General Talk-
Jump to: