So currently our server's having quite a bit of trouble with lag, and I think the current culprit may be the massive amount of monsters on the map who are constantly searching for mobs in their view to find a target.
So, I was wondering what the efficiency of a system where whenever a player walks it searches for an enemy mob, and if it finds one, it "activates" that mob. Meaning that inactive mobs don't move, search, or anything else. Obviously the major problem with this will be that every time a player moves it will be searching for enemies.
So I coded it to see, and sure enough the start-up CPU usage went -way- down (obviously), from 20-30% to 2%. The problem is, we can't test it until later this evening, and I was wondering if I should be prepared to remove the ping-system -fast-.
In my head it seems like as long as there aren't a DRASTIC amount of players (our average right now is 40, but I mean MORE than that), then it should reduce CPU drain by quite a bit. After all, not EVERYBODY will be moving, and even when they do it only searches those in their view.
So, any thoughts or comments?
ID:152178
 Nov 10 2007, 1:19 pm
|
|
That areas approach has the quirk of someone running slightly along edges of areas, keeping "spam-de/activating" monsters. Imagine a battle happening to take place near the end of an area; players running all around.
You could somewhat rectify this by placing smaller 'border areas' separating 2 monster areas. The border areas have no monsters [spawns] in them (and monsters can't Enter() them), and when Entered() they don't do anything, neither activate or deactivate monsters; only if the player goes further on in his direction to the next "real area" such will happen. Though if you already go to this extent and use large areas, it'd be more beneficial to delete monsters in inactive areas (in that case you'd probably prefer to only delete those 2+ areas away from a player etc), keeping track of the deleted monsters in a list on the area (save the type and coordinates, and if wanted maybe another var or 2 like health), and re-create them when a player again steps into range. | |
This is where neighbor areas come into play. If monsters inside an area are activated whenever a player enters a neighbor of that area, that problem won't occur, and you can still place monsters in any area.
| |
I always did Garthor's method with an entire map. No players on the map means AI off. Just have to be careful about multiple enters and exits. I know I managed to let that turn the AI on more than once. Which made me NPCs speedy little buggas. It also means you need to make mapS instead of using just one.
| |
Figured I'd share my results:
With the mob constantly searching for people: Startup 20-30% CPU Usage Ping-Based System, Deactivating Mobs When Nothing in Sight: 0-10% at 40+ players. I call this a success. <3 | |
Well, I think 10% CPU usage for AI is still plenty. You should take a look at the area-based solution proposed.
| |
Just make the monsters stationary until a player comes within a certain distance of them.
| |
Alternatively, and probably requiring less work:
You can just use orange() instead of oview(), for pretty much the same effect with - potentially - a bit more efficiency. Big mazes full of monsters would be something this wouldn't cope well with, though.
Remember to deactivate monsters when they've got nothing to chase. Also, instead of using oview(), save things that trigger a mob in a list, then have it check the distance with get_dist(). If they're out of range, remove them from the list, and if the list is empty, deactivate.