Planet Bob

What are the controls for the C64 Gateway to Apshai? I can't figure out how to attack anything

Use the F7 key to select the FIGHT mode, the F3 key to access the SELECT ITEM mode and the F5 key to cycle through all other actions

Thanks.

Well, Hunt The Wumpus (Trogdor's) seems to handle this pretty well. How many objects are there that one can discover during play? Assign one bit to each object or group of objects that will be discovered simultaneously. If the bit is set, the objects have been discovered. If not, they haven't.

 

One thing that can be done with this approach (how well depends upon the game) is to have a pool of up to, say, 16 objects which can be 'live' at any given time. Until an object is discovered, the only memory associated with it is the bit that says whether it's been found yet. Once the object is discovered, its bit is set and it's added to the pool of live objects (there needs to be some sensible means to jettison the least important object in the pool). If each live object takes four bytes and there are 128 objects total to be discovered, that would require 80 bytes for the 'found yet' bitmap and the 'live object' storage.

I've been playing some Gateway to Apshai lately, trying to see if I can get into it to give me some motivation continuing with a 2600 port.

It's been a while since I've played Apshai on the XE, but I've also thought about how to a do game like Apshai or Fargoal on the 2600.

 

What one does not notice at first, is how essential an element it is, that you have to uncover your surroundings bit by bit in this game. With every step forward you make, you never know what is hidden underneath the next corridor bit until you enter it. Be it some kind of treasures, equipment, potions, or any other goodies, be it some dangerous'n'deadly enemy lurking there waiting to kill you.

 

I've been trying to find a solution for this, but I can't think of any really elegant way of realizing this "feature" on the VCS.

 

One can replicate most of the game, even with 128 bytes of RAM. Instead of generating the dungeons live out of a seed, one can pre-render a certain number of labyrinths and put them into ROM. Same goes with monster and item positions, even doors - considering one finds a way to display them.

 

But, giving the player this original "explorational suspense", I have no really good idea of how to achieve this effect. I think to do it properly and effective, it'd require the RAM buffering of a whole dungeon, just like the original does, requiring at least some 2K.

 

One could possibly define a list of "uncover" squares for a whole dungeon, then just storing single bits wether that square was already uncovered or not.

 

Then, making it a superchip solution: Considering the display would consist of 4 PF1/PF2 columns, 32 byte high each. One could then ROM->RAM copy the actual screen window each frame, and possibly render the then visible parts of still to-be-uncovered squares back into "void" in a second pass.

 

That might work. Maybe.

That's exactly the way I was thinking of doing it-- having some preset mazes in ROM, then you could select among them randomly so the levels wouldn't always be the same, and when you start a new game you can save the maze numbers for each level (e.g., level 1 uses maze 20, level 2 uses maze 152, level 3 uses maze 7, etc.) so the levels aren't selected randomly each time you revisit a level in the same game. The Superchip RAM would be used for actually displaying the maze, starting out with all the bits turned off, then you set each appropriate bit of RAM to match the ROM bits as you move around and uncover each square of the map. The objects-- stairs, pools, altars, enemies, etc.-- would be done with players, missiles, and the ball (but one of those would be used for the hero). Uncovering the objects or enemies could either be controlled by the shape data (i.e., all 0s for invisible objects, or set the shape for a visible object), or else you could go ahead and set the shape but use colors to control visibility (i.e., the sprite color would be the same as the background color if it's invisible, or different than the background if it's visible). I was thinking of using some of the Superchip RAM bits to store whether each object had been uncovered yet. Also, the Superchip RAM could be written to the Memcard or whatever it's being called now, to save the status of each level, and then the data for a previously-visited level could be read from the Memcard (as the player goes from one level to the next), so that the uncovered portions of a previously-visited level wouldn't be "lost."

 

With 128 bytes of Superchip RAM, you can use 5 bytes per maze row-- 1 byte for the PF0 (one nybble for the left copy, and the other nybble for the right half), and 2 bytes each for PF1 and PF2, to get an asymmetrical playfield. Dividing 128 by 5 gives 24 rows (120 bytes), with 8 bytes left over for the sprite visibility flags (up to 64 sprites on each level, 1 bit for flagging each sprite's visibility status). I was thinking of using 7 scan lines per row, because I think that should make the playfield pixels look more squared than using 8 scan lines (or 6 scan lines). That would give 168 scan lines for the whole maze, leaving 24 scan lines for displaying other information (e.g., a score, or other stats, or even a few rows of text describing events, e.g., "You've fallen into a pit!")-- or even more than 24 scan lines, if you're using more than 192 active scan lines.

 

Here's a short program I did in bB a little over a week ago, just as an experiment, although it doesn't include any movement, sprites, or actual uncovering of the maze. Instead, it simply (for the moment) has a maze stored in ROM, copies the bits of the ROM maze into Supercharger RAM (before falling into the kernel), and then draws the playfield from the data in Supercharger RAM. I don't even have a proper maze yet, just a partial maze-- and not even a very good one, just something I "doodled" to help me see the kernel in action. Also, I drew the maze in the code in the "normal" fashion to make it easier to type the 1s and 0s, and then I flip the bits around as needed when I'm loading the ROM data into RAM. So I don't know if you can go so far as to call this a "proof of concept" yet, just a very rough beginning.

 

I was thinking of using this idea to make a game called "Dungeon Crawler," but then I found out that that name is already taken! So I thought of "Dungeon Crawl," or "Dungeon Brawl," but I got Google hits on those phrases, too-- so I chose "Crawl 'n' Brawl"! I guess I can't post attachments in this reply to a blog entry(?), so I'll have to post them in a forum.

 

MR

Hi John!

 

How many objects are there that one can discover during play?

 

AA board member Kroah recently reverse-engineered the whole game. Part of his findings he used to create a map generator Utility, which'll reproduce any of the 128 maps used in the game, as well as any other map using one of the 128 unused seeds. His incredible work is what sorta triggered me again, as in the past I ususally lost interest in doing the reverse-engineering.

 

Here is a screenshot of a complete map of a game level. Speaking in A8 terms, I think it's 4 full screens wide and 3 high: http://bringerp.free.fr/RE/Gta/Images/Map.png

 

Do you recognize the dark gray lines? Those are the "uncovery zone" borders. They're invisible during play of course.

 

My counts for this map are:

 

30 items/treasures

16 monsters

9 doors

61 uncovery zones

 

The A8 has an easy living task here regarding sprites BTW, as it does all non-monster things with redefined chars, not sprites.

 

Looking at this, I think one can optimize the zone checks, when having a list of the top/bottom/left/right neighbours of each zone. Then one can quickly check the four zones adjacent to the zone the player is in at the moment, not needing to check _all_ 60+ zones for one single rendering.

 

That's really going to be very interesting to make fast enough, since even with SC RAM it is impossible to double buffer the screen, i.e. the complete ROM-RAM copy of almost 128 bytes, plus all uncovery checks, plus voiding the unvisited zones - must all happen in a single frame!

 

Also, I don't think the game can ever look as good as my old demo screen:

 

For this screen I already need 256 bytes of data. I've no clue how to pack the tri-state data for this image (wall/floor/void) into 128 bytes only...

 

That is unless I swap the void look with the wall look. Then I can render the screen reading 128 bytes from ROM and 128 from RAM:

 

The ROM holding all-uncovered data:

Wall: 1

Floor: 0

Void: 0

 

The RAM holding un/covered data

Wall: 1

Floor: 0

Void: 0/1

 

This'd result in solid walls and clear floors & uncovered zones, plus striped covered zones.

 

Ok... my daughter just woke up. Answering your post later, Michael

Ok, created a screen half & half:

Seems it's not as bad as I thought

Uncovering the objects or enemies could either be controlled by the shape data (i.e., all 0s for invisible objects, or set the shape for a visible object), or else you could go ahead and set the shape but use colors to control visibility (i.e., the sprite color would be the same as the background color if it's invisible, or different than the background if it's visible). I was thinking of using some of the Superchip RAM bits to store whether each object had been uncovered yet.

 

Ah, ok. So you would track everything "live" all the time? I like Johns idea of having only a select few things "activated"

 

Here's a short program I did in bB a little over a week ago, just as an experiment, although it doesn't include any movement, sprites, or actual uncovering of the maze. Instead, it simply (for the moment) has a maze stored in ROM, copies the bits of the ROM maze into Supercharger RAM (before falling into the kernel), and then draws the playfield from the data in Supercharger RAM. I don't even have a proper maze yet, just a partial maze-- and not even a very good one, just something I "doodled" to help me see the kernel in action.

 

How much time does the plain copying procedure require?

 

Also, I drew the maze in the code in the "normal" fashion to make it easier to type the 1s and 0s, and then I flip the bits around as needed when I'm loading the ROM data into RAM. So I don't know if you can go so far as to call this a "proof of concept" yet, just a very rough beginning.

 

I'm sure writing a generator in C will help this a lot

 

I was thinking of using this idea to make a game called "Dungeon Crawler," but then I found out that that name is already taken! So I thought of "Dungeon Crawl," or "Dungeon Brawl," but I got Google hits on those phrases, too-- so I chose "Crawl 'n' Brawl"! I guess I can't post attachments in this reply to a blog entry(?), so I'll have to post them in a forum.

 

Please do so, yes! I'd like to see it!

 

Good to know someone is working on something similar, so we can exchange ideas and tricks

I was thinking of using some of the Superchip RAM bits to store whether each object had been uncovered yet.

Ah, ok. So you would track everything "live" all the time? I like Johns idea of having only a select few things "activated"

I was thinking of the second approach I mentioned-- using colors-- and just displaying the objects on the screen whether or not they're "uncovered." Then the object's bit flag would control whether the object's color matches the background ("invisible") or uses its normal color ("visible"). An advantage of doing it this way is being able to have collisions with "invisible" objects, like stumbling upon hidden treasure or triggering a hidden trap.

 

it simply (for the moment) has a maze stored in ROM, copies the bits of the ROM maze into Supercharger RAM (before falling into the kernel), and then draws the playfield from the data in Supercharger RAM.

How much time does the plain copying procedure require?

In the little test I did, I copied the ROM maze to RAM before ever getting into the kernel, so that's not a good example. In an actual game, the ROM would be copied to RAM only as needed-- i.e., when a new level begins, the bits of the RAM map would be cleared. Then during game play, only the bits for the area immediately around the player would be copied from ROM to RAM, so that the maze would be uncovered as the player moves around. You don't need to copy the entire maze each frame, since once a bit has been copied to RAM, it will stay set-- so you're only updating a small portion of the maze during each frame.

 

Also, I drew the maze in the code in the "normal" fashion to make it easier to type the 1s and 0s

I'm sure writing a generator in C will help this a lot

Actually, writing a generator in C would hinder a lot, since I don't know C very well! But I could do it in FreeBASIC very easily.

 

I guess I can't post attachments in this reply to a blog entry(?), so I'll have to post them in a forum.

Please do so, yes! I'd like to see it!

The little test program I did isn't much to look at, since it only draws an incomplete map from RAM, and right now the very essential "uncover as you go" function hasn't been added. I'm actually in the middle of another project, and then I need to resume work on "Sudoku," so I don't know when I'll have much time to return to "Crawl 'n' Brawl," but I'm planning on doing it as a mixture of bB and asm. There won't be any in-line asm in the bB listing, but I'm going to develop custom include files. I've already written part of the custom kernel-- just the part that draws the playfield from Superchip RAM (it doesn't even have any sprites in it yet)-- but I'll have to write more custom includes as well. For example, I'll have to rewrite the pf drawing routines to work with a 40x24 playfield, instead of a 32x12 playfield as they do now. Then I'll be able to use the modified pfread function to check the bits of the ROM maze, and use the pfpixel command to set the bits of the RAM maze to match the ROM maze as the player moves around the screen.

 

MR