[Inform] Do new compass directions need common properties; 3D environment
MCYH
Thanks for answering my previous questions. Here's another one!
The Designer's Manual (4th ed.) mentions that creating a new compass
direction (ie. more than the 12 standard compass directions) requires
a direction property, and "this property needs to be declared as a
'common property', partly for efficiency reasons, partly because
that's just how the library works." (paper p.439, Acrobat p.449)
The example given is:
Property xyzzy_to;
CompassDirection xyzzy_obj "magic word" compass
with name 'xyzzy',
door_dir xyzzy_to;
My game is in a 3-dimensional environment, and I'd like to include
commands like 'nwu' (northwest up) or 'ed' (east down). The trouble
is, this requires the declaration of 16 more common properties:
Property nu_to; ! north up
Property neu_to; ! northeast up
Property eu_to; ! east up
Property seu_to; ! southeast up
Property su_to; ! south up
Property swu_to; ! southwest up
Property wu_to; ! west up
Property nwu_to; ! northwest up
Property nd_to; ! north down
Property ned_to; ! northeast down
Property ed_to; ! east down
Property sed_to; ! southeast down
Property sd_to; ! south down
Property swd_to; ! southwest down
Property wd_to; ! west down
Property nwd_to; ! northwest down
Inform allows 63 (or 62?) common properties, but most are taken by the
library. I tried editing linklpa.h and commenting out some library
properties, but this caused errors during compilation.
So my question boils down to: do these direction properties need to be
common? And if so, then is there some alternative method to coding
these 3D compass directions?
Thanks, (and have a nice Christmas holiday).
Cheers,
Michael.
David Welbourn
> My game is in a 3-dimensional environment, and I'd like to include
> commands like 'nwu' (northwest up) or 'ed' (east down). The trouble
> is, this requires the declaration of 16 more common properties:
>
> common? And if so, then is there some alternative method to coding
> these 3D compass directions?
I gotta tell ya, my first ten or twenty thoughts on after reading this were
variations on "do you really wanna do this?" sprinkled with various quibbles
like "'east down' isn't a proper name for a direction" and "are you saying
that most games up until now are in 2D?" and "what are the room descriptions
gonna look like?" and "[What down do you mean, the down, the north down,
etc.]" and so forth. But I eventually pushed most of that aside and thought,
well, how would I do it?
First, I'd rename the new up directions to "upper north", etc. and the new
down directions to "lower north", etc.
Second, I'd create new grammar lines for new GoUpper and GoLower actions,
that neatly parallel the basic Go action. So a "go upper west" command would
generate a GoUpper action in the w_to direction instead of a Go action in
the uw_to direction. That way, there's no new properties at all.
Third, in the rooms that need them, use if-statements that test if action is
equal to ##GoUpper or ##GoLower or ##Go as appropriate.
Now, I don't know for sure if any of that'll really work, especially if
there's more than just the Go action to worry about. My own grasp of Inform
is still rather shaky. But it's an idea, at least.
-- David Welbourn
Adam Biltcliffe
MCYH:
> My game is in a 3-dimensional environment, and I'd like to include
> commands like 'nwu' (northwest up) or 'ed' (east down). The trouble
> is, this requires the declaration of 16 more common properties:
...
> So my question boils down to: do these direction properties need to be
> common? And if so, then is there some alternative method to coding
> these 3D compass directions?
The library requires direction properties to be common so that it can
test, for example, location.n_to without worrying about this producing
an error. I assume it would be possible to Replace all the relevant
routines in the library which do this with ones which first check using
an 'object provides' test and remove the need for direction proerties to
be common. An initial skim through the library suggests that all you'd
need to Replace is GoSub, but I could be wrong.
jw
MCYH
Adam, which part of GoSub were you referring to?
[ GoSub i j k df movewith thedir old_loc;
if (second ~= 0 && second notin Compass
&& ObjectIsUntouchable(second)) return;
old_loc = location;
movewith=0;
i=parent(player);
if ((location~=thedark && i~=location)
|| (location==thedark && i~=real_location))
{ j=location;
if (location==thedark) location=real_location;
k=RunRoutines(i,before); if (k~=3) location=j;
if (k==1)
{ movewith=i; i=parent(i);
}
else
{ if (k==0) L__M(##Go,1,i);
rtrue;
}
}
thedir=noun.door_dir;
if (ZRegion(thedir)==2) thedir=RunRoutines(noun,door_dir);
j=i.thedir; k=ZRegion(j);
if (k==3) { print (string) j; new_line; rfalse; }
if (k==2) { j=RunRoutines(i,thedir);
if (j==1) rtrue;
}
if (k==0 || j==0)
{ if (i.cant_go ~= 0) PrintOrRun(i, cant_go);
rfalse;
}
if (j has door)
{ if (j has concealed) return L__M(##Go,2);
if (j hasnt open)
{ if (noun==u_obj) return L__M(##Go,3,j);
if (noun==d_obj) return L__M(##Go,4,j);
return L__M(##Go,5,j);
}
k=RunRoutines(j,door_to);
if (k==0) return L__M(##Go,6,j);
if (k==1) rtrue;
j = k;
}
if (movewith==0) move player to j; else move movewith to j;
location=j; MoveFloatingObjects();
df=OffersLight(j);
if (df~=0) { location=j; real_location=j; lightflag=1; }
else
{ if (old_loc == thedark)
{ DarkToDark();
if (deadflag~=0) rtrue;
}
real_location=j;
location=thedark; lightflag=0;
}
if (AfterRoutines()==1) rtrue;
if (keep_silent==1) rtrue;
LookSub(1);
];
Adam Biltcliffe
MCYH:
> Thanks for your comments, everyone.
>
> Adam, which part of GoSub were you referring to?
>
> j=i.thedir; k=ZRegion(j);
> if (k==3) { print (string) j; new_line; rfalse; }
> if (k==2) { j=RunRoutines(i,thedir);
> if (j==1) rtrue;
> }
Completely untested, but the above lines seem to be the only necessary
ones to change. Simply replace the first line with:
if (i provides thedir) {j=i.thedir; k=ZRegion(j)} else {j=0; k=0}
jw
Daniel Dawson
Huge maze
You are in a maze of big, twisty passages, all alike. There are exits leading
in all twenty-six directions!
--
Daniel Dawson
dda...@nospam-altavista.net (remove 'nospam-' to send mail)
Robotboy8
human brain?
--
Sanity is a sure sign of a lazy mind.
MCYH
> Wasn't there and example AGT file of such a "3d" game revolving around the
> human brain?
I think you're referring to Brainscape, but it was coded in Pascal. It
uses anatomical directions (rostral, caudal, ventral, etc.) instead of
compass points for travel.
Baf's Guide: http://www.wurb.com/if/game/33
It's quite appropriate that you mentioned this particular game, since
the reason why I wanted 3D directions in the first place was for a
human anatomy game, where you could go from place to place in the
body, a lot like Brainscape.
Michael.
Mark J. Tilford
Brainscape was later rewritten in AGT.
--
------------------------
Mark Jeffrey Tilford
til...@ugcs.caltech.edu