Hi. It's been quite a while since I've taken the time to peruse the message boards. I hope my Username is still good. And I hope nobody mentioned this before, because I'd feel kind of stupid if they did. But it happens when you've been away for a couple years. I recently had the privilege-slash-punishment of playing Gothic for the PC, and while I'm not the least bit interested in ranting about my experience with what could have been the greatest RPG in the world had it not been for a few flaws, there is at least one thing about Gothic I must describe for a point of reference, and that thing is scripted NPC behavior . Gothic isn't the first game to use scripted NPC's, but it's the first one I've seen to use them to such tremendous effect. We're talking about a game world that essentially lives and breathes on its own, without any player involvement. NPC's eat, rest, sharpen their swords, fix their homes, talk to each other, and get this: I even saw one taking a piss in a corner. It'd be impossible for me to describe the effect this has on the game's immersiveness—which is already quite up there with the fantastically modeled game world—so I won't bother, other than to say it's pretty damn cool. So I got to thinking about this, as a designer is wont to do, and it occurred to me that Piranha Bytes only took scripted behavior to the first level, and that there are two or three levels beyond that that we, as designers, have yet to explore. And indeed, back in 2000 or so I recall Wavinator and some other folks talking about what I christened the "Holy Grail" of roleplaying games. . . that is, an autonomous world that functions all by itself. We're a long way from that, but Gothic has proven to me that we're slowly getting closer, and I'm going to explain how we can get closer still—using technology we already have. Let's take a hunter, for example. The NPC leaves town, wanders into the woods, and stalks the first edible creature it sees. When the kill has been made, it brings the animal back to town, where the NPC commences skinning, gutting, and cooking the animal. (Another NPC might purchase the hide for a pence or two and tan it, but we'll get into that later.) This is a pretty simple script, and it can be "faked" using some generic rules that process quickly behind the scenes without eating up precious clock cycles. But what if the NPC gets attacked by monsters? Or bandits? We've just developed an extremely interesting scenario. On the one hand, the NPC might emerge victorious and return to town with quite a tale to tell his buddies in the tavern. On the other hand, he might be killed or even captured (if the assailant is intelligent). In this case, we can assume that there's a rumor pool from which NPC's derive their dialogue. The player discovers, either by asking directly or overhearing someone talking, that one of the hunters has disappeared. The game spontaneously creates a sort of quest that involves the discovery of this hunter's whereabouts (and his rescue, if he was indeed captured). Voila! Automatic random quest. This is a phenomenally simple example, admittedly the first one I came up with, so let's look at something a bit more complicated. My second idea was to incorporate some sort of social behavioral system into NPC dynamics. In other words, NPC's can communicate with one another on a relatively fundamental level, effectively making friends and enemies by comparing personalities and other factors, like quality-of-life, deeds accomplished, allies, adversaries, etc. Thus, the relationships between NPC's will evolve over time. However, all we're interested in at this point (don't want to make too many jumps at once) is the fact that NPC's interact with each other and, at some level, care about each other. So if the hunter were captured or killed, the NPC's might take it upon themselves to find out what happened to him. And then you'd have NPC's striking off on their own pursuits—effectively becoming adventurers, like the player, and potential party members with a common agenda. I've said it before and I'll say it again: the day RPG's reach their peak will be the day a group of NPC's walks up to you, the player, and asks you to join their party. At this point, you have an NPC community that functions on its own, and protects its own people. I'm sure anyone here could think of a dozen ways to expand this idea into other fields: manufacturing goods, traveling cross-country to sell them, forming mobs to bring down orcish camps (cliched, I know, but effective nonetheless), etc. Comments and suggestions are appreciated. [edited by - Tom on September 1, 2002 3:45:02 AM]

I understand. This AI structure is already in my firm''s MMORPG game design document.

By the way, if you''ve played any good, cheap RPG made with RPGMaker 95/2000, you will have found that there are people that make games with this type of AI structure. Although, RPGMaker 95/2000 aren''t all that advanced as say C, but the effect is still very similar.

quote: Original post by Tom
Let''s take a hunter, for example. The NPC leaves town, wanders into the woods, and stalks the first edible creature it sees. When the kill has been made, it brings the animal back to town, where the NPC commences skinning, gutting, and cooking the animal. (Another NPC might purchase the hide for a pence or two and tan it, but we''ll get into that later.) This is a pretty simple script, and it can be "faked" using some generic rules that process quickly behind the scenes without eating up precious clock cycles.

But what if the NPC gets attacked by monsters? Or bandits?

We''ve just developed an extremely interesting scenario. On the one hand, the NPC might emerge victorious and return to town with quite a tale to tell his buddies in the tavern. On the other hand, he might be killed or even captured (if the assailant is intelligent).

The problem is, this is where you start to hit the limitation of scripts. They are not good at dealing with contingencies. They are essentially ''do this - now do that'' lists of instructions. It''s certainly possible for them to make choices based on a situation, but you can''t take them all into account. Would you write an ''attacked by monsters'' subroutine? And an ''attacked by bandits'' subroutine? And subroutines for ''escaping'' and ''being captured''? Scripts really work like branching storylines for individual characters and they don''t adapt well to situations that can vary significantly.

quote: In this case, we can assume that there''s a rumor pool from which NPC''s derive their dialogue. The player discovers, either by asking directly or overhearing someone talking, that one of the hunters has disappeared. The game spontaneously creates a sort of quest that involves the discovery of this hunter''s whereabouts (and his rescue, if he was indeed captured). Voila! Automatic random quest.

This part isn''t too difficult. Write a script that adds the appropriate quest to the rumour pool, and attach that script to the Hunter''s ''OnDeath'' or ''OnCapture'' script trigger. You still need to work out how to set the parameters of that quest though, such as how to determine what constitutes ''finding out'' what happened.

quote: So if the hunter were captured or killed, the NPC''s might take it upon themselves to find out what happened to him. And then you''d have NPC''s striking off on their own pursuits—effectively becoming adventurers, like the player, and potential party members with a common agenda.

I''ve said it before and I''ll say it again: the day RPG''s reach their peak will be the day a group of NPC''s walks up to you, the player, and asks you to join their party.

Well, even that would require some significant AI. They can just pluck a relevant quest from the rumour list, but the real problem is in going about solving it. How do they know what to do? Computer-controlled characters are not known for having good deductive thinking, or being able to follow clues. On the surface, the best I can see them doing is walking to the relevant place, and then wandering around until the target is spotted.

There''s also the issue of whether you really want this - if you could implement this, which is difficult to imagine at this stage, you still run the risk of the game essentially playing itself and leaving nothing to the player.

[ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost | Asking Questions | Organising code files | My stuff ]

quote:
but you can''t take them all into account. Would you write an ''attacked by monsters'' subroutine? And an ''attacked by bandits'' subroutine? And subroutines for ''escaping'' and ''being captured''?

this got me thinking ... so here''s what i got. when you program games, you have to do a lot of checking so that uneccesary checks dont get performed. frustum culling, portals, hidden surface removal and what not.

maybe its possible to implement a "script culler" (ive never seen this or heard of this before). what i mean by script culler is this:

u said how can we take into acount all teh different situations right. lets take a bunch of situations as an example.

say the hunter goes to get his "whatever", and we decide to take care of the following subroutines:

-attacked by bandit
-attacked by monster
-attacked by villager
-attacked by lion
-attacked by mage ants.

-kidnaped by bandit
-kidnaped by monster
-kidnaped by villager
-kidnaped by lion
-kidnaped by mage ants.

-mugged by bandit
-mugged by monster
-mugged by villager
-mugged by lion
-mugged by mage ants.

now to determine what happend ud have to do a lot of checking when the list gets really big with 100''s of possibilities. we could arrange it so that we have base classes for different categories.

-base class attacked
-base class kidnapped
-base class mugged

now u just check the base classes by down-casting, and u automatically skip 8 checks at minimum. when u have many many checks this could save a lot of time.

as for actually writing so many routines, u could try and maybe implement a virtual function type a thing, and write ONE routine for "attacked", and then derive from it and right sub routines . it would be quicker that way. afterall, there is A LOT of place left for AI in RPGs





Al
"For us it''s a natural disaster....For him/she it''s a damn memory leak..."
[Triple Buffer]|[SCRIPTaGAME]|[My Old Site]

quote: Original post by Kylotan
Computer-controlled characters are not known for having good deductive thinking, or being able to follow clues. On the surface, the best I can see them doing is walking to the relevant place, and then wandering around until the target is spotted.

Just brainstorming on how this might actually be able to be implemented and elaborating on it a bit:

Let''s say that the rumor that propagates back to town carries with it the location of the scene of the crime. When a character receives the quest, his or her first step will be to travel to this location. When the hunter was captured, the event causes a hidden game item (maybe the hunter''s bow, or her hat, or a scrap of his clothing) on the ground.
Every PC and NPC then has some sort of "Detective" or "Tracking" Skill which gives them a random chance of seeing this clue. If the character''s skill level is lower than the clue''s challenge rating, they will never see the item and return home. But if it''s high enough and they''re just rolling badly, the character will re-roll every minute. NPCs will also need some sort of stat which describes how badly they want to solve this quest... either based on how much they liked the victim, their desire for justice or by their desire for the fame and fortune of being a hero. This stat would determine how many failed tracking rolls it takes to make them give up the quest and head back to town empty handed.

When an NPC finds a clue, that clue will communicate to them the location of either A) the next clue (the prisoner is programmed to drop a clue every-so-often on their journey to the monster''s lair) or B) the location of the bad guy. If a PC finds the clue, maybe it just shows some sort of arrow on the screen which describes which direction to search next. Some of these clues may also be able to communicate information that wasn''t in the original rumor... such as what type of monster (Orc, Troll, Bandit, whatever) and how many of them captured the hunter.

In addition to physical clues, some of the clues along the way might be NPC witnesses, in which case the questing PC or NPC would need to use social skills and charisma to determine the next location or direction.

I certainly think this is a fun aspect to design and try to program. However, as Kylotan mentioned, you run the risk of writing the player out of the game. I think to protect yourself from this you would need to A) make sure you give any player in town the opportunity to take the quest before you give it to any NPC''s, B) allow the NPC''s to ask for a player''s help if they run into any along their quest, and C) once they find the monster''s lair... have the NPC run to the nearest Player to ask for assistance in exacting the rescue or vengeance.