<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: Can EVE Evolve?</title>
	<atom:link href="http://doublebuffered.com/2008/10/05/can-eve-evolve/feed/" rel="self" type="application/rss+xml" />
	<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/</link>
	<description>A Programmer's View of Game Design, Development, and Culture</description>
	<lastBuildDate>Mon, 23 Jan 2012 13:30:27 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: Whaledawg</title>
		<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/#comment-327</link>
		<dc:creator><![CDATA[Whaledawg]]></dc:creator>
		<pubDate>Sun, 26 Oct 2008 16:17:02 +0000</pubDate>
		<guid isPermaLink="false">http://doublebuffered.wordpress.com/?p=77#comment-327</guid>
		<description><![CDATA[&lt;i&gt;The answer is that it’s heavily optimized for automation. For instance, ship movement is not synced every frame, but is instead sent down only when players actually change parameters. In normal movement, the client solves complicated differential equations to predict the location, which works perfectly when you’re mining.&lt;/i&gt;

They did the same thing with Shadowbane and had the same results. In that game you did character movement by clicking on the ground and the server pathed you to the location. But if you got a bunch of people together for a battle it quickly became a slideshow.

However that game was &lt;b&gt;primarily PvP&lt;/b&gt;. If all there is to do in your game is seige towns &lt;i&gt;and&lt;/i&gt; that&#039;s laggy as hell you have a problem. At least EVE gives you a lot to do within their model.]]></description>
		<content:encoded><![CDATA[<p><i>The answer is that it’s heavily optimized for automation. For instance, ship movement is not synced every frame, but is instead sent down only when players actually change parameters. In normal movement, the client solves complicated differential equations to predict the location, which works perfectly when you’re mining.</i></p>
<p>They did the same thing with Shadowbane and had the same results. In that game you did character movement by clicking on the ground and the server pathed you to the location. But if you got a bunch of people together for a battle it quickly became a slideshow.</p>
<p>However that game was <b>primarily PvP</b>. If all there is to do in your game is seige towns <i>and</i> that&#8217;s laggy as hell you have a problem. At least EVE gives you a lot to do within their model.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: YoMma</title>
		<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/#comment-309</link>
		<dc:creator><![CDATA[YoMma]]></dc:creator>
		<pubDate>Thu, 09 Oct 2008 00:17:05 +0000</pubDate>
		<guid isPermaLink="false">http://doublebuffered.wordpress.com/?p=77#comment-309</guid>
		<description><![CDATA[Interesting article. Always good to get the viewpoint of someone with real knowledge and experience of the way these things work.]]></description>
		<content:encoded><![CDATA[<p>Interesting article. Always good to get the viewpoint of someone with real knowledge and experience of the way these things work.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JZig</title>
		<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/#comment-307</link>
		<dc:creator><![CDATA[JZig]]></dc:creator>
		<pubDate>Mon, 06 Oct 2008 19:07:55 +0000</pubDate>
		<guid isPermaLink="false">http://doublebuffered.wordpress.com/?p=77#comment-307</guid>
		<description><![CDATA[Sure, link away.]]></description>
		<content:encoded><![CDATA[<p>Sure, link away.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: CrazyKinux</title>
		<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/#comment-306</link>
		<dc:creator><![CDATA[CrazyKinux]]></dc:creator>
		<pubDate>Mon, 06 Oct 2008 18:09:12 +0000</pubDate>
		<guid isPermaLink="false">http://doublebuffered.wordpress.com/?p=77#comment-306</guid>
		<description><![CDATA[Though I  have a very limited knowledge of the technical aspects you&#039;re all discussing, I&#039;m finding this post and its comments very interesting.

@Noah - You make a good point of influencing players (mostly the Carebears, Industrialists RPers and Socilalizer) to stay-in-station through Ambulation. It&#039;ll be interesting where they focus their upcoming expansion - Midas &amp; Ambulation being not-PvP focused.

I&#039;m looking forward to see if they&#039;re able to pull this off, as they&#039;ve been doing the past 5 years.

&lt;a href=&quot;http://www.crazykinux.com&quot; rel=&quot;nofollow&quot;&gt;CrazyKinux&lt;/a&gt;

P.S.: JZig, hope you don&#039;t mind if I include a link to this post in my &lt;a href=&quot;http://www.crazykinux.com/search/label/speedlinking&quot; rel=&quot;nofollow&quot;&gt;EVE Speedlinking&lt;/a&gt; on Friday?]]></description>
		<content:encoded><![CDATA[<p>Though I  have a very limited knowledge of the technical aspects you&#8217;re all discussing, I&#8217;m finding this post and its comments very interesting.</p>
<p>@Noah &#8211; You make a good point of influencing players (mostly the Carebears, Industrialists RPers and Socilalizer) to stay-in-station through Ambulation. It&#8217;ll be interesting where they focus their upcoming expansion &#8211; Midas &amp; Ambulation being not-PvP focused.</p>
<p>I&#8217;m looking forward to see if they&#8217;re able to pull this off, as they&#8217;ve been doing the past 5 years.</p>
<p><a href="http://www.crazykinux.com" rel="nofollow">CrazyKinux</a></p>
<p>P.S.: JZig, hope you don&#8217;t mind if I include a link to this post in my <a href="http://www.crazykinux.com/search/label/speedlinking" rel="nofollow">EVE Speedlinking</a> on Friday?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: JZig</title>
		<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/#comment-305</link>
		<dc:creator><![CDATA[JZig]]></dc:creator>
		<pubDate>Mon, 06 Oct 2008 17:51:23 +0000</pubDate>
		<guid isPermaLink="false">http://doublebuffered.wordpress.com/?p=77#comment-305</guid>
		<description><![CDATA[Yeah, I agree that moving self-contained tasklets between physical machines works fine, and there are many supercomputer solutions to such a problem.

I just don&#039;t think combat can really be an isolated tasklet, and be remotely efficient. There are too many interconnections of data for it to really be isolated in the way that would be easy to switch it around.]]></description>
		<content:encoded><![CDATA[<p>Yeah, I agree that moving self-contained tasklets between physical machines works fine, and there are many supercomputer solutions to such a problem.</p>
<p>I just don&#8217;t think combat can really be an isolated tasklet, and be remotely efficient. There are too many interconnections of data for it to really be isolated in the way that would be easy to switch it around.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Noah</title>
		<link>http://doublebuffered.com/2008/10/05/can-eve-evolve/#comment-304</link>
		<dc:creator><![CDATA[Noah]]></dc:creator>
		<pubDate>Mon, 06 Oct 2008 00:50:39 +0000</pubDate>
		<guid isPermaLink="false">http://doublebuffered.wordpress.com/?p=77#comment-304</guid>
		<description><![CDATA[I think the basic model of their SOL nodes will hold up well for the forseeable future. Stackless uses a similar concurrency model to Erlang, and those guys have been doing automated task migration for years (mostly to allow for hardware failure, it just switches to a backup CPU seemlessly). Stackless already support [de]serializing tasklets, so adding support to the VM to transparently move them around should be relatively easy. MOSIX (and openMOSIX) has some pretty good algorithms for knowing when to initiate a relocation and such, not that I doubt CCP could figure it out. I think a harder problem will be DB consistency. They already have a lot of limits in the game as to how fast you send commands, my guess is that they use a decentrazied cache with an eventual consistency model. The further you try to scale a non-transactional system like that, the more likely people will find ways to exploit it. Improving the client-side prediction will also be hard, but I think that will come over time. Given how much they are pushing for ambulation, I think a big part of their future strategy may be to draw people away from constant gate-camping (and other forms of PvP combat) and into more social activities.]]></description>
		<content:encoded><![CDATA[<p>I think the basic model of their SOL nodes will hold up well for the forseeable future. Stackless uses a similar concurrency model to Erlang, and those guys have been doing automated task migration for years (mostly to allow for hardware failure, it just switches to a backup CPU seemlessly). Stackless already support [de]serializing tasklets, so adding support to the VM to transparently move them around should be relatively easy. MOSIX (and openMOSIX) has some pretty good algorithms for knowing when to initiate a relocation and such, not that I doubt CCP could figure it out. I think a harder problem will be DB consistency. They already have a lot of limits in the game as to how fast you send commands, my guess is that they use a decentrazied cache with an eventual consistency model. The further you try to scale a non-transactional system like that, the more likely people will find ways to exploit it. Improving the client-side prediction will also be hard, but I think that will come over time. Given how much they are pushing for ambulation, I think a big part of their future strategy may be to draw people away from constant gate-camping (and other forms of PvP combat) and into more social activities.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

