Community
General and Everything Else => Everything-Else => Topic started by: scott_furphies on January 19, 2021, 02:25:34 AM
-
Hi all,
I always wanted dialogue to be a big part of the SCI.0 game I'm working on. Initially I thought it would be cool to use the text parser for any dialogue sequence (Instead of INPUT the parser either reads "Action:" or "Say:" depending on whether you've initiated a conversation.) I got the idea from Space Ship Warlock (anyone remember that game?) where you would input fairly naturalistic dialogue into the parser ("Who is the captain?") ("What do you think about space pirates?")etc.
This was all before I found out about Heap memory restrictions so it's not like I can create a dialogue option for every imaginable topic relevant to the game. I'm considering implementing more of a dialogue tree like the one in Space Quest V, Gabriel Knight or Lucas Arts games. This would simplify things, maybe even streamline the gameplay a bit, where you're not constantly guessing what I thought was a good question to ask a character. Trouble is, it seems a tad inauthentic, and weird to keep switching to mouse in a mostly keyboard orientated game.
Also, dialogue choices can ruin the joke, if you already know the phrasing of the question before you ask it.
What are people's thoughts on this?
I'm so involved in the development of this project, when making a design decision I must ask myself, "is this fun?"
-
Also, dialogue choices can ruin the joke, if you already know the phrasing of the question before you ask it.
The Tex Murphy series had a nice solution to this. The dialogue choices only described the general tone of each option; the actual lines were at times unpredictable.
-
Heap is cheap, even in SCI0, if you put the text in Text resources and consider the script implementation carefully. Also, I'm with Iskovlun. As funny as it is to see an option "¿ɹǝɥʇoɯ ʎɯ noʎ ǝɹɐ .ǝɹɐqpɐǝɹɥʇ uıqqoq ɯ,ı" when the player is dazed and upside-down, the Tex Murphy solution seems funnier in a way.
-
This was all before I found out about Heap memory restrictions so it's not like I can create a dialogue option for every imaginable topic relevant to the game
That's what made me abandon my attempt to port Zork to SCI0. In my case it was allowing for inventory object interactions within the game that weren't scoped to a single room. It's really tough to keep the heap down when the desire is to allow for the player to be able do anything at any point in the game.
However, what you are trying to do may be possible. I did have a degree of success with dynamically loading scripts which handled Said()s and disposing of them as soon as they were unneeded (IIRC lots of Unload or DisposeLoad calls).
-
However, what you are trying to do may be possible. I did have a degree of success with dynamically loading scripts which handled Said()s and disposing of them as soon as they were unneeded (IIRC lots of Unload or DisposeLoad calls).
For future reference, this is what Regions and Locales are for. Locales are limited to handling Said statements I think, whereas Regions are more general.
-
Iskovlun
It's lskovlun... with a lower-case 'L'... aka Lars... :)
-
But that's what I wrote???
-
However, what you are trying to do may be possible. I did have a degree of success with dynamically loading scripts which handled Said()s and disposing of them as soon as they were unneeded (IIRC lots of Unload or DisposeLoad calls).
I have a feeling this is the solution I need. So far I've moved all of my dialogue scenes into separate (but identical) rooms you go into when you begin a conversation, where there's only dialogue interaction. This seems like a smarter way of implementing the same idea!
I was thinking of separating the dialogue into separate scripts (say have a "who is" script with all the possible characters, a "what is" script for every possible noun etc) it'd be a lot of work, but I think worth it. I like the 'dungeons and dragons' feel of the parser when it feels like the options are limited only by your imagination, so i think that's the way to go, time to learn a bit more about memory management...
I'll take a look at Tex Murphy and see what you mean about that...
-
But that's what I wrote???
You wrote with a capital "I" instead of a lower-case "l".
-
...goddamn, all this time 😹
-
For the record, l didn't notice this until OmerMor pointed it out.
-
...goddamn, all this time 😹
;D
-
I've decided to attempt a dialogue tree interface, if only to see if it's an improvement to the pacing / flow of the game
It functions fine, it's basically just buttons which direct to different states in the script.
The tricky thing is styling the thing so it doesn't look like total garbage. So far I've customised a few things, using a smaller font and vertical alignment for the buttons plus taking away all of the spacing to make it more compact. Also the directional keys for selection when choosing dialogue options.
Is there a simple way to take away the button borders of the deselected options, kind of like in the inventory?
Also I've been looking for a way to align the button text to the left rather than centered?
-
Is there a simple way to take away the button borders of the deselected options, kind of like in the inventory?
Also I've been looking for a way to align the button text to the left rather than centered?
Both of these could be done by using custom buttons. Make your own (class CustomButton of DButton and give it a Draw method. You should now be able to draw the button any way you want, using the ns____ rectangle for positioning.
-
Thanks Kawa, I'm trying to get my head around this, if there was an area of the documentation which explains this it would be most helpful!
Would I call these custom buttons as I would in a print statement? eg: =button Print("" #CustomButton "And then I said that's not a chicken!" 1)
-
No. The #button thing is just a number that Print recognizes. It has no inherent meaning of "place a button control", that's just how Print reacts to it.
I'd rather make my own dialog box, put whatever control I want in it, like custom buttons. Think of the save/restore window, for example.
-
Y'know, I've stared at my janky button interface for so long that I've learned to love it.
I may change my mind if I can ever get my head around customising buttons.
-
If you want something like the inventory code, why not use the inventory code?
-
I like the look of the inventory when you're selecting items, with only the highlighted option getting a border. Also, I expect having some more generalized code to handle this would be less of a headache, if I could get it to work.
I'm pretty new to coding, and I've spent a lot of time trying to pick apart the inventory to no success. I might come back to this later. At the moment I'm enjoying writing fun dialogue trees - so I'm satisfied with my shitty looking buttons for now.
The dialogue tree is definitely the way to go over parser based conversation, dialogue being kind of an in-game hint system, the story has better momentum.
-
Studying the SCI0 inventory window, it seems the item labels are DText objects. How interesting then that they act not unlike buttons.
Looking at the original LSL3 code, there's a description for DText: "A non-editable, generally non-selectable text field." Emphasis mine. And indeed, when the invDialog generates the list of DText elements representing your current inventory, it sets their state to (| csENABLED csEXIT), or (| dActive dExit) as Sierra liked to call it. You can't normally click on a text label because they don't have those state bits set. Now, DText don't do anything to draw themselves, leaving that to their super, DItem. Checking the SCI11 code, text controls are first drawn as usual, then if the control has the "selected" state and is not a field, list, or icon, it's framed. That's a match.
So that's the basic jist behind the inventory window's "buttons without borders". The exact same trickery applies to SCI11's "get items" debug cheat window.
Now, when a Dialog's doit is called, it'll return the value property of the selected control, which in this case is either a pointer to an inventory item or 0 (the "OK" button's implied default value). And since invDialog is itself a subclass of Dialog, it can provide its own doit, which doesn't actually close the window until "OK" is chosen.
What I'd do for the sake of having a "general use" window in this sort of style, is to copy the whole definition for invD/invDialog, give it a data property, and instead of having it iterate gInv/gInventory, you have it iterate whatever List or Set that data property points to. Remove the "OK" button and the whole repeat block -- just memorize what the super's doit returned, dispose of yourself, and return what you memorized.
-
Thanks, Kawa!
I'll have a look into this next time I have a block of free time, and I'll let you know how I get on!