Syntro said:What if you guys implemented a machine learning capacity for mobs of camps and special zone where mobs with randomized initial spawn and/or patrol parameters could slowly learn which parameter increased their fitness or survivability and allowed the mob to slowly begin weighing the probability distribution of each randomized parameters?
Here's a simple example:
3 mobs spawn near a hut. Each hut-bound mob, namely, mob_1, mob_2, and mob_3 have parameters, l_i, d_i, and p_i where l is the x-y spawn location, d is the average distance between other mobs in the hut, and p is the path length of a randomized walk and i=1,2,3 corresponds to each mob. Each parameter could have bounds so that the integrity of the camp could be preserved, if the devs so desire.
Now, lets say players start camping this hut. After this first spawn, each mob_i randomizes their spawn parameters and populates the hut. Let each mob_i have a parameter t_i which records their lifetime in seconds and another paramater tg=t_1+t_2+t_3 is the total lifetime of the group. As the camp gets killed and killed and killed by players, the mobs begin to learn that when d_i is minimized, which means the average distance between each mob is small, tg, the total lifetime of the group increases. As such, the probability that the mobs spawn closer to one another increases slightly and the hut begins to densify over time as the mobs adjust their spawn parameters probability.
This learning process could allow from some pretty sweet emergent behavior where, for example, one mobs learns that if he spawns in a certain location which is behind a wall, he begins effectively ambushing players which increases his lifetime. Or a patroling mob learns that if he walks very near to a camp, his lifetime increases and the lifetime of the camp increases such that he could eventually be integrated into the group.
It would be very important to make the learning process very slow and the range of the spawn parameters very tight so that the whole zone loses its structure and players can enjoy the similarity of a well known camp, but visit it in a year and its configuration has been optimized such that its a fresh experience.
Boundary conditions of these parameters would be important too, otherwise zones sould just turn into deathball zergs of mobs camping the zoneline haha. I'd love to have at least one wild zone where no parameters have bounds and see what behaviors pop up naturally from mobs interacting with the players and see if players could "learn" how to deal with it.
Now that would be some serious PvE, and even allow for EvP, so to speak, where players learn how to deal with the learning of the mobs and the mobs learn how to adjust accordingly in a never ending cycle. Whew.
+1 (Deus ex Ludicrum)
@Syntro
Cool thoughts.
May get more bang for your buck by looking at other traits rather than just spawn location:
-- Mob disposition - Brad has said that some mobs will spawn with certain combat dispositions, ie aggressive, stoic, etc. Having mob spawns learn what dispositions work best might add to the challenge.
-- Mob abilities - In EQ some mobs would only use certain abilities in their skillset. I remember a named in Riftseekers that would either summon adds, or cast a mez/charm (I can't remember which, it's been a while) but it would never do both. Dificulty could be increased by having creatures spawn with a few abilities out of a larger list for that particular class of creature, then randomizing the abilities and seeing which ones create the best bang for the buck.
You could then come up with different measures of 'success.' One obvious one being that the mobs managed to kill a PC character, but others could be things like *time spent alive while in combat* or *amount of damage dealt/absorbed*. Then have mob spawns gradually favor the traits that work best. You could throw other features into the model, like what PC classes were involved in the encounter, their level, etc.
One problem with machine learning models though is that they can very quickly get expensive both in terms of time to run and computational power required. The question would be if there was an algorith that could be applied that was both powerful enough to provide a meaningful impact on encounter difficulty, yet simple enough to not bog down the system.
Elrandir said:May get more bang for your buck by looking at other traits rather than just spawn location:
-- Mob disposition - Brad has said that some mobs will spawn with certain combat dispositions, ie aggressive, stoic, etc. Having mob spawns learn what dispositions work best might add to the challenge.
-- Mob abilities - In EQ some mobs would only use certain abilities in their skillset. I remember a named in Riftseekers that would either summon adds, or cast a mez/charm (I can't remember which, it's been a while) but it would never do both. Dificulty could be increased by having creatures spawn with a few abilities out of a larger list for that particular class of creature, then randomizing the abilities and seeing which ones create the best bang for the buck.
You could then come up with different measures of 'success.' One obvious one being that the mobs managed to kill a PC character, but others could be things like *time spent alive while in combat* or *amount of damage dealt/absorbed*. Then have mob spawns gradually favor the traits that work best. You could throw other features into the model, like what PC classes were involved in the encounter, their level, etc.
Oh yeah, most definitely. I just wanted to give a simple example to get get the point across. You bring up some great options too. There could be plenty of measures and metrics to play around with.
Elrandir said:
One problem with machine learning models though is that they can very quickly get expensive both in terms of time to run and computational power required. The question would be if there was an algorith that could be applied that was both powerful enough to provide a meaningful impact on encounter difficulty, yet simple enough to not bog down the system.
After a little more thought, although model creation can be an expensive task--actually utilizing a model that's already been generated is not. So the models themselves could be generated outside the game itself and updated at whatever interval the devs chose. Each spawn loc would then just need to have a model object attached to it for deciding what kind of mob to spit out, and a 'history' object to cache the relevant data from recent encounters for feeding the model. If say, spawn timers were set at 15 minutes, maintaining a history of 8 encounters would allow spawns to gradually adapt over a period of 2 hours. So if the same group stayed in one location, killing the same mobs for that amount of time, the spawns would have fully adjusted to counter their group makeup.
I could see some advantages to having something like this in game, particularly in regions that were designed to be high difficultly. But it probably wouldn't be good to employ something like this everywhere. I can think of some potentially negative unintended consequences:
-- If certain mobs/dispositions are outright more challenging than others, the model is going to end up favoring them regardless of whatever history data is being fed to it.
-- I remember as a ranger hating clerics... they healed, they gated, and rangers didn't have stuns, so I was often forced to waste burns on them to outpace their heals, or else wait for them to run out of mana which could take a long time. A paladin or an enchanter would probably have loved the same mobs as they had low dps and not a lot of hitpoints. The gates and heals could easily be prevented by those classes with their stuns and other interupt abilities. It would probably be pretty annoying if I were hunting alone in some region and suddenly everything's coming up clerics because the model dictating spawns knows that a ranger is killing these mobs and rangers can't fight clerics.
Aradune said:Btw, improving the AI of mobs is not to make them necessarily more difficult. It's actually easy to make mobs more difficult -- give them more HP, have them hit harder, put simplistic AI in like 'always kill the healer first'.
Our goal with better NPC AI is *variety*. Having key mobs with different strategies, behavior, and dispositions. If there is added difficulty it would be that you'll need to learn different strategy and tactics to use on different key mobs.
This sounds very good to me. Not just make the fights hard, which is pretty easy to do, but make them interessting. For the boss encounters I expect a scripted behaviour with a lot of things to keep in mind for the raid. But if even normal "trash" mobs could be interessting, this would be cool. If not all enemies act the same and have a different behaviour than this variety on its own makes the fighting of NPCs interessting. The NPCs should not allways win, but they should suprise us and make our lifes harder, because they are a bit more unpredictable than in most games today.
Aradune said:Too early to go into specifics, but in general Pantheon uses a hybrid data driven/scripting system. Basic AI for most mobs is data driven which means their race, class, sometimes faction, etc. will define their basic behavior. But then specific mobs will go further and have 'dispositions' and other advanced AI, which we will often use a scripting system to implement.
What I want to know is...will there be migration of herds and flocks ..for more "normal" animal behavior (AI) There is a game that does this already, Saga of Ryzom, now called Ryzom. (released in 2004 if I remember right.) And if you were silly enough to attack one of the herd, solo...the whole herd would be on you. :)
New question on this. We just had a long discussion on the VoT (https://www.twitch.tv/pantheon_vot) Episode #4. The issue I am looking at is the perception system. Is it even possible integrating a system like Story Bricks or advanced AI for mobs, questing, and global event’s into the game? I know stand alone processes can be created but how will it impact the perception system? Could it run parallel or in tandum with game applications to support the game dynamics?
I know tons there but with new discussions comes new questions and possibilities.
Ox
What they've talked about and demonstrated isn't particularly challenging to program.
I mean, perception checks? That's been around since D&D has existed. If you can work out the logic of a perception check in D&D, you can write it in C/C#, or whatever other thing you'd care to, provided you know that language.
I mean... NWN1 had it. You could do it yourself. I wrote a trap system that spawned interactable objects only seen by the Rogue to interact with, for a persistent NWN1 world. It worked incredibly well, generated no discernable server load, and worked with up to 100 people in the same dungeon, concurrently. (over 13 years ago) Based on a player entering a volumetric trigger, it did a skill check from that event. If you passed the skillcheck, it sent a "You hear a clicking" or "you are distracted momentarily" privately to the Rogue, which was the clue to maybe do an active search.
If your Rogue did that, they saw the skill check roll for detection. If they passed that, they could interact with the object that was spawned via a detectives kit, and then flag, disarm, and/or atttempt recovery/removal of the trap. Everyone else failed the Perception check and continued on blissfully ignorant.
My point is asynchronous event driven logic is very easy, well known, and there's lots of tools to manage it. A player crosses a threshold or passes through or touches a volumetric trigger, and that's it. From there, it's just a few object calls/checks and you can offer a quest to them in the exact same way as though they were interacting with a quest giving NPC. Sure, that's a simple implementation, but the logic is straightforward. Profiles for AI is also straightforward. It could be, in practice, load this script with these slightly randomized variables, rather than ("path_to_highest_hated_target, attack_highest_hated_target, press 1,2,3, check_for_timed_effect, repeat") which honestly is how simple some AI is, and it's hard as hell to defeat. Slightly dynamic responses are no problem, and neither are things like dynamically adjusting resistances, hit points, or any/all other stats and skills of the NPC's, if they really want to get fancy.
Triggering events that are zone wide, regional, or similar to what was seen in Warhammer Online public quests or the Coldain Ring Quest events has been possible for many many years, and there's no doubt the VR folks are up to the task, having done it many times before.
All of these threads and processes will be server side, and will have the necessary db access, signals, or whatever other interprocess or interthread communication with each other to make it happen. The client will not be involved other than a conduit for keyboard, mouse, and viewport.
Personally? I think the perception system so far is a bit of a gimmick. Now, hear me out... put down that knife.. The only reason I use the term gimmick is because granting quests or tasks "out in the field" has been done in other games before. If that's what the perception system amounts to... meh? I'm hoping, though, it's considerably more. A counterpoint to my skepticism may be "but they showed finding a key!" sure... yet, replace that fallen pillar with an NPC who would have given you a clue that required you to go and find the locked door before returning. Been there, done that.
Now the logic was: Interact with NPC, they say nothing of interest. You find a locked door, then return to the NPC, who now says something of interest, or gives you the key. So, really, the pillar is an NPC, just not a humanoid or whatever other thing you can 'talk' to. That, to me, isn't particularly innovative, but that's just the jaded voice of experience talking. Yes, I'm aware, there are skill or stat checks involved in perception, which amount to faction checks in the past or gear checks, or buff checks. Again, been there, done that.
Hrmm.... cool stuff. I read the article linked to in the OP.... EQNext's AI... Storybrick I think it was? Wow... I must confess, I'm not a programmer. Not even IT. But I'm a smart guy and read a lot. Well... a lot, sometimes lol
Sounds like the AI element of EQNext became it's demise. Or at least part of it. BUT... it also sounds like the publisher - and possibly the community? - were somewhat afraid of what this level of AI would do to the game? I know Dave Geourgeson
"Orcs by the Road" ... COOL! Mobs LEARNING?! Adjusting to US?
Brad... have you guys looked into this? I don't wanna say more than that. I know you guys have a TON on your plates. But... this does sounds VERY COOL.
At the same time... it would make the world VERY TOUGH or could. Actually, I think it would fix the Raid dilemma. NOBODY would ever know WHEN Vulak Aerr was going to spawn. And maybe not even WHERE! LOL
Fascinating read. Wow... this really has my head spinning a little. Imagining the possibilities in a game world I know or might play in. /boggle
VERY COOL stuff! :)
The more I have read into this the more I am hoping the VR team uses the Storybricks algorithms. If the team can do at least a limited version and or incorporate this level of code to perception system? We might be on to something beyond everyone’s expectations. The key is resources to develop and test this sort of thing. It’s a code and implementation. I am a firm believer that if this is introduced it will change the genre and for the better. They have a great game engine platform and the team to do it. We can keep our fingers crossed and hope that VR moves this direction. …. With a serious nudge from an Ox.
Ox