{"author_name":"yangamedev","cat":"MiniLD","comments":[{"author_name":"MiniBobbo","time":"July 25, 2013 9:06 am","epoch":1374761160,"text":"It has been interesting seeing how you tackled this problem. It is one I’ve been pondering also. I like your implementation and might have to steal the basics.","spam":"N"}],"epoch":1374724260,"likes":3,"metadata":{"p_key":"42292","p_author":"yangamedev","p_authorkey":"20928","p_urlkey":"77915","p_title":"Out of Sight","p_cat":"MiniLD","p_event":"LD27","p_time":"1374724260","p_likes":"3","p_comments":"1","p_status":"UPD5","us_key":"20928","us_name":"yangamedev","us_username":"yangamedev","event_start":"1377216000","event_key":"18","event_name":"LD27"},"text":"

Last time I showed off my 162-unit RTS at a stunning 5 seconds per frame. Not FPS, that’s SPF. And that ain’t good.<\/p>\n

Clearly it’s not scaling well as I crank up the units. What we’ve got here is your classic O(n^2) problem between entities. There’s a bevy of literature out there regarding space-division in a proper manner for these types of issues, but I had an idea.<\/p>\n

The game literature out there deals with LOS for terrain but not for dynamic entities. I decided to roll my own: introducing the Visibility Matrix(tm):<\/p>\n

\"darkness\"<\/a>

Anybody there? “None.” Seems legit, Bob you’re on point.<\/p><\/div>\n

 <\/p>\n

You’re blue, the enemy is red but hidden (left the text on to show their position). I turned off the world so it can read better, but remember there’s a slab in the middle of the world blocking each other’s view. Each cell refers to the visibility between the two actors. The “oo”‘s mean “can see”…the “–“‘s mean “can’t see”.<\/p>\n

 <\/p>\n

\"during\"<\/a>

Good ol’ Bob. Never complained about recon.<\/p><\/div>\n

\n

 <\/p>\n

Visibility between Blue:7 and Red:0-5 has been established in the Visibility Matrix, and the units can query these values rather than generate it on their own expensively.<\/p>\n

What makes this faster is these vis checks are\u00a0time-sliced<\/em>, i.e. only a few of them are updated every frame instead of the O(n^2) nightmare from the last post. To achieve this we simply walk through the matrix left->right, top->bottom, updating each cell with a fresh LOS.<\/p>\n

How many cells do we update each frame? Well if there’s\u00a0n<\/strong>\u00a0units, then the Visibility Matrix only needs n * (n – 1)<\/strong> \/ 2<\/strong> cells, as visibility is commutative<\/a>\u00a0and we assume each actor can see themselves. Best of all we \u00a0guarantee that no enemy can see you before you see them, so no ambushes just a little lag.<\/p>\n

Finally if we demand a\u00a0maximum response time<\/strong> for the unit in frames, then the number of checks performed each frame to guarantee an update = max frames \/ # cells<\/strong>. At 60fps and a 1 second response time your calls are spread out over 60 frames.<\/p>\n

 <\/p>\n

\"pincers\"<\/a><\/p>\n

Here’s the same 162 units rocking it out at a smoking 9fps. I’m calling it 10fps, that’s a 50x framerate increase.<\/p>\n

Where this really takes off is I can store\u00a0more<\/strong> than just vis data in there — distance calculations, health differential, whose turn it is to do the dishes, whatever I’d normally have to generate at runtime about information for each pair of actors.<\/p>\n

Once I move all these calculations to the server I hope to throttle up a gear in terms of units. But maybe I should make a game first…<\/p>","time":"July 24th, 2013 10:51 pm","title":"Out of Sight"}