Does anyone have any good EDP AI resources that I can look into or work with or read or something?
I'm starting to get a better handle on EDP but AI is just the one thing that alludes me, the only real hook that my brain can scramble up for AI is Move(), but that seems needlessly intensive and overcomplicated to be looping mobs every time you move.
Or is it?
Now I think about it, the comparison between having 9001 idle mobs looping once every 10 seconds and having 10 players looping every time they move.
I honestly don't know if it's more efficient or better practice, but regardless I want to figure at least something out so I can say I did it in my most Dunkey of voices.
Either way, some discussion about the topic would be nice.
ID:1332243
 Jul 23 2013, 12:19 am
|
|
|
Jul 23 2013, 12:45 am
|
|
Stephen001
  |
What's an EDP when it's at home? Google has failed me.
|
Mr. DP?
Wait no don't Google that. Event Driven Programming. | |
Oh, we've made that acronym too, huh.
You can go half and half, depending a little bit on if you use areas much already. Divide the map into logical areas, towns, wide spaces, caves etc. When players enter such a thing, you can activate the AI of any enemies in the area. They continue until the last player exits the area, at which point, if they are not engaged in some kind of attack/follow activity, they can switch off. As ordinarily for RPGs, towns are the most populous areas, and contain the least enemies, your most 'active' areas probably don't contribute much CPU use. Similarly, enemy-filled hard dungeons spend much of their time-inactive. If you combine this with reasonably intelligent partitioning of stuff via the map features, 80% of your AI is dormant much of the time. This is particularly useful on initial release, where all your players are newbies, and in the same 3 or 4 areas. Generally, the player driving a check each move isn't so bad. Your own real concern being move latency, more-so than anything else. There's still strategies for de-coupling that a bit, by scheduling an event each move (and making sure you don't have one of those aforementioned events scheduled) that does the check, if it proves problematic for player movement. Your only big issue then being under 90%+ CPU use scenarios, where a player could just glide straight past a group of enemies, and never activate them. | |
You can make use of areas and area/Enter() instead of turfs to cut down on CPU usage. Instead of making a check every move, you'd make one every time a player entered a new area. This also has the added benefit of being able to check the area's contents instead of having to loop through a large range() check.
If your areas don't line up neatly with your maps for whatever reason, you can make an ai_controller datum and specify a list of z's that have active AI's. Then your check becomes a simple if(!src.z in ai_controller.activezlevels) ai_controller.activate_ai_on_level(src.z). Or if that's not fast enough because you need many z-levels to be active at once, you can use bitflags. | |
Another interesting idea is to split the events activation areas into smaller same-size cells.
Normally, everything you do would operate on "tiles" or "turfs". There's only so many of these in a given space. This is the way most games work where they'll make checks on every "Move" which happens per tile. But what if you could call events every 2 tiles, or every 3 even? Then you've saved quite a bit of power and certainly in the case of activating or deactivating AI brains, this wouldn't change much range-considered. But like Stephen said, the check-each-move isn't bad. Its just how you implement it that matters. | |
