Sounds like it might produce something that isn''t a steaming pile.

MONSTERS ARE PEOPLE TOO

"How many goblins can a warrior slaughter before they finally get a clue?"

Many... As long as they have a motive to attack the warrior.
This motive could be their leader, ordering them to attack. It could be rage (maybe the warrior killed their wives). Or they''re cornered. Or maybe they''re protecting their hoard of gold. But, on a random encounter in the wild, they''re certainly bound to run instead of fight...

"Creatures personal objectives are denied. NPCs and mosnters are just scenery. It would be nice to see an NPC go on a quest once in a while."

Yup. That one ties in with the previous comment. Monsters SHOULD have goals (motives, objectives, however you want to call it).

I think that it''s mostly a matter of scope. How far ahead of the player should the program process NPCs objectives and behaviour?

In a world with about 12 players, Tom mentions using Wavinator''s technique (only updating NPCs near the players). I think that''s the right way to think. The smaller the number of NPCs that have to be updated, the less computer power required.

Myself, I''m thinking up a system that is very similar to this, but at the same time completely different.

I''m trying to create a system where the ''worlds'' are small dungeons. Each dungeon only has a limited number of NPCs in it (there can pretty much be as many PCs as desired, since those are controlled by the players themselves). It''s somewhat the same principle: if the number of NPCs that need a behaviour update is small, the behaviour can be much more complicated than current NPC AI behaviour.

Give NPCs a duty to perform.
Give them a goal, a reason for their actions.
Give them a logical behaviour pattern.
Give them lots of different response possibilities.

Player walks along a river. He desperately wants to get to the other side. Finally, he sees a bridge in the distance. He runs, glad to finally have found a solution to his problem. Getting closer to the bridge, he spots a huge Troll in the middle of the bridge.

Troll duty: guard bridge
Goal: prevent anyone from crossing bridge
Reason: if I let anyone through, evil spellcaster will kill me
Behaviour pattern: if anyone gets onto bridge, attack and kill
Different response possibilities: if they don''t actually get on the bridge, just sit and wait. If they start to talk, remain silent. If they swim across the river, remain seated. The spellcaster didn''t say nothing about not letting anyone swim across. If they attack, kill them. If they run away, don''t pursue. Just stay on the bridge. If they seem like a bigger threath than the evil spellcaster... just let them pass. If they give me something I want (item X?) and promise to not let the evil spellcaster notice that they passed, I''ll let them cross. If they kill the evil spellcaster, I''ll leave the bridge and go home.

Designing a behaviour pattern for each of the NPCs would be a little hard... but worthwhile.

Tom, one way to try your system might be to try it on a very small scale first. Just create a simple small dungeon with maybe 10 NPCs in it. Give each of them specific orders and a varied behaviour pattern. Then let your PCs enter the dungeon and see what happens (hopefully, the NPCs will react in logical ways).

Example:

Dungeon housed by goblins. Goblins are hoarding their treasure.
Goblin 1 and 2: stand guard at entrance.
Goblin 3 and 4: stand guard a little deeper into the dungeon, within hearing range of guard 1 and 2.
Goblin 5 and 6: sleeping
Goblin 7 and 8: playing a game of dice
Goblin 9: patrolling dungeon.
Goblin 10: leader of the group. Sitting in a chair watching ''his'' treasure.
Each goblin could have his own set of behaviour patterns.
Goblin 1 might be a very alert guard. At the slightest hint of danger, he will tell goblin 2, shout to goblin 3 and 4 and draw his weapons. If they''re attacked he''ll fight to the death.
Goblin 2 might be a lazy bum. Falling asleep on his spear. When goblin 1 makes him pay attention, he''s annoyed and will only pay attention for a short while. If they''re attacked, he''ll quickly run back into the dungeon.
Goblin 3 and goblin 4 might be sleeping... playing dice... even though they''re on guard duty. They might or might not react to goblin 1''s shout for attention. ''He''s seeing things again'' they might think, having heard goblin 1 yell false alarm many times before. Or they might trust his word and come back him up at the slightest clue of danger.
Each goblin would have it''s own ''if-->then'' pattern.
Each goblin would be have a personality. No two goblins would be alike (well, some would, but there should be enough diversity to create each goblin a little bit different).

If the number of NPCs stays low, you can create very elaborate patterns of behaviour without requiring a lot of processing power (right?).







Woohoo... I''m on day 7 on my C++ in 21 days course. %Another two weeks and I''ll be a master programmer!%

That sounds like a very complex way to generate an encounter that most players will see as "kill ten goblins, watch them yell and scurry about, get treasure."

TOOKH:

It does. But those goblins could also be 15 highly trained human warriors, backed by 2 very powerful spellcasters.

And if the players arriving at the dungeon only see two goblins outside, they don't know what's inside yet. For all they know, 100's of goblins could come streaming out of the entrance at the call of the guards.

It's not so much about the actual encounter as it is about setting up the system that will allow programmers to create realistic AI behaviour on a grand scale (MMORPG).

Woohoo... I'm on day 7 on my C++ in 21 days course. %Another two weeks and I'll be a master programmer!%

Edited by - Silvermyst on August 5, 2001 9:14:20 PM

quote: Original post by Silvermyst
Monsters SHOULD have goals (motives, objectives, however you want to call it).

"Should" is a strong word. Sounds like dogma to me. Can you justify it?

quote: Troll duty: guard bridge
Goal: prevent anyone from crossing bridge
Reason: if I let anyone through, evil spellcaster will kill me
Behaviour pattern: if anyone gets onto bridge, attack and kill
Different response possibilities: if they don''t actually get on the bridge, just sit and wait. If they start to talk, remain silent. If they swim across the river, remain seated. The spellcaster didn''t say nothing about not letting anyone swim across. If they attack, kill them. If they run away, don''t pursue. Just stay on the bridge. If they seem like a bigger threath than the evil spellcaster... just let them pass. If they give me something I want (item X?) and promise to not let the evil spellcaster notice that they passed, I''ll let them cross. If they kill the evil spellcaster, I''ll leave the bridge and go home.

But you''re undermining your own point here. All the ''interesting'' parts of the above can be implemented while totally ignoring the ''goal'' and ''reason'' attributes that form the basis of the discussion. It can all come down to a simple set of scripted responses. The ''goal'' and ''reason'' can be reduced to concepts that the designer bears in mind when they write the script. What you''re really getting at, is that you want the ''response possibilities'' to be automatically generated by some form of intelligence. But until you can formulate a way of doing that, it''s just speculation and "what if" material. In the meantime, all the stuff you mentioned can be done by a designer with an hour or two to spare and a decent scripting system.

quote: Woohoo... I''m on day 7 on my C++ in 21 days course. %Another two weeks and I''ll be a master programmer!%

I''m sure it''s taking you a bit longer than it should...

Silvermyst''s example of smart creatures might be a bit overdone, but you''ve got some good points. It also made me think about another thing that I neglected entirely before this point, and that''s hierarchical intelligence.

Not every creature in the game needs goals and strategies. A dog meandering about the alleys looking for scraps of food has one simple-minded goal that does not really need to be fleshed out. Kylotan makes a good point by suggesting that creatures should react rather than act. But this simply isn''t going to be enough for all creatures.

NPC''s are not going to be the only factor driving the game, because that''s what players are for. However, I''ve already explained that NPC''s must act as antagonists to the players, or at least to each other, so players can pick sides and intervene, therefore gaining a sense of accomplishment when they see their actions taking shape in the game world. This requires a lot more planning than we''ve discussed to this point.

Hierarchial Behavior
Let''s look at Silvermyst''s goblins for a moment. These goblins have a leader, who is undoubtedly responsible for giving them orders. This kind of intellectual system revolves around one parent agent (goblin leader) and any number of child agents (goblin warriors). You can have as many levels to this system as you like. Basically, each agent acquires its "goal" from the agent above it, and its actions comply to that goal.

I started working on a system like this for a strategy game. Since we''re dealing with a fantasy world full of kings and queens and knights and peasants, using this type of hierarchical system makes sense. In many cases (since many NPC''s will be lone adventurers), a hierarchy is unnecessary, and goals can be set on a per-case basis.

I''ll have to keep this in mind for the future.

Setting Up A Chain Reaction
We''re talking about a world that is driven by conflict. If things are going to take off as soon as the first player sets foot in the game world, there must be some conflicts already in place. It''s my job to make sure that happens, but this falls directly into our discussion of how NPC''s should react to conflict.

The game starts off as a line of dominos. When you knock over the first one, the rest fall into place as planned. Players are the hands that move your dominos around, introducing chaos into the system. Ideally, the system will adapt and balance itself out, creating a regular but unpredictable storyline. Once you set things off, they''ll keep moving no matter what, but you might not know where they''ll be in a month.

What kind of safety mechanisms could I introduce into this system to make sure players don''t fling my dominos all over the room and crash the story altogether?

sunandshadow: You have an interesting approach, but I don''t think it fits my project. However, your approach to AI is useful. Agents must understand the world and everything in it if they''re going to act upon it.

KYLOTAN:

Monsters SHOULD have goals... because otherwise they become just a virtual representation of numbers and branches of code.

"What you're really getting at, is that you want the 'response possibilities' to be automatically generated by some form of intelligence. But until you can formulate a way of doing that, it's just speculation and "what if" material. In the meantime, all the stuff you mentioned can be done by a designer with an hour or two to spare and a decent scripting system."

True. But I think that you first need the 'what if' material before you can start to really form goals and objectives for AI. And the 'decent' scripting system should be completely revamped and become a tremendous scripting system. At that point you can start to give AI a greater goal (I think).

I think it might be best to start designing the 'goal' system for unintelligent creatures. That bear roaming in the dungeon. What are its motivations? Why does it do things? When it wakes up, why does it decide to do one action not the other? What actions does it end up doing?

After that I'd start with the low-intelligent creatures (simple goblins). Once you've got them going, go on to average-intelligent creatures (chieftain of goblins). After that, high-intelligent creatures (humans etc). Once you perfected those you might go to very high-intelligent creatures (spellcasters, brilliant minds etc). And after that you could go to supernaturally intelligent creatures (gods etc). The higher up the scale of intelligence, the more complicated the design will become. For the bear it should be pretty simple to set up a logical behaviour pattern (need food-->go hunt. need sleep-->go to nest. need to protect offspring-->patrol perimeter). For the gods the 'logical' behaviour pattern would be almost impossible to code.

And yes, that 21 days course of C++ is taking me MUCH longer than it should. With about an hour to spare each day it seems days turn into weeks pretty quickly. Add to that the fact that my mind doesn't seem to want to accept information to quickly anymore... bah, I hate having to write myself summaries of what I've just learned, but it seems to work. I finally know what I'm doing... the little bit that I can do

Edited by - Silvermyst on August 6, 2001 9:58:07 AM

quote: Original post by Silvermyst
KYLOTAN:

Monsters SHOULD have goals... because otherwise they become just a virtual representation of numbers and branches of code.

But Silvermyst... monsters ARE just a virtual representation of numbers and branches of code. And giving them goals just means you have a load of numbers and branches of code representing goals as well as the creatures themselves. At this stage it seems more like you're arguing philosophy than any compelling gameplay aspect. If you want to argue for the Rights of bits and bytes then I won't reply. But if you can put into gameplay terms why it will help, and how it is possible to implement, then I'll talk.

Monsters using your CPU time to do things to each other that don't affect the player are generally a waste of programmer effort. There are exceptions, in the world of simulation, but when you have a choice of making a world full of barely intelligent creatures, or a world full of creatures that make a good pretense at being intelligent, I'd choose the latter.

It's all about getting your priorities right. With an equal amount of effort, you can get a few NPCs simulating political machinations or intelligent combat choices through scripting, or you can construct a needs-based system that just about allows some animals to manage to feed themselves on occasion. Wow.

Check out "Maslow's Hierarchy of Needs" sometime. It's based on classic studies of motivation. You'll find it online if you search for it. With scripting, we can quickly and easily simulate the upper levels, resulting in an immersive world. With complex goals/needs based systems that you describe, we can just about manage the bottom one and a half categories. It's nowhere near enough.

Remember, people are playing a computer game. They can suspend their disbelief. They are more likely to accept a near-intelligent being that does some 'computer-like' things on occasion, than a world populated with beings on a similar level to ants and showing no pretense of being of human-level intelligence.

quote: True. But I think that you first need the 'what if' material before you can start to really form goals and objectives for AI. And the 'decent' scripting system should be completely revamped and become a tremendous scripting system. At that point you can start to give AI a greater goal (I think).

This is all very vague. This is why it doesn't get done. Everyone stops at the 'goal' notion and doesn't seem to appreciate just how little information there is. What is a 'goal'? How do you define it? (In numbers, or branches of code?) How does a creature know what subgoals go to make up a larger goal? Until you can address that, the idea is worthless, as it has been thrown around on this forum and elsewhere for eternity, with no-one getting closer.

I guess I'm just getting tired of seeing someone say "modern games are not good enough because the NPCs don't have massively advanced intelligence. So I want to give them goals." Does anyone get anywhere with this? No. Because nobody quite realises just how near to impossible this can be. They don't appreciate the complexity of 'intelligence'. Even psychologists don't know how the mind works. So expecting computer programmers to simulate it effectively is asking a hell of a lot. People talk big but can't deliver.

quote: I think it might be best to start designing the 'goal' system for unintelligent creatures. That bear roaming in the dungeon. What are its motivations? Why does it do things? When it wakes up, why does it decide to do one action not the other? What actions does it end up doing?

When you have answers to these questions, and can express them in a data-driven way (which is necessary... as the only alternative to data-driven is code-driven... which is scripting, like I suggested) then you can perhaps start your system.

Right now, intelligence is too poorly understood to think you can represent it effectively in a game. I'd say that it would be best to leave that to the academics who don't have to worry about gameplay. And make the gameplay better with approximations in the meantime.

Edited by - Kylotan on August 7, 2001 3:52:40 AM

Great post Kylotan, I completely agree.

KYLOTAN:

I agree with TOOKH... Great post

But here''s some to keep the discussion going:

"Monsters using your CPU time to do things to each other that don''t affect the player are generally a waste of programmer effort."

I fully agree. I don''t see a reason for having NPCs live their own world. But, in a smaller environment (say in an area of half a mile around the player) it might.

Say we stick with the simple dungeon idea. The fact that each goblin has an interaction with one another might not be important to the PC that''s still waiting outside in the forest, but it will to the thief who''s managed to sneak by the first two guards. He''ll be able to determine what each goblin does, what their behaviour is. And based on that the players can then establish a game plan.

That is why I want my NPCs to have a more complicated behaviour pattern: to give players a chance to design more complicated action plans.

(But, as you said, outside of the player''s immediate vicinity, NPC behaviour doesn''t really matter. UNLESS you create a virtual world where thousands of players walk around, because then, each NPC would likely be close to a PC at any one time, so each NPC would have to have a logical behaviour at any one time.)

How would I implement this? Again, by making ''small'' a design focus. If I design a dungeon (or any other location) with only a few NPCs, I''ll be able to use a lot of processing power to give each of the NPCs a large set of instructions.
You''re right, the NPCs will FOREVER just be branches of code, but I think we can use more branches per NPC to make the code itself more intriguing and give it more options agains the wits of a player. A ''smarter'' NPC will give more of a challenge to players. ''Smarter'' just means more options, more branches.

"It''s all about getting your priorities right. With an equal amount of effort, you can get a few NPCs simulating political machinations or intelligent combat choices through scripting, or you can construct a needs-based system that just about allows some animals to manage to feed themselves on occasion. Wow."

Again, good point. I''d much rather have a player face an exciting combat sequence than having his opponent die after the first whack, because he''s exhausted from having had to stay up at night to nurture his crying baby... something the player is not aware of, of course.

Again though, I think that if we start small, we can have it all. Or is the needs-based system just too complicated no matter how small the number of NPCs is?


"This is all very vague. This is why it doesn''t get done. Everyone stops at the ''goal'' notion and doesn''t seem to appreciate just how little information there is. What is a ''goal''? How do you define it? (In numbers, or branches of code?) How does a creature know what subgoals go to make up a larger goal? Until you can address that, the idea is worthless, as it has been thrown around on this forum and elsewhere for eternity, with no-one getting closer."

Small. That''ll be my focus until the day I die. If I keep my design small, I don''t even need sub-goals. What is a goal? I think it would be the default action an NPC performs. ''Stand at location X.'' IF statements (in my limited knowledge that''s all I can come up with) would further define the goal. ''IF a PC is spotted, ring an alarm.'' This would make the NPCs main goal ''stand at location X, look for PC and if you spot one, ring the alarm''. This would make this NPC a guard.
To make this goal it''s very main movitation, would require you to design ANY possible outcome resulting in the NPC going to ring the bell.
''IF attacked, defend but back off towards bell. Ring bell.''
Please, don''t hesitate to point out the stupidity of these words, because I''ll be the first to admit that I don''t know anything yet about programming.

Maybe ''goal'' should just be reworded as ''driving motivation'' or something else, something that would make it easier to see it in coding terms.

Code:
Do action A
When possibility 1 happens, do action B
When possibility 2 happens, do action B
When possibility 3 happens, do action B
When possibility 4 happens, do action B

Action B would be the goal.

I''ll keep thinking of all this WHILE I''m learning programming (If only I could think up a system that would give me more hours per day) then maybe one day I''ll yell ''EUREKA''!

For now, I''ll have to accept my peer''s (of which I guess KYLOTAN is one) words and just accept that it''s probably a lot more complicated than I''d hoped.