Sign in to follow this  

NPC dialog implementation

This topic is 3472 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I try to understand how usually implement communications with some bots that give some quests... For example: 1. I click on the bot. 2. Appears something like: Hello, I'm your friend a. Tell me about this land b. Give me a task 3. I select the answer and maybe get another form... What to do if I talk with a bot and click again on it, while server sends me a new dialog I answer to the one I see, and changed server state gets it as another one... And the second problem is how to store some data I can enter (for example first form asks me if I'm a man or woman, then asks me my age, then asks me something else, and then all of this data makes some transformations).. Am I wrong somewhere? And how to implement, help me please...

Share this post


Link to post
Share on other sites
When you begin the conversation, actor stores a "cookie" on the player. This cookie is actor-specific, and carries whatever you need to remember where in conversation you are.

When choosing the dialog options, you again scan the player and your database to determine which options to show. Actors, in most cases, will be stateless. Any state you do need to persist or at least hold on for some duration needs to be player-specific.

Quote:
And the second problem is how to store some data I can enter


Well, in the same way you store any other persistent information. If you use some form of ORM, then just add the data within the cookie. Otherwise write it to player-specific store. But it's whatever you are using.

Share this post


Link to post
Share on other sites
But you didn't answer for some lose of synchronization:
1. I get one form.
2. I click on the NPC again.
3. While server sends me a new different from my one (internet went very slow e.g.) I send data from my form.
4. When server changed it's state to a new form it gets my answer as an answer for a new form.

Or maybe there's a lock for "One form a time" or some "Modal dialog"? It's very interesting because maybe only I dream of popups overlaying each other but no one else does?

And on which side such cookie data is stored: on the player's one (in it's structure), or an NPC has a list of connected players and every player has a link to this NPC?

Share this post


Link to post
Share on other sites
Quote:
Original post by Anton Vatchenko
But you didn't answer for some lose of synchronization:
1. I get one form.
2. I click on the NPC again.
3. While server sends me a new different from my one (internet went very slow e.g.) I send data from my form.
4. When server changed it's state to a new form it gets my answer as an answer for a new form.

Or maybe there's a lock for "One form a time" or some "Modal dialog"? It's very interesting because maybe only I dream of popups overlaying each other but no one else does?


Well, that again fully depends on your implementation of networking.
- If you're using blocking calls, then the request for conversation blocks the thread on the client's side.
- If you're using messages or async requests, client remembers that it already issued a request, and will ignore user's attempt to open another until current one is done with
- If you're using ORB or RMI approach, then the life-cycle of the remote form object will determine which is currently visible

Modal dialogues in general have many problems, and are very undesirable in certain environments, since their blocking nature interferes with certain events. So just show request a dialogue, and until the user presses 'close', 'ok', 'cancel' or 'option #', you don't allow that user to open another.

Quote:
And on which side such cookie data is stored: on the player's one (in it's structure), or an NPC has a list of connected players and every player has a link to this NPC?


Server, obviously, unless you're P2P.

NPC doesn't know about players. It's provided (usually) the instance of player interacting with it. Such as PlayerRequestConversaionMessage, which contains instance of player/socket that requests it.

Player object doesn't care what actors store in it. Look at how HTTP sessions are handled with cookies. This is generally better to allow for extensibility - what happens if you change actor's logic at some point? Simply keep a map<ID, std::string>, for example, where ID is actor's ID, and std::string is provided and manipulated by the actor.

...

Another way is to implement remote UI. This generally requires some form of object remoting, but rather than manually handling various cases, you create full UI on the server for the player that requests it. Something like Window->Borders->Buttons->Text Labels.... The client is then sent this definition, creates their visual representation of it, and forwards all events to be executed on the server.

This is similar to the way some terminal services work. This allows for somewhat transparent UI design, doesn't require any extra logic, but may require more resources.


As always, there's a lot of choices when implementing such techniques, but each depends on your particular circumstances.

Share this post


Link to post
Share on other sites
You can run the logic on the server. Thus, when clicking on the NPC, you make the NPC spit out whatever its current text is for the state of the NPC for that player. Thus, if the player did click - A - click, the server would spit out:

Hello! Choices are A or B.

Ah, you chose A!

Ah, you chose A!

Note that "clicking an NPC" is now defined to mean "say whatever the current state says you should say," and thus it will either repeat the current output text, or it will be used for getting more information (in which case clicking on the NPC just serves as "type-ahead").

Share this post


Link to post
Share on other sites
I've never understood why a copy the entire quest database isn't stored on the client in MMOs, and the relevant quests that need updated are updated for each patch (just a list of the ones that need updating). Getting the text fresh doesn't seem to make much sense and storing it locally is only text so it's not going to make a huge database, a lot less than textures etc.

Seems most MMOs get the text fresh each time you click on it, or cache it in some way. I'm sure the designers have thought about this, it just doesn't add up from the angle I'm looking at it.

[Edited by - kangaroocow on June 5, 2008 4:06:12 PM]

Share this post


Link to post
Share on other sites
The main reason is that quests may have server-side implications. For example, depending on the current (world, i e server-side) state of a quest giver or a quest item, the quest may change, not be available, have a different reward, spawn a different target on acceptance, etc.

Whether quest text is transmitted or patched isn't that important, as the amount of data is fairly small. Some games will build a string database of all text strings in the world, and send references to that database; in that case, the text is actually "patched" to the client. I hear that it's a real pain to manage such a database, though, from a coding, build and distribution point of view.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
The main reason is that quests may have server-side implications. For example, depending on the current (world, i e server-side) state of a quest giver or a quest item, the quest may change, not be available, have a different reward, spawn a different target on acceptance, etc.


Wouldn't administration be the deciding factor?

Resource and state propagation, no matter how complex, is solvable.

But client-side resources are reasonably static, and they'll require clients and servers to sync and restart, something which could be argued is not needed for many updates.

Share this post


Link to post
Share on other sites
Quote:
Original post by hplus0603
Whether quest text is transmitted or patched isn't that important, as the amount of data is fairly small. Some games will build a string database of all text strings in the world, and send references to that database; in that case, the text is actually "patched" to the client. I hear that it's a real pain to manage such a database, though, from a coding, build and distribution point of view.


A major benefit/reason is localization. If the server just sends up a reference to a text instead of the text itself, you can keep your servers language-independent and instead be able to switch languages at will client-side.

Share this post


Link to post
Share on other sites

This topic is 3472 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this