ID:1663815
 
(See the best response by Kaiochao.)
Problem description:

Hi, I'm working on an AI system, and I'm running into a few problems. Basically, I'm working on a game where players can group up into parties or go alone on adventures in dungeons and forests. In other words, the player should have the ability to fight my bosses at the same time as another player, but not *with* the other players unless they're grouped up in parties.


Party
var/members = list()
proc/AddMember(mob/m)
members += m



Here is my WIP party system. What I want to do is make enemies only render and process to players within shared parties(unless they're going alone).


I've thought about just making the monster's icons only render to mobs within certain parties, but then you'd still have all of the lag to deal with. What do you recommend?
Best response
Yut Put's Epic does this by loading a new copy of the dungeon for every party that enters it. There are a few ways to do this and a couple libraries that have been made for it, such as SwapMaps by Lummox JR and Map Instancing by Forum_account.
In response to Kaiochao
Thanks for your response, Kaiochao!

I'd imagine that'd be a bit... intense on the processing. Basically, you already have 3,500 tiles in your game that's causing minor lag spikes, and then you create multiple instances of your dungeon and forest with approximately 10-30 looping NPC's in each copy, with about 20 players each in their own dungeon. Not to mention the 50+ NPC's you have in public regions.


So that 50 public NPC's + 20 players * (let's say) 20 NPC's roaming in the party dungeons.


That's 450 NPC's on the server that are looping. That's a big frame loss.

In response to LongCat666
Tiles sitting around doing nothing are causing lag spikes? That's not normal. Sounds like you have bigger issues than map instancing to worry about.

Not all NPCs in a dungeon (or in the public) have to be active at the same time.

When loading a dungeon, you of course don't have to load it all at once. Sprinkle in some sleep delays and throw your player into a loading screen.
In response to LongCat666
ter was benchmarking this with someone recently. He maxed out at 70,000 active objects. Of course more logic means this will max out sooner - but either way, if you want to check out what they were doing, it is in the following post.

http://www.byond.com/ forum/?post=1639389&forum=20&page=2#comment11624198
70K objects with a 3.6ghz processor under the condition that they're seperated from each other and call an unmodified movement procedure. I use oview() in my AI which adds up to have a recursion really similar to the example Theactivenet presented.

That could add up to be problematic if there's several hundred AI's in my game co-exisiting together. I'm beginning to think there's no way to circumvent this problem. This is something that all modern gaming platforms should be capable of, but this seems to primarily be a BYOND issue.
He created 350 AI object in the same square. In the situation you presented above - you would not be doing this.

The more reserved AI programs will look at things active around them - and only start working when someone will see the work. They will preserve things like target data, rather than using oview() every iteration to get a new target, and other things to save on the additional logic they need to do.

Even not so reserved, many games have proven that they can handle this without capping out on CPU.
No, he created 350 regular(non-AI) objects in total, and only 32 were occupied in the same space at one time. An oview() of 5 iterates at the very least, 25 turfs plus whatever objects the turfs are containing-- so you're incorrect.

I'm familar with the second part you've wrote, but in context I assume they are needed to be active. 100 Players, 5 AI in a dungeon each at the least-> 500 AI that needs to be active at once.

Oh yeah, which BYOND games?