Turns out my newmenu extension still has some annoying deficiencies. In the thought-I-fixed-that-but-if-so-I-lost-the-updated-code department, it turns out that my latest version wasn't clearing the screen enough when menus are initially opened or when options are selected. Fixing it ended up being a bit more complicated than I figured- and I'm not yet sure I've found my optimal solution- because, depending on the interpreter and the speed of the computer, clearing the screen (or "window 0") can cause text flicker which just annoys me for whatever reason. I'm trying to optimize it so only necessary text is cleared, allowing for as little flicker as possible.
Two of my WIPs are either entirely or partially driven by a
>GO TO [room] mobility system. The second one, which I just recently started working on, got me thinking that I should turn the idea into an extension (or at least a page on
Hugo by Example). I haven't really perfected anything, but I'll share what I've got so far.
First off, before "hugolib.g" is included, I declare some new >
GO grammar:
verb "go", "walk"
* DoGo
* "to"/"in"/"into"/"inside"/"through" anything DoGoTo
* "out" object DoGo
* "out"/"outside" DoExit
* anything DoGoTo
Now, since we're going to be giving rooms noun and adjective properties, making them refer-able, we'll replace the room class with something that redirects a lot of actions:
replace room
{
type room
is static, light, open, known
before
{
object
{
if verbroutine = &DoGo, &MovePlayer,&DoLook, &DoGoTo
{
return false
}
object = 0
Perform(verbroutine)
return true
}
object DoLook
{
Perform(&DoLookAround)
}
}
}
EDIT: It turns out the above is really bad code, as lots of verb routines (like DoGet) expect to have an object value, so Perform-ing them with no object actually makes you pick up the nothing object (and so on). Here is some better code (although it's kind of "blunt force"; maybe there's a more elegant solution):
replace room
{
type room
is static, light, open, known
before
{
object
{
if verbroutine = &DoMove,&DoGet, &DoDrop, &DoPutIn,
&DoEmptyOrGet, &DoGive, &DoShow, &DoWear, &DoTakeOff,
&DoEat, &DoDrink, &DoHit, &DoLookThrough, &DoLookUnder, &DoExit
{
"I didn't understand you. Try being more specific."
return true
}
elseif verbroutine = &MovePlayer,&DoLook, &DoGoTo
{
return false
}
elseif verbroutine = &DoGo, &DoEnter
{
Perform(&DoGoto, self)
return true
}
object = 0
Perform(verbroutine)
return true
}
object DoLook
{
Perform(&DoLookAround)
}
}
}
We'll also make an "exits" property that keeps track of which rooms are available from other rooms (in this game, >GO TO just works room-to-room; this is not intended to be a Magnetic Scrolls type >GO TO scenario).
property exits
Now, our DoGoTo routine:
routine DoGoTo
{
if object = location
{
"You're already there!"
return false
}
if not FindObject(object, location)
{
if object.type = room
{
if InList(location,exits,object)
{
return MovePlayer(object)
}
else
{
if not location.cant_go
{
"You can't go that way."
}
return false
}
}
}
return Perform(&DoGo,object)
}
A "here" object to redirect things like >GO TO HERE to the current location:
object here_object "here"
{
noun "here"
before
{
object
{
Perform(verbroutine, location)
}
xobject
{
Perform(verbroutine, object, location)
}
}
in_scope you
is known
}
An example room:
room STARTLOCATION "Start Location"
{
adjective "start"
noun "location"
exits pond, barn
}
So, that's basically it. An issue: one of the things my code does is make every room known so that MovePlayer works. If you still want a sense of discovery in your games, you could have DoGoTo automatically make rooms listed in the exits property known (so that rooms
2 connections away might still be a mystery).
Anyhow, I don't think the code is ready for HbE yet, but I thought people might find it interesting just the same. Plus, hey, this blog needs all of the posts it can get.
