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.

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.

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]

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.

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.