Bombs Away!

[+Atarius Maximus]

A couple of comments after spending a little time playing it with Stella:

 

1) When the bombs drop, do you check that they are not so far apart that it's physically impossible to race from one bomb to another? It seems to me that when zapping one bomb, sometimes the other bomb is so far away that you couldn't get it even if you play perfectly.

 

2) If you just hold down the fire button and sweep back and forth, then there's not much point in the easy level.

 

 

Thanks for the comments. You're right, it is possible for the bombs to be so far apart that it would be nearly impossible to get from one to the other. I don't check for that now, it's completely random. I can make a minor adustment to the randomization on the fastest screens so you at least have a fighting chance. It's a fine line, though, it's got to be difficult enough at the hardest levels so that the game isn't endless. I did make the laser that sweeps back and forth faster at the highest difficulty levels, I could bump that up a little more again.

 

Regarding the easy level, I figured I may have to make some adjustments, I can adjust that level so it's a little bit harder. It's probably too easy, but it would be good for kids, and my youngest (7 yrs old) likes to play my atari creations. I'm always going to play it on hard, which is why I made it the default.

 

Steve

Edited March 7, 2010 by Atarius Maximus

[+Atarius Maximus]

A couple of comments after spending a little time playing it with Stella:

 

1) When the bombs drop, do you check that they are not so far apart that it's physically impossible to race from one bomb to another? It seems to me that when zapping one bomb, sometimes the other bomb is so far away that you couldn't get it even if you play perfectly.

 

2) If you just hold down the fire button and sweep back and forth, then there's not much point in the easy level.

 

 

Thanks for the comments. You're right, it is possible for the bombs to be so far apart that it would be nearly impossible to get from one to the other. I don't check for that now, it's completely random. I can make a minor adustment to the randomization on the fastest screens so you at least have a fighting chance. It's a fine line, though, it's got to be difficult enough at the hardest levels so that the game isn't endless. I did make the laser that sweeps back and forth faster at the highest difficulty levels, I could bump that up a little more again.

 

Regarding the easy level, I figured I may have to make some adjustments, I can adjust that level so it's a little bit harder. It's probably too easy, but it would be good for kids, and my youngest (7 yrs old) likes to play my atari creations. I'm always going to play it on hard, which is why I made it the default.

 

Steve

 

This version tweaks the difficulty a little bit. The laser is a little bit slower on easy/level 12, and a little bit faster on hard/level 12. I've also adjusted the randomization so that the bombs won't fall at the very edge of the screen on either side, so they'll always be a little bit closer together. They're minor changes, but should help a bit.

 

Steve

bombsaway26.bin

[sandmountainslim]

The best way I can describe this game is it's like Missile Command and Kaboom had a bastard step-nephew

Very cool! I am enjoying this more than anything I have played in a while.

Wp

[+Atarius Maximus]

Have you tested it with Stella using {_scan>#262}? I think you might have a little problem.

 

I just ran a test on real hardware (an Atari 7800 & a Cuttle Cart 2) and took a quick video with my digital camera. Yes, there are issues. Once the game starts, the screen jumps around a little bit. I can probably fix this, but it's going to take a little time to figure out. I'm fairly certain it's because all of the playfield updates require switching banks and that probably just takes too much time. Each time the laser moves it requires a playfield update as the laser is drawn with playfield blocks.

 

Steve

 

Edited March 8, 2010 by Atarius Maximus

[+Random Terrain]

I can probably fix this, but it's going to take a little time to figure out. I'm fairly certain it's because all of the playfield updates require switching banks and that probably just takes too much time. Each time the laser moves it requires a playfield update as the laser is drawn with playfield blocks.

Maybe you could change the laser to a missile and change the city shields to playfield pixels since they are fairly small. The movement of the city shields wouldn't be as smooth, but if you still have the ball available, you might be able to use it to make the movement look smooth. If you have to, you could cut it down to one city shield so two shields wouldn't have to share one ball.

 

If you had to, each level could have random static city shields (that don't move).

Edited March 8, 2010 by Random Terrain

[+stephena]

Have you tested it with Stella using {_scan>#262}? I think you might have a little problem.

In this case, you can simply turn on the onscreen scanline overlay (Alt-l) and immediately see that it jumps from 262 - 260 (or so) very frequently.

[yuppicide]

I tested Bombs Away on a real machine using my Harmony cartridge. I see the scanline issue I found was brought up here already and lots of revisions since 18. Unfortunately I don't have internet at home right now, so I had to wait until I got to work today to reply.

 

I was going to list the scanline issue. When pressing the fire button it makes the scanlines go from 262, to 263, to 271, and the back to 262. But as soon as you press fire it'll do it again. If you HOLD fire it the screen flickers a lot and jumps (rolls?) on a real machine. I was testing and thought I'd just not fire and let the bombs fall. I did get a scanline issue once when a bomb hit the city.

 

You did that in bB? It's excellent. I love the colors and the graphics.

[+Atarius Maximus]

I tested Bombs Away on a real machine using my Harmony cartridge. I see the scanline issue I found was brought up here already and lots of revisions since 18. Unfortunately I don't have internet at home right now, so I had to wait until I got to work today to reply.

 

I was going to list the scanline issue. When pressing the fire button it makes the scanlines go from 262, to 263, to 271, and the back to 262. But as soon as you press fire it'll do it again. If you HOLD fire it the screen flickers a lot and jumps (rolls?) on a real machine. I was testing and thought I'd just not fire and let the bombs fall. I did get a scanline issue once when a bomb hit the city.

 

You did that in bB? It's excellent. I love the colors and the graphics.

 

I've been working with it this morning and I think I can make it work. I'm not going to be able to use playfield blocks for the laser at all - it simply uses too many cycles no matter which way I slice it. The version I'm working on now uses the ball as the laser and so far it seems to be working ok, but there are still some more kinks to work out before I post a new version.

 

Steve

[+Atarius Maximus]

I tested Bombs Away on a real machine using my Harmony cartridge. I see the scanline issue I found was brought up here already and lots of revisions since 18. Unfortunately I don't have internet at home right now, so I had to wait until I got to work today to reply.

 

I was going to list the scanline issue. When pressing the fire button it makes the scanlines go from 262, to 263, to 271, and the back to 262. But as soon as you press fire it'll do it again. If you HOLD fire it the screen flickers a lot and jumps (rolls?) on a real machine. I was testing and thought I'd just not fire and let the bombs fall. I did get a scanline issue once when a bomb hit the city.

 

You did that in bB? It's excellent. I love the colors and the graphics.

 

I've been working with it this morning and I think I can make it work. I'm not going to be able to use playfield blocks for the laser at all - it simply uses too many cycles no matter which way I slice it. The version I'm working on now uses the ball as the laser and so far it seems to be working ok, but there are still some more kinks to work out before I post a new version.

 

Steve

 

Well, here's my first attempt at fixing the scanline issue. This version has a few minor issues that probably won't cause much of a problem. I played through levels 1-12 on the hard skill level lots of times, and once or twice the scanline count would jump from from 262 to 263 for a second or less, which may be barlely noticeable on a real TV. It was at 262 scanlines about 99.9% of the time during actual gameplay. The only other times I see a large spike in scanlines is when I move from the game over screen back to the title screen (it jumps up to about 272), after you've played through at least one game and go from the options screen to the "get ready" screen it jumps into the 270's, and whenever you press the reset button it jumps into the 270's. All seem to be related to clearing and switching to a completely different area/screen. These aren't much of a problem since it's in the process of clearing and redrawing the screen anyway - it's not during gameplay. I'll test this again tonight or tomorrow on real hardware again and see how it goes, I suspect this version will probably be fine. If this version still causes too many problems after futher testing, I'll look into moving some of the routines into vblank.

 

The only major change to the game is how the laser is drawn, it's now the ball instead of playfield graphics. I also removed the "smart bomb" feature, it wasn't very useful in practice.

 

Steve

bombsaway31.bin

[yuppicide]

Great. I'll give it a go when I get home from work.

[+Atarius Maximus]

Great. I'll give it a go when I get home from work.

 

Well, after a little more trial and error testing, I figured out what's causing the problem. The method I'm using to randomize the X location of the bombs is causing the scanline count to jump occasionally. If I remove the randomization completely, the scanline count never goes above 262.

 

When a bomb is cleared, a subroutine is called in the same bank that erases the bomb sprite and does a random number generation to reposition the X value of the next bomb to appear.

 

It looks like this:

 

A collision is detected first between the ball (laser beam) and the bomb (player 0 or player 1 sprite). It then jumps to a subroutine to clear the bomb, reset it to the top of the screen, and generate a new random X value.

  if collision(player0,ball) && y<35 then score=score+20: goto p0clear	:  rem this is one of several lines, the scoring is different depending on the Y location of the bomb. 

This is the subroutine that runs when the collision is detected:

p1clear
 if p<240 then p=p+1                      : rem this increments the level counter to keep track of when the next level should start
 player1:                                      	: rem this erases the bomb from the screen
 000000 
end
300 v=rand                       		: rem this generates a random X value for the next placement of the bomb that was just destroyed
 if v<20 || v>80 then goto 300 		: rem  I don't want the X value to be less than 20 or greater than 80.  (The other bomb has a range of 80 to 130).
 w=0                                	: rem this resets the Y value of the bomb sprite to 0 (back to the top of the screen)
 goto gamestart 

 

As I mentioned, if I remove the randomization lines (300 v=rand, if v>20 || v>80 then goto 300), the scanline problem goes away. Does anyone have any suggestions for a more efficient way to randomly change the X values of the falling bombs? I suspect the problem is due to the conditional nature of the statement. I've got it set up so that it will keep looping back to itself if it generates a number outside of the range that I want. If it generates a long string of consecutive numbers outside of my defined range it could be causing it to take too long and cause the issue I'm seeing.

 

Steve

[+Random Terrain]

Have you tested it with Stella using {_scan>#262}? I think you might have a little problem.

In this case, you can simply turn on the onscreen scanline overlay (Alt-l) and immediately see that it jumps from 262 - 260 (or so) very frequently.

That's even more useful than {_scan>#262}. How long has this been available?

[+Random Terrain]

As I mentioned, if I remove the randomization lines (300 v=rand, if v>20 || v>80 then goto 300), the scanline problem goes away. Does anyone have any suggestions for a more efficient way to randomly change the X values of the falling bombs?

Instead of this:

 

300 v=rand                       		: rem this generates a random X value for the next placement of the bomb that was just destroyed
 if v<20 || v>80 then goto 300 		: rem  I don't want the X value to be less than 20 or greater than 80.  (The other bomb has a range of 80 to 130).

 

 

How about using something like this:

 

  v = (rand&63)
  if v > 60 then v = 60
  v = v + 20

[+stephena]

Have you tested it with Stella using {_scan>#262}? I think you might have a little problem.

In this case, you can simply turn on the onscreen scanline overlay (Alt-l) and immediately see that it jumps from 262 - 260 (or so) very frequently.

That's even more useful than {_scan>#262}. How long has this been available?

Pretty much just as long as the other feature was available. The manual is your friend

 

In this case it's better, but the breakif has its uses, too. Particularly if the scanline jump doesn't happen too often. Sometimes you might want to actually play the game and not keep watching the overlay.

[+Atarius Maximus]

As I mentioned, if I remove the randomization lines (300 v=rand, if v>20 || v>80 then goto 300), the scanline problem goes away. Does anyone have any suggestions for a more efficient way to randomly change the X values of the falling bombs?

Instead of this:

 

300 v=rand                   			: rem this generates a random X value for the next placement of the bomb that was just destroyed
 if v<20 || v>80 then goto 300 		: rem  I don't want the X value to be less than 20 or greater than 80.  (The other bomb has a range of 80 to 130).

 

 

How about using something like this:

 

  v = (rand&63)
  if v > 60 then v = 60
  v = v + 20

 

Thanks for the suggestion, RT, I'll give it a try.

[+Random Terrain]

Pretty much just as long as the other feature was available. The manual is your friend

Thanks. Similar to what I've said before, Stella doesn't seem to have a button you can click to bring up the manual, so you have to go looking for it and on the rare occasion that you do go out of your way to look for it, there seems to be a boatload of keyboard shortcuts, so it shouldn't be surprising that something could be missed. It's kind of like expecting people to rescue a guy floating in the middle of the ocean when they didn't know he was there. The Stella manual isn't like a little 4 page Atari 2600 game manual that you can read in 2 minutes and know everything.

 

After searching AtariAge, I see that Nukey Shay told me about Alt + L in 2008, but I thought he was talking about using it in the debugger.

 

This is the first time I've used Alt + L while a game is running. I'll be using Alt + L all of the time now. Thanks again for mentioning it.

[+stephena]

Pretty much just as long as the other feature was available. The manual is your friend

Thanks. Similar to what I've said before, Stella doesn't seem to have a button you can click to bring up the manual, so you have to go looking for it and on the rare occasion that you do go out of your way to look for it, there seems to be a boatload of keyboard shortcuts, so it shouldn't be surprising that something could be missed. It's kind of like expecting people to rescue a guy floating in the middle of the ocean when they didn't know he was there. The Stella manual isn't like a little 4 page Atari 2600 game manual that you can read in 2 minutes and know everything.

I know it sounds corny, but the saying is 'with great power comes great responsibility'. The manual has gotten large over the past few years because of the insane number of features that have been added. It can never be a short document, simply because of how complex Stella has become (I believe the HTML for the manual itself, not including pictures, is well over 100KB).

 

After searching AtariAge, I see that Nukey Shay told me about Alt + L in 2008, but I thought he was talking about using it in the debugger.

 

This is the first time I've used Alt + L while a game is running. I'll be using Alt + L all of the time now. Thanks again for mentioning it.

Alt-l in the debugger steps through the emulation scanline by scanline. Alt-l in the game itself shows the scanline count (as well as bankswitch type, virtual framerate, and NTSC/PAL/SECAM variant). As I said, both this and the breakif have their uses, depending on how often the scanline count changes, and how much attention you want to pay to it.

[yuppicide]

Agreeing with RT.. great use!!

 

Have you tested it with Stella using {_scan>#262}? I think you might have a little problem.

In this case, you can simply turn on the onscreen scanline overlay (Alt-l) and immediately see that it jumps from 262 - 260 (or so) very frequently.

[+Random Terrain]

I know it sounds corny, but the saying is 'with great power comes great responsibility'. The manual has gotten large over the past few years because of the insane number of features that have been added. It can never be a short document, simply because of how complex Stella has become (I believe the HTML for the manual itself, not including pictures, is well over 100KB).

I'm not complaining about the size. It's just a fact that the size can make it easier miss things. I could have looked at your page for hours and still missed what you pointed out, especially since I didn't know what to look for. It can be even harder to find things on the bB page. That's just the way it is when you're dealing with a lot of info.

[+Atarius Maximus]

Ok, this version works on real hardware. Using the breakif statement in the stella debugger, the game never goes above 262 scanlines. The only time I noticed it going above 262 is when you push the reset switch during gameplay to go back to the titlescreen - that's not really a big deal and I'm not going to worry about it. Thanks to RT for giving me a suggestion on changing the randomization code, that worked perfectly. I may fine tune it to get the locations that the bombs fall exactly where I want them, but it works well how it is right now.

 

A new feature in this version is the ability to change your laser. You can keep it at static height, which is the default, or make it slowly shoot up from the bottom and reset itself when it gets to the top. Changing the laser to a "shooting" type really increases the difficulty! The type of laser you want is now a selectable option on the options screen. Another change is that the options you choose are saved from game to game. When you press fire on the game over screen, you are taken back to the options screen which will display the most recent choices you made. That way you can keep starting the same game over without having to change your options every time you want to try again.

 

I've still got over 4K left in the current 16k version, so I may think of a few more changes to make before I call it done. Suggestions are always welcome.

 

Steve

bombsaway36.txt

bombsaway36.bin

Edited March 9, 2010 by Atarius Maximus

[+Atarius Maximus]

Oops, found a bug in my playtesting. The score wasn't being reset properly when restarting a game. This version fixes that. I also made a few cosmetic changes to the titlescreen and options screen, and activated the reset switch when you're on the options screen and level notification screens, it wasn't available before.

 

Steve

 

EDIT: Updated this version ... go two posts down for the binary/source.

Edited March 10, 2010 by Atarius Maximus

[+Random Terrain]

Never mind. Thought I found a problem, but it wasn't a problem.

Edited March 9, 2010 by Random Terrain

[+Atarius Maximus]

Oops, found a bug in my playtesting. The score wasn't being reset properly when restarting a game. This version fixes that. I also made a few cosmetic changes to the titlescreen and options screen, and activated the reset switch when you're on the options screen and level notification screens, it wasn't available before.

 

Steve

 

Ok, changing the options screen so it saves the last selected choices has caused me a few problems... I found another issue. The increased speed of the laser on the later levels wasn't being reset when you restarted the game. This fixes that. Same version number, I'll just remove the last posted binary. Hopefully this is the last one I find. My oldest son (12 years old) found it, he was able to last about 20 seconds on level 12 with the default options.

 

Steve

bombsaway37.txt

bombsaway37.bin

Edited March 10, 2010 by Atarius Maximus

[yuppicide]

Would be nice to figure out how to work in speech to make it say "Bombs Away!".. would really remind me of the INTV B-52 game.

[Cliff Friedel]

Oops, found a bug in my playtesting. The score wasn't being reset properly when restarting a game. This version fixes that. I also made a few cosmetic changes to the titlescreen and options screen, and activated the reset switch when you're on the options screen and level notification screens, it wasn't available before.

 

Steve

 

Ok, changing the options screen so it saves the last selected choices has caused me a few problems... I found another issue. The increased speed of the laser on the later levels wasn't being reset when you restarted the game. This fixes that. Same version number, I'll just remove the last posted binary. Hopefully this is the last one I find. My oldest son (12 years old) found it, he was able to last about 20 seconds on level 12 with the default options.

 

Steve

 

The gameplay on this is great! So much better than when the laser just made a vertical line. Great job!

 

Cliff