Ambiguous Interactive Dungeons: Upgraded to Version 3

[Legacy_henesua]

               

[EDIT 2016 july 27]
This project is on the Vault
http://neverwinterva...s-onchat-script 
[/EDIT]

 I am rewritting some of Layonara's AID scripts to work with the player chat event and integrate with the DMFI emotes system. Its going well, and I should have this working in my module soon.

I have two questions:
(1) Is there any interest amongst other scripters to use this? Should I post an upgraded AID to the vault?
(2) What is the general feelign towards such thngs as a player or DM? I know there will be those that feel strongly about it one way or the other, but am looking for whether there is much interest or disdain for such systems beyond a vocal minority.

               
               

               

                     Modifié par henesua, 27 juillet 2016 - 10:17 .
                     
                  

            

[Legacy_kalbaern]

               Can you give a bit more detailed explanation of what the system does? I looked over the linked page and even there its kind of vague. I.E., how it works/is used would help us better determine if anyone else might use it.
               
               

               
            

[Legacy_Fester Pot]

               Kalbaern, think of it as an extended description script. So instead of coming across a placeable that you can simply view its description, you can also use AID through the chat event to learn a little bit more by "looking" for other clues or descriptions in that area.

Where a builder may put a picture that is useable and has a description above a fireplace, with the AID system, that builder can put a picture placeable and let the function of the AID system handle the rest.

*looks at picture above fireplace*

AID looks for chat hook matches LOOK, FIREPLACE, PICTURE, and spits out information.

*The picture may have been tampered with at some point, as one edge looks to have been disturbed*

FP!
               
               

               
            

[Legacy_kalbaern]

               

Fester Pot wrote...

Kalbaern, think of it as an extended description script. So instead of coming across a placeable that you can simply view its description, you can also use AID through the chat event to learn a little bit more by "looking" for other clues or descriptions in that area.

Where a builder may put a picture that is useable and has a description above a fireplace, with the AID system, that builder can put a picture placeable and let the function of the AID system handle the rest.

*looks at picture above fireplace*

AID looks for chat hook matches LOOK, FIREPLACE, PICTURE, and spits out information.

*The picture may have been tampered with at some point, as one edge looks to have been disturbed*

FP!

OK, now that sounds useful indeed.

So my follow up questions are:

- Does hooking into the chat commands have significant overhead costs that could cause issues on a large PW?

- Does the AID System first make Spot or Search checks before revealing the extra information and if so, does the extra information gleaned vary dependent on the skill check results?
               
               

               
            

[Legacy_henesua]

               I will do my best to answer your questions, but if you download AID you can read their manual which goes into significant detail.

• Resources: I don't have data showing how resource intensive the chat event is but I don't believe it is significant. More importantly converting AID to use the chat event should imrove tis performance over the prior method which was to use "listeners" (which is the other option for doing this) because the event eliminates the requirement that a creature follow each player around and listen to what they say. For a point of reference... DMFI prior to 1.69 used listeners to process all of the chat commands. DMFI now uses the chat event and performance "feels" much snappier.
• Skill checks: There appears to be the option for skill check requirements for AID's events, but I have not looked closely at how this functions yet.

AID has 2 methods for responding to player chat commands. The first is a "Do" method which responds with AID scripted behavior depending on "verb" used. The second is an "On" method which allows the builder to specify a custom script for a "verb" used on a particular "object".  The On method performs a skill check prior to running the custom script. For any of the methods to work however, local variables need to be set on objects. So if you want the "examine" functionality to work on a particular object you need to set a local variable called "examine" on the object.

As a builder thats the fiddly part of this that is annoying. You have to explicitly flag game objects with the "verbs" that they will respond to.

As a player you have to get used to typing commands in the chat bar rather than just using the "tab" key to highlight active objects. To see what nearby objects are available you type in "look around", and a list of AID objects will show up. This works for my module because I use lots of text feedback for players already such as area descriptions, object descriptions, triggers that provide descriptions, feats like the track feat also provide descriptive text feedback, etc....  But if the module does not provide much descriptive text I can see this system as jarring for a player.
               
               

               
            

[Legacy_wyldhunt1]

               Looks like it has a lot of potential.
At the very least, I'd be willing to test it as long as it didn't use a listener any more.
               
               

               
            

[Legacy_kalbaern]

               

henesua wrote...

I will do my best to answer your questions, but if you download AID you can read their manual which goes into significant detail.

• Resources: I don't have data showing how resource intensive the chat event is but I don't believe it is significant. More importantly converting AID to use the chat event should imrove tis performance over the prior method which was to use "listeners" (which is the other option for doing this) because the event eliminates the requirement that a creature follow each player around and listen to what they say. For a point of reference... DMFI prior to 1.69 used listeners to process all of the chat commands. DMFI now uses the chat event and performance "feels" much snappier.
• Skill checks: There appears to be the option for skill check requirements for AID's events, but I have not looked closely at how this functions yet.

AID has 2 methods for responding to player chat commands. The first is a "Do" method which responds with AID scripted behavior depending on "verb" used. The second is an "On" method which allows the builder to specify a custom script for a "verb" used on a particular "object".  The On method performs a skill check prior to running the custom script. For any of the methods to work however, local variables need to be set on objects. So if you want the "examine" functionality to work on a particular object you need to set a local variable called "examine" on the object.

As a builder thats the fiddly part of this that is annoying. You have to explicitly flag game objects with the "verbs" that they will respond to.

As a player you have to get used to typing commands in the chat bar rather than just using the "tab" key to highlight active objects. To see what nearby objects are available you type in "look around", and a list of AID objects will show up. This works for my module because I use lots of text feedback for players already such as area descriptions, object descriptions, triggers that provide descriptions, feats like the track feat also provide descriptive text feedback, etc....  But if the module does not provide much descriptive text I can see this system as jarring for a player.

• Definately sounds like something I'd use then. '>

               
               

               
            

[Legacy_henesua]

               Alright, I'll clean it up and finish my rewrites of the system. When finished I'll post it on the Vault.

That said however-- what are people's thoughts on how potentially jarring the system is?
               
               

               
            

[Legacy_kalbaern]

               

henesua wrote...

Alright, I'll clean it up and finish my rewrites of the system. When finished I'll post it on the Vault.

That said however-- what are people's thoughts on how potentially jarring the system is?

I honestly cannot see how it would be jarring at all. Infact, I think it'd just heighten the "experience" when playing.

- If its chat based, most players that merely run around killing stuff rarely emote or RP and they'd be unlikely to even fire the system and notice.

- In the same vein, players that do RP and emote constantly likely will fire the system and find that it adds that little "extra something" thats often lacking and just adds to the immersion.

Will it be a "pain in the rump" and a lot of tedious work for builders to add? Possibly, but most likely when adding it to an older module. I know that I personally find such things worth the extra effort though.
               
               

               
            

[Legacy_wyldhunt1]

               I think it would be less jarring and more... ignored.
Players will forget that it exists and miss things.
I think players would have a lot of fun with it if it was used well, but it would need to be used often enough for the player to want to check the area often. If it always says there's no items near, they'll stop trying and miss the stuff that does use it.
I'd send a reminder that it's used when they log in, and maybe add a journal entry with instructions.
Then, use it in enough places to make sure that it's useful.
               
               

               
            

[Legacy_henesua]

               The reason why I have some concern about it is that typically players look for "secrets" in a module by doing two things (1) is to hold down the tab key and carefully look at everything on the screen and (2) slowly walk every square inch of an area with the "search" mode toggled on.

Those are the typical ways of "exploring".

This system however is completely invisible to those methods plus it requires that the player think of the game more in narrative terms which is an entirely different way of thinking about the game. That is what i think is jarring. It changes the way a player approaches the game.

For the module I am currently working on I don't think it is a problem because I immerse the player in narrative and description from the very beginning. The player is already required to do some reading and to consider game events within the context of what they have read. So adding a little more on top of this reading should not be a problem. HOWEVER for players that expect to ignore descriptions and fast forward to the action - if a puzzle is designed in game using the AID system I am sure they would be upset by that.

So that is my concern. What percentage of potential players will be turned off by a module that relies on AID?
               
               

               
            

[Legacy_Fester Pot]

               

henesua wrote...
So that is my concern. What percentage of potential players will be turned off by a module that relies on AID?

Well it was used in a module but from the look of the comments, the AID system provided more headaches for players than it did enjoyment. Perhaps such a system would better be used in a full mystery type of module, where the AID was more of a tag-based script off of particular items that could share information - if you had said items - rather than a requirement?

From reading the comments, it seems there was no other way of completing certain quests without using AID. Two options could have been made available to the player - the normal way and the AID way - and if using the latter, perhaps extra experience could be awarded for finding more information about the quest than would otherwise be available.

An example -

You find a puddle of blood by the fireplace and your journal updates to tell you someone obviously was killed here as Bob mentioned when you met him. The quest advances as normal. If the player uses AID in the home, perhaps they learn of blood drips on the bedroom floor or in the hallway on the wall - added experience for investigating further. By no means does this change the line of the plot of someone being killed but by using AID, adds more touches to the murder and its investigation. The tool is there for the player to use - IF they choose to take the time to do it BUT it is not a requirement to complete the quest.

Some of the AID quotes from the player's who voted (only those quotes related to the system).

Average storyline of going 3 different places to collect things, but like some others have commented, the AID system was a turnoff. Very time consuming.

I thought AID was interesting, but kind of a pain to use even with hot keys.

the aid system can be axed for descriptions of placeables

AID: What's the point? Graphic environments of videogames were created for the purpose of *not* typing things like "pick up the mithral acid-coated gauntlet of DOOM". Good example is Xora's tower, where portraits could've just been made to be selectable and having descriptions...

Weaknesses: at times the AID system seemed insufficiently integrated into the quests. In the murder investigation early on, which should really have been the high point of the AID system use, ended up being quite frustrating, because the PC's observations from AID were not always incorporated back into the conversations/questionings. For instance, when talking to the woman who my character has observed has a spellbook upstairs, my character can't bring this inconsistency up in conversation. I think this side quest had a lot going for it, and I am sucker for mysteries, but here the AID system just added frustration and inconsistency.

AID was annoying at first but fine once I got the hang of it.

The AID system should be in every module.

Great Module, great story, AID system did not slow down the game for me.

Awesome. I'd never seen the AID plugin before, and I love it. It makes for much better puzzles--players can't simply get around by clicking on things until they figure it out, you actually have to stop and read things.

AID is good, once you get accustimed and are a good typist;

AID didn't bother me at all and was sorta fun in a way.

The AID system is a really good, very original idea but in the module it felt like a bit of a hassle to type all those orders instead of clicking.

This had a lot of potential, but the reality is ridiculous. The AID system should never have been used. I played text-only games 25 years ago. What century is it again?

I think the AID is very interesting, but I too became frustrated with the Mill Quest.

Excellent mod, but I did mark it down for the AID system, which I found to be tedious and actually delayed information gathering.

FP!
               
               

               

                     Modifié par Fester Pot, 28 décembre 2011 - 12:26 .
                     
                  

            

[Legacy_henesua]

               FP -
         I'm still thinking over your comment, and considering how to best implement AID from a game play stand point. But my priority right now is to rewrite the AID system. I'll look at implementation after I have this rewrite done.

Everyone else -
         Getting close to a complete rewrite of a parser for emotes that integrates DMFI and AID.

Improvements so far:

• DMFI and AID get text from the player chat event rather than using a listener
• DMFI and AID can be processed together which limits overhead when using both systems.
• emotes are parsed regardless of where they are located in a chat string. Previously the start of the string had to contain an *. Now emotes are understood to be text contained by *'s.

             Example: Hello! *bows in greeting* It is good to see you. *looks around at the group*
             Result: And your character will bow. Previously you had to start the emote on a fresh line. I have not however created a way to queue multiple emotes in succession into the action queue so "looks around" will not result in another emote animation. Only the first "actionable" emote reesults in animation. AID however will not respond to bows and will instead keep looking for the first actionable verb to respond to. see below.

• AID's parser is smarter and more efficient. It now is smart enough to recognize words, and then whether the word is a verb, an ignored word, or an object. It no longer needs to strip "ignored words" from the emote string. In addition it is easy to make it smarter by creating more word lists such as prepositions, conjunctives, etc... by following the example set with the "ignored word list".

               what it does is looks for the first verb. then it starts looking for an object, while skipping over ignored words. If it encounters the end of the emote snippet before finding a suitable object or verb it will start looking for the first verb in the next emote snippet.
               example: Hello! *bows in greeting* It is good to see you. *looks around at the group*
               emote snippet 1: bows in greeting
               emote snippet 2: looks around at the group
               no actionable verbs are found in the first snippet. "looks" however is then found, and then "around" is identified as an object. AID parsing stops and then the "looks around" function is executed.


I am considering rewritting the DMFI emote parser further, so that it responds similarly to the way AID does - looking at each word one by one until it finds a match that it can do something with. OR ... I might give AID precedence - if AID finds an actionable verb that verb is the only one that will stimulate an animation. If however AID finds nothing that it can work with, then any emote will do for stimulating an animation.
               
               

               

                     Modifié par henesua, 28 décembre 2011 - 05:56 .
                     
                  

            

[Legacy_henesua]

               I uploaded to the vault my improvements to DMFI v 109. These are not strictly required to use my pending release of a revised Ambiguous Interactive Dungeons, but they are required if you want to integrate AID with DMFI. A few other improvements are included as well. Examples: that weird hanging behavior when the first player enters a module with DMFI 109 has been eliminated, and DMFI chat functions have all been extracted to an include so that they can be used with any Player Chat Event script.

[edit: uploaded my initial improvements to AID as well. I will post links to both projects when they are live. I curtailed my complete rewrite of AID so that I can get back to working on my module. If you have ideas I'll be ahppy to hear them. I am still on the fence about whether to completely rewrite the parser to more closely reflect the abilities of the z-machine style parser from Infocom, but the amount of work required is too distracting as I would prefer to continue producing my module which is due for its next play test in two weeks)
               
               

               

                     Modifié par henesua, 29 décembre 2011 - 09:33 .
                     
                  

            

[Legacy_henesua]

               

Vault entries for what we've been talking about: 
Ambiguous Interactive Dungeons upgraded to version 3
Dungeon Master Friendly Initiative v1.09 patch

               
               

               

                     Modifié par henesua, 27 juillet 2016 - 10:19 .