Oddly, this one’s entirely script based.
I was reminded of this when I watched one of Space Quest Historian’s videos, where he played the Space Quest 2 remake by Infamous Quests. Now, one thing he mentions about the version he plays in that video is that besides the narrator being muted so he can narrate it himself, well…
but recently Steve Alexander, who was one of the co-CEOs of Infamous Quests had a little peek around the old game files and decided to spruce it up a bit, fix some old bugs, add some you know, touch-ups here and there. Most importantly, at least according to him, replace the standard AGS font with something that looks a little more Sierra-ish. And that’s the version I’m going to play.
All well and good but then the main menu appeared and I noticed just how important this font thing seemed to be.
One thing immediately came to mind when I saw this. Notice how the button cuts into the caption? If I was a betting cat, I’d say the original version’s main font was just slightly shorter than this replacement. Also when I prepared the image I noticed each of these buttons has a different height, but that’s not the issue here — that’s just sloppy work.
This thing with the buttons cutting into the message text? It can’t happen accidentally in SCI0/1, but it can easily happen in SCI11. How is that?
In SCI1, the system scripts include a PrintD
function. It’s pretty powerful on the face of it:
(PrintD "Would you like to skip\nthe introduction or\nwatch the whole thing?" #at 100 60 #new #button "Skip it" 0 #new #button "Watch it" 1 #new #button "Restore a Game" 2 )
And that gives you this:
The function itself will track how large every item should be as they are defined, and adjust the final size of the window accordingly. Just to simplify the explanation a bit. And then it’ll return the value of a given button so the game knows how to react.
(Update: SCI0 had Print
which worked not entirely unlike this, and SCI1 added PrintD
as a more streamlined variant with #new
support, because…)
In SCI11, Print
is now an object. You have to call a bunch of methods on it, in sequence, then finish with an init:
call, and that will trigger its display and return the value chosen. But one important distinction is that addText:
, addButton:
, and its ilk… don’t automatically position themselves. You have to do that yourself.
That’s why these games came with a built-in dialog creation tool, among others. It’d create code like this:
; DialogEditor v1.0 ; by Brian K. Hughes (Print posn: 0 28, font: 0, addText: {bluh bluh} 71 18, addButton: 0 {button} 71 30, addButton: 1 {button} 0 0, init: )
The Sierra programmers could then integrate that into their game scripts. But importantly, those manually-positioned buttons could overlap other controls.
(Update: … PrintD
also had a dialog editor made for it. This is pretty explicitly stated in the changelogs.)
AGS dialog boxes also use manual positioning, just with a nice WYSIWYG form editor. So if you take a perfectly good (yeah right) introduction menu and change the font for one with a higher X-height and don’t adjust things… you get that SQ2 window.
Update just because: this is what the SQ4 intro menu would look like with font.001
instead. That is, with SCI1’s PrintD
and its automatic layout.