KH War TODO List

I tried coming up with a good logo the last two days but i didn't really succeed. This one is like the small one in my signature, the axes took me quite a while to get them look good. I don't really like it but right now i can't think of something better.

And yeah, really nice work accounthack this should be good to use.

Fuck yeah!

Just waiting on Kong to get back with me about changing tax informtion.

Another try, i like this one better but i am not so sure if the WAR part is actually readable. I guess many would read it as KRH or something.

Looks bad ass man!  Definitely like this one better.  The KH WAR is a bit confusing, but since it's re-stated right below it, it should work out. :)

Please consider removing the timer for attacks that fail because the selected spot is not adjacent to your land, and for evacs on land you don't own.

Also, if you do leave the global-ish geo eff recalc and go with the much-more-efficient local updates to face/tile count, consider removing or seriously reducing the timer on evacs generally.  Partly, players are happier grinding out time to expand, compared to spending time to contract; partly, spending half your time evac'ing to advance your scouting party across the plain is tiresome; and partly, there are tactics that leave you utterly crippled and unable to do anything but abandon unless you spend a large chunk of time on evac, which is likely to drive away players who would otherwise tough it out, and we'd rather have them around.

OK, i tried several ways to make the WAR part in the last logo more readable but nothing really worked so i am back with a simple version. I slighty rearranged the axes and the text as well and i guess i gonna call this the final version

@ZuckeR
Very nice, i like it.
Reminds me of the good old game classics.
 

So you gonna create an image that shows a certain part of the map (25x25) so the browser does not need to render the individual cells anymore? That sounds good, especially since i don't like that the map moves on every attack/evac even if it does not need to. It would be great if the game would only automatically move when you do something close to the border of your visible map. Which makes me think that a quadrant should actually be smaller than what is displayed so it should actually be like 12.5x12.5 or are you gonna display more quadrants if needed (max 4).

Do you also want to have more tiles for the terrain? Because i already tried but it is hard because of the variety of the terrain. Especially those tiles connected to water have a complete different color. I guess the map image you created the map from was created from the original map data and those blue tiles should actually be water and some colors are just jpeg compression artifacts. If you would use three images (grass/water/hills) the map would loose variety but might gain some texture.

Quadrants are a 25x25 area, one entire map's view.

The inherent problem is the speed of database transactions.  I'm still working through how I want to handle this. I'm thinking of a few different options.  All of them end with making the map "static".  That is, only load one screen, change the individual parts on that screen, etc. instead of moving to a new screen on each point.  The old game did things that way, and it worked out very well.

1) My first thought on speedings things up is to throw a compiled array into memcache and maintain it.  I'd need a 27x27 array for this, as I'd need a 1 tile ring around the map for display purposes only.  I'd need to swap data in and out of the memcache array just to be safe.  It does lead to an issue with writes though.  The DB isn't async, so the response would still hang.

2) To build on #1, scrap the memcache thought, and add a memory table to the DB for "queued updates".  Have a php job that runs in an infinite loop, looking every few seconds to see if there's anything in the memory table, and if so, process and update the DB.  This would separate the business logic from the display and would drastically speed up game play, with the down-side of non-immediate responses.

3) Combine the memcache & memory table scenarios together.  It'd be extensive and memory intensive, but it might work...

Any other ideas?

Having the map scroll is convenient for attacking/evac'ing in a line, and inconvenient for keeping your head about you in an active skirmish.  The former is more common, and the latter more locally important.  Both are likely less important than making the game take a smallish amount of resources so that it can scale up in users.

The descriptions of the DB access quantities and times suggests that a more effificent underlying structure would be 'an array by rows, of pointers each to an array for that row of cells, each cell containing nation, water/land/resource/orb, and potentially image/color index'.  Then you could use direct access instead of more expensive queries.

But it might difficult depending on how much would need rewriting, so whether it's worth it is up to you.

I think you could get some aspects of the map completely static. So you could put those infos in a simple php array rather then putting it in the database. This of course would only work if you do not plan on changing the map too often.

Map cell data could be static and if quadrants are pre-rendered you would only need to send the cell type for each one visible.
$map[x][y] = array(
 'type' => 1,         // ground/water/??? determines if you can walk/attack a tile.
 'color' => '#ffffff' // not needed on pre-rendered quadrants or if the cell type would have a color assigned to it.
);

Landmarks / Orbs could be static if you do not plan on changing them on a regular basis.
$landmark[x][y] = array('type' => 1);
$orb[x][y] = array('type' => 1);

Now you would still need to get who owns which cell and how many forts are placed from the DB. But that way you would only need to improve those requests rather than getting all the other infos as well.

The down side there is parsing a massive array on each successive hit.  Essentially loading 2.6 million records on each load is more exhaustive than querying the database for 250.

I've found a way to do a lot of what needs to be done.  It's just a matter of having the time to do it.
I'm going to be knocking out the overhead of map calls by using a stream server and async checks.  My new central function should be able to take care of things.  I just need to time to get it all functioning. :D

Yeah, you are right databases are pretty damn efficient for searching. You would need to split the data into several arrays and files you could include when needed so only having the quadrant you are on in memory. It could work but would also be pretty messy. I guess your async idea should be more efficient.

I'm supplementing this with memcached quadrant arrays that drop themselves from ram if they aren't used in 2 minutes.  This way updates will appear lightning fast for the end user when they're actively playing. :D

A few 'would be nice' enhancement ideas:

1) have the keys E/A/F/M set the next action type, so we don't have to go down to the picklist
2) have the coordinates appear in the, hmm, status line updates (Attacking could be [2,494] Attacking, etc.)
3) have the status line updates spawn/stack from the lower right instead of the upper right, so they don't overlap your xp in Stats or the recent actions in Log.

None of them are showstoppers, but they'd be good ROI, I think.