<?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"
	>
<channel>
	<title>Comments on: Lots of AI = performance hit</title>
	<atom:link href="http://www.ludumdare.com/compo/2008/04/19/lots-of-ai-performance-hit/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.ludumdare.com/compo/2008/04/19/lots-of-ai-performance-hit/</link>
	<description>A tri-annual 48 hour solo game development competition.</description>
	<pubDate>Sun, 05 Jul 2009 21:36:55 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.5.1</generator>
		<item>
		<title>By: DrPetter</title>
		<link>http://www.ludumdare.com/compo/2008/04/19/lots-of-ai-performance-hit/#comment-1198</link>
		<dc:creator>DrPetter</dc:creator>
		<pubDate>Sun, 20 Apr 2008 10:50:10 +0000</pubDate>
		<guid isPermaLink="false">http://www.ludumdare.com/compo/2008/04/19/lots-of-ai-performance-hit/#comment-1198</guid>
		<description>I'm embarrassed to say that I don't have a clear idea of what KD trees would be... but a simple and effective method would be to use a good old rectangular grid and store a list of occupant ID:s in each grid cell. So for each tick you start by populating the cells (constant time per entity, grid[y/cellsize*width+x/cellsize].occupants.pushBack(me)), then when you need to find neighbors you just step through a few of the nearby grid cells and check the occupant lists of those. If you just need very close neighbors you can take the surrounding 3x3 block of cells for example.
This should nicely reduce the complexity from N^2 to roughly N (for all but the most clustered cases).</description>
		<content:encoded><![CDATA[<p>I&#8217;m embarrassed to say that I don&#8217;t have a clear idea of what KD trees would be&#8230; but a simple and effective method would be to use a good old rectangular grid and store a list of occupant ID:s in each grid cell. So for each tick you start by populating the cells (constant time per entity, grid[y/cellsize*width+x/cellsize].occupants.pushBack(me)), then when you need to find neighbors you just step through a few of the nearby grid cells and check the occupant lists of those. If you just need very close neighbors you can take the surrounding 3&#215;3 block of cells for example.<br />
This should nicely reduce the complexity from N^2 to roughly N (for all but the most clustered cases).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: LunarCrisis</title>
		<link>http://www.ludumdare.com/compo/2008/04/19/lots-of-ai-performance-hit/#comment-1160</link>
		<dc:creator>LunarCrisis</dc:creator>
		<pubDate>Sun, 20 Apr 2008 01:49:20 +0000</pubDate>
		<guid isPermaLink="false">http://www.ludumdare.com/compo/2008/04/19/lots-of-ai-performance-hit/#comment-1160</guid>
		<description>If the performance hit is coming from finding nearby enemies, you really want to use some sort of space-partitioning data structure for speedup. I've used kd-trees in the past with good results. I did it with the ANN library (http://www.cs.umd.edu/~mount/ANN/), but the algorithms involved aren't that difficult to implement.</description>
		<content:encoded><![CDATA[<p>If the performance hit is coming from finding nearby enemies, you really want to use some sort of space-partitioning data structure for speedup. I&#8217;ve used kd-trees in the past with good results. I did it with the ANN library (http://www.cs.umd.edu/~mount/ANN/), but the algorithms involved aren&#8217;t that difficult to implement.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
