Jump to content
IGNORED

Cave-In (PAL50/60 versions available)


Atarius Maximus

Recommended Posts

HI,

This game has really progressed fast! Great job!!

After checking out your lastest revision I thought I might toss out a couple more requests /suggestions.

 

Right now the enemies come at you in a very linear fashion and are very predictible. Would it be possible to make some of them have a more "hit and run" scheme so they can circle around you? Maybe some of them could have the ability to warp in and out so they reappear at random places around you? Or since you can only fire to the sides, maybe more difficult enemies could try to stay on top or beneath you.

 

As it is right now, all of these enemies are pretty easy to kill. I think the game might create more tension if there were fewer but more difficult enemies/monsters.

 

cheers---Ron

 

Thanks Ron. I agree that the enemies are a bit too easy and predictable, I would like to change that up a little bit. Making major changes like having them circle you probably won't be possible due to ROM space and timing issues, but I could make them change positions a little more randomly after hitting you instead of just boucing back a little (or just to the top or bottom like you suggested), and I could easily make them faster. Actually, you can make them a little faster now by setting the left difficulty to A.

 

Steve

Link to comment
Share on other sites

Here's the the new title screen I finished over the weekend, I toyed with the game name title using different words.

I left the name "FOOT FALLS" in there, it has a nice ring to it. Of course you can change it to any name you like, I just did'nt bother putting back the working title again after all the experimenting with it.

Here's the bin:adv54_1_.bin

..and the screen shot.

post-7623-1184597541_thumb.png

 

I'll be away for a couple weeks so I'll post the remaining sprite designs tonight and then go on a short vacation. I'll check in when I can just to read up but other than that I really need to enjoy this warm weather! It's so nice and sunny today! :cool: Catch you all later.

 

I Love it! :lust: Thanks espire. I'll get that added into the next update.

 

I'm still struggling a bit with timing issues, the main problem is a slight screen roll when a new room is drawn. Still working on that, but it could take some time to correct. Hopefully I won't have to start removing existing features of the game. :(

 

I'll wait to post the next update until I get all of the timing issues resolved.

 

Steve

Link to comment
Share on other sites

the gun is probably better than the "sword"

but now all the villains seem to look the same (well for the first 10 screens I checked)

that giant snake looks cool and is impressive

but I like the diversity that you had in the previous version

even the silly looking enemies, it is different than other games

and gives its own personality

you should keep them

My thoughts the same, I do like alot of Steve's own designs myself which is why I did'nt create so many of my own. In fact my creatures are kinda mudane where Steve's are more on the fantastical realm.

Here are just a couple more new mudane types with some extra frames and a death pose for experimenting with. I don't think every creature needs to be animated or have a death pose, maybe just one or two which I used the snake and bat as examples.

I don't know if you can assign each creature it's own solid color but that will help keep them from looking the same as was quoted above.

post-7623-1184670307_thumb.png ...post-7623-1184669069.gif post-7623-1184669058.gif

Also, I forgot to tell you how I really like the hero death screen in an older build you did showing the creature on the same screen with the dead hero sprite -which I hacked into a dead body. Looks as if the monster were gloating over it. :twisted: Think you can keep that death sequence in your next build?

I included the older binary with the screen shoot below:

post-7623-1184670341_thumb.png

adv35_indy_v2_1_.bin

Edited by espire8
Link to comment
Share on other sites

I updated the latest version with the new titlescreen graphics that espire8 created. That took a really long time, I had to transfer the hacked binary he created into my source. Definitely worth it, though, it looks great! There's been a few more changes as well:

 

* Sprite colors are now varied.

* Boulder has been removed - I had to do this to free up space in bank 1. I may add something different to replace it.

* Bug Fixes - there were some room connections that caused the player to get stuck in the playfield.

* Screen shake - Since you're stuck in a mine due to a cave-in, I thought it would be cool to add some screen shake (like a mini-earthquake) when you touch the walls.

* Enemies are now faster, and will also now evade you attacks a little more efficiently by jumping above or below you. They're harder to kill. I may also make them even more difficult to kill and just reduce the number of enemies you encounter.

* Sprites were updated - I re-added some of the original sprites, since some people have mentioned that they liked them ;)

* The gun is unavailable after you kill an enemy. You can shoot again after you leave the room or pick up a treasure.

 

There is still much to do. There is still no sound, which is now going to be difficult due to the lack of space in bank 1. The sounds in this game will probably end up being very basic, nothing fancy. I also still need to update the death sequence and the "game win" sequence, which are a little bland.

 

The slight screen shake on real hardware when you change rooms may be unavoidable, I've spent hours trying to rearrange the code to avoid it to no avail. Moving code from bank 1 to other banks just makes the problem worse - I think the only way to fix it completely would be to start removing existing features from the game. I could justify the slight screen shake by saying it's another earthquake when you change rooms, right? ;) It's really not that bad, but I know no one is going to be able to see it to give me their opinion unless they have a kroko cart or cuttle cart. I'm planning on making some other changes as well, mostly just polishing the game up.

 

Anyway, here's the latest revision, enjoy! :D

 

Steve

adv80.bin

adv80source.txt

Edited by Atarius Maximus
Link to comment
Share on other sites

To fix your screenroll, you'll have to have your "Entered a new room" routine use an extra drawscreen. It's caused by the 32x32 playfield using up way too many cycles.

 

This is getting better and better, really showing off what bB can do now. I'm jealous of the game, and the attention from excellent sprite artists. I'm on my own for the most part when it comes to that.

 

Great work, hope this makes it to cart.

Link to comment
Share on other sites

To fix your screenroll, you'll have to have your "Entered a new room" routine use an extra drawscreen. It's caused by the 32x32 playfield using up way too many cycles.

 

This is getting better and better, really showing off what bB can do now. I'm jealous of the game, and the attention from excellent sprite artists. I'm on my own for the most part when it comes to that.

 

Great work, hope this makes it to cart.

 

Thank you for the tip, MausBoy, adding an additional drawscreen to my 'draw_room' subroutine did fix the problem with the screen roll on real hardware. :cool: I've been focusing on that problem for the last week, it will be nice to work on other parts of the game for a change.

 

I was really lucky to get espire8's help on the sprites (and the titlescreen). I'm going to be returning the favor by assisting him on some of his upcoming hacks.

 

I've managed to squeeze in some audio to this version, although it's my first go at it so it may change. There is now a rumbling sound when you touch the walls, a firing sound when you shoot your gun, a sound when you are hit by an enemy, and a sound when you pick up a treasure. I've also added an all new death animation sequence, but it's also my first go at it, I'll probably end up changing it or at least polishing it up a little bit. That's really all that's new in this revision, other than some other random bugs that I found and fixed - which are mostly due to my own tinkering with the code and moving stuff around. I've got a lot more things planned for this game, and now with the hardware compatibility issues pretty much worked out I can focus on that. I've got tons of space left, I'm only using about 17k of the 32k so far. ;)

 

I do hope to get this one on a cart when it's done and get it in the AA store, but I don't want to get ahead of myself. I suppose I need to drop Albert a line and see if he'd be interested.

 

EDIT: I just played through this revision and I see that I've created a few more minor bugs that will be easy to fix - the warp rooms and health rooms aren't going to work right in this version. It's too late to work on this anymore tonight, but I'll post a fixed version in the next day or two.

 

Steve

adv86.txt

adv86.txt.bin

Edited by Atarius Maximus
Link to comment
Share on other sites

This revision just includes bug fixes. In the process of moving code around and making changes, I had created some problems that didn't exist before - they've all been fixed. I'll wait to post the next revision until there are more substantial changes to the game.

 

Steve

 

EDIT - removed attachments, there were errors.

Edited by Atarius Maximus
Link to comment
Share on other sites

I can't play it because I'm stuck in the playfield! Move the guy's position at the beginning.

 

Thanks for pointing that out, I'm suprised no one had mentioned yet that the last revision I posted was unplayable. I usually change the start room on the game when I'm testing it to go directly to the rooms I'm working on, it saves a lot of time - the last revision I posted I just forgot to change the start room back to the correct place.

 

I've been pretty much working exclusively on making this 100% hardware compatible since my last post, but I did add one new feature. There is now a shield you can pick up that will make you invulnerable to enemy attacks. It's located outside the health recharge room, you'll have to find the hidden entrance to get to it. If you don't want to try and find it yourself, I've included the location of the shield below (enclosed in spoiler tags):

 

 

It's to the left of the 'rockslide' room with the brown background. Go to the upper left of the screen, and move down on to one of the rocks, you'll slide down and be able to access the left side of the screen, which will take you to the hidden entrance containing the shield. If you refer to the map I posted earlier, it's to the left of Room 6.

 

 

You will drop the shield if you touch the walls of the cave, so you'll have to move very deliberately and slowly if you want to hang on to it. You also cannot take it past the gated cave entrances. If you lose the shield, it will go back to it's original location and you'll be able to pick it up again.

 

Steve

adv96source.txt

adv96.txt.bin

Edited by Atarius Maximus
Link to comment
Share on other sites

Everything is great so far. What's next?

 

Good question! I think I've added about all I can to the game given the ROM constraints in bank 1 and timing issues I've had to work through. I would still like to make a much cooler ending sequence to the game, ditto for the death animation sequence -- I've got virtually unlimited space for those, as they run in their own loop in alternate banks. The regular game is pretty much out of space, I've done about all the tweaking and code moving I can do in bank 1, it's just plain full.

 

I'm toying around with some different gameplay elements that I may or may not be able to add in, like limited gun shots, enemies that don't move through the walls, making some enemies faster than others, reducing the frequency of enemies that appear, and some other things that I'm probably not thinking of right now. I'm trying to balance out the gameplay so it's not too easy or too hard, and of course I want it to be fun to play. Any other thoughts, comments or suggestions on that?

 

I just realized I commented out the line that reduces your health when I was doing some testing. Here's the same version as my last post, but it removes the invincibility.

 

Steve

adv96.txt.bin

Link to comment
Share on other sites

You should take your time and keep trying things, I think this project deserves all the time it takes to be extremely polished.

 

If you have to, ask for help from ASM pros to convert any code possible to asm tags that will speed up your main loop, to allow for more subroutine calls to your empty banks. You need to have the cycles available to implement more of your ideas using that space.

 

I especially think you need to take the time to do this to allow for a better enemy AI system. You should be able to have enemy types, with different attributes. Some should attack when you enter a room, some only when you get

close, some only when attacked themselves, etc.

If you are going to bother with an ammunition counter, you should also have a random routine for powerups left by dead enemies such as ammo, health, etc. That way if there are various enemy AI types, the player can decide for example if it's worth attacking a sleeping bat to try to get more ammo.

 

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?

Link to comment
Share on other sites

The regular game is pretty much out of space, I've done about all the tweaking and code moving I can do in bank 1, it's just plain full.

I've only glanced at your code, but it looks like there might be little ways that you can reclaim a few bytes here and there in bank 1. For example:

 

  if room<>69 then skipstuff
 if room=69 && pfscore1=168 then ballx=100:bally=35
 if room=69 && collision(player1,ball) then t=1
skipstuff
 if t=1 then ballheight=4:ballx=player1x+4:bally=player1y-12

 if room<>43 then goto s20ret
 if collision(player0,player1) && room=43 then AUDF0=1:AUDC0=29:AUDV0=12:goto s19 else AUDV0=0:REFP0=0:goto s20
s20ret

You can remove "room=69 &&" from the ifs in the second and third lines above, since "if room<>69" in the first line will take care of that. Likewise with "&& room=43" in the next section. Also, the "else" in that same line is unnecessary; you could just move the subsequent statements to the next line, since there's a goto right before the else. If I'm not mistaken, that will also help you save a few bytes, since there are some similar statements in the else (AUDV0=0 and REFP0=0). If there are enough places in bank 1 where you can move or remove code like that, then you might be able to reclaim enough bytes to squeeze in a few more things.

 

Also, there might be ways you could optimize the movement tables, although it would involve changing the room numbers around (i.e., renumbering the rooms). Basically, you could group rooms together based on their exits. For example, if there are a lot of rooms that have no north exit, then you could put them all at the end, and then you wouldn't have to include them in the move_north array, since the program shouldn't ever get into a situation where it needs to check the move_north array for those rooms. Or you could arrange the rooms in ways that would let you overlap the movement arrays. For instance, say you have 20 rooms that have no north exit, and 20 rooms that have no south exit (or it could be east or west exits, but we'll take south for this example), then you could overlap the arrays in the following way:

 

-- Suppose there are 100 rooms in all, numbered 0 to 99.

-- Suppose rooms 0 through 9 have no south exit.

-- Suppose rooms 90 through 99 have no north exit.

 

   data move_north
  rem followed by 80 bytes of data, for rooms 0 through 79,
  rem to define where you end up if you exit north from those rooms
  data move_south
  rem followed by 10 bytes of data, for rooms 80 through 89,
  rem to define where you end up if you exit *north* from those rooms...
  rem and those 10 bytes would also double for rooms 0 through 9,
  rem to define where you end up if you exit *south* from those rooms
  rem (but the program should never need to check for those situations anyway)...
  rem then 10 more bytes for rooms 10 through 19,
  rem to define where you end up if you exit south from those rooms...
  rem and those 10 bytes also double for rooms 90 through 99, north exit
  rem (which the program should never have to check anyway)...
  rem then 80 more bytes, for rooms 20 through 99, south exit

I hope you follow what I'm trying to say-- both move_north and move_south would be 100-byte arrays (since there are 100 rooms in this example), but the last 20 bytes of move_north would also be the first 20 bytes of move_south, so you'd save 20 bytes. And if you could overlap move_east and move_west in the same way-- or maybe even overlap the last part of move_south with the first part of move_east (or move_west)-- then you could save even more bytes.

 

But as I said, you'd have to change the room numbers, and I don't know how icky that would be at this stage, since you're already referring to specific room numbers in different parts of your code-- not to mention having to redo the movement tables for the new numbers.

 

Michael

Link to comment
Share on other sites

The regular game is pretty much out of space, I've done about all the tweaking and code moving I can do in bank 1, it's just plain full.

I've only glanced at your code, but it looks like there might be little ways that you can reclaim a few bytes here and there in bank 1. For example:

 

  if room<>69 then skipstuff
 if room=69 && pfscore1=168 then ballx=100:bally=35
 if room=69 && collision(player1,ball) then t=1
skipstuff
 if t=1 then ballheight=4:ballx=player1x+4:bally=player1y-12

 if room<>43 then goto s20ret
 if collision(player0,player1) && room=43 then AUDF0=1:AUDC0=29:AUDV0=12:goto s19 else AUDV0=0:REFP0=0:goto s20
s20ret

You can remove "room=69 &&" from the ifs in the second and third lines above, since "if room<>69" in the first line will take care of that. Likewise with "&& room=43" in the next section. Also, the "else" in that same line is unnecessary; you could just move the subsequent statements to the next line, since there's a goto right before the else. If I'm not mistaken, that will also help you save a few bytes, since there are some similar statements in the else (AUDV0=0 and REFP0=0). If there are enough places in bank 1 where you can move or remove code like that, then you might be able to reclaim enough bytes to squeeze in a few more things.

 

Also, there might be ways you could optimize the movement tables, although it would involve changing the room numbers around (i.e., renumbering the rooms). Basically, you could group rooms together based on their exits. For example, if there are a lot of rooms that have no north exit, then you could put them all at the end, and then you wouldn't have to include them in the move_north array, since the program shouldn't ever get into a situation where it needs to check the move_north array for those rooms. Or you could arrange the rooms in ways that would let you overlap the movement arrays. For instance, say you have 20 rooms that have no north exit, and 20 rooms that have no south exit (or it could be east or west exits, but we'll take south for this example), then you could overlap the arrays in the following way:

 

-- Suppose there are 100 rooms in all, numbered 0 to 99.

-- Suppose rooms 0 through 9 have no south exit.

-- Suppose rooms 90 through 99 have no north exit.

 

   data move_north
  rem followed by 80 bytes of data, for rooms 0 through 79,
  rem to define where you end up if you exit north from those rooms
  data move_south
  rem followed by 10 bytes of data, for rooms 80 through 89,
  rem to define where you end up if you exit *north* from those rooms...
  rem and those 10 bytes would also double for rooms 0 through 9,
  rem to define where you end up if you exit *south* from those rooms
  rem (but the program should never need to check for those situations anyway)...
  rem then 10 more bytes for rooms 10 through 19,
  rem to define where you end up if you exit south from those rooms...
  rem and those 10 bytes also double for rooms 90 through 99, north exit
  rem (which the program should never have to check anyway)...
  rem then 80 more bytes, for rooms 20 through 99, south exit

I hope you follow what I'm trying to say-- both move_north and move_south would be 100-byte arrays (since there are 100 rooms in this example), but the last 20 bytes of move_north would also be the first 20 bytes of move_south, so you'd save 20 bytes. And if you could overlap move_east and move_west in the same way-- or maybe even overlap the last part of move_south with the first part of move_east (or move_west)-- then you could save even more bytes.

 

But as I said, you'd have to change the room numbers, and I don't know how icky that would be at this stage, since you're already referring to specific room numbers in different parts of your code-- not to mention having to redo the movement tables for the new numbers.

 

Michael

Thank you for the tips, Michael, I appreciate you looking over the code. You're right, I can easily make those changes you suggested at the top of your post, however changing the room tables would be a monumental task at this point. I'm not sure if I'll do that or not, but it's nice to know that it's an option. Even if I free up lots of space in bank 1, I think I've about reached the maximum amount of machine cycles I can use. When I playtest the game in debug mode using Stella, I notice lots of screen flashing when you're running around shooting at the enemy, however when I test it with the CC2 on real hardware there are no visible issues on the TV screen. Can I assume that it's going to work OK on all atari hardware, even though it looks like I'm using too many cycles when in debug mode?

 

I have the screen roll problem when changing rooms figured out - I was occasionally calling the playfields more than once using two gosubs (based on room number), that was just using too many cycles. Giving each playfield it's own subroutine in the draw_room sub helped fix that, but it used up even more space in bank 1. Also, adding an additional drawscreen in the draw_room sub (MausBoy's suggestion) helped.

 

Do you have any further suggestions that might help speed up the main game loop? Are there any easy changes I could make to convert some of the bB code into ASM? Right now, even if I do free up lots of space in bank 1, I'm not sure there's enough machine cycles left to add anything without causing the screen to roll.

 

Very Nice!

 

Things I like:

- main character

- playfield

- moving-with-light

- some of the antagonists

- speed of movement

 

Possible improvements:

- bumping into wall sound is annoying

- most antagonists are kinda weird looking

- end game texts

Thanks for the comments. I could see why you'd think the wall sound is annoying, but I'd like to leave it in there. I may just reduce the volume of it. I agree that many of the atagonists are weird looking, I created them initially as placeholders and intended to change them later. One person commented that they liked them, which is why I put them back in, but I'll probably end up changing them all to creatures you might expect to find in an underground mine. The end of the game text (I assume you mean the alternating "Cave In - Game Over" text when you die) will most likely change, that was my intial run at a death animation and ending screen.

 

You should take your time and keep trying things, I think this project deserves all the time it takes to be extremely polished.

Agreed, I'm going to take as much time as I need.

 

If you have to, ask for help from ASM pros to convert any code possible to asm tags that will speed up your main loop, to allow for more subroutine calls to your empty banks. You need to have the cycles available to implement more of your ideas using that space.

I'm already using too many cycles in my main game loop, as I do get some screen flicker when I run the set debug cycles command. It works fine on my CC2 however, so I must be right at the limit of what will work on real hardware. I would definitely need some help from a more experienced ASM coder to change anything. I don't know anyone to ask other than Micheal or Fred, if you guys want to take a look and see if you see anything obvious that could be changed that would be great. I know everyone is busy with their own projects, I hate to ask for help on something that I know could take a lot of time.

 

I especially think you need to take the time to do this to allow for a better enemy AI system. You should be able to have enemy types, with different attributes. Some should attack when you enter a room, some only when you get

close, some only when attacked themselves, etc.

If you are going to bother with an ammunition counter, you should also have a random routine for powerups left by dead enemies such as ammo, health, etc. That way if there are various enemy AI types, the player can decide for example if it's worth attacking a sleeping bat to try to get more ammo.

It would be cool to have a more advanced enemy AI. I would need to free up lots of space and time in the main loop to do anything like that, though.

 

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?

 

Steve

Link to comment
Share on other sites

Really the only things that should go into your main gameloop is something like:

 

PUTITUP

COLUPF = X : COLUBK = X : NUSIZ0 = X : NUSIZ1 = X : CTRLPF = X (x is whatever you are using)

drawscreen

return

 

 

Then you can put kernel stuff in any bank, and just do a "gosub PUTITUP bank1" each loop. This is the way to do it if every part of the main loop is not useful every single loop, which is what it sounds like if your cycles remaining counter is jumping all over the place.

I believe that bank jumping slows things down though, so you may want a second opinion.

Link to comment
Share on other sites

Here's a complete map of the game. Hopefully somebody will find this useful, it took about 6 hours of work to finish. ;) I still need to work on it a little bit to make it look nicer, but all of the rooms are on there. I worked on map this through many revisions of the game, so there may be slight differences in some of the rooms. I'll post a much nicer, cleaned up, higher quality version in the future.

 

Steve

post-2143-1185425515_thumb.jpg

Link to comment
Share on other sites

^^ That is just freaking awesome! Looking at the map, theres this one room that is just a straight hallway (the one in the top left corner.) It looks like it has spikes sticking out the sides. Is there a way to add room interaction in addition to the critters?

Link to comment
Share on other sites

Is there a way to add room interaction in addition to the critters?

 

Yes, it is possible, and I did play around with that idea. I tried dynamically changing the playfield in one of my early revisions, and it made the screen roll pretty badly - it used too many cycles. I may try again, but it probably won't be possible.

 

Steve

Link to comment
Share on other sites

Thats exceptionally ambitious.... how are you dealing with creating the rooms in each screen???

 

When I did Adventure II for the 2600 I found that I had to mirror the screens to get it the game to work properly and even then I had a small hiccup in the game where the screen would jump due to the system having to keep tracking of all of the objects within the game.

 

 

 

Curt

 

Here's a complete map of the game. Hopefully somebody will find this useful, it took about 6 hours of work to finish. ;) I still need to work on it a little bit to make it look nicer, but all of the rooms are on there. I worked on map this through many revisions of the game, so there may be slight differences in some of the rooms. I'll post a much nicer, cleaned up, higher quality version in the future.

 

Steve

Link to comment
Share on other sites

Thats exceptionally ambitious.... how are you dealing with creating the rooms in each screen???

 

When I did Adventure II for the 2600 I found that I had to mirror the screens to get it the game to work properly and even then I had a small hiccup in the game where the screen would jump due to the system having to keep tracking of all of the objects within the game.

 

 

Curt,

 

I based the game on a short demo that Michael Rideout wrote, so I can't really take credit for the method in which the rooms are drawn. There are six data tables, four keep track of which room is N,S,E, and W of you, one stores which playfield shape is assigned, and the other stores the color of the room. When you move off the screen, the 'draw room' subroutine is called, which checks the playfield assignment table and then does a gosub to a different bank and redraws the playfield. I've spent many hours of time trying to perfect moving between rooms and avoiding any screen roll, I can't tell you how many times I've gone back and forth between my computer and my Cuttle Cart. ;) This game is not nearly as complex as Adventure II as far as keeping track of many different objects, I'm sure I wouldn't be able to squeeze all of that in.

 

Steve

Link to comment
Share on other sites

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.

 

 

CUrt

 

 

Thats exceptionally ambitious.... how are you dealing with creating the rooms in each screen???

 

When I did Adventure II for the 2600 I found that I had to mirror the screens to get it the game to work properly and even then I had a small hiccup in the game where the screen would jump due to the system having to keep tracking of all of the objects within the game.

 

 

Curt,

 

I based the game on a short demo that Michael Rideout wrote, so I can't really take credit for the method in which the rooms are drawn. There are six data tables, four keep track of which room is N,S,E, and W of you, one stores which playfield shape is assigned, and the other stores the color of the room. When you move off the screen, the 'draw room' subroutine is called, which checks the playfield assignment table and then does a gosub to a different bank and redraws the playfield. I've spent many hours of time trying to perfect moving between rooms and avoiding any screen roll, I can't tell you how many times I've gone back and forth between my computer and my Cuttle Cart. ;) This game is not nearly as complex as Adventure II as far as keeping track of many different objects, I'm sure I wouldn't be able to squeeze all of that in.

 

Steve

Link to comment
Share on other sites

Here's a complete map of the game. Hopefully somebody will find this useful, it took about 6 hours of work to finish. ;) I still need to work on it a little bit to make it look nicer, but all of the rooms are on there. I worked on map this through many revisions of the game, so there may be slight differences in some of the rooms. I'll post a much nicer, cleaned up, higher quality version in the future.

 

Steve

Hi Steve

Thanks for the map :)

greetings Walter

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...