 |
 |
|
 |
|
| Author |
Message |
Spazmatic
Joined: 18 May 2005
Posts: 76
Location: Pittsburgh, PA
|
 Posted: Fri May 20, 2005 6:45 pm Post subject: |
 |
|
| Quote: | | So: how does this work out for you, performance-wise? |
I work primarily in prototyping and algorithms, haven't done full-scale development in a while. However, yes, I'm well aware of this problem. It's worth noting, though, that PRECISE is merely an example, and it offers 100% comprehension. That's expensive. For a similar project, I have built tokenizers that have closer to 80% accuracy on similar input spaces, but work in a significantly shorter amount of time (perspective-wise, it was part of a web data miner targeting billions of webpages).
PRECISE is more of an example of what can, in theory, be achieved - mapping from question to query can be done in a variety of ways that would still be infinitely better than regex. The basic concept is NLP in limited input spaces, which I think would be very useful. I do plan on dedicating some free time in the near future to the literature and some careful thought, maybe produce a more useful MUD-specific algorithm for certain input spaces, but it'll be a while at any rate.
Notably, as far as actual trials, my third generation protoype codebase (personal playground, really) used a dirty tagger solution to parse, though that drastically reduced the available input space. Still, it got sensible enough queries for questions like, "Where is the museum?" and slightly harder ones like, "What is the best way to level?" with time only worse than a complex regex. Solution output was horrific, though, and it failed on anything remotely out of place, like, "Where would I find the museum?"
It's a direction, at any rate. |
|
| Back to top |
|
|
|
|
 |
|
 |
|
|
|
|
| Author |
Message |
Lindahl
Joined: 29 May 2005
Posts: 56
|
| Posted: Tue May 31, 2005 12:27 am Post subject: |
|
|
I prefer to have NPCs participate in topic-based discussions. Each token has associated discussions with it. Each NPC will have several tokens that refer to discussions they are interested in. If an NPC is spoken to about a topic that doesn't match a token it holds, then it simply expresses a disinterest in the subject, or perhaps that it doesn't know anything about suchandsuch. The administration can add token topics to the database and assign them to random NPCs. NPCs who have the same tokens can discuss the topics. Tokens can be traded among NPCs, sort of like a rumor system. Tokens can be based on an NPCs job, giving him some personality that is somewhat relevent to their job. The tokens can even represent and fire off roleplaying events. For example, when an NPC is asked about one of it's token's subject, a barkeeper might overhear the conversion, if it has a matching token and offer some new information. This allows more than just a 1vs1 interaction and allows a much more interesting experience on a grander scale.
All sorts of interesting things can be done with this tokenized topic system. As well as saving lots of processing time and memory. They are loaded on-demand. Therefore its quite possible to have a HUGE database of topics and only have a few be in memory at any given point in time. The tokens don't need to be in memory until a dicussions begins about one of them. At that point in time, all the necessary parsing and output information about the topic is loaded. |
|
| Back to top |
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Alister
Joined: 13 May 2005
Posts: 62
Location: Alberta, Canada
|
| Posted: Sat Nov 26, 2005 9:01 pm Post subject: |
|
|
It's not perfectly on theme with the thread, but it seems relevant enough. I opted to go for a dialog system similar to what you might see in RPGs like Ultima, Baldur's Gate, or Morrowind. Players approach or greet an NPC. If the NPC has something to say, he says it and the player is given a list of ways he or she might respond. So, for instance:
| Code: |
> greet bartender
You greet the bartender.
The bartender acknowledges you and responds:
Well hello there. Welcome to the Stuck Swine! What can I do for you?
Responses:
1) How do I get a drink around here?
2) What is this place?
3) Who are you?
4) Goodbye
Enter a choice, or Q to say goodbye:
|
Originally, I had interaction with NPCs done with the say command and simply highlighted topics that the player might consider enquiring further about. However, I found this approach dissatisfying. For one, coloring became quite the eyesore when NPCs had lots to talk about. But when I took coloring out, I ran into the problem that it wasn't always obvious what sorts of topics players could follow up with. I think one downfall to this system is that, like Alayla mentioned, when the options for response are so obvious it feels less like a conversation or puzzle, and more like cycling through all the options until you've heard all there is to say. I hope to combat this by actually making the responses players make matter. Some responses will be mutually exclusive, not allowing players to backtrack. Players will have to decide what sort of information they need the most and respond accordingly. It's still not really puzzle-esque (but that can be addressed with something along the lines of social combat like KaVir mentioned earlier), but I think it still retains the conversation aspect of it since what you say matters, and it can be fun with sufficiently complex dialogs. So, for instance:
| Code: |
Enter a choice, or Q to say goodbye: 3 (Who are you?)
The bartender responds:
My name is Julesz. I own this place. Most nights you can find me working the
bar. Who are you?
Responses:
1) I'm a traveller
2) I'm an adventurer
3) I'm nobody, really
4) My name is Alister
5) None of your business
6) Goodbye
Enter a choice, or Q to say goodbye:
|
Depending on the response a player gives, he gets different information. If he says he's a traveller, the bartender enquires about the places he's been, and if he has ever heard of certain exotic locations (and hints that it might be worthwhile to visit them). If the player says he's an adventurer, the bartender tells him about the days when he was a caravan guard, and where the player can find some work and adventure.
It also integrates quite nicely with other forms of communication with NPCs. So, for instance, shopkeepers and trainers. I no longer need buy, sell, list, and train commands. I just need a single "greet" command, and responses to bring up the shopping/training interfaces. I think this is especially nice for people who may not have played muds before. It keeps everything unified.
From my experience, systems like this are fairly common for computer and console RPGs. But I've never once seen something like this in a mud. Does anyone have an opinion on why this is? Am I just playing the wrong sorts of muds? |
|
| Back to top |
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Cornelius
Joined: 13 May 2005
Posts: 42
Location: Florida
|
| Posted: Sun Nov 27, 2005 5:40 am Post subject: |
|
|
I think the main reason why a command based interface is more appealing than a menu based one for most in-game interactions is to keep the character free to do anything at any time rather than being locked in a menu. For instance say a player perusing a shopping list is suddenly interrupted by a friend to whom they wish to respond- now they need to exit the menu, respond, and re-enter to keep perusing- now they see three items they want, they can probably afford two of the three but unsure of their exact funds they need to exit the menu again, check their purse, and re-enter the menu once more to continue perusal. Gods forbid they were attacked while in a menu...
Of course this effect might be beneficial for a quest type interaction where you want the player to answer the question without outside help. Now they cannot ask for help with the riddle or which response does what unless they can anticipate the question (or use AIM). |
|
| Back to top |
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Tyche
Joined: 13 May 2005
Posts: 176
Location: Ohio, USA
|
| Posted: Sun Nov 27, 2005 6:21 am Post subject: |
|
|
| Cornelius wrote: | | I think the main reason why a command based interface is more appealing than a menu based one for most in-game interactions is to keep the character free to do anything at any time rather than being locked in a menu. |
It shouldn't be necessary to lock them into the menu. Just maintain a context sensitive command environment. As long as menu options are different from commands it shouldn't cause confusion (i.e. numbered like the example). Just push the menu in the stack along with the necessary context. Context could be as simple as a boolean expression of object keys that need to be present. The menu can be popped off the stack automatically when the context is invalidated. That would allow you to have the menu active and do other things through normal command fall thru. No need for a [Q]uit option. A stack allows nested menus as well. I wanna say, "for free!!!", but I will resist.  |
|
| Back to top |
|
|
|
|
|
|
|
|
|
|
|
| Author |
Message |
Cornelius
Joined: 13 May 2005
Posts: 42
Location: Florida
|
| Posted: Sun Nov 27, 2005 8:12 am Post subject: |
|
|
| Tyche wrote: | | It shouldn't be necessary to lock them into the menu. Just maintain a context sensitive command environment. |
I had a feeling someone was going to bring this up... and yes you could but you're adding an extra level of complexity to acheive the same effect. I compared simple command based vs simple menu based interfaces at face value because I think they are on par in terms of complexity. Adding another level changes the comparison into which is simplest, so in that case command based still wins out, no?
I suspect that was the sentiments of the original coders of mud, and from there perhaps it just became a legacy no-one thought to question? I didn't. |
|
| Back to top |
|
|
|
|
|
|
|
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
|
|
|
|
