Hi My pal told me that the major thing in networking often is syncing and waiting to get all the stuff from all the actors. But what if EVERYTHING is done and stored on one computer and other players only send their mouse and keyboard inputs? Too much lag for those players he said. But. If you play it on a lan wouldnt the lag be ok even with a non-correcting system for delays?Could one do a simplified network sollution that works only on lan? Why i ask i becouse im interessted in that for my rts and i know networking is NOT easy but im investigating what options i might have... Thanks Erik

Ya, networking for a realtime game is indeed not an easy thing to do. And it of course highly depends on how many players you want to maximally allow to play your game at the same time and the amount of data you send for each player.

If those numbers are small, the one-computer solution will most likely work best and is easiest to program.

However, if all your clients are "dumb" and are only sending inputs to one server and are waiting for the server to calculate new positions for all the units, those positions would have to be sent every frame to every client for them to see anything moving on their screens, which in turn means a lot of traffic on the network.

I would start by doing some research on time syncronisation and at least implement a simple correction mechanism to be on the safe side. Check out this link:

http://www.codewhore.com/howto1.html

and this forum dicussion:

http://www.gamedev.net/community/forums/topic.asp?topic_id=206731

im thinking in the vicinity of maybe 4 players (one of them host). I guess i have to send all data back to everybody since how could they otherwise see the game world? And sending the view as a image would be larger...

Ive been out looking for some sort of "networking-engine" but maybe this is impossible to implement? But many of the basics should be the same in every game, sending keyboard/mouse input, sending a variable, ask for a variable value from another computer etc.

Theres a bunch of engines covering other aspect, but nearly nothing on networking. It would be great for getting into the game.

Sayonara
Erik

have you ever heard of raknet ?
its an engine for networking that is used in many commercial games.

its not wrong to just send the input to the server.
and sometimes, its even better to send only key-events.
(e.g. when a user fires a machinegun, he wont just hit the button for every bullet, so you may send a "begin_shoot" and "end_shoot" event or something).

of course, you will not see any movement on the clients screen until a packet from the server comes back to the client.
the solution is: precalculation.
player hits button "W" (forward).
player-pc sends "BUTTON_W" event to server.
player-pc begins movement of the player in the local world.
//the players pc can also do client-side collision detection,
// and also other physical calculations etc.
server receives packet.
server calculates physics and movement for himself
server sends back the new data
player-pc now overrides his own data with the one just received from the server.
// the server can not only send the position, but also a velocity vector
// this helps the client to predict where the player will move to

only sending the key-input (and precalculation) was already done in quake 2+3, and you can play them quite well on the internet...

sorry, my fault:

player pc does of course NOT send an "BUTTON_W"-like event.
buttons are of course configurable by the client, so this
would more be an "MOVE_FORWARD_START"-event.
(since you dont walk-and-stop all the time, its enough to send an start/stop-movement event)
you should use a single event when e.g. reloading ("RELOAD_WEAPON"-event) or sth.

well in therms of what will be in the game, its a rts so loads of units will be in it, but only one computer will need to calculate everything (this is tested already and no problem there).

Maybe:
Could the non-master clients request only the data needed for the current view etc? For example where is the 20 guys currently in frame? And a "slave" computer only sends controls/mouse; only the master computes/controls the "entire game".

Delays will be ok to a certain degree as it these will be delays in overhead commands. For example move this group here. There is no real action like in a shooter where you must time your trigger.

Also is it possible to do a very broad estimation on what kind of delays i'd be looking at (if this project is ever implemented...)

So controls will take 1Time to reach the master, and the master sends to slaves so slaves see the world 1Time after it officially happens. And can see the effect of a mouseclick 2Time after the mouse is being clicked. Right?

Thanks
Erik

FYI, the networking in Quake (1) worked much like what you're talking about... The clients were more or less "terminals" that merely displayed what the server told them to. It was playable on LAN with up to 16 players, and over the internet if you had low (<50ms) ping.

This might not work in an RTS game due to the large number of units though. I think most RTS games keep more or less the whole gamestate on each client.

If you want to do an RTS, you might want to read this paper:

http://www.gamasutra.com/features/gdcarchive/2001/terrano_1500arch.doc