https://homeostasis.scs.carleton.ca/wiki/index.php?action=history&feed=atom&title=Game_Engines_2021W_Lecture_16 2026-04-08T03:16:31Z Revision history for this page on the wiki MediaWiki 1.42.1 https://homeostasis.scs.carleton.ca/wiki/index.php?title=Game_Engines_2021W_Lecture_16&diff=23019&oldid=prev 2021-03-11T19:31:05Z

<p>Created page with &quot;&lt;pre&gt; MMO&#039;s ----- MMOs are probably the hardest distributed applications to build What is hard when you do a distributed application? - managing consistent state - managing...&quot;</p> <p><b>New page</b></p><div>&lt;pre&gt;<br /> MMO&#039;s<br /> -----<br /> MMOs are probably the hardest distributed applications to build<br /> <br /> What is hard when you do a distributed application?<br /> - managing consistent state<br /> - managing latency<br /> <br /> Latency is always an issue in games<br /> - time from input to modifying output<br /> - e.g., how long for a keypress to be echoed in a<br /> terminal<br /> - we want them responsive<br /> <br /> But add in wide-area networking and it gets much harder<br /> - we&#039;re always fighting the speed of light<br /> - and networking infrastructure adds additional slowdowns<br /> - add in packet loss &amp; delay and it gets much worse<br /> - really bad for TCP streams<br /> <br /> TCP congestion control?<br /> <br /> Internet is based on TCP/IP<br /> - IP: packets, sent best effort<br /> - just a fixed-sized record of data with source and<br /> destination, i.e., a message<br /> - IP makes no guarantees whether packets will arrive or<br /> not, or what order<br /> - TCP layers atop IP to build connections<br /> - i.e., a pipe<br /> - continuous byte stream with guaranteed order,<br /> integrity<br /> - but, at the cost of arbitrary delays (i.e.,<br /> data has to be re-sent)<br /> - if you don&#039;t need these guarantees, you use UDP<br /> on top of IP<br /> <br /> So, if we care about latency, TCP is a problem<br /> - no guarantees about data delivery<br /> - in fact, when packets are lost, TCP interprets<br /> this as congestion (i.e., too much data) and expotentially slows things down (throttles)<br /> <br /> Why is video streaming easier than gaming, from a distributed perspective?<br /> - you don&#039;t care about latency with video so much<br /> - so you can buffer<br /> - this is why pause can take a while to work on some<br /> platforms<br /> - (what should happen is pause happens instantly<br /> even if the data keeps coming for a while longer)<br /> - you really see this when seeking<br /> <br /> You have to develop ways to hide latency in an MMO<br /> - but you can&#039;t just cache<br /> - one major strategy<br /> - predict what the players will do (simulations)<br /> - originally just dead reckoning<br /> - build in undo (rollback) when simulation is wrong<br /> <br /> <br /> You also try to reduce latency<br /> - localized servers<br /> - minimize communication<br /> - send as little data as possible back and forth<br /> - but this means the clients have to do more<br /> - and this enables cheating<br /> - because the world is resident on the client<br /> - so the client knows things the player shouldn&#039;t<br /> - cheats can make this info available to the player<br /> - example: seeing through walls<br /> - this is why many online games are so strict about<br /> DRM or are restricted to consoles<br /> <br /> The other hard thing with MMOs is managing shared state<br /> - because it is so easy to get inconsistency<br /> <br /> This is really just the parallel programming problem<br /> - it is even hard on the client (i.e., multi-core<br /> programming)<br /> <br /> Parallel programming is hard because it isn&#039;t easy<br /> for two cores (connected in ANY way) to have consistent view of any shared state<br /> - really, the only data they manipulate are in their<br /> registers<br /> - data in registers is loaded from and stored to caches and then main memory (RAM), and from there sent over the network<br /> - at any place where data is stored, concurrent access<br /> is problematic<br /> - because all concurrent access is actually networking<br /> of some kind<br /> <br /> Cores A and B, data x<br /> A set x=5<br /> B checks if x=5, then sets it to 0<br /> What&#039;s the value of x?<br /> - could be 5, could be 0, depending on the order<br /> - this is a race condition<br /> <br /> To avoid non-deterministic behavior, we have locks<br /> - but locks are just a protocol for deciding<br /> who went first<br /> - they ALWAYS slow things down, sometimes<br /> exponentially<br /> <br /> So in the end, it is all messages<br /> - order of messages matter<br /> <br /> data is never consistent unless we make sure it is<br /> <br /> Player A shoots enemy, kill it<br /> Player B sees enemy<br /> - is it dead?<br /> <br /> This is why development in teams is harder than<br /> development on your own<br /> - coordination is hard, because communication<br /> is expensive<br /> <br /> <br /> Think about Fortnight<br /> - note the limit of 100 players, not too many,<br /> can be centralized in one server<br /> - matchmaking may use geographic location (ping times) to<br /> choose who should play whom<br /> - that&#039;s latency tolerant<br /> - lots of opportunities for predicting player behavior<br /> - but if your connection is bad, you&#039;re going to die<br /> and not even realize it<br /> <br /> Whether your MMO works or not really depends on<br /> your game design<br /> - has to take into account limitations of medium<br /> &lt;/pre&gt;</div>

Soma