What I mean is that moving one square costs practically nothing with A* if you have the graph in memory already. The cost is only prohibitive if you have to build the graph on every click.

If you already have the graph you're going to traverse, A* will not cost pretty much anything since it will only check one node. If you need to build the graph for every movement then it'll probably be too costly. You could consider doing an adjacency check, since you won't need A* for a mouse click...

Jackolantern wrote:I am not sure MySQL will like having a linebreak in the middle of a query.

Doesn't care.

The screenshot link doesn't work.

You could also lazy unload the divs when they're no longer in view.

Yes, the sessions are handled chronologically because the session file is locked and the later loads are waiting for the file lock to open. If the same user polls a lot he may experience lag because of this. I think that session_regenerate_id() creates a whole new session file, which explains why it...

I've used jQuery UI draggable (http://jqueryui.com/draggable/) in the past for some prototypes of draggable game maps. It was pretty simple in my experience, but I'm not sure if it suits your requirements, you'll have to test it for yourself.

You should combine all those load() function calls into one getJSON(). Seven calls means up to seven times the bandwidth wasted.

Most of the lag is probably caused by your server-side scripts. A likely culprit is DB writes causing locks.

What does stats_update_query.php do? 15 players polling at 20 second intervals shouldn't lag at all unless you're doing some heavy stuff.

You mean something like <?php for( $i = 1; $i <= 6; $i++ ) {     ?>     <select name="attack[<?php echo $i ?>]" tabindex="2">     <option value="3">Attack High</option>     <option value="2">Attack Medium</option>     <option value="1">Attack Low</op...