XPost: rec.games.int-fiction

I have been writing Part II of Game of XYZABCDE in Glulx, as a text
adventure game (Part I is with ZZT instead). Even though I have more time
now, I will still need to think of what locations and that stuff to put;
that is the difficult part, and programming it is the easy part. (That is
the opposite to some people, who find it difficult to program but know
all of the story and stuff they want.) But, I will explain what I am doing here, both the technical aspects and some ideas about story and puzzles.
I may post more once I am requesting some testing; so far there isn't
really enough for that, though. There is also an article in IFWiki about
this game, including download links.

This game is a sequel to a ZZT game called XYZABCDE.ZZT. In that game
(Part I), your wing suddenly broke while flying to Mornington Crescent,
and now fell down and got badly injured, but this is ZZT, so there are
magic diamonds to help you. You have only: a broken wing, an unloaded
gun, and no tea. If you like ZZT, then you can try to play that game.

In Part II (the game being described here), Giants Who Hate Liberty Bell
Match stepped on the operetta house and even though you were hiding, you
fell down anyways, but your wing didn't break so you can slow your
falling. But many of your possessions broke, although some are intact.

Some of my ideas about puzzles and other stuff in the game includes:

* Some puzzle that if solved, the game is unwinnable. This is not
necessarily direct, for example: If you break the mirror, then you can
collect the shards, which can be used to achieve something else, but you
need the mirror intact for another purpose in the game, so if you break
the mirror then the game is unwinnable. There could be other possibilities
to implement such a thing too; this is just one possibility.

* Some puzzle involving computer cards. You could rearrange them, and
add additional holes, but cannot remove holes that are already there. You
could also omit some cards. If you put cards that already have holes in
the card punch output of the computer, then it just adds more holes.

* You may have to fly into some place to do something before carrying
something that it is too heavy to fly into there, or vice-versa.

* Puzzles and other scenarios do not necessarily exist in one location.
They may be found in diverse locations and, possibly with remote controls, surveillance cameras, radio, etc. You might also find an item which is
used far away from some other place. And some scenarios may interfere with
each other, and some things in one location may be used for multiple
purposes, some there, some elsewhere, or a puzzle may need to be solved in
two different ways in two different scenarios.

* The source code include a file with some more ideas.

I have started making a map on a paper, and have added those locations
into the game, but I just added a few locations so far, and I have not put
in what is in there, so far, yet.

I can also mention some programming tricks of Glulx. These explanations
are using my own Glasm syntax, and not the Inform syntax.

Here are a few uses of some instructions:

* You can write "ushiftr 1,$,$" to change 1 to 0 and other numbers to 1.

* You can use linkedsearch to find if one object is inside of another one
even though not necessarily directly inside of the other way. Another use
of linkedsearch is to find what room the player is in, if you designate
rooms by setting the LOC slot to zero (like I do); you can then display
the room title in the status window.

* With the object format described below, which is similar to that of Z-machine, linkedsearch can also be used to find where an object is listed
in the FIRST-NEXT chain, in order to remove it.

* You can use linearsearch to find the length of a null-terminated string.

For objects, I am using the following format:

* Flags (3 bytes): Bit flags with various meanings. Flag 7 is unusable,
because the CallP subroutine uses it to check for the existence of a Glulx object (string or function).

* Number of properties (1 byte): An object can have up to 255 properties.

* NEXT slot (4 bytes): Pointer to next sibling object, or 0 if none. This
is like the NEXT slot in the Z-machine. For rooms, these four bytes store additional flags instead, since rooms don't have siblings.

* FIRST slot (4 bytes): Pointer to first child object, or 0 if none. This
is like the FIRST slot in the Z-machine.

* LOC slot (4 bytes): Pointer to object this one is in, or 0 if this
object is a room (or removed from the game). This is like the LOC slot
in the Z-machine.

* Prototype (4 bytes): Prototype object, or 0 if none. If a property is
not found in an object, it looks in the prototype, and going through the prototype chain until it finds one or there are no more prototypes left.
Note also that NEXT/FIRST/LOC slots are not used for objects which are
used only as prototypes, so global variables are stored there instead.

* Properties: Each property consists of the four byte value, followed by
the one byte property number, stored in order (so a binary search works).
The benefit to doing it this way is to avoid doing extra arithmetic. The
start address is the beginning of the object header, the key offset is 24,
and then aload can be used to load from index 5 of the returned address
of where it has been found.

* Noun phrases: Noun phrases are then stored after the property list for objects that have noun phrases. Look at the source code for the details
of the format of the noun phrases list. Of note here is that each noun
phrase has a priority number, and priority may also be added by context;
if there are multiple matches, the priority is used to disambiguate.

Note also that the linkedsearch opcode can be used to find the room that
the player character is in, even if the player character is also inside
of another object in that room; another use of linkedsearch is to check
if one object is anywhere in the prototype chain of another object.

The player character in this game can fly (as long as you are not carrying
too much to fly), so in order to avoid having to double the number of
rooms, in many cases where you can fly above a location but there isn't anything special about flying above it, instead there are a few special
rooms and prototypes to deal with this default case (see proto.asm for
details about how this works).

Directions are also given numbers, which are used both as property numbers
and as flag numbers, and there are actually two sets of direction numbers,
one for normal directions and one for flying directions. The directions
are numbered such that you can XOR by 1 for the reverse direction. Also,
all directions other than up and down fit in one byte. This means that it
can copy the flying direction flags from one room into the normal
direction flags for another room (specifically, R.FlyingAboveRoom).

Another note about CallP is that the first four bytes of the header are
all going to be less than 128, so CallP can be used with constants from 0
to 3, in addition to subroutines that calculate the value. (If you do not
need to calculate the value, then GetP can be used instead.)

Also, this game is public domain, so you are free to use any part of the
code or anything else in your own game if you want to do so. This is true
of the entire series; I intend all of the games in the series to be public domain, and to use different VMs and/or game styles for each one if I can.

The game so far (which unfortunately isn't very much; I don't know if I
will have made more by the time you read this) can be downloaded from:
http://zzo38computer.org/xyzabcde/2.zip

You can download a source code archive from:
http://zzo38computer.org/xyzabcde/2src.zip

(You can use curl or wget to download these files)

Please mention whatever comments you have. I may post some more later once
I have more to write, such as if I have implemented some more stuff later (although probably not with every change; only major ones, I think).

--
This signature intentionally left blank.
(But if it has these words, then actually it isn't blank, isn't it?)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)