Are you doing visibility checking (like line of sight) frequently between objects (to see if they can shoot at each other or other ranged interactions) and their enemies/targets?

If so, you can down grade any constant RE-pathfinding to a lower frequency when the target is out of view (you cant be sure where the target is so you are doing more an approximation until you can determine its position again). You would crank it back up when you are closer - but lack of visibility still will effect the raw pathfinding in some way and you would have some searching behaviors or somesuch in the non-visible cases.

The less frequent (rougher) pathfinding also might be used when the target is at sufficient )far) distance.

You might want to look into hierarchical pathfinding which allows pathfinding at a Coarser level and then with a more limited area (to be in your candidate lists) when you are pathfinding in Finer (full) detail.

First: Networking affects the design of games all the time. It is *not* in general possible to take an arbitrary game design, not made with consideration to the needs of networking, and then "make it magically work on the network." If you have certain memory or performance requirements, then that explicitly means you have to exclude certain machines from partaking. Saying "it just has to work" is like taking the design for Far Cry 4, and then telling the graphics programmers "and now make it work on an Intel GMA 950."

Second: The point about "don't load all the graphics" is that, if the total size of all assets is 1.7 GB, and it's split on a large number of maps, then it's likely that only one map will be loaded at a time, and thus only a subset of those 1.7 GB will be loaded at a time.

Third: You really do need to take a profiler to this game, if the performance behaves like you say it does.

Hi.

If Path finding is to slow, you may need to allow the path to be found over a couple of frames or more, don't block until you have a path, this means if the unit does a line of sight and there is nothing blocking its path you can move the unit upto the point the line of sight found a block , this way the unit moves while the path is being generated.

I had to do this with my very first game it was directx 7 on a p2, also I the paths are stored for a while and when a unit wants a path it checks the avalible path if the end node and start node is near the destination and start it would reuse that path. that alone cut down path blocks heaps.

And keep in mind that the program should be like a river that always flows no dams, any big lists of objects don't process them in one go each frame proccess a few at a time no one will notice it.

All of the above what you've suggested is already done. And really I'm not here to discuss about pathfinding. That's a problem what I won't be able to fix.

So, you are saying that there is no other way to handle multiple maps, just if the host handles them all? This requires a lot of rewriting, because the game is now only handles one map. I mean there are animation based events too, scripts on the maps, etc. I don't think I will be able to pull it off in an already existing code, maybe in the next game...

Thanks for the answers, you've been a great help! :)

So, you are saying that there is no other way to handle multiple maps, just if the host handles them all?

Well, you can have the first player to enter a map be the "host" of that one particular map, and then if he leaves the map someone else in that map needs to take over (or if nobody else is on the map, destroy it). Basically, "peer-to-peer" instead of any single player doing the entire hosting.

But this is far more complex, far more buggy, far easier to grief other players, then just fixing the broken part of your code. If Doing It Right isn't an option, you can do it differently. But we'd be negligent if we didn't try to convince you that there are better ways.

Grief is not really a problem, but yeah, it's so complex, and hard to code.. So I guess this remains in the older games, and in the new ones, I'll write a normal map handling.