Game - See serpant land moving

[jendan]

Strange behavior of see serpant.
When you select see serpant and try to move him to not coastal city, game is frozen for few(2-5) seconds. In the end the path is calculated and it seems you can move to city.

http://imageshack.us/photo/my-images/7/seeserpant.jpg
I think this path calculation can use pretty much of server cpu time.
My guess is that see serpant has ability to move in water, swamp and city but path calculation at the begging don't know if the city is coastal or not, so path calc start to calc path.
Solution: Every city would have boolean flag that says if it is coustal or not and in path_calc method will be if clause to ask it.

EDIT: Posted link to image, because image tag is not working for me. What Am I doing wrong?

[SnotlinG]

Hello,

Yes you are correct, seaserpent can move on sea/shore/swamp and city, so it tries to find a way to that city but cant, so it takes the shortest road. Maybe it should return an error-popup instead.

The problem is that its hard for the game to know it is impossible to find a path to this city until after it has made the calculation (client freezes for a few seconds). Even if we make a flag for cities for costal cities (or cities next to swamp) it wont be enough, as you can have a city with just a small sea or small swamp next to it, but which isnt connected to the main sea where your seaserpent is. So its a bit hard to solve this issue in a nice way

[jendan]

If I may, I come up with idea solving it.

When you submit or finalize map, mapEditor will create sets of coordinates where sea serpant, kraken and other future water-creatures can move. Lets call them "pools". Pools will be attached to each map (part of the map). When water-creature is created, server will find out in which pool the creature is in. Each creature can live only in the pool it is created. Each time you select destination, path_calc checks if destination pool is same as creature.pool. If pools are different there is no need to calculate path.

I think that my rough outline of code in ruby-pseudocode will speak for itself.

#centrum of pools must be cities, because creatures is created there even if they don't have swamp or water near => Now, it is able transfer production of sea serpant to city in the middle of grassland. Sea serpant can move only in that city. I dont see reason of doing that, but it is possible.

#part 1 preperation, creating pools
pools = Array.new
for city in cities
pool = Pool.new(city.position) #returns array of coordinates
pools.insert(pool)
end

#part 2 creating creature
create = WaterCreature.new(..., pool_id) #each water-creature will obtain id of pool it can live in

#part 3 path_calc
if (create.pool_id == destination.pool_id)
path_calc
else
raise error/dialog
end

What do you say?
I may look at it closer

[SnotlinG]

Its a good idea
I will take it into consideration.

Downside is:
1. calculate the pools when map is finalized - if done by client it would add some time to the processtime. If done by the server it adds load to the server. This is probably a minor thing though
2. DB space, we need to save all the diffrent pool coordinates in the DB, taking up diskspace. Some pools can be quite big so might be disk consuming.
3. We need to load the pools into the client memory when loading a game. Might be a bit memoryconsuming cosnidering the limited use (many games dont build any seacreatues etc).

But still, it might be the best solution so far, so I will consider it Its not urgent though so its only on the consideration-list for now

Thanks for input!

[jendan]

Ok
to Downsides: Everthing is compromise. In coding it is between cpu time and memory.

[KGB]

I think the code for this will be a lot harder to implement than you think.

It looks like you are creating arrays of pools based on cities. That *seems* OK, but how are you going to handle double calculations. For example cities straddling 2 bodies of water like this:

C = city
W = water
L = land

LLLLLLLLL
CWWCWW
LLLLLLLLL

The left most city must be able to path to the water of the right city when you own both but not when you own only the left city. But I suspect your code won't be able to do that. Unless you are literally going to try and move to every map square from every city and record whether it's possible. On a 150x150 map with 22000 squares that's going to take number_of_cities*22000 paths which is going to be more than a few seconds

KGB

[LPhillips]

KGB,
You brought up the issue I was thinking of while reading this: "pools" connected by cities or other path barriers. Stole my thunder
Simply plotting a path through the enemy occupied territory (just as it does now when a unit stands in your way) should avoid any extra hassle. "Pools" connected by anything passable, such as a city, should be considered one pool. Then the pool recalculation needs to be done only when a city on the map is razed or rebuilt.

Snotling/Piranha,
Pathing is always a nightmare, but you have a system now which allows players to figure out paths themselves and input them piecemeal when required. It's a pretty impressive and effective system right now. Some delays when a player attempts to path to unreachable locations are probably unavoidable, but the player has to take some responsibility for causing the delay himself.

[SnotlinG]

Yes I think easiest solution might be to just give the player an info-popup if the calculated path is impossible (as the seaserpent case for example). Otherwise you might start moving your unit and not realizing it will never be able to get to the destination.

Thanks for all input

LP, yes Im quite happy with it now also Its based on a* algorithm: http://en.wikipedia.org/wiki/A*_search_algorithm