• ### Announcements

#### Archived

This topic is now archived and is closed to further replies.

# MORPG - Realizing the Holy Grail

## Recommended Posts

Tom    352

##### Share on other sites
Kylotan    9860
Limited Player-base - definitely a bonus. How are you achieving/enforcing this?

Next point: "Beta-testing will ensure that things fall into place once the engine and world are complete, and I'm sure administrative "tweaks" will be required throughout the game's life cycle to keep it running smoothly."

Remember that if you leave it until testing to get things right, it's going to take you longer than if you design them right in the first place. Think through all the potential design and gameplay issues and try to make your system such that it avoids them, rather than assuming you'll be able to balance everything at the end.

"Modifying the world through mysticism is a perfectly acceptable means of balancing the game, even after players have already entered the world. This doesn't mean everyone will like whatever changes you make, but they will accept it nonetheless, even if the excuse is, "it's just a game."

No, they say "the admins here SUCK!" and leave for a game where the administration staff don't interfere. Perhaps you'll get some leeway on this because you know the players personally, but that depends on their patience with you. Players don't like having the world manipulated around them. Players generally like to know that what they do has an effect. The more things you do regardless of them, or do to reduce their power, the less influence they will believe they have and therefore less fun.

"However, the greatest tool a fantasy writer can use is realism. It's realistic for creatures to migrate to another area if they are being mercilessly slaughtered by rampant killers."

Yes, and it also annoys players. Are you going for realism or fun here? If creature migrate away, will players have to eventually roam further and further from home? Will this be practical... will this be fun?

"It's realistic for the authorities to confiscate equipment from a player because he is simply too powerful (although some of the authorities might be wasted in the process)."

Now this would Really cause an outbreak of "the admins SUCK!" Assuming you are having the administration arbitrarily decide what is unbalanced. After all, if you could computationally decide what is unbalanced, why not just refrain from introducing unbalanced entities into the game in the first place? As before, maybe you have a select group of players who don't mind you effectively undoing their hard work. But most players don't appreciate this one bit.

"It's realistic for a jealous NPC to attack a powerful player-character who threatens his status."

That's different, because the players consider this 'part of the game'. It's not a human making arbitrary decisions to make their life harder... it's the game giving them increased automated challenges.

"These are all ways to balance a flexible game system."

On the contrary, I believe some of them are ways to try and fix up a broken system. Balance is not a case of trial and error, it is a case of pre-planning, setting limits and constraints, checking statistics and probabilities, and so on.

(Note: I'm not just speaking from opinion here. I run a multi-user game with a small user-base myself )

Edited by - Kylotan on August 3, 2001 9:03:55 AM

##### Share on other sites
I''m curious, what is the point of having such a small user-base? If the number is small enough that a player has a good chance of being the only player online, doesn''t that defeat the purpose of it being multiplayer? e.g. suddenly there isn''t any socialization

Anyway, for the dynamic world part you may want to go with a story generator. I can''t remember whether you were at the RPGs of the 21st century messageboard where you would have seen my design, but if you weren''t, and you''re interested in the idea, I can provide you with my flowchart and example pieces. There isn''t any code, just design specs.

##### Share on other sites
Tom    352
Kylotan:
Good points. I thought about these after reading the lines you quoted from my original post. The point of the making the world autonomous is so I don''t have to use the Hand of God to change things. That''s where balance is critical, and pre-planning as you''ve said is the most important step to achieveing that.

Migrating creatures would be part of the fun, and it''s also a balancing factor to prevent them from being utterly wiped out by a single party of power gamers. Following prey across the land is just another part of the strategy involved in gaining combat skill. This also fits into the political system, which I''ll explain in a moment.

How do I plan to enforce a limited player-base, that''s a good question. So far, the only people who know about this project (short of everyone at GameDev now) are my friends, whom I''ve known for many years and trust implicitly. Of course, like all players they have their own idiosyncracies that will require my attention (one likes to crunch levels and pretty much nothing else, while another loves to cause trouble with NPC''s).

There is no possibility of me opening this project to the public ever. I simply don''t have the computing power to handle a large player-base.

I hope your question has already been answered. It''s not likely that anyone would stay online unless someone else were already there. We would schedule times and places to meet and go adventuring together, most likely as a group but perhaps not, depending on the characters we decide to play. If somebody wants to log on and crunch levels, so be it.

I think I''ve seen your story generator notes, but I don''t remember. I''d like to. I prefer specs over code.

Here, I''m basically talking about inter-culture relationships. Players will have the largest impact on this. Running into a village and lighting up the civilians is going to make your hometown look very bad in that village''s eyes. It works both ways: rescuing a village from marauding demons will boost your personal reputation.

This system needs to be refined. A character''s actions would only affect his hometown if everyone knew where he lived, which translates to a high reputation. For adventuring types, this probably won''t apply since most of them move around quite a bit. Reputation in this case is a personal factor.

Any adjustments in reputation should gradually flow into other regions, rather than instantly change like they do in EverQuest. If you massacre a small village, people 500 miles away should hear about it in couple weeks, which might give you enough time to get there and cross the border before they find out, if you''re quick about it. Even then, the influence will be far less as the news filters into outlying regions. People 5,000 miles away really couldn''t care less; they probably never even heard of that village.

Migrating fits into politics in two ways. First, it''s a means for nomadic races to locate new feeding grounds. Second, conquering and occupying another city is a subtle form of migration (although we''d be more accurate to call it expansion). Since politics determines wars, this is where migration comes into play.

Goals of the Game
Of course, I''m mostly discussing things that involve killing, which is not something the game should be based upon. Being an explorer myself, my ultimate objective is to create a fascinating world that will appeal to other explorers. It''s probably beyond my capability to make a system that will surprise even me (although it has been done; Creatures 2 anyone?), but new players will be seeing everything for the first time.

Ideally, I want a world that appeals to all gamers in some respect, but primarily I''m concerned with the anticipated user base. I''ve had few opportunities to discuss this with my friends, despite the fact that this project has been ongoing for over two years. I made it a point to schedule a meeting this Sunday so we can mull things over.

Non-player Combat
With NPC''s walking around doing things, they are bound to get into trouble sooner or later, and that trouble is likely to involve killing something. Combat can occur on a wide number of scales, from the individual to the entire nation. The largest level want to analyze is city-scale.

All combat bodies are singular entities. In battle, a city is the same as a person, except it has more attributes. When two cities battle one another, many factors are taken into account: fortification, population, average level of skill, quality of weapons and armor, location, number and type of magic-wielders.

Most battles in the game world will occur away from players. It will not be unusual for a player to stumble into the wake of a battle that they had nothing to do with. Indeed, this will provoke a lot of questions on the player''s side, and they may be interested in finding out exactly what happened. The game must cater to this kind of "triggered quest."

Objective Redefined
The goal in this project is to create a world that players can influence, but more importantly it is to create a world that players can explore indefinitely and continue to find new things. While most people probably won''t be all that interested in politics, they will be especially interested in the wars that break out because of them, and the land that changes hands.

I''m refining the background for this world right now. In the meantime I''d like to hear more input from everyone.

##### Share on other sites
Kylotan    9860
quote:
Original post by Tom
The point of the making the world autonomous is so I don''t have to use the Hand of God to change things. That''s where balance is critical, and pre-planning as you''ve said is the most important step to achieveing that.

Right, but if you have an automated hand of god that appears to be as arbitrary as a human one, then although you gain on administration costs and the lack of ''personal vendetta'' rumours, you still annoy players who come across what they perceive to be unfair boundaries. eg. If the game doesn''t want you to have more than (for example) 400 armour points, why make individual pieces of armour that give 100 points each? Prevention is better than cure.

quote:
Migrating creatures would be part of the fun, and it''s also a balancing factor to prevent them from being utterly wiped out by a single party of power gamers. Following prey across the land is just another part of the strategy involved in gaining combat skill.

Did you know that Ultima Online had this kind of thing to begin with? It was taken out because (a) it was no fun for anyone except the developers, and (b) it consumed CPU cycles doing interesting things that nobody got to see.

I don''t want to speculate on the other issues because it doesn''t appear that you are 100% clear on what you want the game to be about. Or, perhaps more accurately, you are trying to do ''everything'' in one game, combat, politics, exploration, etc. It''s hard to comment on how to do something when that aspect alone is not the main focus of the game. Most of those elements compete against each other, that''s the problem. The only reason most big games try to do all those things, is to get more subscribers. With a small user base, I''d be more inclined to specialise in one style of play.

Btw, something I missed from the first post: "creatures are denied personal objectives" because they didn''t buy the game: the player did Programmers who spend time making NPCs more realistic without making sure these changes have a positive impact on PCs - like the Ultima Online programmers did - are ultimately programmers who waste their time.

##### Share on other sites
Tom    352
quote:
Kylotan said:
Or, perhaps more accurately, you are trying to do ''everything'' in one game, combat, politics, exploration, etc. It''s hard to comment on how to do something when that aspect alone is not the main focus of the game. Most of those elements compete against each other, that''s the problem. The only reason most big games try to do all those things, is to get more subscribers. With a small user base, I''d be more inclined to specialise in one style of play.

That''s an extremely good point. I''m glad you brought that to my attention. My means to achieving all my goals is to take baby steps, rather than attempt to cram everyone into one big mess of an engine during the first month of programming, and then pretend I can weed out all the bugs later. We all know that''s the absolute wrong way to program. Doing one thing at a time, and making them modular so it doesn''t destroy the engine if something does break, is the best way to do it.

Anyway, I''m saying that it probably won''t be necessary to do all this. I can pick and choose which features are most important to the engine, implement those, and find out during alpha-testing if anymore features are really necessary. For example, you keep making points against migration, so it would be wise to see if I should even waste my time with it. I think it would be good enough to have village wars and forego migration altogether.

quote:
Kylotan also said:
Btw, something I missed from the first post: "creatures are denied personal objectives" because they didn''t buy the game: the player did Programmers who spend time making NPCs more realistic without making sure these changes have a positive impact on PCs - like the Ultima Online programmers did - are ultimately programmers who waste their time.

I pretty much came up with this philosophy, and obviously so did you. I used to go around telling designers, "Combat doesn''t have to be fair for the monsters, because the monsters aren''t paying you to play." But I don''t think anyone ever listened to me. We designers tend to be close-minded folk.

And you make a good point. But I would also fire an argument at you saying, with such an extraordinarily small player base (which we agree is good in many ways), there has to be something to provide a challenge, and other players aren''t going to be enough. So, NPC''s must think for themselves and establish goals that will, in all likelihood, contradict those of the players.

I really wish Wavinator would jump in and start spewing out ideas on how to make goal-oriented NPC''s. He and Naz always have something good to say. I did read their posts on macro dialogue, and I think it''s a really fantastic idea for this type of game, especially with such a small number of players. (This means NPC''s won''t have to remember very much.) If anybody has ideas on this, do share.

##### Share on other sites
TookH    122
quote:
Original post by Tom
I''m also frustrated when creatures are denied personal objectives. NPC''s and monsters have always existed as protagonists and antagonists in what is basically the player''s story. Most of the time, they''re just scenery. It would be nice if an NPC would go on a quest once in a while. With my limited player base, this is going to be doubly important.

Although it was entirely scripted, the old SNES RPGs frequently had an "explorer" character that the player would run into from time to time. Mario RPG had that mushroom guy who was always sleeping at inns, Secret of Mana had Watts and Neko, the blacksmith and shopkeeper, ChronoTrigger had that... uhm... guy... forgot his name... and so on. Often these characters would be important to the plot at some point or lead the player to a secret area. They were always one of my favorite parts of the game.

...So what I''m saying is, if someone can get a good NPC quest engine going, then I want to see it.

##### Share on other sites
Kylotan    9860
quote:
Original post by Tom
Anyway, I''m saying that it probably won''t be necessary to do all this. I can pick and choose which features are most important to the engine, implement those, and find out during alpha-testing if anymore features are really necessary. For example, you keep making points against migration, so it would be wise to see if I should even waste my time with it. I think it would be good enough to have village wars and forego migration altogether.

Creature migration often seems to be something that is done because "it adds realism" or "makes the creatures more believable". However, so far, nobody has managed to make the game significantly more fun by doing it. Certainly not to the extent that would justify the effort spent on it.

If you have a clear view of how it would add to the gameplay, then go for it. (Or if you don''t care about gameplay and just want to make a simulation, go for it: but this would probably be the wrong board for that.) But this is one of those ''tried before'' concepts that either needs a fresh approach or to be steered clear of.

quote:
But I would also fire an argument at you saying, with such an extraordinarily small player base (which we agree is good in many ways), there has to be something to provide a challenge, and other players aren''t going to be enough. So, NPC''s must think for themselves and establish goals that will, in all likelihood, contradict those of the players.

Do they need to come up with pseudo-intelligent actions, or do they just need to provide pseudo-intelligent reactions to player actions?

To pervert a famous saying: "If an NPC woodcutter chops down a tree in the middle of the woods when there is no PC there to see it, does anyone care?"

My approach on my current project is to make NPCs pretty dumb for the most part, but attempt to be intelligent when it comes to reacting with PCs. The major part of this is the combat, but hopefully I can make trade interesting, too. I am ignoring politics

##### Share on other sites
Silent Error    122
Only thing I can think to say to Tom after reading this thread is it''s easier to try than to prove it can''t be done. Give it a shot. Since this doesn''t sound like it''ll be a commercial product, I''d implement the features that interested me instead of focusing solely on making it appeal to a large audience. I''ve often learned more that way. Besides, if you find it doesn''t work out, maybe someday it will. You''d have a jump on the competition if commercial companies started using some of these ideas since you would have already implemented them. But alas, I''m no commercial programmer so such things really don''t matter to me. I write stuff for my own amusement and on occasion hand it over to my friends if they want to give it a stab. That''s about all I can say. Hopefully at least somewhat helpful to you.

##### Share on other sites
My story-generating process is like this:

There are a number of mythical/metaphorical themes stored in a database. Ferex, one of these was "The Icarus Myth" This was a bunch of nouns (Icarus, pegasus, feather, pen, sun, moth, flame, hybris) and some associated adjectives (driven, mesmerised, suicidal, glorious, poetic, fatale) Each was tagged as to its relation with the other words. Some tags were: synonym, antonym, metaphor, agent, goal. At the beginning of the story-generating process the generator used modified random choice to choose one of these themes. One agent was assigned to the player and the rest were assigned to AIs.

Next a world file was also chosen from the database. Ferex the Undersea file contained room descriptions (coral reef, sunken ship, island, underwater cave) agent descriptions (fish, shark, seahorse, mermaid, octapus) and object descriptions (seashell, driftwood, artefact, weapon, plant) and each of these was associated with an image and some information as to which of them should go together or be assigned which roles. Object roles included container, key, barrier, tool, treasure. Then a madlibs style sentence and paragraph constructor with a bias toward paralellisms and other poetic devices used all this info to tell the player about the world and his/her goal.

I have a flowchart, but it's on a different computer I can't get access to for a few days.

Oh, I should explain that AIs had drive variables (like hunger, sleepiness, boredom) ala the system used in Creatures 3, and modifiers for personality (ferex tendency to commit a crime) and we intended to implement the AIs using the pridicate calculus language SOAR, on which bishop_pass is the resident expert. The SOAR implementation would allow the AI to "understand" all the objects in the game and use them to attain their goals.

Edited by - sunandshadow on August 5, 2001 11:06:12 AM

##### Share on other sites
TookH    122
Sounds like it might produce something that isn''t a steaming pile.

##### Share on other sites
Silvermyst    113
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!%

##### Share on other sites
TookH    122
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."

##### Share on other sites
Silvermyst    113
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

##### Share on other sites
Kylotan    9860
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...

##### Share on other sites
Tom    352
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.

##### Share on other sites
Silvermyst    113
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

##### Share on other sites
Kylotan    9860
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

##### Share on other sites
TookH    122
Great post Kylotan, I completely agree.

##### Share on other sites
Silvermyst    113
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.

##### Share on other sites
Tom    352
Silvermyst:
What you''re talking about is called a finite state machine (FSM). Even the most well-developed AI generally breaks down to this system, because it''s tried-and-true. I''ve seen a few examples of neural networks in action, but they''re always very specialized, which makes them stupid in every other area. FSM''s and FuSM''s (fuzzy state machines) are the most reliable AI tools to date.

Kylotan has mentioned scripting so many times that you''d think he married it. I''m all for scripting, and I don''t think any exceptional game can exist without it. But this doesn''t mean you should script every single character in an autonomous world. Some of them for sure, but not all of them.

Let''s analyze this problem from another angle...

Power by Perspective

Let''s divide our NPC''s into three fairly distince categories:

First, we have static NPC''s. These are the people who are pretty much in charge of global affairs at every conceiveable level. To put it more simply, their positions are static. These guys don''t wander into the woods to adventure. This is the type of NPC you''d want to script.

Next, we have dynamic NPC''s. These are the computer-controlled adventurers who wander the world looking for wealth/fame/knowledge/whatever. They are basically player-characters that are not controlled by players. These are the NPC''s who follow their own set of roughly-defined goals. A goal can be general (acquire wealth) or specific (avenge father''s death), and the strategies required to fulfill these goals will be dynamically altered as the world-state changes.

Finally, we have the blurry margin in between, which I will call non-static NPC''s (not quite static, not even close to dynamic). These guys are the random encounters of the world, extras in the background that get paid 1/100,000th as much as the regular actors. They might have some simple scripts that define their general activities (wake up, eat, farm, eat, farm some more, eat, go to bed), but more likely they''ll be driven by a simple FSM (if spot enemy, kill it).

Kylotan:
Goals are defined on several levels. The goal of a rat might be to escape the maze. This is very straight-forward and easy to achieve (given enough time and patience); all the rat has to do is wander around until he finds the exit. Ideally, he will remember which paths he''s already chosen so he doesn''t spend infinity running down the same two tunnels. That''s part of the AI, and I won''t discuss it here.

Let''s take a complex creature, like a knight. Let''s say our knight has one ultimate goal: to protect his kingdom. This is a very noble thing, even for a knight, because most knights were mercenaries who fought for a paycheck. Anyway, this goal breaks down into many sub-goals: destroy enemies of the kingdom, destroy criminals, destroy those who do not pay tax, stay alive so you can continue destroying things.

A very simple example, but viable nonetheless. The goal-state of any character is going to fluctuate based on the world-state (by which I mean "what''s happening around the character"), and this can be converted to a finite state machine that is unique to each character. You could code this yourself using your own scripting language, and I believe it would work extremely well, so well in fact that I''m surprised nobody has done it for a single player game.

Now that I think about it, this system might be best tested in a single player environment. Something for me to consider before I get back to work.

##### Share on other sites
Kylotan    9860
Big reply time *exercises typing fingers*

I'll just try to address everybody's points here in one big chunk.

TookH: the check is in the post

Silvermyst...

"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."

Fair enough, and we can draw an implied rule from this: "Don't model behaviour that can't (a) be seen by the players, or (b) won't affect the player's game plan." Initially, this might not seem to rule much out at all. But in the case you gave with the goblins, is the player really going to notice their behaviour? More likely he is just going to hack through them in the order that they present themselves to him. So now you have a dilemma: make the goblins more simple, since they are gonna get wasted anyway (aka the Diablo approach), or make them more intelligent so that you really have to plan your attack. This second way is the appealing one, but as long as 'decent' computational intelligence is beyond our grasp, it's a never-ending quest. Progress will be made here, but I don't think it'll be any time soon, and it probably won't be by the likes of you or I.

As it is, I could see several simple data-driven ways of simulating your goblin scenario. A laziness variable for each NPC is part of it. An attention span variable could be another. However the part where 1 goblin may or may not believe the others is awkward, as you are getting into the bounds of exponentially sized data. (Each goblin could need a 'trust' score for each other goblin, meaning you need (goblin*goblin) variables... not so good.) Alternatively, each goblin could have a trustworthiness score, but that would apply to every other NPC judging them.

This is how I would approach a data-driven system without trying to go too low level. Instead of thinking about needs and goals and hoping they will coalesce into something resembling intelligence, I try to recognise the factors involved in the behaviour I want to be exhibited, and do that directly. It's a step further up the ladder. Every step you take up that ladder loses you flexibility, but gains you reliability (in terms of knowing the NPC will do what you want) and saves on developer time. The top rung is scripting, where you have next to zero flexibility, but very quick and accurate results. The whole idea of scripting a response is admitting that the NPC has no intelligence of its own. However, a Real Intelligent Human Being had to write that script, and instilled some of their intelligence into the response. Therefore you get a degree of intelligent behaviour without intelligent thought. It's a good tradeoff for many situations.

"'Smarter' just means more options, more branches."

I agree with you to a point, but remember that branches as such are limiting. For each branch, you're only adding one extra response. Scripting is about branches, and is great for modelling the high-intelligence things that you'd never be able to do with basic AI methods given today's technology. However, you can take a step down the 'ladder' I mentioned and give an NPC some attributes on a percentage basis. If you make interesting responses based on different values of each attribute, they can combine together to make interesting combinations. 2 attributes, each with 10 different levels giving 10 slightly different responses, means you have 100 potential behaviours resulting from only 20 'branches' of code. Add another attribute with another 10 actions and you have perhaps 1000 behaviours. Of course, most of these behaviours will be similar. But then, so are most human behaviours anyway.

"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."

The problem with IF statements is that they are hard-coded and limiting. I don't believe that's really how you could go about achieving any kind of goal-based intelligence. What you described was basically a script-driven approach, and is close to what I was mandating anyway, for the more complex concepts

One of the lines in Tom's posts was "NPC's must think for themselves and establish goals" (my emphasis) implying dynamic goal creation as the game progressed, creating more 'content' for the players. Whereas telling a goblin up front to guard a door or a troll to guard a bridge is a pretty one-off static goal. You can't really achieve much in the way of dynamic goals with simple ifchecks as you have described, and you need to look at lower level concepts, and how to represent 'goals' on an abstract level. It is many of those lower level concepts that I am criticizing for delivering too little in terms of gameplay.

Ok, moving more onto Tom's post now...

I am not married to scripting... not even engaged But I am using it as an example of how there are tools that give you far more 'bang for the buck' than the other methods that have been suggested. Supposedly the 'Creatures' games were cutting edge technology as far as needs, emotions, and motivations go. Well to me, it was just a load of little furry people dying and making random noises. Interesting as a toy, but far from being entertaining multiplayer online game content.

"Let's take a complex creature, like a knight. Let's say our knight has one ultimate goal: to protect his kingdom. This is a very noble thing, even for a knight, because most knights were mercenaries who fought for a paycheck. Anyway, this goal breaks down into many sub-goals: destroy enemies of the kingdom, destroy criminals, destroy those who do not pay tax, stay alive so you can continue destroying things."

Here's the problem. Let's say you create a character, and your system decides it's got the 'Protect the kingdom' goal. It even decides which kingdom that is. You then need to convert that very high level concept into low level activity. There are 2 approaches:

1) Hardcode all the high level concepts. This guarantees that they all work, but is very limited and inflexible. This is the way that most games take, and works very well where content is static, such as single player RPGs. As you know, this is not suitable for multi player games where content needs to be replaced and replenished as the game continues.

2) Build high level concepts out of lower level concepts (which, at some level, will obviously also have to be coded, but the lower, the better). This is like building an AI out of Lego, in that once you have a load of bricks, you can build almost anything you like.

The problem is... how do you know how to build? How do you know what to build? If you're doing it from the bottom up, it becomes nearly impossible.

However, your example was a lot simpler, and actually tended more towards type 1 than type 2, in my opinion. Your knight has these sub-goals: "destroy enemies of the kingdom, destroy criminals, destroy those who do not pay tax, stay alive so you can continue destroying things." How does 'destroy enemies of the kingdom' work? How does it determine an enemy of the kingdom? How does 'stay alive' correspond to anything specific? You have to break that down into a load of goals too. And the worst thing is, all this seems to be deterministically based on the 'protect the kingdom' goal, which means you've gained no flexibility over a simple script:

  // Triggers when a Person comes near to the knighteventfunction OnPersonNearby(Person p) if ((IsEnemyOfKingdom(p, my.kingdom)) OR (CrimeRating(p) > 0) OR (TaxesPaidToKingdom(p, my.kingdom) == 0) OR (IsAttackingMe(p)) THEN SetAsCurrentOpponent(p)end if end eventfunction

Now, I'm not trying to say scripting is the be-all and end all. Far from it. In fact, I am trying to move away from scripting in my game engine. But I managed to encapsulate your example in 2 minutes and 7 lines of script. (And my current system can do 50% of the the things in the above script, with the other things only taking a little extra coding to add.) Ok, so I missed out the "stay alive bit", but at its most trivial that can be just another event with 2 or 3 lines of code. At this rate, you could do 30 different NPC types an hour So the question has to be asked: what are you gaining from a goal based system, if you can't demonstrate added flexibility over a scripted event? I do admit that you mentioned scripting yourself in the last post, but that seems to be going back on previous ideas of dynamic goal generation and so on.

I'm not against more engrossing AI at all. However I am against trying to get emergent behaviour to do the work when there are far easier ways to get better gameplay from it.

Edited by - Kylotan on August 8, 2001 9:20:46 AM

##### Share on other sites
Silvermyst    113
TOM:

So the system I was referring to is already established? Good... Makes it a little more likely that one day I''ll be able to achieve my goal. All I want to do is give a LOT of attention to each individual NPC. Recent rpgs are all about size. Of course, when you have to code 1000s of NPCs you simply can''t give as much attention to each single one as you''d like.
I''ll start with 1 and work my way up to maybe a maximum of 10.

KYLOTAN:

Another great post. It''s good to read material that''s obviously coming from more advanced programmers. Me like to learn.

"Don''t model behaviour that can''t (a) be seen by the player, or (b) won''t affect the player''s game plan."

I agree... and disagree.
In my own design, creatures ARE expendable (on average, players will be stronger than their ''prey''), but always pose a danger. Players SHOULD study the behaviour patterns (if they don''t they risk permanent death). Even if their opponents can be easily dealt with, because you never know what''s waiting for you behind those easily defeated enemies. So, there will (should) be a desire from players to be able to study their opponents.

I agree that there''s no reason to design behaviour that can''t be seen by the player (but you''d have to determine what can and can''t be seen by the player. I guess ''vicinity'' should be the keyword here).

I partly disagree with the ''if it won''t affect the player''s game plan'' . I think there''s something to say for ''flair'' . Not EVERYthing you design should have a clear reason. I think that if you want to create the illusion of ''real'' NPCs you HAVE to make parts of their behaviour trivial. Let them scratch their heads etc, the run-of-the-mill stuff that''s already being done. But I think that''s the simple part of the design (and probably the fun part).

I''d almost like to achieve a way to give players a way to look into the mind of NPCs, read their actions and figure out what they are ''thinking''. Like you said though, those thoughts are merely put there by human programmers. It''s just an attempt to simulate intelligence.

"Give an NPC some attributes on a percentage basis. If you make interesting responses based on different values of each attribute, they can combine together to make interesting combinations."

I think I see where you''re going. Instead of having to code behaviour patterns for each individual NPC, you code individual attributes to each individual, code a large set of possible behaviour actions and let the combination of the attributes determine which of the several behaviours the individual NPC will act out. Seems like a smart way to save a lot of programming time while still allowing for a large set of very unique NPCs, each with their own personal behaviour (like you mentioned, if you have 10 attributes with 10 different levels and 10 different responses each, you''ve got a thousand slightly different behaviour patterns).

"One of the lines in Tom''s posts was "NPC''s must think for themselves and establish goals" (my emphasis) implying dynamic goal creation as the game progressed, creating more ''content'' for the players. Whereas telling a goblin up front to guard a door or a troll to guard a bridge is a pretty one-off static goal."

I agree. In a bigger setting, if you want NPCs to live with actual goals, you have to completely change the way you think about the coding. But in my design there will be no ''greater'' goal for NPCs to pursue. There will only be very simple, clear, precise goals. Easy to understand for the NPC and possible for the player to notice.

Back to Tom''s ideas...

Kylotan said:
"There are 2 approaches:

1) Hardcode all the high level concepts. This guarantees that they all work, but is very limited and inflexible. This is the way that most games take, and works very well where content is static, such as single player RPGs. As you know, this is not suitable for multi player games where content needs to be replaced and replenished as the game continues.

2) Build high level concepts out of lower level concepts (which, at some level, will obviously also have to be coded, but the lower, the better). This is like building an AI out of Lego, in that once you have a load of bricks, you can build almost anything you like.

I think that for Tom''s plan, with a limited player base, the Hardcoding might actually work, if slightly adjusted. Maybe a hybrid between 1 and 2 would work.

Still, as an old Lego-fan (I spent hours, days, weeks, building castles, putting my little knights in its towers... then wrecking the place and building yet another castle all over again. Funny, I never actually played with the knights, no royal battles etc... anyway...) I prefer the second method. Construct numerous (hundreds?) lower level blocks and use those to build up higher and higher. Somewhat like a pyramid structure I guess (or should it just be a tall stack?).

Ah well, I better get back to actually learning how to program. I just opened up the book and flipped the page to week 2 (I actually had a little adrenaline rush... and a feeling of accomplishment!)

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

##### Share on other sites
Kylotan    9860
quote:
Original post by Silvermyst
KYLOTAN:
"Don't model behaviour that can't (a) be seen by the player, or (b) won't affect the player's game plan."

I agree... and disagree.
In my own design, creatures ARE expendable (on average, players will be stronger than their 'prey'), but always pose a danger. Players SHOULD study the behaviour patterns (if they don't they risk permanent death). Even if their opponents can be easily dealt with, because you never know what's waiting for you behind those easily defeated enemies. So, there will (should) be a desire from players to be able to study their opponents.

I agree that there's no reason to design behaviour that can't be seen by the player (but you'd have to determine what can and can't be seen by the player. I guess 'vicinity' should be the keyword here).

I should add that I think my wording was sub-optimal here. When I said "behaviour that can't be seen by the player" I really meant "behaviour which has effects that can't be observed by the player". Basically, don't do anything that doesn't affect the player or player's character in some way. This might be due to distance from the player, but it also might be due to irrelevance to the player.

Remember that players tend to have their own motives for playing. Maybe it's just to pass the time, maybe it's to accumulate a high score, finish the game, uncover the story, or whatever. But you can't decide what they should or should not want to do. Therefore, when you say "there will (should) be a desire from players to be able to study their opponents", you need to make it so that the game demands it. I won't study the battle tactics of creatures I can kill without thinking. Therefore not only do you have to make tactics interesting enough to consider, but you have to make the tactics deadly enough so that failing to consider them is risky. That is the 'stick'. The other side of this, 'the carrot', is that watching this behaviour needs to provide insights that are valuable enough for the player to exploit. This corresponds with my "affect the player's game plan" statement: if you can't learn a more optimal way of attacking a group of foes through observation, then people are going to stop bothering, no matter how deadly the foes are.

The same goes for any system: if you want the player to use it, there has to be a stick, or a carrot, or preferably both.

quote:
I partly disagree with the 'if it won't affect the player's game plan' . I think there's something to say for 'flair' . Not EVERYthing you design should have a clear reason. I think that if you want to create the illusion of 'real' NPCs you HAVE to make parts of their behaviour trivial. Let them scratch their heads etc, the run-of-the-mill stuff that's already being done. But I think that's the simple part of the design (and probably the fun part).

But, that is a clear reason: that's for immersion purposes. It makes it easier for the player to suspend their disbelief. But I agree that my original statement appeared to rule out this type of design. I admit that I was just talking about the AI side of things, rather than the holistic picture.

quote:
I'd almost like to achieve a way to give players a way to look into the mind of NPCs, read their actions and figure out what they are 'thinking'. Like you said though, those thoughts are merely put there by human programmers. It's just an attempt to simulate intelligence.

There are ways to implement needs and goals, but not so easily in the context of generating new and interesting ones for ongoing content. As an example, think about Theme Park, if you've played it: the customers had little thought bubbles indicating whether they were bored, hungry, out of money, etc. These were very basic goals: if (some variable representing a need is above or below a certain threshold) then { go to nearest source of 'relief' }. Note that the programmers had to hard-code the concept that the burger bars fixed hunger, rides fixed boredom, and so on. There must also have been some rudimentary checks to see which of the 'needs' was most pressing at any given time. You can do something similar for creatures in an RPG, and it certainly adds something, but with relation to the original post, it's not dynamic enough to generate a lot of content and it's not detailed enough to provide any interesting content. That's the problem.

quote:
I think I see where you're going. Instead of having to code behaviour patterns for each individual NPC, you code individual attributes to each individual, code a large set of possible behaviour actions and let the combination of the attributes determine which of the several behaviours the individual NPC will act out. Seems like a smart way to save a lot of programming time while still allowing for a large set of very unique NPCs, each with their own personal behaviour (like you mentioned, if you have 10 attributes with 10 different levels and 10 different responses each, you've got a thousand slightly different behaviour patterns).

That's the idea. Let's take 3 factors, aggresion, wanderlust, and bravery, with just 3 degrees of freedom, zero, low, and high.

High aggression + high wanderlust + low bravery might give you a wolf's behaviour pattern: they wander all over but only attack when they feel they can win.

Zero aggression + zero wanderlust + high bravery might suit someone who was set to stand guard somewhere.

Low aggression + high wanderlust + high bravery might be the mark of a knight or paladin.

Zero aggression + high wanderlust + low bravery might indicate a travelling merchant, or minstrel, or a religious missionary.

Just 3 variables, working independently of each other, give an interesting range of observable responses. You can add other factors to suit. Loyalty might determine whether this character will assist characters of the same type when they are under attack. Greed might determine whether a character will pick up expensive-looking items that don't belong to them. The only factor limiting you is the ability to code in the different situations that pertain to that attribute. But none of the above are difficult to do.

quote:
But in my design there will be no 'greater' goal for NPCs to pursue. There will only be very simple, clear, precise goals. Easy to understand for the NPC and possible for the player to notice.

I think that's a wise choice to begin with. And once you've done that, take a look at how you could improve on it, build upon it, and maybe you'll come up with The Answer

quote:
Construct numerous (hundreds?) lower level blocks and use those to build up higher and higher. Somewhat like a pyramid structure I guess (or should it just be a tall stack?).

Yeah. The problem is, if you have a load of small low-level blocks which are things like "Go to location X", "Attack character Y", "Hunt edible animals", "Purchase weapon better than current weapon", it's hard for any system to be able to construct these into some sort of intelligent structure. It's like being given a Lego set with all the bricks, but without any instructions, or having ever seen what a house looks like, and being told to build a house. Somewhere, there has to be a system that tells the game how to meaningfully group these low level tasks into higher level tasks, and sadly there is no easy way to do this without hard-coding lists of "what goes into making what", in which case, you're not very dynamic any more. *sigh* (One way which is promising, is simply to randomly group them together, and use genetic algorithms to weed out the poor combinations. But that's quite advanced, takes a while, and isn't guaranteed to produce anything interesting in terms of gameplay.)

Edited by - Kylotan on August 8, 2001 1:32:52 PM

##### Share on other sites
I think this thread is a good place to mention something that''s been brewing in my head for a while, and what I think is the greatest problem with all procedural game AI at the moment.

We can''t ask our AIs to explain WHY they chose to do something. It has never been built in. Now, I think it can be done with a FSM-AI quite easily. For instance, in the knight-of-the-realm case above, if the knight imprisoned a criminal, and was asked "why", it could answer straight from the ruleset "because this guy had commited crime" (i.e. crime rating > 0). That''s not a very interesting explanation though, so you''d need to go into which crime he had commited, and then you''d need an explanation of how the knight knew he had commited that crime etc. etc.

BUT, if you could ASK the AI why it''s doing certain things, you would get an insight into how its mind works (or in AI terms, what ruleset it is following). Even with really simple AIs, this could make things interesting, because you could start asking those goblins why they keep throwing themselves on swords en masse (of course, they''ll probably reply something like "because we attack anything human with no regard for personal safety").

So now I wonder, how much difference would this asking-system make to the player''s experience?

People might not remember what you said, or what you did, but they will always remember how you made them feel.