Mob status
#31
@xoft: The "field data" would become stale once the mob moves a bit. So, essentially, whenever the mob picks a single place to go to, it has to throw away the field and calculate a new one. That essentially takes us back to the current implementation.

(05-29-2015, 01:37 AM)worktycho Wrote: The problem is that you need ~800KB of information per mob.

800KB per mob? What? Who? How?

Perhaps the main interface problem is that the PathFinder is a "dumb machine" which knows nothing except spitting out the Path from A to B. This leaves the management stuff to Monster.cpp. One option would be creating a PathFinder wrapper which offloads the Pathfinding logic from Monster.cpp
Reply
Thanks given by:
#32
48 * 48 * 48 * 4 = ~800,000. I think a PathFinder wrapper would be the way to go if we find we need more options than just give me the path from a to b.
Reply
Thanks given by:
#33
(05-29-2015, 02:26 AM)worktycho Wrote: 48 * 48 * 48 * 4 = ~800,000. I think a PathFinder wrapper would be the way to go if we find we need more options than just give me the path from a to b.

We do have a more sophisticated logic, but it's ugly tight coupling right inside monster.cpp.

What's the 48 and the 4?
Reply
Thanks given by:
#34
I figured out your numbers.

A naive implementation would indeed reach this. But a well-written Dijkstra/Astar is much more efficient, because it won't scan the whole area, it will only scan walkable areas. So, for a 1x1x1 chicken on a plane, only the ground plane will be scanned, that would be 48 * 48 * 4 = 9216. A typical mob is bigger than 1x1x1 and the world isn't always a plane, so I'd roughly estimate that the memory demand is 48 * 48 * 4 * x where x is somewhere between 1 and 5.

Note, that the idea of a reversed Dijkstra (a field around each player) would mean that memory is consumed per *player* and not per *mob*.
Reply
Thanks given by:
#35
It goes up to 36K, because you need to store the coordinates the cost is associated with. Thats less than 800K, but still a considerable amount of memory per mob, but I agree that per player, it would be a good thing to have.
Reply
Thanks given by:
#36
Per player pathfinding would be nice, but a dumb path finding code should be available too (for plugin devs, and other future uses).
Reply
Thanks given by:
#37
I don't think it's really needed though (per player Path field). There isn't a significant performance issue, and JPS should boost performance if it's ever needed.
I think we just need a wrapper around cPath to remove some responsibilities from cMonster.
@jan64: Agreed, cPath should still be available on its own.
Reply
Thanks given by:
#38
^^ That wasn't me -- I understand nothing of this process, but it sure sounds like magic to me, if you know the quote. Smile
Reply
Thanks given by:
#39
Meant janTongue
Reply
Thanks given by:
#40
Yeah, I didn't crunch the numbers when I wrote that, I was just brainstorming out loud Smile
Reply
Thanks given by:




Users browsing this thread: 2 Guest(s)