The Mana World Forums

To prevent a monster from fleeing you can use group hunting tactics. If you give it the ability to flee make it likely it can flee from an individual requiring cooperation for effective hunting. In the current version of the game I see little use for it a multiple player RPG, I welcome any challenge that strengthens the need for cooperation.

The only way to feasibly force real player cooperation with our current testing platform is to have monsters so tough even if you have the best gear and are of the highest level and optimal stats distribution, you cannot put down the toughest monster with less than five people.

This is already happening with some of our high level caves, but with swarms of monsters instead of a single tough one.

Rotonen wrote:The only way to feasibly force real player cooperation with our current testing platform is to have monsters so tough even if you have the best gear and are of the highest level and optimal stats distribution, you cannot put down the toughest monster with less than five people.

This is already happening with some of our high level caves, but with swarms of monsters instead of a single tough one.

New skills could also encourage teamplay (example: a monster's shell can only be defeated by elemental magic, and after the shell is broken, he only takes physical damage, a healer would be handy in teams to)

Crush wrote:The new server software already has monsters blocking each others paths and monsters can damage each other but they don't do so intentionally but only when another monster gets in the way.

Oh, btw, can monsters walk trough players, and can players walk trough monsters? They can on the current server.

5t3v3 wrote:Oh, btw, can monsters walk trough players, and can players walk trough monsters? They can on the current server.

No, they can't do so on TMWServ. But to make navigation in towns easier and to avoid griefplay players can walk through other players and through NPCs (but NPCs can't walk through players).

What I was thinking for the family model would be that the server spawns a family (if the mob supports a family) at one time, as opposed to just a single mob spawn. Then the server could track the family via a mob_family_id string in conjunction to a mob_id. The server can determine how each member of the family reacts in accordance to its family_id. Example: When a mob is attacked, the server checks if that mob is part of a family, if it's not then no family style AI is executed. If it is, then family AI is determined to be executed. Like if you attack a child, and the mother is not involved in an attack with someone else, then the mother comes to the aid of the child. If the mother is attacked, and the father isn't involved in an attack the father comes to the aid of the mother. If both the father and mother are defeated, the child may flee the map or may attempt to seek revenge executing attacks that you normally wouldn't see a child execute (like if its a fire breathing dragon, typically a child wouldn't have developed a fire breathing ability but it may be seen in a vengeful child).
Some options that can be added to the Monster_DB are:
- "Can it be part of a family?"
- "Does the family have more than one child?"
- "Does the family have a mother?"
- "Does the family have a father (maybe fathers don't hang out with their families but hunt on other maps)?"
- "Does the family have more than one mother (like a pride of lions, typically one male and several females)?"
- "Does the child flee when the family is defeated?"
etc. etc.

I think all this could be generalized by having "monster parties" where each member of the party has a distinctive role (supporter, attacker, protector, protectee etc.)

This would not only cover families but also bosses with minions, military units of humanoid monsters and so on.

Crush, I was just reading over my post and noticed that the family model is like the minion/master model and was gonna add that then I refreshed the browser window only to see that you added what i was thinking. Yes, instead of monster families, I think there should be more general terms that could relate to both a family as well as the master/minion model. That way we can cover both under one AI system. How about the following classifications, each member can have multiple classifications to generate a wide variation of mobs:
- Weakling (a.k.a. - Child - weak but can become vengeful if the party is felled)
- Supporter (comes to the aid of a weakened mob in the form of healer)
- Attacker (comes to the aid of a weakened mob in the form of an aggressor)
- Protector (comes to the aid of a weakened mob in the form of long-range attacker)
- Protectee (a mob who is protected - like the master of a master/minion model)
etc. etc.

Yes, it needs work but you get the idea.

This can be done using "behaviour types".

But we won't.

Hum, you only answered that I knew nothing about code so I cant tell how to do a program, however I have undergraduate studies in Computer Science and currently in graduate studies, so I really dont get why you just tell that I dont know about the code so my opinion isnt valid, is that what you tell to any idea you cant understand or that you dont like, the current monster code you made me see is composed of "checkboxes" on some properties of behaviour, it doesnt allow complexe behaviour and is probably interpreted by the main AI code which must use some "if" followed by script that would compose a behaviour function proper to a behaviour type.

Separating the main AI code into pieces, is modular and allow to clearly see a monster's behaviour instead to have to read the series of checkboxes (true/false) properties.

You can always create groups within a map and then when creating a monster allocate him to a group, but this would take as much or more cod ethan what I proposed.

Perhaps would you explain to me how you consider doing monster groups and other complexe behaviour?

From privates messages I got it seems people didnt understand at all what I meant.

Yes, with what I wanna do, a n boolean function become 2^n, but you forget to analyse the fact that the extra code is within the main function, which must do 2^n cases anyway.

I mostly meant to use someking of superclass/class to make behaviourial objects, or categorizing objects like FFXII gambit systems, (a priority list of conditions (who/what, with status), with an action to do with that condition.

A light script, we could make premade set of conditions/actions and write a monster whole script with a small list of 3 static variables objects.

So we could make behaviourial classes with superclasses, which would help.

Or simply add a monster type property, with a gambit system using 3 sets of premade conditions.
like 1= self,2 = enemy(player and monsters within this particular monster enemy type list ), 3= ally,
4 = other/neutral/unknown
with 1 status = blind 2 hp < 50% 3 attacking self/ally 4= nearest 5 = weakest def 6 = best attack
and finally actions: 1 attack 2 run from target 3 pick item 4 cast firaga 5 heal target
a monster behaviour could be writen (125)-(244)-null.

Of course those are only basics idea, need to see more code to add this feature properly, and would require to gather informations about nearby other monsters/npc/players, etc.

ok I read the code, and it can be implemented easily
We simply need to map monster specy in a set (behaviourtype) of action priorities.
We calso could set target priority in a different way than hate, if a monster is really slow and short range best for him is targetting closest target. Change stuff like allowing monsters to attack each other depending specy, raising deads. And finally the need for monsters to watch for nearby monsters event (healers).

Hmmm ok here is a new progress
In the code where the monster range property is determined from its specy, we can add a behaviour creation and a sight creation, the behaviour return an initial action to do.

The sight make the monster detect events in the area determined by his position and sight, we'll need monsters move in their sight events too.

the behaviour will consist of lists, one of nearby enemies, one of nearby allies, one of nearby other objects, one of actionManaging.

When an event happens, monster will call a modification function of his behaviour, that will return him which action he should do.

Then the monster ai take the returned action and change its current action for this one.

the behaviour actionmanaginglist is a list (or datastructure) of actions to do depending of current states and events it receive, a monster state is his pointer in this list/datastructure.

In fact we could, ultimately, make actionManagement objects/scripts already made for all monsters, and managing them from monster.cpp, which can contain every possible actions that all monsters can do, but would only pick the restricted actionManaging action-target.