As many of you might know, in my Games Slime Journey (1 and 2) I USED to have monsters roam the world at free will. At first this was fine, but I started to have problems of too many monsters moving at once and beating the hell out of my CPU Usage and Mem Usage. I don't know if this will work, but I think I have a solution I want to share for anyone who might or does have this problem.
It's probably pretty obvious for some people, but sometimes I lack in common sense, and many others join in on this.
Simply add a if(prob(25)) or something similar to the movement command that the mobs use. This will help a lot on this problem, as they will MORE randomly move about, at only a 25% chance. So far I think this should do it.
Any other ways people can think of of mob movement cpu-usage assistance?
I used to try a thing where mobs only moved if they were visible within your screen, but somehow it didn't really work, or at least it didnt seem to help.
ID:152333
 Mar 23 2007, 2:04 pm
|
|
Well the run away exploit isnt a problem because the monsters are there just to touch-start Turn-based combat. I like having visible monsters when you fight them, not random battle starts.
I'll think about doing the Z level activation. It sounds plausable if the prob() doesnt assist in the problem | |
Polantaris wrote:
Well the run away exploit isnt a problem because the monsters are there just to touch-start Turn-based combat. I like having visible monsters when you fight them, not random battle starts. You should seriously look into turning off the loops when they aren't necessary. The prob() will reduce the problem by quite a bit - until you add more monsters, then you'll just be back where you are now. There are LOTS of threads on this in these forums that you could consult for code, too. ~Polatrite~ | |
Polantaris wrote:
Simply add a if(prob(25)) or something similar to the movement command that the mobs use. This will help a lot on this problem, as they will MORE randomly move about, at only a 25% chance. So far I think this should do it. That won't solve the problem as well as you think it would. Don't forget that prob(25) is also a command, and it relies on a mathematically-expensive operation -- a random number generation -- in order to evaluate. While you do save a lot of cycles that would be spent on Move(), which is a rather complex function (Move()->Enter(),Exit(),Exited(),Entered()), you also add more computation into the original system. Basically, you won't cut down the problem by 75%, but probably only closer to 40%-50%. Instead of doing this, you can try a cheap trick: Track creatures in terms of population numbers per region. When a player moves on a map, make a random probability roll. If the probability roll passes, subtract one from a randomly-chosen population (more advanced systems will weight based on populations and will make depopulation make it less probable you'll encounter a creature), and place the creature just outside of the player's sight, preferably a small distance ahead of the direction player is moving (also check to make sure that your location isn't in the line of sight of some other player, 'cause it always breaks fiction in a bad way when a monster spawns from nothingness unless it's a spell or other special effect). If the creature goes too far away from any player, the creature gets deleted and the population number gets increased again. Allow the population to increase naturally over time, as well, up to a certain population cap (this should be based on how much natural food a population could expect to find in a given region). Alternatively, you can include more intricate migration and breeding systems. This is extremely good for memory as well as CPU, but when you get more and more players it bogs down. Thankfully, you'll never have as many players in the game as you'll have monsters in the game -- unless you decide to move to almost pure PvP some day ;-) -- so this will always be cheaper than having all of the monsters make random rolls. | |
Anyway, the best solution is to simply turn off their AI when no one is around. Generally speaking it's easier to track players by z level and turn them off when no players are on that z-level. Doing it based on whether they're in view or not isn't much harder, but it often leads to exploitable mistakes (ie, a player can attack a monster, run until it's off screen, heal safely, come back and continue fighting it and repeat until it dies).
[Edit]
Oh, and when I say 'turn off' I mean completely turn off, not just stop their movement. Stop their AI loop and restart it later when you turn them back on.