• # Realistic NPCs

Game Design and Theory

Realistic NPCs (Active vs Reactive)

* Subject: (General) Realistic NPCs (Active vs Reactive)
* From: scythe@u.washington.edu (Dan Shiovitz)
* Date: 9 Sep 1995 19:15:50 GMT
* Newsgroups: rec.arts.int-fiction
* Organization: University of Washington, Seattle

(This was discussed a little, I believe, around the time _Christminster_ came out. It's an important topic, so I thought I'd bring it up again.) (There are some vague spoilers for _Christminster_ and Curses here, which provide decent examples for what I'm talking about.)

In whatever next game I put out, I intend to have a real NPC (since I didn't have any real ones in my last game). To bolster the illusion of reality in an NPC, there are a couple things you can do. One of the things I was thinking about doing was having the NPC actually be active, rather than reactive. Most NPCs in most games are purely reactive. They don't seem to have any lives of their own, they take no initiative, they have no curiousity about the world, they have no apparent goals that they work to achieve, and (in worst cases) they don't even seem to have a reason for being in the adventure. This doesn't do much for my suspension of disbelief.

For instance, in _Christminster_ Professor Wilderspin has a one-room living space. If you inspect the fireplace, you notice the griffins to either side, and notice that they're one-eyed. Asking Wilderspin about them gives the response that they're unusual, created by such-and-such a person. Looking up their creator in your college book shows that he was rumored to have created a number of secret passages, and so on, and so forth. Professor Wilderspin is a professor of archaeology. He's used to pyramid explorations, and what-not.

Further on, we're shown he's curious and fairly intelligent. Yet we're supposed to believe he's never even wondered about the griffins? We're expected to believe he's lived in this room for who knows how long, and never even accidentally pushed an eye? Furthermore, to make matters worse, when you take the initiative and push an eye, all he says is something to the effect of "Wow, that's neat." There's no feeling there, there's no move towards "Hmm, what happens if we push both eyes at once!" [The above should not be taken as a personal attack on _Christminster_, persay. I enjoyed the game immensely, but its somewhat-detailed NPCs only show how much farther we have to go.]

So, I was thinking about making the NPC in my game be a little more active, more willing to take action (and maybe tell the player what to do!). The obvious problem with that is how to keep the NPC from solving all the puzzles, then? I'm not really sure what to do about that. One thing to try, I guess, is to have some puzzles that are character-specific, and some more that require cooperation. I suppose the NPC could even be used as a hint system, having them solve certain puzzles if the player takes too long. Anyone got other thoughts on the topic?

My ideal NPC interaction would be something like this:

>LOOK
South end of Attic
[...]
Igor is here.
A robot mouse is on the floor.
There is a small hole in the western wall.

Igor says "go west" to the mouse.  The robot mouse zips westwards into the
hole.
>Z
[..]
Igor sighs.  "The mouse can't hear me from out here," he says.
>HOLE, WEST
You bend down to the hole and say "go west" into it.  "Hey, good idea," Igor
says.  He bends down and says "go north" into the hole.  You hear the whirring
of wheels.
>HOLE, NORTH
Igor glares at you.  "Hey!  I'm the one with the map of the maze, here."
He bends down to the hole and says "go north" into it.  You hear the whirring
of wheels.
>IGOR, GIVE ME MAP
"Fine," he grumbles, handing you the map.  "You can do all the fun stuff, see
if I care."  He stomps off to the north.
>HOLE, NORTH
You hear the whirring of wheels, and an excited beep from the hole.
[etc]


I'm not sure how much effort this would take to do, but I think it is doable today with the programming we have.

------------------------------------------------+--------------
The Grim Reaper ** scythe@u.washington.edu     |
Dan Shiovitz   **  shiov@cs.washington.edu    |     Aude
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   |    Sapere
_Music of the Spheres_ : Coming Nov '95  |
------------------------------------------------+--------------


Report Article

## User Feedback

There are no comments to display.

## Create an account

Register a new account

• 14
• 22
• 9
• 31
• 19
• ### Similar Content

• By menyo
I really like to add AI to my game in the form of behavior trees and have been reading about them. The primary thing I am "stuck" with is how to pass data. Some articles mention a blackboard that should be passed down the tree nodes so they can set fields on it, but this means for each leave task that needs some form of data the blackboard gets a field. I imagine a lot of leave leave tasks and some need many fields to set on this blackboard and this deviates from my perception of clean and scalable code. Are there other ways to handle this?
• By sprotz
What pathfinding technique is used for an enemy to find their way around when looking for the player, and also I'm curious... What pathfinding technique did Goldeneye 64 use when an enemy is alerted to the player's presence and begins to move through the level until they find the player?
• By EGDEric
Have you ever played Starcraft, or games like it? Notice when you tell a group of air units to attack a target, they bunch up and move towards it, but once they're in range, they spread out around the target. They don't all just bunch up together, occupying the same spot, even though the game allows them to pass through each other.
How would you approach this problem?
I went with a "occupation grid": It's just a low-resolution 2D boolean array (640x480). Each ship (my game only has ships) has one, and updates it every frame. When attacking, they refer to the grid to figure out where they should move to. It works pretty good: The ships are nice and spread out, and don't just all occupy the same space, looking like they merged into one ship.
The problem is is that this way is pretty inefficient. Just updating every ship's grid sometimes takes 24-31% of the CPU time. Using Bresenham line-drawing algorithm for every ship is the culprit.
I'm thinking of having one shared grid for all the ships on a team, and instead of using a simple boolean 2D array, allow each square of the grid to keep track of every ship that is using it, by using a data structure with a linked list of references to the ships using that square. That way, I wouldn't have to update a grid for each and every ship.
Maybe the solution would be to use a much simpler grid, minus the bresenham line drawing, just: a bunch of squares, try to stay in your grid square. Maybe allow larger ships to occupy more than one square.
Another solution might be evading me completely, one that doesn't involve grids at all. Any thoughts?

• I wanted to get some thoughts on player character collisions in MMOs for my project.   As I recall the original Everquest had them, however WoW didn’t. I also remember Age of Conan had them but I’m guessing they were done on the server which was highly annoying because you could collide with things that were unseen. I’m not sure how EQ did them but I don’t remember having this problem in EQ, but it was a long time ago.

My general idea as to do player collisions on the client side. A collision would only affect a given clients player character as seem from that client. On the server, characters would pass right through each other.  This means that because of lag, two players might see different things during a collision or one may think there was a collision while the other doesn’t, but I figure that’s less annoying than colliding with something you can’t see and everything should resolve at some point.

There is one more case which I can see being a bit problematic but I think there might be a solution (actually my friend suggested it).  Suppose two characters run to the same spot at the same time.  At the time they reached the spot it was unoccupied but once the server updates each other’s position, they both occupy the same space. In this case after the update, a force vector is applied to each character that tries to push them away from each other. The vector is applied by each client to its own player. So basically player to player collisions aren’t necessarily absolute.

I was also thinking you could generalize this and allow players to push each other.  When two players collide their bounding capsule would be slightly smaller than the radius where the force vector would come into play. So if you stood next to another player and pushed he would move.  By the vector rules he is pushing back on you (or rather your own client is pushing) but since your movement vector could overcome the collision force vector, only he moves unless he decides to push back. You could add mass calculation to this, so larger characters could push around smaller characters more easily.

Of course there are griefing aspects to this, but I was thinking I would handle that with a reputation/faction system. Any thoughts?

• As DMarket platform development continues, we would like to share a few case studies regarding the newest functionality on the platform. With these case studies we would like to illuminate our development process, user requirements gathering and analysis, and much more. The first case study we’re going to share is “DMarket Wallet Development”: how, when and why we decided to implement functionality which improved virtual items and DMarket Coins collection and transfer.
DMarket cares about every user, no matter how big or small the user group is. And that’s why we recently updated our virtual item purchase rules, bringing a brand new “DMarket Wallet” feature to our users. So let’s take a retrospective look and find out what challenges were brought to the DMarket team within this feature and how these challenges were met.
DMarket and Blockchain Virtual Items Trading Rules
Within the first major release of the DMarket platform, we provided you with a wide range of possibilities and options, assuring Steam account connection within user profile, confirmation of account and device ownership via email for enhanced security, DMarket Coins, and DMarket Tokens exchanging, transactions with intermediaries on blockchain within our very own Blockchain system called “Blockchain Explorer”.
And well, regarding Blockchain... While it has totally proved itself as a working solution, we were having some issues with malefactors, as many of you may already know. DMarket specialists conducted an investigation, which resulted in a perfect solution: we found out that a few users created bots to buy our Founder’s Mark, a limited special edition memorabilia to commemorate the launch of the platform, for lower prices and then sell them at higher prices. Sure thing, there was no chance left for regular users. A month ago we fixed the issue, to our great relief. We received real feedback from the community, a real proof-of-concept. The whole DMarket ecosystem turned out to be truly resilient, proving all our detractors wrong.
You Can’t Make Everyone Happy….. Can You?
By removing the transaction signing requirement we made most of our users happy. Of course, within a large number of happy people, we can always find those who are worried about owning a public key wallet. When you don’t own a public key, it may disturb you a little bit. Sure, DMarket is a trusted company, but there are people who can’t trust even themselves sometimes. So what were we gonna do? Ignore them? Roll back to the previous way of buying virtual items and coins? No!
We decided to go the other way. Within the briefest timeline, the DMarket team decided on providing a completely new feature on Blockchain Explorer — wallet creation functionality. With this functionality, you can create a wallet with 2 clicks, getting both private and public keys and therefore ensuring your items’ and coins’ safety. Basically, we separated wallets on the marketplace and wallets on our Blockchain in order to keep great UX and reassure a small part of users with a needed option to keep everything in a separate wallet. You can go shopping on DMarket with no additional effort of signing every transaction, and at the same time, you are free to transfer all the goods to your very own wallet anytime you feel the need. Isn’t it cool?
Outcome
After implementation of a separate DMarket wallet creation feature, we killed two birds with one stone and made everyone satisfied. Though it wasn’t too easy since we had a very limited amount of time. So if you need it, you can try it. Moreover, the creation of DMarket wallet within Blockchain Explorer will let you manage your wallet even on mobile devices because with downloading private and public keys you also get a 12-word mnemonic phrase to restore your wallet on any mobile device, from smartphone to tablet. Wow, but that’s another story — a story about DMarket Wallet application which has recently become available for Android users in the Google Play.
Stay tuned for more case studies and don't forget to check out our website and gain firsthand experience with in-game items trading!