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

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