New menu-based conversation system update

This is a discussion / support forum for the Hugo programming language by Kent Tessman. Hugo is a powerful programming language for making text games / interactive fiction with multimedia support.

Hugo download links: https://www.generalcoffee.com/hugo
Roody Yogurt's Hugo Blog: https://notdeadhugo.blogspot.com
The Hugor interpreter by RealNC: http://ifwiki.org/index.php/Hugor

Moderators: Ice Cream Jonsey, joltcountry

Roody_Yogurt
Posts: 2179
Joined: Mon Apr 29, 2002 6:23 pm
Location: Milwaukee

New menu-based conversation system update

Post by Roody_Yogurt »

For a long time, I've been trying to update Christopher Tate's conversation system to make it a bit more robust. It's a long ways off from it being pretty enough to upload as an official library contribution (actually, I'm not sure that day will ever come), but I think I've fixed some of its worst problems (that is, the problems introduced by my changes) and that it's ready to be shared. I'm sure I have lots of inefficient and redundant code in there and I probably broke some of the original functionality, but hopefully some of the new features are worth it.

Like the original, you can have top-screen conversation menus that allow you to interact with objects in the room normally as you talk to the NPC, but you can also do bottom-screen "Photopia-style" menus. Instead of using a bunch of arrays to keep track of characters, questions, and responses, this uses an object-based container system (one conversation object holds topic objects which, in turn, hold assertation objects). The current topic determines which assertations are available at any given moment.

Download it here.

In this zip file, there is a chat.hug file which is a working example, but I'll go over all of the main points here:

1. Besides including newconverse.g and newconverse.h, call InitConverse in the init routine, after the player global variable has been defined (" player = you" or whatever).

2. Rearrange the main routine so PrintStatusLine is run after events and other possibly game-changing calls, like so:

Code: Select all

routine main
{
	if speaking not in location : speaking = 0
	counter++
	run location.each_turn
	runevents
	RunScripts
	PrintStatusLine
}
3. Characters use the "npc" object class.

4. Set the game's chat options by replacing the "talkoptions" object and changing to your heart's content:

Code: Select all

replace talkoptions
{
	gNumAvailableAssertions 0 ! not to be changed
	gDidSpeak 0 ! not to be changed
	top 1 ! true if conversation menu on top of screen
	show_topics 1 ! show available convo topics?
	topic_change 1 ! allow topic changing?
	conv_force 0 ! force convo commands?
	auto 1 ! automatically switch topics when 1 is depleted?
	stop_undo 0 ! disallow undo-ing in a conversation?
	can_quit 1 ! disallow leaving a conversation?
}
Of course, certain option combinations work better than others.

5. So, topic objects go in the conversation object, and Assertion objects go in topic objects.

Assertion objects have a bunch of optional (and non-optional) properties-
only_npc - the assertion is only available for this character
menu_choice - how the choice is listed in the menu
menu_response - the character's response text
show_assert - (defaults to true) when this Assert is chosen, it is printed again with quotes around it, like the player just said it... before going on to print the response. You can set it to false when you want to change the line completely and just throw the entire thing into the menu_response field
pretext - text to go before the assertion is printed (example: "You say, ")
posttext - text to go after the assertion (example: " you ask sheepishly.")
needscomma - if true, takes the last character from menu_choice and turns it into a comma (so a "This menu is cool." choice could be turned into '"This menu is cool," you say.'

6. If you want an Assertion initially hidden (but 'unlocked' later), define it with the visited attribute but take it away when you want the option to show up.

7. Non-forced conversations can be exited by typing >END CONVERSATION, >STOP TALKING, or >SHUT UP. On the other side of things, if you want to stop a conversation in-progress, call DoStopTalk(1) (The 1 means it is called silently).

Well, that's it for now. If you have more questions, ask me or take a look at the Christopher Tate's original conversation library; it probably describes some things better.

Anyhow, like I said, it ain't pretty, and I don't expect people to have no problems with it but I think it could be just the thing for some people trying to get menu-based conversations into their games.

Roody_Yogurt
Posts: 2179
Joined: Mon Apr 29, 2002 6:23 pm
Location: Milwaukee

Post by Roody_Yogurt »

I've uploaded a new version. First off, the code should be somewhat cleaner. I took out some redundant routines, although there's still a little work that can be done on that front. I also changed the one global variable I was using to an array. If you define the constant UNDO_WORDS as a value larger than 1 before "newconverse.h" is included, it creates an array that number big and uses it to hold commands, so when the player types >UNDO, it says, "UNDOING >get axe" (or whatever).

If you don't define an UNDO_WORDS constant, it makes a 1-element array and uses it like a global variable, so when you have a game where it's possible to UNDO over a whole conversation, UNDO says, "UNDOing to before the conversation."

There's more optimization to be done, to be sure, but we're getting there.

Roody_Yogurt
Posts: 2179
Joined: Mon Apr 29, 2002 6:23 pm
Location: Milwaukee

Post by Roody_Yogurt »

Another new version. There was a pretty serious bug where games that didn't include "glk.h" weren't doing menus properly on official interpreters. I hope nobody ran into that. Also, I added some code from Future Boy! that hides the cursor (in official interpreters) while waiting for a keypress.

User avatar
RealNC
Posts: 2244
Joined: Wed Mar 07, 2012 4:32 am

Post by RealNC »

Roody_Yogurt wrote:Also, I added some code from Future Boy! that hides the cursor (in official interpreters) while waiting for a keypress.
That one always bugged me (seeing a blinking cursor when the game is waiting for a keypress). It's why I disabled the cursor by default in Hugor when not editing the command line. I wonder though if this could potentially break things. Are there any games that use single keypress input to implement their own command line editor?

Best would be if Hugo had a flag for this (enable/disable the cursor), though with Kent's current workload, future Hugo updates look grim.

Roody_Yogurt
Posts: 2179
Joined: Mon Apr 29, 2002 6:23 pm
Location: Milwaukee

Post by Roody_Yogurt »

RealNC wrote:That one always bugged me (seeing a blinking cursor when the game is waiting for a keypress).
Yeah, previously, the best I could do was use the "locate" command to try to hide the cursor in a corner somewhere. This gets to be a pain, though, when you are trying to write something glk-friendly, as locate doesn't work in the main window (since glk interpreters detect the main window as having some 30,000 lines).
RealNC wrote:It's why I disabled the cursor by default in Hugor when not editing the command line. I wonder though if this could potentially break things. Are there any games that use single keypress input to implement their own command line editor?
First off, I hadn't noticed that Hugor did this, but yeah, I see now that the cursor doesn't show up in non-main-window windows. Interesting.

I don't think anyone has used keypress stuff for anything other than skipping through movies (in Future Boy!) and menu navigation, but yeah, I can see how it could be used for something a bit more ambitious.
RealNC wrote:Best would be if Hugo had a flag for this (enable/disable the cursor), though with Kent's current workload, future Hugo updates look grim.
I'll pass this along. Just last night, Kent compared all of the ideas he has for "Hugo 4" as to having something in pieces on the floor of his garage. Between the little things I've mentioned (I don't feel like I've suggested so many things) and the larger things that'd help Hugo catch up with more popular languages, I think Kent has a lot to digest.

Plus, Kent has been writing, promoting, and supporting his screenwriting program, Fade In Pro ( http://www.fadeinpro.com/ ), for the last couple years (*and* he's been doing some more writing on the side), so it is just nice that he has Hugo on his mind at all.

But the good news is, yes, he does!

Roody_Yogurt
Posts: 2179
Joined: Mon Apr 29, 2002 6:23 pm
Location: Milwaukee

Post by Roody_Yogurt »

RealNC wrote:Are there any games that use single keypress input to implement their own command line editor?
I threw together a proof of concept of this last spring but forgot to say anything here. I do a "fake prompt" in the official release of The Halloween Horror. The code could probably be a bit more efficient, and the timing on my fake cursor could be better but I thought it was a good start. It's an interesting idea that could be useful in several future games.

Anyhow, the main reason I dug up this old thread is that I've made some more updates to the conversation system I started this thread for and thought I'd announce it here.

The latest version has nice UNDO-behavior options if you are using roodylib and a new "undolib" extension and is generally more consistent across different settings.

You (that is, anyone who wants to use it, not Nikos) can get it here: http://roody.gerynarsabode.org/hbe/newconverse.zip

And the latest version of roodylib here: http://roody.gerynarsabode.org/notdead/ ... _suite.zip

Post Reply