<!-- MHonArc v2.4.4 --> <!--X-Subject: Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks) --> <!--X-From-R13: Oqnz Ivttvaf <avtugsnyyNhfre1.vasvpnq.pbz> --> <!--X-Date: Sat, 28 Feb 1998 04:54:39 +0000 --> <!--X-Message-Id: 199802280448.VAA28818#user1,inficad.com --> <!--X-Content-Type: text/plain --> <!--X-Reference: 199802231920.TAA33106#out4,ibm.net --> <!--X-Head-End--> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <html> <head> <title>MUD-Dev message, Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law suck</title> <!-- meta name="robots" content="noindex,nofollow" --> <link rev="made" href="mailto:nightfall#user1,inficad.com"> </head> <body background="/backgrounds/paperback.gif" bgcolor="#ffffff" text="#000000" link="#0000FF" alink="#FF0000" vlink="#006000"> <font size="+4" color="#804040"> <strong><em>MUD-Dev<br>mailing list archive</em></strong> </font> <br> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] <br clear=all><hr> <!--X-Body-Begin--> <!--X-User-Header--> <!--X-User-Header-End--> <!--X-TopPNI--> Date: [ <a href="msg00640.html">Previous</a> | <a href="msg00642.html">Next</a> ] Thread: [ <a href="msg00570.html">Previous</a> | <a href="msg00654.html">Next</a> ] Index: [ <A HREF="author.html#00641">Author</A> | <A HREF="#00641">Date</A> | <A HREF="thread.html#00641">Thread</A> ] <!--X-TopPNI-End--> <!--X-MsgBody--> <!--X-Subject-Header-Begin--> <H1>Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</H1> <HR> <!--X-Subject-Header-End--> <!--X-Head-of-Message--> <UL> <LI><em>To</em>: <A HREF="mailto:mud-dev#null,net">mud-dev#null,net</A></LI> <LI><em>Subject</em>: Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</LI> <LI><em>From</em>: Adam Wiggins <<A HREF="mailto:nightfall#user1,inficad.com">nightfall#user1,inficad.com</A>></LI> <LI><em>Date</em>: Fri, 27 Feb 1998 21:48:01 -0700 (MST)</LI> <LI><em>Reply-To</em>: <A HREF="mailto:nightfall#inficad,com">nightfall#inficad,com</A></LI> </UL> <!--X-Head-of-Message-End--> <!--X-Head-Body-Sep-Begin--> <HR> <!--X-Head-Body-Sep-End--> <!--X-Body-of-Message--> <PRE> [coder#ibm,net:] > On 20/02/98 at 02:35 AM, Jon Leonard <jleonard#divcom,umop-ap.com> said: > >On Sun, Feb 15, 1998 at 11:55:11PM +0000, coder#ibm,net wrote: > On > >> It makes a lot more sense to me to move away from TCP for MUD clients, and > >> instead look to UDP and design the client and server to be tolerant of > >> dropped packets. Sure, things will get a bit jerky of occassion, but it > >> sure beats waiting for the time-out and re-send of a dropped packet. > > >I'd be extremely reluctant to do this. It's very easy to redesign TCP > >badly, and nearly impossible to do better. > > No, you misunderstand. > I am proposing that MUD clients move to a protocol and data model which is > tolerant of data loss. If packets get lost, or arrive far to late, the > client won't care and will continue to offer a decent representation of > what is happening in the game. The main problem with telnet lag is *not* > latency but dropped packets -- the whole damn client freezes while > awaiting the lost packet. Instead have the client be predictive and work > on a best-effort basis. It works with the data it gets, and ignores or > attempts to generate the data it never sees for whatever reason. > Raph has commented that UOL's client does this in some areas. I've been idly pondering this area for a while now. Both UO and Furcadia are in a similar position - fast enough to be playable, slow enough to be annoying and quickly tiresome, especially if your connection sucks. IMO part of the problem is that the frame rate on both of these seems to be reflective of the speed of your connection. Thus even a killer rig seems slugish and unresponsive if your connection happens to be running a bit behind. So I'd say the number one thing would be to have an engine which runs at 30 fps or higher all the time, regardless of the info it receives from the server. On a slighty more interesting and possibly less practical line of thought, I've been considering using the timestamps on the packets in creative ways. As long as the server and all clients were synced, and all packets were timestamped with an extremelly high granularity timer (say, 1ms or lower) then the server could actually "insert" the packets it receives from the client at that point in time, and then recompute all the events that happened since then. In order for this to work you'd need a very robust event system (like JC's) and predictable AI for the computer-controlled characters. You'd also need to clip the timestamps on incoming packets to a resonably small interval - probably three or four seconds. On these same lines, I had a brief idea about systems actually being a different places in "time" on different clients depending on the average response (ping) time. A system with a 500 ms ping time would be .5 seconds ahead of the 'real' system time. Thus a player can react to events in the world at a pace seemingly on par to those with a 10ms ping time. I would imagine anyone over 1s would probably booted off with a message about finding a better connection or a closer server. (I suppose this depends on how time-dependant your server really was. A high-speed car game which requires twitch responses might choose a number as low as 500ms; a slow paced RPG might go for as much as 5s.) Assuming that it works this way (players at different locations in time), I'm not sure what would happen when you had a whole bunch of players with wildly different connection speeds all very near each other doing highly time-dependant stuff (namely collisions of whatever manner). Even though you may be ahead in time, this only helps you avoid predictable things like walls in the way of your spaceship travelling at high speed, or computer-controlled entities with static AI. You still wouldn't get the data about the other player's movements until a little late, leaving you at a disadvantage - but hopefully better than if it was just a straightforward "process packets as you get them" type server. Now, assuming that we're using both high-framerate clients and the timeline breaking I'm suggesting above, this is going to cause some incongruous stuff. A simple case would be the aforementioned spacecraft, piloted by a player, speeding towards a cliff wall. The player's connection is slow. On their machine, they hit the up key just in time to clear the cliff face and continue flying. Everyone else sees their ship fly into the wall, and then a moment later, as the server inserts the packets, they fly clear to safety. Depending on your world, you could approach this different ways. You could have certain events (collisions being the main example) flaged as requiring server confirmation. Thus, everyone would see the player's ship disappear into the cliff face, but they would only see an explosion and a rain of ship parts once the server confirmed the crash. Otherwise they just see the ship pop out of the other side of the cliff, making it look more like a glitch in the clipping routines than a total server botch. I would also tend to, instead of making the ship "pop" to its new location, speed up by some large amount based on the distance from the old position to the new one, so that it appears to hurry to the new place. This will certainly look funny, but hopefully not like a 'break' - and if you have ships which speed up and slow down easily anyways, hopefully this should rarely cause anyone to think anything is strange. Sudden turns will have the effect of doing a larger, sweeping turn - a sudden 45 degree turn by the lagging player should look more like an overshot 60 degree turn, which then turns back to the new heading. I haven't thought this through real thoroughly, nor attempted any complex or hairy scenarios. I'm sure once I do some problems will pop up, but at the moment it seems much more appealing than the usual unresponsive clients. I also used all sci-fi examples (ships) because client prediction would tend to be more accurate with them (I imagine). Thank's to Newton's first law, a missed second or two of packets won't be a big deal unless something unexpected (collision, sudden direction change) happens, and even then it can be made to look relatively seemless. </PRE> <!--X-Body-of-Message-End--> <!--X-MsgBody-End--> <!--X-Follow-Ups--> <HR> <ul compact><li><strong>Follow-Ups</strong>: <ul> <li><strong><A NAME="00654" HREF="msg00654.html">Net protocols for MUDing (was: Moore's Law sucks)</A></strong> <ul compact><li><em>From:</em> s001gmu#nova,wright.edu</li></ul> </UL></LI></UL> <!--X-Follow-Ups-End--> <!--X-References--> <UL><LI><STRONG>References</STRONG>: <UL> <LI><STRONG><A NAME="00565" HREF="msg00565.html">Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</A></STRONG> <UL><LI><EM>From:</EM> coder#ibm,net</LI></UL></LI> </UL></LI></UL> <!--X-References-End--> <!--X-BotPNI--> <UL> <LI>Prev by Date: <STRONG><A HREF="msg00640.html">Re: Tutorial: Let's build a Compiler! - Part I: Introductio</A></STRONG> </LI> <LI>Next by Date: <STRONG><A HREF="msg00642.html">Re: [MUD-Dev] Version Control (was: DBs and Events)</A></STRONG> </LI> <LI>Prev by thread: <STRONG><A HREF="msg00570.html">Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</A></STRONG> </LI> <LI>Next by thread: <STRONG><A HREF="msg00654.html">Net protocols for MUDing (was: Moore's Law sucks)</A></STRONG> </LI> <LI>Index(es): <UL> <LI><A HREF="index.html#00641"><STRONG>Date</STRONG></A></LI> <LI><A HREF="thread.html#00641"><STRONG>Thread</STRONG></A></LI> </UL> </LI> </UL> <!--X-BotPNI-End--> <!--X-User-Footer--> <!--X-User-Footer-End--> <ul><li>Thread context: <BLOCKQUOTE><UL> <LI><STRONG>Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</STRONG>, <EM>(continued)</EM> <ul compact> <ul compact> <ul compact> <ul compact> <LI><strong><A NAME="00565" HREF="msg00565.html">Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</A></strong>, coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 23 Feb 1998, 19:20 GMT <UL> <LI><strong><A NAME="00569" HREF="msg00569.html">Net protocols for MUDing (was: Moore's Law sucks)</A></strong>, s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Mon 23 Feb 1998, 21:15 GMT <UL> <LI><strong><A NAME="00774" HREF="msg00774.html">Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</A></strong>, J C Lawrence <a href="mailto:claw#under,engr.sgi.com">claw#under,engr.sgi.com</a>, Thu 19 Mar 1998, 23:43 GMT </LI> </UL> </LI> <LI><strong><A NAME="00570" HREF="msg00570.html">Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</A></strong>, Vadim Tkachenko <a href="mailto:vadimt#4cs,com">vadimt#4cs,com</a>, Mon 23 Feb 1998, 22:18 GMT </LI> <LI><strong><A NAME="00641" HREF="msg00641.html">Re: [MUD-Dev] Net protocols for MUDing (was: Moore's Law sucks)</A></strong>, Adam Wiggins <a href="mailto:nightfall#user1,inficad.com">nightfall#user1,inficad.com</a>, Sat 28 Feb 1998, 04:54 GMT <UL> <LI><strong><A NAME="00654" HREF="msg00654.html">Net protocols for MUDing (was: Moore's Law sucks)</A></strong>, s001gmu <a href="mailto:s001gmu#nova,wright.edu">s001gmu#nova,wright.edu</a>, Sun 01 Mar 1998, 02:40 GMT </LI> </UL> </LI> </UL> </LI> </ul> </ul> </ul> <LI><strong><A NAME="00475" HREF="msg00475.html">Re: [MUD-Dev] Moore's Law sucks (was: 3D graphics)</A></strong>, Ben Greear <a href="mailto:greear#cyberhighway,net">greear#cyberhighway,net</a>, Mon 16 Feb 1998, 04:41 GMT <UL> <LI><strong><A NAME="00491" HREF="msg00491.html">Re: [MUD-Dev] Moore's Law sucks (was: 3D graphics)</A></strong>, Ling <a href="mailto:K.L.Lo-94#student,lboro.ac.uk">K.L.Lo-94#student,lboro.ac.uk</a>, Mon 16 Feb 1998, 14:53 GMT </LI> </UL> </LI> <LI><strong><A NAME="00481" HREF="msg00481.html">Re: [MUD-Dev] Moore's Law sucks (was: 3D graphics)</A></strong>, coder <a href="mailto:coder#ibm,net">coder#ibm,net</a>, Mon 16 Feb 1998, 06:32 GMT </LI> </ul> </LI> </UL></BLOCKQUOTE> </ul> <hr> <center> [ <a href="../">Other Periods</a> | <a href="../../">Other mailing lists</a> | <a href="/search.php3">Search</a> ] </center> <hr> </body> </html>