Cave-In (PAL50/60 versions available)

[+Atarius Maximus]

Here's an adventure style game I've been working on this week. I thought I'd post a preview to get some feedback and ideas for gameplay. My favorite atari game has always been adventure (Adventure Plus was my first real hack ), and I've been wanting to make a game in that genre since bB was first released. What really got me interested was Micheal Rideout's "move around rooms" demo, which is the code I used to get started on this project. (Thanks Mike, had to give credit where credit is due!)

There's not alot to the gameplay just yet. The rooms and enemy sprites are pretty much just placeholders now, I expect they'll all be changed in the future. There is a health meter and life counter, but you can't die in this version. Your hero has a sword that you can use to kill the enemies that you'll encounter on each screen. The goal of the game (at least for now) is to find the treasure and return it to the correct room. The treasure is the ball, it's just a 4x4 pixel box on the screen. The location of the treasure and the correct room to return it to are noted on the map that I've attached to this post. Don't look if you don't want to know. There are 31 rooms in the maze, although some of the map screens are used more than once (there are 15 unique screens). The game doesn't end when you return the treasure, you're awarded 5000 points and the treasure is placed back where it started. The gameplay and the goals in the game will likely change, I just wanted there to be a reason to play this demo.

I'd love some feedback and ideas for gameplay, I don't really know what I'm going to do yet.

Steve

12/23/2009 Edit: I've added the final version of the game (cavein230.bin) to this post.

1/10/2011 Edit: Added PAL50/60 versions for download.

8/9/12 Edit: Added updated version with Map screen. WARNING: It has bugs! Toggle Color B/W switch to view. Blinking squares represent cave entrances, lines represent room connections. Accessing the map room is disabled on certain screens. It works but has a few bugs and is not suitable for a cart release, and has not been thoroughly playtested. One bug I know if is that the game will crash if you pull up the map in a cave entrance room.

You can also view the home page for Cave In on my website, http://www.bjars.com/mygames.html#Cave_In

 

1/6/14 Edit: Secrets Revealed: You can now download an image that reveals all the secrets in the game, including the easter egg, hidden warp room, hidden gun room, invisible maze map, and how to get a free health recharge during the game. http://www.bjars.com/images/CaveInSecretsRevealed.jpg

adv10.txt.bin

cavein230.bin

CaveInPAL.zip

CaveInNTSC-Update.bin

CaveInPAL60-Update.bin

[lord_mike]

Wow!!!!

 

I mean... wow!!! how did you get so many playfield rows in the standard kernel... would love to see the source code, someday!

 

Thanks,

 

Mike

[Gorf]

Looks extremely promising....kind of 'Venture' like even.

 

Im diggin it.

 

Good work.

[espire8]

Nice looking screen shot. I can't seem to download your bin demo though. all I get is text garbage. anyway to fix that?

I always loved adventure myself and I remember your CYOA program way back, that helped me alot! would gladly contribute what I can for you here.

Let me know if you need any sprite artwork when you get to it, that's my specialty.

[Guest moonshot22]

Hi,

Looks cool so far! I'm going to toss out some ideas. What if instead of retrieving one item and returning it, you have to find 3 pieces of an item that are randomly placed? As for their placement, could you have 3 hidden rooms that appear randomly on the map that you would have to locate? To open them you would have to retrieve randomly placed keys in the known "kingdom."

 

How about having monsters that regenerate every 10 seconds in some rooms so that it's more difficult to find the hidden rooms.

Maybe some rooms could have more than one monster?

 

What about some sort of limit on the sword usage such as needing to find power ups.

 

Also, can you make clusters of a few rooms a different color scheme? That always helps to orient yourself. Maybe the final destination could feature an invisible maze that randomly changes? I'm definitely a fan of randomization.

 

I don't know if anything I've suggested is useful or feasible in batari basic but I thought I'd give it a shot:-)

 

cheers

Edited June 16, 2007 by moonshot22

[Gregory DG]

Looks great! Although the character looks like a cross between Indiana Jones and Pitfall Harry.

[gambler172]

Nice

greetings gambler172

[SeaGtGruff]

I can't seem to download your bin demo though. all I get is text garbage.

Your system is probably getting confused by the ".txt" that's in front of the ".bin." I don't know what operating system and browser you're using, but if you can right-click on the link and get a "save target as..." type of option, then you can select that to download the file, and even save it with a new name.

 

Or, if you aren't able to do that, here's the same .bin file, with ".txt" taken out if the name...

 

adv10.bin

 

Michael

 

PS-- The reason I mentioned the "save target as..." option, instead of just posting a renamed version of the file as I did anyway, is in case it proves helpful in the future.

Edited June 16, 2007 by SeaGtGruff

[SeaGtGruff]

What really got me interested was Micheal Rideout's "move around rooms" demo, which is the code I used to get started on this project. (Thanks Mike, had to give credit where credit is due!)

You're welcome, and I'm glad someone finally made use of that example.

 

Michael

[Dan Iacovelli]

looks really good.

I had the same trouble as well with the dl, figured to do the save target as bit and that worked.

[SeaGtGruff]

how did you get so many playfield rows in the standard kernel...

The only way I know to do that-- other than customizing the standard kernel to use ROM playfields, just as the multisprite kernel does by default-- is to use the Superchip. The BIN size is 16K, so I'm guessing that's what he did.

 

Michael

[+Atarius Maximus]

how did you get so many playfield rows in the standard kernel...

The only way I know to do that-- other than customizing the standard kernel to use ROM playfields, just as the multisprite kernel does by default-- is to use the Superchip. The BIN size is 16K, so I'm guessing that's what he did.

 

Michael

 

Yes, I used the superchip option. Actually, the increased screen resolution is the only thing that I'm using that option for now, I could remove that and just have low-res rooms. If I'm not mistaken, there's no way to put an SC game on cart (is that right, Michael?).

 

Wow, lots of replies and downloads so far. I'll read through them all and post again.

 

Steve

[+Atarius Maximus]

Nice looking screen shot. I can't seem to download your bin demo though. all I get is text garbage. anyway to fix that? ... Let me know if you need any sprite artwork when you get to it, that's my specialty.

I always use a .txt extension for my source code because I primarily use windows notepad as my editor. I tend to work on the games during downtime at work, and I can't load any third party software on my work computer, and of course notepad is on every windows computer. I'm not sure why that doesn't work for you, but you can just change the extension after you download it.

 

I may take you up on your offer to help on sprites in the future. Unfortunatley, the enemy sprites will have to be single colored since I can't give up the missile, you can't have both.

 

Nice

Thanks, gambler.

 

Looks cool so far! I'm going to toss out some ideas

I like some of your ideas, thanks! I always start on a game before I really know how it's going to turn out. I don't want a clone of the original adventure, I want to do something a little different. Multiple Monsters on the screen may be possible, but it would involve lots of flicker. Hidden rooms, mazes, and randomization are all in my future plans, but I won't know what can and can't be done until I try it.

 

Looks great! Although the character looks like a cross between Indiana Jones and Pitfall Harry.

Yeah, I was kind of going for the Indiana Jones look. I loved those movies!

 

You're welcome, and I'm glad someone finally made use of that example.

I had a lot of fun playing around with it, and I finally got around to making something with it. Thanks for posting it. Any way you could explain how the room data works and how you determine how the rooms connect? It looks a little confusing. Right now, the map is laid out exactly like you had it in your demo, I didn't change anything.

 

Thanks,

 

Steve

Edited June 16, 2007 by Atarius Maximus

[SeaGtGruff]

If I'm not mistaken, there's no way to put an SC game on cart (is that right, Michael?).

Actually, you *can* create 8K, 16K, and 32K carts with a Superchip on them; you can buy them from Atari Service. From what batari told me about his decision not to officially support the M-Network bankswitching customizations that I'd added to bB v0.35 a while back, I don't think he would have added the Superchip option to bB if it weren't possible to produce actual carts for the games.

 

Michael

[+Atarius Maximus]

If I'm not mistaken, there's no way to put an SC game on cart (is that right, Michael?).

Actually, you *can* create 8K, 16K, and 32K carts with a Superchip on them; you can buy them from Atari Service. From what batari told me about his decision not to officially support the M-Network bankswitching customizations that I'd added to bB v0.35 a while back, I don't think he would have added the Superchip option to bB if it weren't possible to produce actual carts for the games.

 

Michael

 

Great! Thank you for clarifying that for me. I was debating whether or not to continue on an SC game if it could never be put on a cart. So what are all the extra options that bB gives you when you use the superchip option? Is it documented somewhere? I of course know about the pf resolution option, but nothing else.

 

Steve

[+Atarius Maximus]

If I'm not mistaken, there's no way to put an SC game on cart (is that right, Michael?).

Actually, you *can* create 8K, 16K, and 32K carts with a Superchip on them; you can buy them from Atari Service. From what batari told me about his decision not to officially support the M-Network bankswitching customizations that I'd added to bB v0.35 a while back, I don't think he would have added the Superchip option to bB if it weren't possible to produce actual carts for the games.

 

Michael

 

Great! Thank you for clarifying that for me. I was debating whether or not to continue on an SC game if it could never be put on a cart. So what are all the extra options that bB gives you when you use the superchip option? Is it documented somewhere? I of course know about the pf resolution option, but nothing else.

 

Steve

 

I looked around and I see that you've already posted information about the superchip here: http://www.atariage.com/forums/index.php?s...mp;hl=superchip. I've got some reading to do!

[SeaGtGruff]

Any way you could explain how the room data works and how you determine how the rooms connect? It looks a little confusing. Right now, the map is laid out exactly like you had it in your demo, I didn't change anything.

Sure, here are the data statements from that example:

 

   data room_shape
  7,11,4,1,2,9,10,3,9,12,8,4,15,6,5,3,13
  11,10,3,5,15,0,1,1,14,8,4,15,14,10,2,12,14
end

  data move_north
  0,0,0,0,5,2,4,8,9,0,11,12,0,0,0,14,0,0
  3,21,0,0,20,0,0,22,23,28,0,27,24,32,0,31
end

  data move_east
  1,0,3,4,0,0,7,10,0,0,0,13,0,14,0,17,15,0
  19,20,0,0,24,22,23,0,0,26,0,0,31,0,0,0
end

  data move_south
  2,0,5,18,6,4,0,0,7,8,0,10,11,0,15,0,0,0
  0,0,22,19,25,26,30,0,0,29,27,0,0,33,31,0
end

  data move_west
  0,0,0,2,3,0,0,6,0,0,7,0,0,11,13,16,0,15
  0,18,19,0,23,24,22,0,27,0,0,0,0,30,0,0
end

  data room_color
  $86,$86,$86,$86,$C6,$C6,$66,$66,$66
  $66,$00,$00,$00,$00,$46,$46,$46
  $46,$1C,$1C,$1C,$1C,$24,$24,$24,$24
  $0E,$0E,$0E,$0E,$3A,$3A,$3A,$3A
end

 

First of all, you can have up to 256 rooms, numbered from 0 to 255, simply because the room number must fit in a byte, and will be used to index the data tables.

 

Actually, if you want to have more than 256 rooms, you can, but to do that you'll have to split the map into two or more zones, each having up to 256 rooms. Then each zone would have its own set of data tables. You'd also need to use either a separate room number variable for each zone, or one variable for the room and another variable for the zone. That would give you up to 256 zones, for a maximum of up to 65536 rooms in theory. Of course, you'll also need a logical way to move between zones, so you might want to reserve some room numbers from each zone for indicating that a transition to a new zone is occurring-- I haven't tried to work out the logistics of all that. But now that I think about it, that approach probably wouldn't work well. One workable approach would be to store two bytes for each of the inter-room movement tables-- one byte for the new zone number, and another byte for the new room number. But a more ROM-efficient approach might be to use the current room number for the new room number, to indicate that a special type of movement is occurring, and then use if statements to process the special movement based on the zone number and room number. That approach would mean you couldn't have rooms that go to themselves (e.g., if you leave through the north exit, you end up back in the same room).

 

Anyway, for the time being we'll focus on having just one zone with up to 256 rooms. (That may sound like a lot of rooms, but if you consider that a 16-by-16 grid for a dungeon would be 256 rooms, and that you might want to have more than one dungeon level, then you start to see the potential benefit of having multiple zones, be they levels of a dungeon, areas of one or more kingdoms, the interiors of various castles, etc.)

 

The bytes of the data tables are arranged in room number order, so they can be indexed by the room number. That is, the first entry in each data table is for room 0, the second entry is for room 1, the third entry is for room 2, etc.

 

The room_shape table is just a way to have two or more rooms with exactly the same shape, without having to define that shape more than once. For example, if you've got a dozen rooms that have no walls, but are just locations in a field, or something like that, it's more practical (as far as the amount of ROM used) to define that "room shape" just once, and then specify that shape for any number of rooms you want to, without having to define the same room shape a dozen times in ROM. That way, when you're ready to draw a new room, you check the room_shape table to see what shape number the room should have, and then draw that particular room shape, as follows:

 

draw_room
  COLUPF = room_color[room]
  if room_shape[room] = 0 then goto draw_room_shape_0
  if room_shape[room] = 1 then goto draw_room_shape_1
  if room_shape[room] = 2 then goto draw_room_shape_2
  if room_shape[room] = 3 then goto draw_room_shape_3
  if room_shape[room] = 4 then goto draw_room_shape_4
  if room_shape[room] = 5 then goto draw_room_shape_5
  if room_shape[room] = 6 then goto draw_room_shape_6
  if room_shape[room] = 7 then goto draw_room_shape_7
  if room_shape[room] = 8 then goto draw_room_shape_8
  if room_shape[room] = 9 then goto draw_room_shape_9
  if room_shape[room] = 10 then goto draw_room_shape_10
  if room_shape[room] = 11 then goto draw_room_shape_11
  if room_shape[room] = 12 then goto draw_room_shape_12
  if room_shape[room] = 13 then goto draw_room_shape_13
  if room_shape[room] = 14 then goto draw_room_shape_14
  if room_shape[room] = 15 then goto draw_room_shape_15

 

Of course, if I'd used shorter routine names, I could have set some variable to room_shape[room], and then used an on...goto statement instead of a series of if statements, as follows:

 

draw_room
  COLUPF = room_color[room]
  new_room = room_shape[room]
  on new_room goto d0 d1 d2 d3 d4 d5 d6 d7 d8 d9 d10 d11 d12 d13 d14 d15

 

In my example program, the only thing each of the draw_room_shape routines does is execute a playfield statement to draw that room shape, as follows:

 

draw_room_shape_0
  playfield:
  XXXXXXXXXXXX........XXXXXXXXXXXX
  XX............................XX
  XX............................XX
  XX............................XX
  ................................
  ................................
  ................................
  XX............................XX
  XX............................XX
  XX............................XX
  XXXXXXXXXXXX........XXXXXXXXXXXX
end
  return

 

You could also use playfield drawing commands (pfclear, pfhline, pfvline, pfpixel) to draw the rooms.

 

The movement tables (move_north, move_east, move_south, move_west) are for moving around between rooms. This assumes that there are only four exits, one in each compass direction, but you could also have others (move_up, move_down, move_northeast, etc.) if you work out the logistics. Each entry in a given table indicates which new room you'll end up in if you leave the current room by that exit, as follows:

 

   data move_north
  0,0,0,0,5,2,4,8,9,0,11,12,0,0,0,14,0,0
  3,21,0,0,20,0,0,22,23,28,0,27,24,32,0,31
end

 

Rooms 0, 1, 2, and 3 have no north exit, so that's why there's a 0 for those entries in the table. But room 4 does have a north exit, and the 5 indicates that if you're in room 4, and move north, you'll end up in room 5. The other movement tables work the same way.

 

Finally, the room_color table is just a way to let multiple rooms share the same shape, yet still allow each room to have its own color.

 

I think that should explain things well enough for you to start designing your own map layout, instead of just using the map layout from my sample piogram. But if you have any questions, just ask.

 

Michael

[SeaGtGruff]

I looked around and I see that you've already posted information about the superchip here: http://www.atariage.com/forums/index.php?s...mp;hl=superchip. I've got some reading to do!

I haven't followed that link yet to see which post(s) you're looking at, but I suggest that you start with the documentation that comes with bB v1.0, as far as reading about any builtin bB options that make use of the Superchip.

 

Michael

[SeaGtGruff]

   data room_shape
  7,11,4,1,2,9,10,3,9,12,8,4,15,6,5,3,13
  11,10,3,5,15,0,1,1,14,8,4,15,14,10,2,12,14
end

  data move_north
  0,0,0,0,5,2,4,8,9,0,11,12,0,0,0,14,0,0
  3,21,0,0,20,0,0,22,23,28,0,27,24,32,0,31
end

 

Rooms 0, 1, 2, and 3 have no north exit, so that's why there's a 0 for those entries in the table.

 

I take that back, room 2 uses shape 4, which *does* have a north exit, so in that case, the 0 in room 2's move_north table entry indicates that moving north from room 2 will take you to room 0. That may make it a little more confusing to look at a table and know whether 0 means "move to room 0" or "no exit in that direction," so you could use some other value-- e.g., 255-- when there is no exit in that direction. But 0 takes up less space on a program line than 255 does, which is why I used 0-- and the value doesn't matter anyway in that case, because if a room doesn't have an exit in a given direction, then the collision detection and knock_player_back logic will prevent the player from ever being able to exit that side of the screen, hence the program will never have occasion to check that particular entry in the table. I actually used that fact to my advantage in the old Reventure game that I started but never finished, because I was able to combine two movement tables into one, based on the exits. But if I remember correctly, the tables in Reventure used a different sort of logic, which is why I was able to get away with combining two tables into one in that program. I don't think you can do that sort of thing if you use the logic from move_around_rooms, so just forget I even mentioned it!

 

Michael

[+batari]

If I'm not mistaken, there's no way to put an SC game on cart (is that right, Michael?).

Actually, you *can* create 8K, 16K, and 32K carts with a Superchip on them; you can buy them from Atari Service. From what batari told me about his decision not to officially support the M-Network bankswitching customizations that I'd added to bB v0.35 a while back, I don't think he would have added the Superchip option to bB if it weren't possible to produce actual carts for the games.

 

Michael

Yes, that's true; I'm resistant to work on supporting any schemes in which boards are not readily available for a reasonable price. But I do encourage others to add support themselves.

[+Atarius Maximus]

   data room_shape
  7,11,4,1,2,9,10,3,9,12,8,4,15,6,5,3,13
  11,10,3,5,15,0,1,1,14,8,4,15,14,10,2,12,14
end

  data move_north
  0,0,0,0,5,2,4,8,9,0,11,12,0,0,0,14,0,0
  3,21,0,0,20,0,0,22,23,28,0,27,24,32,0,31
end

 

Rooms 0, 1, 2, and 3 have no north exit, so that's why there's a 0 for those entries in the table.

 

I take that back, room 2 uses shape 4, which *does* have a north exit, so in that case, the 0 in room 2's move_north table entry indicates that moving north from room 2 will take you to room 0. That may make it a little more confusing to look at a table and know whether 0 means "move to room 0" or "no exit in that direction," so you could use some other value-- e.g., 255-- when there is no exit in that direction. But 0 takes up less space on a program line than 255 does, which is why I used 0-- and the value doesn't matter anyway in that case, because if a room doesn't have an exit in a given direction, then the collision detection and knock_player_back logic will prevent the player from ever being able to exit that side of the screen, hence the program will never have occasion to check that particular entry in the table. I actually used that fact to my advantage in the old Reventure game that I started but never finished, because I was able to combine two movement tables into one, based on the exits. But if I remember correctly, the tables in Reventure used a different sort of logic, which is why I was able to get away with combining two tables into one in that program. I don't think you can do that sort of thing if you use the logic from move_around_rooms, so just forget I even mentioned it!

 

Michael

 

Thank you so much for all the detailed information, it all makes much more sense now. I probably will have more questions as I get further into this project, I really appreciate your help. As far as the documentation, I've never actually looked at the docs that come with bB, I've always gone to Random Terrain's website for info. He may very well have info about the SC option there, I just haven't looked yet. I'll guess I should check out what actually comes in the bB distribution, huh? The link that I posted is the thread where you announced support for the superchip in v.99, so I guess it might be a little outdated.

 

Steve

[+batari]

Thank you so much for all the detailed information, it all makes much more sense now. I probably will have more questions as I get further into this project, I really appreciate your help. As far as the documentation, I've never actually looked at the docs that come with bB, I've always gone to Random Terrain's website for info. He may very well have info about the SC option there, I just haven't looked yet. I'll guess I should check out what actually comes in the bB distribution, huh? The link that I posted is the thread where you announced support for the superchip in v.99, so I guess it might be a little outdated.

 

Steve

RT's website is up-to-date. There's nothing in the bB docs that isn't there too. The docs are intended for offline use, though I suppose you can use them while online if you prefer.

[Impaler_26]

I just tried this one out, looks really great!

 

I'm looking forward to see how this game develops!

[+Atarius Maximus]

I've been playing around with this code for a few hours today, and I think I've got the move_around_rooms code all figured out now. This is a minor change, but I added two additonal rooms to the game, which are accessible by entering the blue castle. There are two castles in the game, but you can only enter one of them. I changed the demo so you have to return the treasure (ball) to the second room of the blue castle to get the bonus points. If you'd like to go straight to the blue castle from the start screen, go right, down, down.

 

My problem now is space - I've got so many rooms and sprites defined that there's very little room for code left in bank 1. Any suggestions for code optimization on this one, short of deleting rooms and sprite definitions? I need to free up a ton of space if I'm going to really be able to do anything useful with this game...that's what I'm going to be focusing on next.

 

Steve

adv15.txt

adv15.txt.bin

Edited June 19, 2007 by Atarius Maximus

[+batari]

I've been playing around with this code for a few hours today, and I think I've got the move_around_rooms code all figured out now. This is a minor change, but I added two additonal rooms to the game, which are accessible by entering the blue castle. There are two castles in the game, but you can only enter one of them. I changed the demo so you have to return the treasure (ball) to the second room of the blue castle to get the bonus points. If you'd like to go straight to the blue castle from the start screen, go right, down, down.

 

My problem now is space - I've got so many rooms and sprites defined that there's very little room for code left in bank 1. Any suggestions for code optimization on this one, short of deleting rooms and sprite definitions? I need to free up a ton of space if I'm going to really be able to do anything useful with this game...that's what I'm going to be focusing on next.

 

Steve

I'd suggest spreading the room definitions across several banks. The sprite definitions probably don't matter too much as just a little bit of code is placed in the calling bank. The actual sprite graphics data is placed in the last bank regardless.

Edited June 19, 2007 by batari