Trying to learn TAB has been a little tough (I used to know BASIC, but it's been over a decade and I'm not sure I want to learn to code a parser all by myself, so here we are), but I've been confident for my possible end results in the future because-- so I'm told-- I'm decent at writing, especially dialogue.  But unfortunately, I'm starting to dread having to write the dialogue for my practice game because I am unsure of how to best approach it.

I haven't had the fortune to be able to play a lot of parser-driven games since I'm a bit of a whippersnapper, but most adventure games I've tried either have just a generic "talk" command, or a list of predetermined responses to select (I've played one graphic adventure that had an optional parser for dialogue, but it never had characters understand any word I put in there, which doesn't bode well).  This kind of leaves me at a loss for references as to how to approach creating dialogues with memorable characters in my game... I guess I could narrow it all down to "hello", "yes", "no", and similar brevities, but that can't be all there is, can it?  I feel like I wouldn't be doing them justice.

It was said in another topic:

catventure wrote:

All you have to remember is that if there is a command (coding entry) that must be recognized by a CHARACTER then it must be listed in the "Char Responses" as opposed to the normal "Player Response" list.

Character speech commands are simply commands that follow an input command that begins:

>say to character,
>say character,
or
>character,

and thus that is how they are differentiated and interpreted as a non player character (NPC) command rather than a normal player character command.

In general, you should find it beneficial to have all these sorts of commands in the same place and it seemed therefore a good idea to have them accessible via the Character Editor.

Which definitely helps!  But I guess I could say I'm overwhelmed by the endless possibilities, and would like to know the limitations so that I can try and use them as best I can, and write all the dialogue to consider the limitations so my ideas don't surpass them and have to be scrapped.  TAB's vocabulary list comes with "say" separate from "talk/speak", and from "tell", which gives me lots to consider...  The idea of having to program in accounting for every possible player question's and phrase's slightly different phrasing is a bit nightmarish, to be honest.  I know I won't prepare for everything, but I do want to minimize "(character) doesn't understand what you mean" moments.
I guess I could just include a manual document saying that your character is so good at charades that they can be understood from one-or-two-word utterances like some sort of civilized caveman, but would that be what's best for me to aim for?  Is there a "best way" to program dialogue and conversation in TAB?  A way that's efficient but capable of handling the various player inputs?  Whenever I see footage of text adventures it usually seems that NPCs do most of the talking all by themselves regardless of what you want to ask or tell them, and I expect that for mine as well, but I'd like mine to feel decently interactive because I love writing character interactions.  If not like real people, then at least like reliable entities a player can get responses from using logical phrases besides just the ones to physically jostle them and show them things.

Hi Somnosa,

There are no dedicated character conversation trees in TAB - unlike some other utilities.
In my last game "Arkham Abomination" there were not many Characters. I did not use the Character speech commands in the Character Editor and just handled conversational responses in the normal Response Editor using "talk to x"  and sometimes "ask x about " when the character was present. By setting a flag value in an action I could invoke different replies {or random replies) from them, if necessary, by checking the flag value in the conditions each time the "talk to x" command was inputted.

Another possibility is talk to . (For example, talk to julia)
Player is then presented with a MENU of questions or statements that best fit the present situation, and a dialog box pops up to enter the response into. To say any of the things in the menu to the Character, just enter the appropriate NUMBER of the selection into the dialog box, then hit ENTER or press OK.

To say/pick another of the listed menu selections and converse further, the player must re-enter talk to again (or use 'again' or 'g'), and the menu will reappear. The dialog box expects a numerical equivalent of the menu message.

It is the "ask" action that shows the dialog box and a messX action or cmess action that lists the text options...

The character will then respond (or not respond) in any way that they "want." (what you have decided how they react)

I should also add here that if player enters such a talk menu like this and then changes their mind, or doesn't see anything they want to say, they can always just hit the escape key (or click cancel), and be brought back to the standard command prompt again. Since the character has not said anything (and thus has not yet actually done something), the turns do not increase.

Conditions required:
answer=X$ - is answer obtained thru ask action = X$ ?
answer<>X$ - is answer obtained thru ask action not equal to X$ ?
flag conditions eg: flagX=Y

Actions required:
ask - invoke an ask dialog box and wait for input from player (response can be tested using 'answer=X$' and 'answer<>X$' conditions in Script 2)
flag actions eg: flagX=Y

Here is a simplistic example.

Example Response Coding (Julia is Character 1)
======================
[start]talk to julia#charpresent1[acts]cmess
1. Some text
2. Some more text
3. Even more
4. And another
5. Final text
Please enter 1,2,3,4 or 5.#pause3#flag30=1#ask[end]

You could print option texts in a different colour eg: red or blue

Example Script 2 entries
======================
[start]flag30=1#answer=1[acts]cmess.....whatever...#flag30=2[end]
[start]flag30=1#answer=2[acts]cmess.....whatever...#flag30=2[end]
[start]flag30=1#answer=3[acts]cmess.....whatever...#flag30=2[end]
[start]flag30=1#answer=4[acts]cmess.....whatever...#flag30=2[end]
[start]flag30=1#answer=5[acts]cmess.....whatever...#flag30=2[end]
[start]flag30=1[acts]cmessYou must choose a number from 1 to 5.#flag30=0[end]



Another method is: ask about , such as an item, or another character, or just a thing that they've mentioned before, or that you think they might know about. The thing to remember is to ask about a NOUN. You could make it so entering ask jeff about dragon, will result in Jeff telling you what he knows about the dragon (if he does indeed know anything about that). Typing ask jeff about getting out of here will get you nowhere.

With both talk and ask, characters could be made to remember things you've asked them, so they won't always give the same answer twice. Sometimes asking the same question repeatedly will give you more information or not as the case may be!

Hope this helps.

catventure

Hi Somnosa,

>>>I've been confident for my possible end results in the future because-- so I'm told-- I'm decent at writing, especially dialogue. But unfortunately, I'm starting to dread having to write the dialogue for my practice game because I am unsure of how to best approach it.<<<

Well - I hope you didn't find it too tough. Folks that used the 8bit game creators of the 80s would probably understand and master things quicker because I built the program to have a kind of retro feel to those authors and based it on some of the popular adventure writing utilities that were around at that time.

I tried to make the Editor easy to use so as to help the creator concentrate more on the storyline, plot and game mechanics.

As for writing text or writer's block; why not get AI to help produce some atmospheric text or flowery prose for your location texts, object examine or Character descriptions to put in your database?

Dialog between player and characters, can be kept brief and informative or helpful on how to proceed with a clue or hint etc.. Don't need to go overboard with that, remembering that it is an "adventure" and more about doing things, finding things and solving puzzles, making headway, scoring points and overcoming obstacles and avoiding death and whatnot that will make it exciting and memorable for the player. You can always put the rules for interacting with NPC in your game instructions readme file.

Regards,
catventure/Phil.

>>>Folks that used the 8bit game creators of the 80s would probably understand and master things quicker because I built the program to have a kind of retro feel to those authors and based it on some of the popular adventure writing utilities that were around at that time.<<<

Haha, I figured!  I'm lucky to have known someone who grew up in that time once who gave me some wisdom about such games, and that did give me a better idea of how these games are usually set up than I might have otherwise had.  Things must have been much harder back then when there was so much less storage space to fit cool game stuff in, I'm glad to have as much room as I want to write descriptions for things and responses from characters.

As for AI, well... as tough as it can be, the writing is one of my favorite parts of the process, honestly, so I'll stick to doing it manually.  That's one thing I find handy about text adventures-- they're an interactive story, so sometimes real novelists worked on them, and I can just work on the prose in my writing program without having to worry about text box overflow or cutoff later (since the whole game is a text box! ).  Not sure an AI could really match my intended vibe for the game's tone consistently, either; I like my occasional wacky moments, and I've heard of some people winding up with output that's on the predictable or tame side when they ask for an AI's help.  At the moment I'm just putting in placeholder text until I write full descriptions and responses to everything to copy-paste into the editor.

>>>Don't need to go overboard with that, remembering that it is an "adventure" and more about doing things, finding things and solving puzzles, making headway, scoring points and overcoming obstacles and avoiding death and whatnot that will make it exciting and memorable for the player. You can always put the rules for interacting with NPC in your game instructions readme file.<<<

That's pretty useful to hear.  It's easy for me to get overly ambitious when it comes to stories and games, even little ones.  I'm trying to start learning TAB with a pretty tiny game with pretty basic puzzles, so I guess I had some urge to make the character interactions more deep as a counterbalance...  Maybe some other time when I have a better handle on programming simple dialogue.  I'll already have my hands full writing just item interactions with all the characters!  I have some friends on hand who can help me playtest, so I'll also see what they try and do with the game's characters to see if it'd be productive to expand NPC interactions by much.  Including a format for talking to NPCs in a readme definitely sounds like the best option for now so I don't get overwhelmed with coding all the ways a player might try and fail to address them.  Thanks!

It's really great news to hear that you are planning a small test game and I really hope you enjoy planning and building it.
I was very happy to read your post today and am thrilled you have decided to take some time to experiment and see if you can convert your idea into a suitably effective parser text adventure.
Good luck with your efforts and please keep the forum posted about your journey making it!