Memory / CPU Overhead of Grid Graphs On Mobile

I am curious about the overhead of certain graphs on mobile (galaxy tab A/S2 or ipad air) and what the limits would be, considering each unit has around 700 or so triangles and basic shaders.

The graph sizes im considering are:
180x180 (node size: 4)
90x90 (node size: 8)
60x60 (node size: 12)

I want to use these 3 grid graphs to support 3 different unit sizes (small, medium, large). Each unit will NOT be driven by physics, unless RVO comes into play, and will use simulated acceleration / deceleration.

My game will feature a max of 5 teams, each with a max cap of around 150 units. So that means a max of 750 units could be on these grids. I will need to “block” other graphs where a unit of a differing size is located. EG: place an obstacle in the small / medium graphs for a large unit occupying that space in those graphs.

Do you think this is feasible for that number of units, graphs and obstacles on mobile?

Hi

750 units is A LOT of units for a mobile game. You will need to use a very cheap movement script (the included ones such as AIPath and RichAI will be too slow, AILerp might be fast enough). The graph sizes look ok, that shouldn’t be a big problem. Possibly calculating paths on the 180x180 graph might be a bit slow. If your graphs would be static (if you decide to not use dynamic obstacles that is), you should look in to http://arongranberg.com/astar/docs/heuristic-opt.php.

To do that in a stable way requires cooperative pathfinding, something which is not implemented in this library (I have been doing experiments with it however: http://arongranberg.com/2015/06/cooperative-pathfinding-experiments/). You can place obstacles like you are suggesting, but with 750 units I fear that would be too slow.

Also, note that 700 triangles * 750 units = 0.5 million triangles. That is quite a lot for a mobile game I think.