Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
I thought I'd start a new topic on this rather than continue it on from another post because it might turn out to be quite an extensive thread.
The topic is synchronisation of network games. If we all had really fast computers with really fast network connections, we probably wouldn't have to worry about this. My game Helian Wars currently has network support but no sync features. This means that everyones screens look completely different. This is bad.
My idea to solve this problem is to have a clock. This clock would go from 0 to infinite in increments of 1. But the only time it would proceed would be when the server tells it too. The server would only tell it too when all computers are ready for the next lot of inputs.(I know this is a really awful explanation. Sorry.)
For example: One server. Three clients. The server tells everyone to start their game and the time is 0. All three clients push some keys and sends those keys to the server. When the server recieves all three client's keys, it sends each client the key inputs they don't have and also that the time is now 1.
Only when the time is 1 can the clients then send the server their next key inputs. As you can probably guess, the game would only go as fast as the slowest computer/connection. But this is typical with most multiplayer games.
Does this sound alright? Have I missed anything? Any better ideas?
Tycho
------------------ Where the Hell's my roof?
umm...yeah...
JUST GET THE DAMN THING TO WORK SO I CAN PLAY IT AND KICK ALL YOUR ASSES WITH MY SUPERIOR EV/O SKILLS!!!!!
Okay, I got that out of my system now...
------------------ I bought a Venus Fly Trap today. I was going to name it 'Republican', but the fly trap is beneficial to the enviroment. I'll save that name - someday I might find a plant that eats poor people and minorities.
Do not throw snowballs at me. Do not throw them from a tree. Do not throw then at my knee.
AIM-OctoberFost(b) (url="http://"http://www.geocities.com/octoberfost")October Development(/url) (url="http://"http://pages.hotbot.com/games/ambjorn/index.html")A Thousand Worlds(/url) (url="http://"http://members2.boardhost.com/1kwpub")A Thousand Worlds Public Webboard(/url) (url="http://"http://www.drippingchipmunk.com")DrippingChipmunk.com(/url)
one suggestion to speed up larger games: make the bulk of the processing client-side. instead of sending all key-press events to be processed server-side, let each client process all of their associated items (ships, escorts, projectiles, etc.) and just send the server position, velocity, and the sort. i'm not sure if that's what you had meant but if not it'd probably be better. it means a longer initial download, but it'd be a whole lot faster to let the slowest computer process two ships and five projectiles than to wait for the server to process keypress events from 60 ships and update 1000 projectiles
------------------ if tin whistles are made of tin, what's a fog horn made of?
Good idea but since most people have at least 56k I'm not sure that it would matter much, would it?
------------------ (url="http://"http://CelticStarbase.tsx.org")http://CelticStarbase.tsx.org(/url) (url="http://"mailto:webmaster@CelticStarbase.com")mailto:webmaster@CelticStarbase.com(/url)webmaster@CelticStarbase.com
You idea sound good in principle. Unfortunately, know nothing about synching networked games. There must be documentation on how to do this sort of thing....
Something you might want to consider is what happens if one of the human players gets dumped by the server (like his machine isn't responding fast enough, or if his machine crashes, or whatever. The server says "are you there?" and the player machine never responds).
I see two possibilities. The first is easy to set-up: the player's ship explodes. This is probably the easiest to set up, but if this game evolves into the fabled MPEV (Escape Velocity Networked: EVN. Heh), this would suck for the player, as his ship is now gone.
The second possibility is that, if the players client doesn't respond, the server takes control of the ship and uses it as some AI routines. The server could then try and get the players ship to "jump" out of the system, at which point it leaves active play. When the player manages to log back on, his ship is waiting for him where he last landed.
Of the two, I'd personally lean toward option #2.
------------------
Each client will process all the key presses themselves when they get them from the server. All the server will do is send the keys to each player. It has no idea what they do.
The idea of synching is so that the guy with the fastest connection who gets the keys the fastest and can send them off again the quickest, can't kill everyone else off because they are slow.
As for when a player accidently gets disconnected, I think the blowing up option is best. Then they can just restart on the last planet they landed on.
PS October: Just between you and me. Go to: (url="http://"http://uq.net.au/~zzlukirk/downloads/HW.sit")http://uq.net.au/~zz...ownloads/HW.sit(/url)
It doesn't work really well, because you can only turn clockwise, but it works none the less.
But keep it quiet, OK?
Only clockwise! Ergh!
that's my theory of a distributed (peer to peer) netplay: each player connect to each other...
P-----P | / | | x | | / | P-----P
those players sen all nessesary data like XPOSITION YPOSITION DIRECTION EVENT (FIRE WEAPON)
sending keystrokes would be too inaccurant i think
...no more time... code this... must go now... knock knock neo... arhg sebek
------------------ -- live and let die...
(This message has been edited by sebek.du.law (edited 10-02-2000).)
Oh boy, this is a doozy... This is by no means an easy problem to solve. Let me give some observations from how Asheron's Call is put together. AC is a public client/private server pool MMPOG game I played for a while.
Both the client and the server would keep a model of the immediate universe, following the same rules. The server's model was law, and the client would have to sync up to it when it detected discrepancies.
All PvP interaction was approved by the server before consequences took place on either client. Thus, if you try to hit a player adjacent to you, the server might veto the action because the player had actually run off. You would not have seen him run off due net lag.
Clients wouldn't send keystrokes to the server, but more processed information, such as position, velocity, and request for actions. The goal was to decrease network traffic to allow use of modems and reduce the effect of net lag.
The client would do things to keep motion continuous in spite of net lag. 1) if lag was detected, your maximum velocity would decrease (to keep position discrepancy from increasing), 2) if after lag, the client and server positions for a person were different, the client would "slide" the person from the client to the server position over a period of time to get things back in sync.
Personally, I think the idea of having actions timestamped is a good one. (I know that this is how chess servers keep a consistant clock in a speed chess game.) Don't necessarily use a broadcast tick (generates too much traffic). Don't send keystrokes, use a higher abstraction. Try to fit as much state update info into a single IP packet as possible.
I hope some of this information helps... good luck!
Quote
Originally posted by seant: **You idea sound good in principle. Unfortunately, know nothing about synching networked games. There must be documentation on how to do this sort of thing....
**
That reminds me, there is a book called The Black Art of Game Programming or something. It might have a chapter about network gaming tricks and techniques.
Oh, and didn't Bungie release the source code to an early version of Marathon? You could look at their networking code to gain some insight on how to synchronize clients.
On the topic of handling lag, I have a third idea: sensor interference.
If you are the player experiencing lag (ping to server isn't responding or is slow), simulate it with sensor interference in the radar display. For other ships, either 1) make them vanish (easiest), or 2) dim them and let them drift in a straight line if they are another player's ship (this would be the computer's way of showing projected course in the absence of a sensor lock). In this mode, weapons couldn't hit, and missles couldn't lock on target. You could fire rockets at the projected position, gambling that the lag would disappear by the time the rocket arrived. (These are kind of like submarine tactics.) When the lag disappears, make a full update of the universe showing all ship positions and velocities.
If you are not having lag but another player is, use option 1) or 2) above just on that player's ship (a cloud of space dust got in the way).
In the case of a total disconnect, I think system egress (hyperspace) makes more sense than self destruct.
Or you could have a "Sorry EVN (drooool) is busy, please wait for player" meassage ĺ la Avara/Ares.
Implement the green lazers and the splash screen i sent you.....six months ago.......I've long deleted Rengade Wars
Here's the oringnal message I posted on relation to a MP EV thread months ago
<<<<<<<<<< <<<<<<<<<<<<<<<<<<<<<<<<<<<<<
God, EV mp would be soooooo cool but plug-ins would have to be done in with (for compatibility reasons) or maybe there could be another server for each of the Major plug-ins (New horizons etc...) . I just hope that they won't go like ultima online and do a $20 dollar a month thing for access to servers :frown:. The best option would be to opt for (or buy out) Game ranger and the whole server thin could be done/
Anyone heard of robot wars ? (www.robowar.co.uk) The advanced boarding thing could be done by like already programmed bots (identical to robowars) or you could make your own.
The system itself could be like this but then rendered so you'd need a powerful computer but could run it on a 28.8k --------------------------------- "UE cruiser 487" landing on planet earth
*19871012 cust : UE cruiser 487. sendreg: earth msg1: "Commence initial apporach <sn>" "if : x20 y20 = yes goto msg 2 msg2: "Welcome to Earth" ship: land - display = no transmit= all = yes ---------------------------------
Ambrosia would be able to buy microsloth rather then ask them to sponser it if they actually ****ed nova away and got down to work !
------------------ -------------------------- Wham!Man - The original and still the best
Originally posted by Wham!Man: **Or you could have a "Sorry EVN (drooool) is busy, please wait for player" meassage la Avara/Ares.
that gets soo annoying!!
Learn from history... (url="http://"http://www.gamasutra.com/features/19990903/lincroft_01.htm")http://www.gamasutra...lincroft_01.htm(/url)
This article will provide much enlightenment. Because of this I'm currently replacing all discrete functions in my source with continuous ones. (Note: I FINALLY got an Apple Pro Keyboard today! The addition of a forward delete key to my computer will increase my coding productivity immeasurably )
------------------ Democracy is like a Reimann sum...
Originally posted by kberg: **Learn from history... http://www.gamasutra...lincroft_01.htm
hey kberg. it's been a while since i've seen you. maybe you should keep us posted about how the project is coming along?
This article will provide much enlightenment. Because of this I'm currently replacing all discrete functions in my source with continuous ones. (Note: I FINALLY got an Apple Pro Keyboard today! The addition of a forward delete key to my computer will increase my coding productivity immeasurably ) **
Thanks, kberg! That is one excellent reference. Mandatory reading Tycho!
The important points were:
Use a client/server model for shared universes, not peer-peer.
If you can't have a dedicated server, let one of the clients host the game.
Use UDP, not TCP. Implement your own retransmit protocol.
If you can, design to allow processing your packets out-of-order.
Send your data redundantly to avoid having to resend a dropped packet.
Send player commands (keystrokes, joystick) rather than state information. This reduces bandwidth requirements and makes it harder to cheat.
Allow sending the complete state to allow late join and large lag recovery.
Design for the case of no data getting through for several seconds.
Keep two copies of the world, one accurate based on all user input received so far (with latency), and one real-time used for drawing where incomplete data is predicted. Detect discrepancies between the two worlds and correct them gradually in the real-time world.
Do testing over the wide open internet to encounter the various lag problems.
All power to you guys!
Re: peer to peer vs server driven
Why not a hybrid of both? When playing EV, the system is larger than will fit on any one screen, so there's a lot of data that isn't necessary for the player/s. The only time information is important is when 2 or more ships are in sight of one another.
I don't know if anything like this has even been done/suggested, but couldn't player computers that have ships on the same screen use a peer-to-peer method, while players that are in a different part of the system could communicate with the server.
Does that make sense? No other player ships on play screen=server; Other player ships on screen =peer-to-peer.
The peer-to-peer communication would have to check in with the server every now and then to make sure things aren't getting out of synch, of course. The radar screen would be roughly based on what the server says and would be updated at each check in. Someone said this already, but a failure to reach the server would result in static on the radar. If you've locked on to a ship that you can't immediately see and the server loses communication with your computer, you loose the lock. Conversely, in a peer-to-peer setup, a loss of communication with the server while locked onto a ship, the lock remains.
If this doesn't make much sense, sorry. Sound good to me.
(This message has been edited by seant (edited 10-05-2000).)
Yes, exactly!! Only send keystrokes!! I'd rather just send "shift" than ""12,34,32,18" for velocity, x, y, fire needle missiles.
I'll take a look at that page you posted, kberg. Sounds interesting.
As for peer-to-peer or client/server. I think at the beginning it'll be peer-to-peer but when the whole thing gets up and running it will definitely be client/server based.
This is a really bad post, I know, but I have no time at the moment to comment on everything else.