Hi guys,

I thought I'd let you know that I'm writing a new game for the Commodore PET/CBM series, which will be a texty (or 'interactive fiction') game. I can't tell you too many details as - rather oddly - I'm under an informal NDA at the moment, but I can say that my target machine is the original 2001 4k PETs. I'm having a little bit of difficulty in fitting all of the locations, but I think I've found a way of saving 6 bytes and I might need to drop the title screen. What I might do, once it's finished, is have an '8k and above' version with the glossy extras like a title/welcome screen and proper 40-column formatted text.

The adventure engine should mean that it's a fast 'home-made' adventure game. My one complaint about games of this nature is that they're too slow, simply because they're programmed in a way that tests a load of conditions that don't need to be tested because you're in the wrong location.

Anyway, when it's released, I'll let you know.

Regards,

Shaun.

     Oooo, a new game!  That would be very interesting.  Would it be a commercial, shareware, or free product?

            Writing from the Portland, Oregon area,
            Robert Bernardo
            Fresno Commodore User Group
            http://videocam.net.au/fcug
            The Other Group of Amigoids
            http://www.calweb.com/~rabel1/
            Southern California Commodore & Amiga Network
            http://www.sccaners.org

Basic or machine code? I used to do a few homemade adventures and picked up a rather compact way to represent the map in DATA statements. Of course as you want to read it into an array, the compactness is lost at that point. Or maybe you will utilize a floppy drive - relative files? - so you don't need to keep all the game data in memory at once.

It's a single load written in Commodore BASIC and has 12 locations, six objects, and 9 commands. I have about 250 bytes left to play with and the only command I've not implemented is the 'use' command. I may be able to fit the 'secret' location in yet as that only takes up around 60 bytes. It all depends on how I implement use.

I've found a lot of ways to save bytes, and I'll post the program when it's finished. If anyone can find a more efficient way of doing things then I'd be very interested.

Regards,

Shaun.

I can give away my "secret" right away.

Assume you have rooms 1, 2, 3 ... 19, 20. Usually when you define the map, the DATA statements look something like this:

10 DATA1,"THE LABORATORY",2,0,3,0,0,0
15 DATA2,"THE HALL",0,1,14,0,15,0
20 DATA3,"THE KITCHEN",0,0,0,1,0,0
etc

It would visually give us this map:
#  ___
# |   |
# | 15|
# |_UP|
#  _|_   ___
# |   | |   |
# | 2 |-| 14|
# |___| |___|
#  _|_   ___
# |   | |   |
# | 1 |-| 3 |
# |___| |___|
#

where each data statement consists of room number (perhaps not required), a description and integer numbers telling to which room you will be able to move. You will read all this into floating point or at least integer arrays, representing all data twice. In order to pack data somewhat, you can introduce an invalid room number -1 which means "end of room description" instead of filling up the DATA statements with trailing zeroes for all directions (north, south, east, west, up, down, in, out, special?) you can not move to.

The method I used instead was to convert integers to ASCII characters, using an offset like CHR$(33) # for room 0:

10 DATA1,"THE LABORATORY","%#&"
15 DATA2,"THE HALL","#$1#2"
20 DATA3,"THE KITCHEN","###$"

Indeed it means the routine which initially reads the DATA statements need to parse these map strings character by character which adds some overhead to the program. For a very small map it probably is not worth the trouble, but I found that for a somewhat complex map of 30-40 rooms and the ability to move in many different directions, in the end I would save perhaps a few hundred bytes at least.

As a bonus, anyone breaking into your program to LIST it and take advantage of the map will have a hard time parsing the DATA statements as they don't say clearly which room links to what.