Cave-In (PAL50/60 versions available)

[+Atarius Maximus]

Well, I tried out your demo and I was elated to see such a phenomenal looking game for the 2600, I hope you (and Michael) bring this game to a fully playable game, its remarkable in what I see. I like the whole Indiana Jones look as well, I personally loved RoTLA, though many seemed to pan it, so having a sort of hyped-up super-sequel would be great, if I can help you out please let me know.

 

I also loved Raiders of the lost Ark, it was one of my favorites as a kid. I appreciate your offer to help, I may shoot some technical questions your way as I continue to work on this.

 

My biggest concern now is about gameplay elements, I'd love some more feedback on that. As it stands now, without really going into detail about the story of the game, you simply have to collect three items and take them to a specific location, which then gives you a special item that you have to take with you to a hidden exit. The hidden exit is opened with a switch in a certain room. There is a health powerup room, two warp rooms, and a shield that you can carry that makes you invulnerable to enemies. That's pretty much all there is to it, besides killing the enemies and collecting random treasure. Is there enough to the gameplay now to make it fun to play, or does it need more? It's already been mentioned that an improved enemy AI system would be nice, but I keep thinking about all of the other things that made the original Atari adventure so much fun, like the bat, the bridge, the magnet, random placement of objects, etc... all things that were'nt neccessarily essential to win the game but added that extra "something" to make the game more interesting to play. I'm just a little stuck as to what to try to add next.

 

Steve

[+batari]

I'm sure there are still plenty of ways to speed up your main game loop and put the extra cycles to use. Have you tried using "SET DEBUG CYCLESCORE" to see just how many you have left?

I have used the 'set debug cyclescore' command, but the numbers jump around so much I found it to be pretty useless - that's why I've just used 'set debug cycles' as a gauge for when I'm over the limit. Is there a way to use that command so that it just shows the maximum cycles used, instead of constantly changing?

Yes. You need to set aside a variable called mincycles. From the help page:

Since cyclescore changes every frame, it may be hard to see the numbers flashing by. You may find it useful to record the minimum number of cycles. To do so, you must define mincycles to be one of the 26 user variables. During debugging you can't use the variable for anything else, but of course you get it back once you're done debugging. To use mincycles, for example:

 

dim mincycles = z

mincycles=255

 

The latter statement is needed to set (or reset) mincycles to a large value so it can properly find a minimum.

 

Also, I posted a few tips to help reduce the number of cycles in a game:

 

http://www.atariage.com/forums/index.php?showtopic=110810

[+Atarius Maximus]

I'm sure there are still plenty of ways to speed up your main game loop and put the extra cycles to use. Have you tried using "SET DEBUG CYCLESCORE" to see just how many you have left?

I have used the 'set debug cyclescore' command, but the numbers jump around so much I found it to be pretty useless - that's why I've just used 'set debug cycles' as a gauge for when I'm over the limit. Is there a way to use that command so that it just shows the maximum cycles used, instead of constantly changing?

Yes. You need to set aside a variable called mincycles. From the help page:

Since cyclescore changes every frame, it may be hard to see the numbers flashing by. You may find it useful to record the minimum number of cycles. To do so, you must define mincycles to be one of the 26 user variables. During debugging you can't use the variable for anything else, but of course you get it back once you're done debugging. To use mincycles, for example:

 

dim mincycles = z

mincycles=255

 

The latter statement is needed to set (or reset) mincycles to a large value so it can properly find a minimum.

 

Also, I posted a few tips to help reduce the number of cycles in a game:

 

http://www.atariage.com/forums/index.php?showtopic=110810

 

Thanks, batari. I'm now working to change around the variables I'm using to just use bits for simple flags, as I'm being pretty wasteful now with how I'm using them. That should free one up so I can set that option.

 

I have a question about using debug mode... I do see lots of screen flashing when I use the 'set debug cycles' option during regular gameplay (mostly when the enemy is just randomly moving but not chasing you), but when I test it on real hardware I see no problems at all. Should I be concerned about this?

 

Thanks,

 

Steve

[+batari]

I have a question about using debug mode... I do see lots of screen flashing when I use the 'set debug cycles' option during regular gameplay (mostly when the enemy is just randomly moving but not chasing you), but when I test it on real hardware I see no problems at all. Should I be concerned about this?

Maybe. The cycle detection might say you're going over, but there might be a few dozen cycles of leeway before you see effects on real hardware. I looked at some of your code but there's nothing in the random movement routine that should take a significant number of cycles. However, I did find a way to streamline the routine a bit:

Old code:
 s = rand
 if s < 64 then d = d | 000001
 if s < 128 && s > 63 then d = d | 000010
 if s < 192 && s > 127 then d = d | 000100
 if s <= 255 && s > 191 then d = d | 001000

New code:
 s=rand&3
 d=d|dir_rand[s]
 data dir_rand
 1, 2, 4, 8
end

 

EDIT: The old code above is supposed to have a % in front of the binary numbers, but it and the first 3 digits are disappearing. Anyone know why?

Edited July 27, 2007 by batari

[SeaGtGruff]

I have a question about using debug mode... I do see lots of screen flashing when I use the 'set debug cycles' option during regular gameplay (mostly when the enemy is just randomly moving but not chasing you), but when I test it on real hardware I see no problems at all. Should I be concerned about this?

Maybe. The cycle detection might say you're going over, but there might be a few dozen cycles of leeway before you see effects on real hardware. I looked at some of your code but there's nothing in the random movement routine that should take a significant number of cycles. However, I did find a way to streamline the routine a bit:

Old code:
 s = rand
 if s < 64 then d = d | 000001
 if s < 128 && s > 63 then d = d | 000010
 if s < 192 && s > 127 then d = d | 000100
 if s <= 255 && s > 191 then d = d | 001000

New code:
 s=rand&3
 d=d|dir_rand[s]
 data dir_rand
 1, 2, 4, 8
end

 

EDIT: The old code above is supposed to have a % in front of the binary numbers, but it and the first 3 digits are disappearing. Anyone know why?

It's some kind of bug in the (relatively) new version of the forum software, or possibly an option that needs to be set differently. I started noticing it shortly after the conversion to the new forum software, and a few other people have also commented on it. It seems to be when you have a % followed by zeros, the % and the leading zeros are being dropped for some reason:

 

   rem the following should be _%_0_0_0_1 (without the underlines)
  data test1 01

 

   rem the following should be _$_0_1
  data test2 $01

 

Michael

 

Edit:

Okay, so it seems to take the % and only the first *two* leading zeros, and hex numbers are not being affected by it, just binary numbers.

Edited July 27, 2007 by SeaGtGruff

[MausBoy]

Since your game is Superchip, you have something like 47 extra variables to use, labelled var0 through var47. Not sure the actual amount, but you aren't even close to running out of variables if you aren't using any of them.

[SeaGtGruff]

Okay, so it seems to take the % and only the first *two* leading zeros, and hex numbers are not being affected by it, just binary numbers.

I just had a thought. Perhaps the forum software is interpreting the % numbers as hex characters, as if they were part of an URL or whatnot? Thus, _%_0_0 would be the unprintable ASCII(0) character, _%_0_1 would be the unprintable ASCII(1), _%_1_0 would be ASCII(2), _%_1_1 would be ASCII (3), etc. Here's another test.

 

   rem This should be ",_%_2_0,", which is invalid as a binary number, but a space in hex,
  rem so if it displays as ", ," instead of ",,", then we know what's going on!
  test ,%20,

 

   0
  1
  %010
  %011
  %100
  %101
  %110
  %111

 

Michael

 

Edit:

OK, so it's only doing it with _%_0_0. Hmm...

Edited July 27, 2007 by SeaGtGruff

[+Atarius Maximus]

I could easily add some treasure or other items to pick up (as sprites), I just wouldn't be able to have an enemy on the screen at the same time - I'm trying to avoid any flicker in this game. I may be using the score display as an inventory screen for keys, though. If there's no scoring points, I'm not sure what the motivation would be to search for random treasure in the game. Something else to ponder while I try and figure out the whole theme (and ultimate goal) of this game.

I saw your request about the inventory strip in another thread, I'll see about making that customization for bB v1.0 as well, but it might take me several nights to get around to it.

Michael,

 

Have you had a chance to look at updating the inventory strip for bB 1.0? I started to take a crack at it myself by examining what you've done, but I think it's a little over my head.

 

Steve

[+Atarius Maximus]

Since your game is Superchip, you have something like 47 extra variables to use, labelled var0 through var47. Not sure the actual amount, but you aren't even close to running out of variables if you aren't using any of them.

 

Unfortunately, setting the playfield resolution to 32 uses all of the superchip RAM. Those variables are unavailable.

 

Steve

Edited July 31, 2007 by Atarius Maximus

[+batari]

Since your game is Superchip, you have something like 47 extra variables to use, labelled var0 through var47. Not sure the actual amount, but you aren't even close to running out of variables if you aren't using any of them.

 

Unfortunately, setting the playfield resolution to 32 uses all of the superchip RAM. Those variables are unavailable.

 

Steve

They actually are available. When you use Superchip, the playfield gets moved to Superchip RAM, leaving those 48 bytes of standard RAM available no matter how big you make the playfield.

[+Atarius Maximus]

Since your game is Superchip, you have something like 47 extra variables to use, labelled var0 through var47. Not sure the actual amount, but you aren't even close to running out of variables if you aren't using any of them.

 

Unfortunately, setting the playfield resolution to 32 uses all of the superchip RAM. Those variables are unavailable.

 

Steve

They actually are available. When you use Superchip, the playfield gets moved to Superchip RAM, leaving those 48 bytes of standard RAM available no matter how big you make the playfield.

 

Wow, that's great, I misread the documentation. With 48 more variables, that opens up a whole lot of possibilities.

[+Atarius Maximus]

I've been working on a very basic inventory status system that replaces the score, I'm not sure yet if this will be a permanent change. In order to enter the 3 caves with the treasure pieces, you'll now have to find the appropriate key to unlock the gate. Each of the 3 keys is hidden in three different rooms. To search for the keys, you'll have to bump into the wall in the correct room, which will reveal the key and automatically place it in your inventory. You have to have the correct key for the correct cave, I've included a screenshot to show which key goes to which cave (there's no way to give them different colors in the status bar). In addition, the enemies will now occasionally be more agressive in their attack and run toward you much faster.

 

Currently, I've got the three keys hidden in rooms 21, 49, and 157, which you can look up on the numbered map I posted a while back. I could easily randomize the key locations in the future. I'm not sure about this change yet - does it just make the game more tedious, or is this a nice addition? I'm kind of running out of any more workable gameplay ideas on this one.

 

If you want to compile this yourself you'll have to use a custom score graphics file, which I've included in the zip file.

 

Steve

adv110.zip

Edited August 3, 2007 by Atarius Maximus

[gambler172]

Nice

Great game;i like it.........

Maybe...is it possible to add a little title melody?

Or could you add a big monster,which must be killed to get(for eample)a key???

This are only a few suggestions,but the game is really great as it is.

greetings Walter

[+Atarius Maximus]

Nice

Great game;i like it.........

Maybe...is it possible to add a little title melody?

Or could you add a big monster,which must be killed to get(for eample)a key???

This are only a few suggestions,but the game is really great as it is.

greetings Walter

 

Walter,

 

The titlescreen melody may be over my head, as the titlescreen is written in pure asm, and I don't know how to write music in asm. There's about 600 bytes of space left in the bank that the titlescreen's located in, so I could probably add a tune if I could figure out how to write one.

 

I've been working on the boss monster idea, though, and I have something working now. In the last room of the fourth castle, where you are supposed to take the three crown pieces you've collected, there is now a 'boss' fight. Here's a few quick notes about how it works:

 

- The boss has hitpoints, and requires multiple hits to kill. It doesn't have as many hitpoints as you however.

- You can't re-enter room once you have killed the boss and picked up the final piece. I called the final piece the 'dynamite' in my last backstory description, but I think it's going to be considered the 'completed crown' that you have to escape the mine with.

- The crown piece meter on the lower left changes to a hitpoint counter for the boss when you enter the room. The meter decreases from right to left, opposite of yours.

- Once you leave the room after killing the boss, the hitpoint meter reverts back to the crown piece display.

- If you leave the room without killing the boss, the boss's hitpoints recharge to full, yours don't. Don't leave the room once the fight starts!

- When you leave the room after killing the boss, your health recharges back to 100%.

 

Other Changes:

- Key locations are now randomized throughout 9 different rooms in the cave. Every time you reset the game the keys will change locations.

- Changed the random treasure that appears to a health recharge pack. The treasure became pointless after I removed the scoring for the inventory display.

How the health recharge works: it resets the current hit counter, but doesn't visibly affect your onscreen health meter.

The onscreen health meter goes down by 1 unit with every 10 enemy hits. The backpack resets the meter to 0 hits.

 

Just so everyone can see the boss monster room, I've included a 'cheat' binary that puts you inside the last castle, in the room directly below the final room. Just go up one room to see the final fight. The boss is just a double sized copy of the player sprite, I will probably change it (want to help out again, espire8? ). I had to make a whole new game loop in a different bank to pull this off, so there should be plenty of ROM space and machine cycles to add a few more things to this screen. I was able to animate the boss because of the separate loop... Any other suggestions?

 

Here are the room locations that the keys will be randomly located in:

98, 15, 101, 81, 158, 157, 3, 21, 41.

 

 

One last note -- the game is now using about 21k of ROM space!

 

Steve

adv115source.txt

score_graphics.txt

adv115cheat.bin

adv115.bin

Edited August 9, 2007 by Atarius Maximus

[gambler172]

Hi Steve

Great

greetings Walter

[+Atarius Maximus]

Hi Steve

Great

greetings Walter

 

Thanks Walter! Right now I'm working on a complete instruction manual now that describes all of the gameplay additions I've made. Right now all of the instructions and additions are scattered all over this thread, so I thought it might be time to bring it all together in one document.

 

Steve

[MagMax667]

Man, this game is good. I've always wanted to see a homebrew adventure game. As far as I know, there's only Dark Mage and Lord of the Rings (both text adventures). I must admit, I'm a little confused about the game's objective, so I'm glad you're making an instruction manual. Other than that, this game is absolutely phenomenal. Great job!

[Nognir]

Also kudos from me. This is a really great game!

 

I already downloaded the music kit from paul slocum. I will read through the tutorial tomorrow, maybe I can code some music, but don't expect too much. I'm a beginner ^^

[+Atarius Maximus]

Here's the instruction Manual, as promised. The zip file includes a Word 2003 and RTF format manual, as well as the original numbered map and graphical map that I posted earlier. This may not be the final revision of the instruction manual, but it's very complete and provides a good explanation of all the options in the game and how to win.

 

Steve

CaveIn_Map_Instructions.zip

[+Atarius Maximus]

Wow, the game has gotten so large (4700+ lines of code!) it's hard to spot potential problems. I was doing a little more playtesting tonight, and at some point I made the room with the hidden exit impossible to leave once you've entered it. That doesn't work too well if you don't yet have the completed crown, you're stuck in an unwinnable situation. Here's a binary that fixes that problem.

 

Steve

adv116.bin

[SeaGtGruff]

I was just playing around with the game, and looking at the source.

 

One thing you might do is have the hero keep facing in whichever direction he was last headed (left or right), instead of facing left or right as he's moving, but then snapping back to the right when he stops. I see that you're setting variable w to 0 or 8 based on the direction of movement, then immediately setting REFP1 to the same value as w, so I'm guessing that you were trying to make it work the way I described, but were having trouble doing it?

 

The problem is that batari Basic clears REFP1 before it draws the score, so it will only stay set a certain way if you're actively moving the stick in that direction (assuming your program is setting REFP1 based on the stick, which it is). So the way to overcome that is to set a variable to the value you want REFP1 to have, so your program can remember which direction the man should be facing-- exactly like you're doing with w. However, the second thing you need to do is set REFP1 to w just before you draw the screen, since batari Basic keeps clearing REFP1 when it gets to the part where it displays the score.

 

Thus, you can take all of the places where you're setting w and REFP1, and change them as follows:

 

   rem * old code
  if joy0left then w=8:REFP1=8
  if joy0right then w=0:REFP1=0

   rem * new code (just take out the REFP1 part)
  if joy0left then w=8
  if joy0right then w=0

 

Then set REFP1 to w just before you draw the screen:

 

skipenter

  REFP1=w
  drawscreen

  rem * there might be other places where you need to do this, too

 

That lets the man keep facing left or right when the player stops pushing the joystick left or right.

 

The next problem is that the man snaps back to facing right when the player pushes the button, unless the player is actively pushing the stick left at the same time that the button is being pushed. That's happening here:

 

   if !joy0right && !joy0left then w=0

  if joy0fire && w=8 then missile0x=player1x-e:missile0y=player1y-5
  if joy0fire && w=0 then missile0x=player1x+8+e:missile0y=player1y-5

skipthis

 

I think it plays better if you take out that first if:

 

   rem   if !joy0right && !joy0left then w=0

  if joy0fire && w=8 then missile0x=player1x-e:missile0y=player1y-5
  if joy0fire && w=0 then missile0x=player1x+8+e:missile0y=player1y-5

skipthis

 

This still leaves the situations where the man is actively (or has just finished) walking up or down, and then fire is pressed. I'd suggest letting the hero shoot straight up, straight down, or diagonally, as well as shooting just left and right, regardless of whether he's moving or standing still. I tried to modify the code to do that, but haven't got it working yet.

 

Michael

[+Atarius Maximus]

I was just playing around with the game, and looking at the source.

 

One thing you might do is have the hero keep facing in whichever direction he was last headed (left or right), instead of facing left or right as he's moving, but then snapping back to the right when he stops. I see that you're setting variable w to 0 or 8 based on the direction of movement, then immediately setting REFP1 to the same value as w, so I'm guessing that you were trying to make it work the way I described, but were having trouble doing it?

 

The problem is that batari Basic clears REFP1 before it draws the score, so it will only stay set a certain way if you're actively moving the stick in that direction (assuming your program is setting REFP1 based on the stick, which it is). So the way to overcome that is to set a variable to the value you want REFP1 to have, so your program can remember which direction the man should be facing-- exactly like you're doing with w. However, the second thing you need to do is set REFP1 to w just before you draw the screen, since batari Basic keeps clearing REFP1 when it gets to the part where it displays the score.

 

Thus, you can take all of the places where you're setting w and REFP1, and change them as follows:

 

   rem * old code
  if joy0left then w=8:REFP1=8
  if joy0right then w=0:REFP1=0

   rem * new code (just take out the REFP1 part)
  if joy0left then w=8
  if joy0right then w=0

 

Then set REFP1 to w just before you draw the screen:

 

skipenter

  REFP1=w
  drawscreen

  rem * there might be other places where you need to do this, too

 

That lets the man keep facing left or right when the player stops pushing the joystick left or right.

 

The next problem is that the man snaps back to facing right when the player pushes the button, unless the player is actively pushing the stick left at the same time that the button is being pushed. That's happening here:

 

   if !joy0right && !joy0left then w=0

  if joy0fire && w=8 then missile0x=player1x-e:missile0y=player1y-5
  if joy0fire && w=0 then missile0x=player1x+8+e:missile0y=player1y-5

skipthis

 

I think it plays better if you take out that first if:

 

   rem   if !joy0right && !joy0left then w=0

  if joy0fire && w=8 then missile0x=player1x-e:missile0y=player1y-5
  if joy0fire && w=0 then missile0x=player1x+8+e:missile0y=player1y-5

skipthis

 

This still leaves the situations where the man is actively (or has just finished) walking up or down, and then fire is pressed. I'd suggest letting the hero shoot straight up, straight down, or diagonally, as well as shooting just left and right, regardless of whether he's moving or standing still. I tried to modify the code to do that, but haven't got it working yet.

 

Michael

 

Thank you very much for the suggestions. I made the changes you suggested and I really like the result, I should have done it that way from the beginning! You're right in that I had a little difficulty with setting the player reflection, I didn't know about bB clearing REFP1 when it gets to the part where it displays the score.

 

I'll look at adding the ability to fire in all directions as well, but I remember having great difficulty just getting the left/right firing to work correctly. There was a whole lot of trial and error testing.

 

Steve

adv117.bin

adv117source.txt

[+Atarius Maximus]

I'll look at adding the ability to fire in all directions as well, but I remember having great difficulty just getting the left/right firing to work correctly. There was a whole lot of trial and error testing.

 

Maybe I just got lucky, but this was much easier to figure out than I was anticipating. This revision now has up/down and diagonal shots. It adds a whole new dynamic to the game, it may make it a bit too easy to kill the enemies now.

 

If you're standing still, you can only fire in the direction you're facing. In order to fire diagonally or up & down, you'll have to be moving. I don't see any way around that.

 

Here's the code for firing the gun:

 

 rem   after an enemy is killed, you can't fire your gun.  It's turned back on
rem   after you enter a new room with an enemy or pick up a treasure, which resets F to 0.  

if f{0} then AUDV1=0:missile0x=0:missile0y=0:goto skipthis

  if joy0fire then z=z+1:AUDF1=12:AUDC1=z:AUDV1=6
  if !joy0fire then z=0:e=0:AUDV1=0
  if z>19 then AUDV1=0:missile0x=0:missile0y=0:goto skipthis
  if !joy0fire then missile0x=0:missile0y=0:goto skipthis

  rem disable gun when you're in the invisible maze (not needed)
  if room=122 || room=123 then goto skipthis
  if room=124 then goto skipthis

  e=e+1
  if e>25 then e=0

  rem left and right shots
  if joy0fire && w=8 then missile0x=player1x-e:missile0y=player1y-5
  if joy0fire && w=0 then missile0x=player1x+8+e:missile0y=player1y-5

  rem up and down shots
  if joy0fire && joy0up then missile0x=player1x+5:missile0y=player1y-10-e
  if joy0fire && joy0down then missile0x=player1x+5:missile0y=player1y+3+e

  rem diagonal shots
  if joy0fire && joy0down && joy0right then missile0x=player1x+7+e:missile0y=player1y-3+e
  if joy0fire && joy0up && joy0left then missile0x=player1x-e:missile0y=player1y-7-e
  if joy0fire && joy0down && joy0left then missile0x=player1x-e:missile0y=player1y+1+e
  if joy0fire && joy0up && joy0right then missile0x=player1x+7+e:missile0y=player1y-7-e
 
skipthis 

if collision(player1,playfield) then goto still2 : rem display non-animated player sprite
if !joy0up && !joy0down && !joy0left && !joy0right then y=20 :goto still  : rem display non-animated player sprite

adv118.bin

adv118source.txt

[SeaGtGruff]

Maybe I just got lucky, but this was much easier to figure out than I was anticipating. This revision now has up/down and diagonal shots. It adds a whole new dynamic to the game, it may make it a bit too easy to kill the enemies now.

 

If you're standing still, you can only fire in the direction you're facing. In order to fire diagonally or up & down, you'll have to be moving. I don't see any way around that.

What you'd have to do for the standing-still shots is have flags (bits of w, perhaps?) to save the last direction the man was moving in, and then check those flags instead of directly checking the joystick when processing the fire button. But the tricky part is setting those bit flags correctly, because you want to set them if the stick is being pushed in *any* of the eight possible directions, but you do *not* want to change the flags if the stick is no longer being pushed at all. If you can work out the logic for doing that, then checking those flags while processing the fire button should be a snap.

 

Michael

[+Atarius Maximus]

Maybe I just got lucky, but this was much easier to figure out than I was anticipating. This revision now has up/down and diagonal shots. It adds a whole new dynamic to the game, it may make it a bit too easy to kill the enemies now.

 

If you're standing still, you can only fire in the direction you're facing. In order to fire diagonally or up & down, you'll have to be moving. I don't see any way around that.

What you'd have to do for the standing-still shots is have flags (bits of w, perhaps?) to save the last direction the man was moving in, and then check those flags instead of directly checking the joystick when processing the fire button. But the tricky part is setting those bit flags correctly, because you want to set them if the stick is being pushed in *any* of the eight possible directions, but you do *not* want to change the flags if the stick is no longer being pushed at all. If you can work out the logic for doing that, then checking those flags while processing the fire button should be a snap.

 

Michael

 

Ah, ok. What you're saying does make sense. Figuring out the logic for that would be a little challenging, but I'm sure it could be done. What concerns me more now is the fact that I'm adding lots more code to the main loop, and I'm really close to the limit on cycles. If I run the latest version I just posted with 'set debug cycles', the screen is almost constantly flashing. Not good.

 

I remember batari saying that changing if-thens to use data statements could save time, but I've never used them in that manner. Could you give me a quick example of how I might do that? I've got lots of if-then statements in the main loop, as I'm always checking to see if you're in a specific room to make gameplay adjustments.

 

Thanks,

 

Steve