Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

I'm reading about techniques for implementing game networking.

Some of the resources i've read state that it is a common practice (at least for some games) to send the actual controller input across the network, to be fed into the remote game's loop for processing.

This seems a bit odd to me and i'd like to know what are the benefits of using such a method?

To me, it seems that controller input is merely a way to gather data to be fed into the game, which in turn determines how to translate these into specific game actions.

Why would i want to send the control data and not the game actions themselves?

share|improve this question
1  
By "Actions" do you mean generic actions that are mapped to keys EG Mouse1 (Key) = Primary Fire (Action) or do you mean certain events such as "player spawns bullet"? –  Lewis Wakeford Jun 25 '13 at 21:07
    
You currently have an accept rate of 7%, which is really, really poor. It is considered good form on the SE sites to accept answers for questions, after some time has passed. My understanding is that the system will soon start displaying your low accept rate if you do not, and that will prevent many of the regular users here from paying attention to your questions in future. –  Nick Wiggill Dec 7 '13 at 18:07
add comment

4 Answers 4

up vote 2 down vote accepted

Sending Input to the Game Server

Pros

  • The computation for all players is done at once on one machine.
  • Each player receives the same game state.

Cons

  • The player has to wait for the server's response to his/her input.

Sending Game Actions to the Game Server

Pros

  • The player will not experience any latency relating to his/her own actions.

Cons

  • The server has to stitch together and arrange multiple events from multiple players to be sent back out to the players.

Summary

It takes more work for a server to listen to multiple players' actions than it is to just take their input, calculate the result, and return a game state for all players.

share|improve this answer
add comment

In general, yes, you send desired actions, not raw inputs. Sanity-check on the server, though (otherwise players could run at twice the max speed, etc).

I've written a series of articles detailing how all this works, some people have found it useful: http://www.gabrielgambetta.com/fpm2.html.

share|improve this answer
    
What if server and client run at different fps? –  Wolfrevo Kcats Jul 30 '13 at 10:41
    
They usually do, in fact I got away with a 10fps server and a 60fps client with no problems. How it works is explained in detail in the 3rd article in the series, Client Interpolation: gabrielgambetta.com/fpm3.html. –  ggambett Jul 30 '13 at 14:04
    
What i mean is, since they both run on differents fps, when the client press to move maybe it just move the client a few pixels or whatever, usually depending on delta time. But server will just know that client pressed to move, not how much. It cannot knows if, in that moment, client was running under pression and for 5 secs just run 20 fps. So, how does server know exactly the amount of space client has moved if you only send actions? Dont know if i have explained myself. –  Wolfrevo Kcats Jul 30 '13 at 17:05
1  
No, the server should know. The client doesn't just send "I pressed this key", it sends "I pressed this key at this milliseconds and released it at this milliseconds". –  ggambett Jul 30 '13 at 18:09
1  
BTW, the client also doesn't have to send updates continuously! Even if you render and process inputs locally at 60fps, you can (and should) buffer your updates and send them at a lower rate; this saves bandwidth and the server only updates at 10fps, so... in any case you will be sending inputs with timestamps. –  ggambett Jul 30 '13 at 18:11
add comment

The problem comes from cheaters. You might want to read some about the so called authoritative game server. It is very well explained in this article by Gabriel Gambetta.

But lets think about the following example.

You have an online shooter game, which can be either ammo or cooldown based. Your client is a nasty hacker. By accepting game actions (events) from the client, the client can feed the server with new bullets fired, even when he is out of ammo, or his weapon on cooldown. By collecting user input, you need to do the maths and all the checkings on the server side but in return your game is kinda cheat safe. Using an aimbot also gets a lot easier for hackers if you simply accept game events on server side.

You could of course validate the events sent by the client, but sending game events can be heavier on bandwidth.

Have fun implementing your game.

share|improve this answer
add comment

Depends on your game more specific...

Action/Event based System

  • Strategy Game
  • Turn based games
  • ...

you need to send the actions which the players do because the server don't care about the realtime informations

Live/Streamed System

  • Realtime games

the server need to know as fast as possible what the input of each user is to update gameworld objects.

For example if i hold the forward button of a racer game the client should send on every network tick the state of all buttons so the server can simulate the world in realtime.

You could also realisize this with an event based system, but you need more bits to encode the event for a button change which is not that good.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.