RoadBlaster - A new batari basic game

[+Atarius Maximus]

Thanks for the idea about using fractional math for scrolling -- I'm going to try and add that in the next revision.

 

For now, I was able to add the second missile in -- the enemy cars now shoot back!

See the first post in this thread for the updated bin and source.

 

Here's my To Do list for future revisions of the game:

 

1. Make the cars "do something" when they're hit - move down, left or right a little, or shake. Right now enemy missiles and cars just pass right through you.

2. Scroll Speed Tweaking -- I'll try to add the ability to slow your car down by pressing down on the joystick, make hitting the side of the road slow you down, and hitting an enemy car should slow you down as well.

3. I'll try and add Random Enemy Car Sprites.

4. Variations on Enemy Car movement - it's pretty predictable right now.

5. I may play with the enemy car shots a bit - I like the moving missile now, but I could provide the option for enemy car shots that don't move.

6. I need to add sound to the game.

7. I may try and implement a "pause" feature with the color/bw switch -- just to see if I can do it.

 

Steve

Edited January 25, 2006 by Atarius Maximus

[+batari]

If you have extra RAM, look into using fractional math to control scrolling speed.  This will give you more possible speeds.  Something like...

   ScrollCounter = ScrollCounter - ScrollSpeed
  ScrollCounter = ScrollCounter - ScrollSpeed
  if ScrollCounter < 50 then ScrollCounter = 255 : gosub ScrollStuffSubroutine
  rem else don't scroll this frame

You can also use fixed point math (see documentation). In 0.35 there are some bugs with the 4.4 type, so I'd use the latest build if you want to use this type. The 8.8 type is more accurate, though, and works fine in 0.35. It may be easier to use fixed point math than routines like the above, since you can assign, add and subtract decimal values.

[supercat]

You can also use fixed point math (see documentation).  In 0.35 there are some bugs with the 4.4 type, so I'd use the latest build if you want to use this type.  The 8.8 type is more accurate, though, and works fine in 0.35.  It may be easier to use fixed point math than routines like the above, since you can assign, add and subtract decimal values.

1006839[/snapback]

 

Another way to get fractional-speed movement without adding fraction counters to everything is to keep a frame counter and then check it in certain ways to see if you should perform an action on any given frame.

 

For example, if you simply increment your frame counter on every frame, you can do something like:

  if (framecounter & 1) then enemy_position = enemy_position+1

to make the enemy move on every other frame (maybe you could even do

  enemy_position = enemy_position + (framecounter & 1)

but that might be trickier.

 

If you want to do something every fourth frame,

  if !(framecounter & 3) then do_something

would work. Doing non-power-of-two subdivisions can be tricky, but there are some ways that should translate adequately into bB. One difficulty with such methods, though, is that changing speeds on the fly may cause 'anomolies' in movement. Power-of-two motion doesn't have that problem.

[+batari]

You can also use fixed point math (see documentation).  In 0.35 there are some bugs with the 4.4 type, so I'd use the latest build if you want to use this type.  The 8.8 type is more accurate, though, and works fine in 0.35.  It may be easier to use fixed point math than routines like the above, since you can assign, add and subtract decimal values.

1006839[/snapback]

Another way to get fractional-speed movement without adding fraction counters to everything is to keep a frame counter and then check it in certain ways to see if you should perform an action on any given frame.

1006850[/snapback]

That's how we usually do things in assembly, as powers of two and binary go together well. Fixed point math does use extra RAM (and likely more ROM) but its use feels more like other BASICs, so it might feel more comfortable and easier to read if you've got the space to spare.

 

I should note some of Supercat's routines won't compile properly yet, even in the latest builds, but they will in an upcoming release. I just haven't got around to adding the support yet - I've got a bunch of stuff on my plate right now.

 

For now...

  if (framecounter & 1) then enemy_position = enemy_position+1

can be rewritten as:

  if framecounter{0} then enemy_position = enemy_position+1

 

This should compile properly in the latest build.

  enemy_position = enemy_position + (framecounter & 1)

 

And this:

  if !(framecounter & 3) then do_something

could be rewritten as this (assuming latest build):

  temp1=framecounter & 3: if !temp1 then do_something

Or, this should work in either the latest build or in 0.35:

  if !framecounter{0} && !framecounter{1} then do_something

[+Atarius Maximus]

Thanks for all the suggestions, guys. I've got a lot of work to do!

 

I made one more change this morning, the enemy cars are now randomly chosen between 5 different sprites. I still need to work a little on making the sprites look better, I was just concentrating on making the routine work for now.

 

I'll post the update on the first post in this thread in a few minutes.

 

Steve

[+Atarius Maximus]

I'm just about done with this game.

 

Scroll Speed has been tweaked using 8.8 variables. Your car will now slow down a little bit when you push down on the joystick, hit the side of the road, or hit an enemy car.

 

Now I plan on updating the car sprites and adding a few audio routines -- then calling this game done. I'm down to 96 bytes free, which I'll use all of adding audio. It's going to be a full 4k game. The only major thing left that I can't do is change around the enemy car movement -- but I think the game is challenging enough as is.

 

Slowing down when you hit the side of the road adds a new challenge, it can throw off your timing for swerving to the side of the road to avoid getting hit by the oncoming cars. It messed me up a little bit at first.

 

I updated the first post again with the latest build. I hope to finish this up late this evening, when I'll have a little more free time.

 

Steve

[vdub_bobby]

Looks very good! You've done a really nice job with this.

 

A few glitches, though...

 

-If you die when one of the car-pairs is shot, then we restarting the game only one car comes out at first.

-When only one enemy car exits the screen at the bottom right, the pair that appears at the top starts out off the road.

-There are some other wierd glitches with the enemy bullets, cars; especially related to dying and restarting. Make sure all variables are properly reset when a new game begins!

 

And a few more suggestions...

-A brief pause before dumping you back to the title screen would be nice.

-An indicator of how many more hits you can take before you die would also be nice.

-And, again...it would be nice if you could fire again immediately after shooting a car, rather than waiting for your bullet to make it to the top of the screen (kind of weird to watch it move up behind the side of the road).

 

 

Again, good job.

[+Atarius Maximus]

Looks very good!  You've done a really nice job with this.

 

A few glitches, though...

 

-If you die when one of the car-pairs is shot, then we restarting the game only one car comes out at first.

-When only one enemy car exits the screen at the bottom right, the pair that appears at the top starts out off the road.

-There are some other wierd glitches with the enemy bullets, cars; especially related to dying and restarting.  Make sure all variables are properly reset when a new game begins!

 

And a few more suggestions...

-A brief pause before dumping you back to the title screen would be nice.

-An indicator of how many more hits you can take before you die would also be nice.

-And, again...it would be nice if you could fire again immediately after shooting a car, rather than waiting for your bullet to make it to the top of the screen (kind of weird to watch it move up behind the side of the road).

 

 

Again, good job.

1007458[/snapback]

 

Thanks for the compliments. Your suggestions have really helped.

 

I figured I'd have to do a little bug fixing - I can't actually play the game for very long at my desk here at work (usually 5 second bursts), but having notepad running with a bunch of text on the screen doesn't look out of the ordinary.

 

All of the glitches you mention are probably related to variables not being reset - exactly what you pointed out. I'll try and take a look at that later tonight.

 

-A brief pause before dumping you back to the title screen would be nice.

 

How would I do that?

 

Also, what's the easiest way to implement a "pause" feature in the game itself? I attempted this and my initial plan didn't work - creating an infinite loop that would only be broken if the color/bw switch was set to color. This didn't work:

 

Main
 if switchbw then goto pause
 ...code...
pause
  if !switchbw then goto main
  goto pause

 

-An indicator of how many more hits you can take before you die would also be nice.

 

I would love to do this, but I'm not sure how I'd add an indicator to a scrolling playfield. I'm also about out of space in the ROM. I tried to add some scenery (like a tree) to the side of the road, but scrolling it down proved troublesome. I couldn't figure out how to clear the pixels behind it -- it would leave a trail of pixels and become a solid bar. I'd have the same problem with a "lives" indicator.

 

-And, again...it would be nice if you could fire again immediately after shooting a car, rather than waiting for your bullet to make it to the top of the screen (kind of weird to watch it move up behind the side of the road).

 

Heh...that was my "quick fix" to the problem of making the missile disappear from the road. There's no command to erase the missile from the screen, so I tried to "hide" it by shifting it's X position instead. Do you have any ideas on how I would code the missile to actually disappear from the screen when it hits a car?

 

Steve

[vdub_bobby]

Thanks for the compliments.    Your suggestions have really helped.

You're welcome. And I'm glad they've helped.

-A brief pause before dumping you back to the title screen would be nice.

 

How would I do that?

The thing to remember is that you have to continue to call Drawscreen all the time. So you're code wouldn't work. What I would do is this:

have a pause timer variable; PauseTimer.

Check this variable once every frame and if it is greater than zero, decrement it and skip all game logic; skip straight to Drawscreen.

Something like this:

Main
  if PauseTimer = 0 then goto GameRunningNormally
  PauseTimer=PauseTimer - 1
  Drawscreen
  goto Main
GameRunningNormally

So when the player dies, set this to 120 for a two second pause.

 

To use the BW-COLOR switch to pause the game, check the BW-COLOR switch once per frame and if it is at BW, set PauseTimer to 5 or something. Make sure you check the BW switch while the game is paused also.

  -An indicator of how many more hits you can take before you die would also be  nice.

 

I would love to do this, but I'm not sure how I'd add an indicator to a scrolling playfield.  I'm also about out of space in the ROM.  I tried to add some scenery (like a tree) to the side of the road, but scrolling it down proved troublesome.  I couldn't figure out how to clear the pixels behind it -- it would leave a trail of pixels and become a solid bar.  I'd have the same problem with a "lives" indicator.

Yeah that might be kinda tricky. Maybe by changing the color of the player's car?

Heh...that was my "quick fix" to the problem of making the missile disappear from the road.  There's no command to erase the missile from the screen, so I tried to "hide" it by shifting it's X position instead.  Do you have any ideas on how I would code the missile to actually disappear from the screen when it hits a car?

Well, once a missile hits something can't you just immediately reset it's position to wherever it was before you shot it?

 

[+Atarius Maximus]

Thanks for the compliments.     Your suggestions have really helped.

You're welcome. And I'm glad they've helped.

-A brief pause before dumping you back to the title screen would be nice.

 

How would I do that?

The thing to remember is that you have to continue to call Drawscreen all the time. So you're code wouldn't work. What I would do is this:

have a pause timer variable; PauseTimer.

Check this variable once every frame and if it is greater than zero, decrement it and skip all game logic; skip straight to Drawscreen.

Something like this:

Main
  if PauseTimer = 0 then goto GameRunningNormally
  PauseTimer=PauseTimer - 1
  Drawscreen
  goto Main
GameRunningNormally

So when the player dies, set this to 120 for a two second pause.

 

To use the BW-COLOR switch to pause the game, check the BW-COLOR switch once per frame and if it is at BW, set PauseTimer to 5 or something. Make sure you check the BW switch while the game is paused also.

  -An indicator of how many more hits you can take before you die would also be   nice.

 

I would love to do this, but I'm not sure how I'd add an indicator to a scrolling playfield.  I'm also about out of space in the ROM.  I tried to add some scenery (like a tree) to the side of the road, but scrolling it down proved troublesome.  I couldn't figure out how to clear the pixels behind it -- it would leave a trail of pixels and become a solid bar.  I'd have the same problem with a "lives" indicator.

Yeah that might be kinda tricky. Maybe by changing the color of the player's car?

Heh...that was my "quick fix" to the problem of making the missile disappear from the road.  There's no command to erase the missile from the screen, so I tried to "hide" it by shifting it's X position instead.  Do you have any ideas on how I would code the missile to actually disappear from the screen when it hits a car?

Well, once a missile hits something can't you just immediately reset it's position to wherever it was before you shot it?

 

1007521[/snapback]

 

Thanks for explaining the pause feature - that makes perfect sense. I think changing the car color is a very good idea, and would be a good substitute for an indicator bar. I could have 4 or five levels of color - maybe blue-orange-yellow-red-"dead". Re: the missile position - sometimes it's amazing how I can miss the most obvious solutions to problems.

 

Hopefully I'll be able to fix all the bugs when the game resets - and get this thing done in the next few days.

 

Steve

[+Atarius Maximus]

Thanks for the compliments.     Your suggestions have really helped.

You're welcome. And I'm glad they've helped.

-A brief pause before dumping you back to the title screen would be nice.

 

How would I do that?

The thing to remember is that you have to continue to call Drawscreen all the time. So you're code wouldn't work. What I would do is this:

have a pause timer variable; PauseTimer.

Check this variable once every frame and if it is greater than zero, decrement it and skip all game logic; skip straight to Drawscreen.

Something like this:

Main
  if PauseTimer = 0 then goto GameRunningNormally
  PauseTimer=PauseTimer - 1
  Drawscreen
  goto Main
GameRunningNormally

So when the player dies, set this to 120 for a two second pause.

 

To use the BW-COLOR switch to pause the game, check the BW-COLOR switch once per frame and if it is at BW, set PauseTimer to 5 or something. Make sure you check the BW switch while the game is paused also.

  -An indicator of how many more hits you can take before you die would also be   nice.

 

I would love to do this, but I'm not sure how I'd add an indicator to a scrolling playfield.  I'm also about out of space in the ROM.  I tried to add some scenery (like a tree) to the side of the road, but scrolling it down proved troublesome.  I couldn't figure out how to clear the pixels behind it -- it would leave a trail of pixels and become a solid bar.  I'd have the same problem with a "lives" indicator.

Yeah that might be kinda tricky. Maybe by changing the color of the player's car?

Heh...that was my "quick fix" to the problem of making the missile disappear from the road.  There's no command to erase the missile from the screen, so I tried to "hide" it by shifting it's X position instead.  Do you have any ideas on how I would code the missile to actually disappear from the screen when it hits a car?

Well, once a missile hits something can't you just immediately reset it's position to wherever it was before you shot it?

 

1007521[/snapback]

 

Thanks for explaining the pause feature - that makes perfect sense. I think changing the car color is a very good idea, and would be a good substitute for an indicator bar. I could have 4 or five levels of color - maybe blue-orange-yellow-red-"dead". Re: the missile position - sometimes it's amazing how I can miss the most obvious solutions to problems.

 

Hopefully I'll be able to fix all the bugs when the game resets - and get this thing done in the next few days.

 

Steve

1007569[/snapback]

 

I've managed to add most of the suggestions you mentioned. The game now pauses for a few seconds after you die, and your car progressively changes colors as you take damage. That adds alot to the game, and was a great idea -- thanks. I also added all of the variables to the list at the top, and they're all reset to what I think they should be at the beginning of the game -- now when you reset the game they should all be correct. I still see a bug that I'm not sure about, if you wait a long time to reset the game after you die, the game restarts at a higher speed briefly.

 

I still can't figure out how to make the missile properly disappear after it hits an enemy car. I can reset the X position of the missile after a hit, but it doesn't seem to matter what i reset the Y position to, the missile continues on up the screen. I tried resetting missile0y to 1 after a hit is detected, thinking it would immediately jump to the top of the screen and scroll off before you could even see it -- but it doesn't work.

 

I had to make a few concessions due to lack of available ROM space, as I'm now down to 3 bytes free. I removed all of the audio routines I had in there (they were all untested anyway), and I removed one of the 5 possible enemy car sprites, there's now only four. I'm completely out of space to add any more features. I guess there won't be any sound in this game.

 

I guess I could use some ideas/code samples for making the missile disappear when it hits a sprite, and any other code cleanup suggestions would also be appreciated.

 

Updated code will be posted on the first post shortly.

 

Steve

[Atariboy2600]

Once this game is done I like to use this label I made for it

[supercat]

I still can't figure out how to make the missile properly disappear after it hits an enemy car.  I can reset the X position of the missile after a hit, but it doesn't seem to matter what i reset the Y position to, the missile continues on up the screen.  I tried resetting missile0y to 1 after a hit is detected, thinking it would immediately jump to the top of the screen and scroll off before you could even see it -- but it doesn't work. 

 

You need to set missile0y and q both to zero. Otherwise missile0y will get reloaded from q.

 

I had to make a few concessions due to lack of available ROM space, as I'm now down to 3 bytes free.  I removed all of the audio routines I had in there (they were all untested anyway), and I removed one of the 5 possible enemy car sprites, there's now only four.  I'm completely out of space to add any more features.  I guess there won't be any sound in this game. 

 

I'm pretty certain that your title screen uses up a LOT more code than it has to. I think I see 121 playfield flip commands there. EOG has another 24. Every one of those commands is 9 bytes, so that's 1305 bytes there--more than 31% of your code space!. I don't know the best way to generate the playfield in BatariBasic, but in machine code it would take less than 64 bytes--a savings of over 1200 bytes.

[+batari]

I'm pretty certain that your title screen uses up a LOT more code than it has to.  I think I see 121 playfield flip commands there.  EOG has another 24.  Every one of those commands is 9 bytes, so that's 1305 bytes there--more than 31% of your code space!.  I don't know the best way to generate the playfield in BatariBasic, but in machine code it would take less than 64 bytes--a savings of over 1200 bytes.

1007838[/snapback]

Yes, I agree - plotting the playfield a pixel at a time takes up a lot of space.

 

The latest build has a new playfield command to specify an entire screen at once, which makes it easy and saves a lot of space.

 

If you are using 0.35, it's still possible to save space by using a data statement, then a for-next loop to copy the bytes to the playfield RAM, but it's not as easy to specify the playfield this way since half of the bytes have reversed bit order (BTW, the playfield command above reverses the appropriate bits for you.)

Edited January 27, 2006 by batari

[+Atarius Maximus]

Thanks, supercat, for pointing out the problem with resetting the missile. I don't know why I didn't see that q needed to be reset to 0 as well. I updated the code and bin, and reposted the result at the beginning of the thread. You're right about the playfield, it's using up way too much ROM space - I need to figure out a different way to do that.

 

batari - I think I'm using the latest version, I downloaded the "bleeding edge build 99a" from your blog. Can you give me any more detail on the new playfield command and how to use it? I could also use the title.bas file you posted in the Solar Plexus thread as a title screen for this game-- although that would take up a good bit of ROM space too I would think.

 

Now down to 1 byte free! :!:

 

Steve

Edited January 27, 2006 by Atarius Maximus

[+Atarius Maximus]

Once this game is done I like to use this label I made for it

1007830[/snapback]

 

Nice label, Atariboy2600. This game was inspired by the old RoadBlasters arcade game, but I dropped the "s" just to make it a little more non-copyright infringing.

 

Steve

[+Atarius Maximus]

If you are using 0.35, it's still possible to save space by using a data statement, then a for-next loop to copy the bytes to the playfield RAM, but it's not as easy to specify the playfield this way since half of the bytes have reversed bit order (BTW, the playfield command above reverses the appropriate bits for you.)

1007846[/snapback]

 

What is the appropriate method to use the data tables? I attempted to rewrite the title screen with this method (replacing all of those individual pfpixel commands), and the code below gives me a compilation error. I'm sure I did something wrong, I'm just not sure what.

 

I checked on the title screen code that you posted in the Solar Plexus thread, and even after removing all of the title screen data from my RoadBlaster code, adding the title.bas code makes the ROM about 6.5k.

 

intro
 data g : rem Title Screen X Data
 0,7,12,0,5,14,5,11,0,7,15,2,11,16,21,27
 0,12,27,2,11,16,24,30,9,23,1,7,15,23,30
 1,3,9,14,1,7,17,7,12,3,9,16,5,12,17,23
 28,3,14,30,5,12,17,27,0,12,27,2,9,16,24
 2,5,10,15,2,9,0,9,14,5,12,0,9,14,19,24
 29,5,20,0,9,14,20,28,3,17,29,5,12,17,25
 3,6,11,16,3,12,2,10,17,6,14,1,10,15,20
 25,30,9,23,1,10,15,23,29,5,20,0,6,14,20,27
end
 data s : rem Title Screen Y Data
 1,1,1,2,2,2,3,3,4,4,4,6,6,6,6,6,7,7,7,8
 8,8,8,8,9,9,10,10,10,10,10,0,1,1,1,2,2
 2,3,3,4,4,4,6,6,6,6,6,7,7,7,8,8,8,8,9,9
 9,10,10,10,10,0,1,1,1,2,2,3,3,3,4,4,6,6
 6,6,6,6,7,7,8,8,8,8,8,9,9,9,10,10,10,10
 0,1,1,1,2,2,3,3,3,4,4,6,6,6,6,6,6,7,7,8
 8,8,8,8,9,9,10,10,10,10,10
end
 for e = 1 to 125 : for y = 1 to 125 : pfpixel g[e] s[y] flip : next : next 
 rem -- tried this too:  for e = 1 to 125 : pfpixel g[e] s[e] flip : next
 drawscreen

[+batari]

If you are using 0.35, it's still possible to save space by using a data statement, then a for-next loop to copy the bytes to the playfield RAM, but it's not as easy to specify the playfield this way since half of the bytes have reversed bit order (BTW, the playfield command above reverses the appropriate bits for you.)

1007846[/snapback]

 

What is the appropriate method to use the data tables? I attempted to rewrite the title screen with this method (replacing all of those individual pfpixel commands), and the code below gives me a compilation error. I'm sure I did something wrong, I'm just not sure what.

 

I checked on the title screen code that you posted in the Solar Plexus thread, and even after removing all of the title screen data from my RoadBlaster code, adding the title.bas code makes the ROM about 6.5k.

g and s are reserved, so this confuses the compiler. This should work:

 

intro
 data gg : rem Title Screen X Data
 0,7,12,0,5,14,5,11,0,7,15,2,11,16,21,27
 0,12,27,2,11,16,24,30,9,23,1,7,15,23,30
 1,3,9,14,1,7,17,7,12,3,9,16,5,12,17,23
 28,3,14,30,5,12,17,27,0,12,27,2,9,16,24
 2,5,10,15,2,9,0,9,14,5,12,0,9,14,19,24
 29,5,20,0,9,14,20,28,3,17,29,5,12,17,25
 3,6,11,16,3,12,2,10,17,6,14,1,10,15,20
 25,30,9,23,1,10,15,23,29,5,20,0,6,14,20,27
end
 data ss : rem Title Screen Y Data
 1,1,1,2,2,2,3,3,4,4,4,6,6,6,6,6,7,7,7,8
 8,8,8,8,9,9,10,10,10,10,10,0,1,1,1,2,2
 2,3,3,4,4,4,6,6,6,6,6,7,7,7,8,8,8,8,9,9
 9,10,10,10,10,0,1,1,1,2,2,3,3,3,4,4,6,6
 6,6,6,6,7,7,8,8,8,8,8,9,9,9,10,10,10,10
 0,1,1,1,2,2,3,3,3,4,4,6,6,6,6,6,6,7,7,8
 8,8,8,8,9,9,10,10,10,10,10
end
 for e = 0 to 124 : pfpixel gg[e] ss[e] flip : next
 drawscreen

[supercat]

...
 data g : rem Title Screen X Data
 0,7,12,0,5,14,5,11,0,7,15,2,11,16,21,27
 0,12,27,2,11,16,24,30,9,23,1,7,15,23,30
...
 data s : rem Title Screen Y Data
 1,1,1,2,2,2,3,3,4,4,4,6,6,6,6,6,7,7,7,8
 8,8,8,8,9,9,10,10,10,10,10,0,1,1,1,2,2
...

1008128[/snapback]

 

Storing the XY data is less efficient than storing the bitmap, but is a big improvement over how the code was before. You could cut the storage in half, however, by doing something like the following:

i=0
loopy:
 q=titledata[i]
 if q==255 then goto alldone
 i=i+1
 if q(7) then x=q & 31:goto loopy
 if q(6) then x=x+1
 q=q & 15
 pfpixel x q flip
 goto loopy
alldone:

The points should all be stored in order of X coordinate. The numbers in the data list have the following meanings:

 

0-11 : Plot a point at the specified Y coordinate in the last X coordinate

 

64-75 : Plot a point at the specified Y coordinate minus 64, at the previous X coordinate plus one

 

128-159 : Set X coordinate to #-128

 

255 : End of data

 

There would be other ways of adding more information to the encoding so as to further reduce the amount of data required, but it probably isn't worth doing too much with that sort of thing unless you want to have an animated title screen which slowly draws the letters (like StarFire, but in low resolution). Otherwise Batari's bitmap facilities will likely render such efforts obsolete.

 

BTW, note that it's important that the data start by setting the X coordinate before doing any drawing, and that the data end with 255; otherwise the results could be unpredictable.

[+Atarius Maximus]

Thank you batari & supercat for your suggestions -- I wouldn't have been able to do what I've done in this game without your help.

 

For now, I used batari's suggestion of simply changing the data table names, which was a simple fix that freed up 840 bytes of ROM Space. :!: That may be enough extra space for me to make all of the additional changes i'd like to make. If not, I'm going to work at using supercat's routine that would save even more space.

 

I'm not posting an update now, as the game hasn't changed except for the code crunching. Time to get back to work on it!

 

Steve

[+Atarius Maximus]

Ok, a new version is ready! There are several changes, and I still have 627 bytes free.

 

1. Audio has been added. It's amazing how much this adds to the game!

- There is a constant engine rumble sound

- The engine sound revs up when you go faster

- The engine sound slows when you slow down

- Missile shot sounds from both player and enemy car

2. On difficulty level A, the shot now fires from the center of the double size car.

3. The tires turn left and right when you move your car left and right.

4. The player and enemy car sprites are now cleared when the game is reset

to the title screen -- you no longer see them behind the "RoadBlaster" text.

 

Nagging Bugs:

 

1. You still can't destroy the remaining car after one car has been hit. I played around with that for about an hour tonight -- can't figure it out.

2. Sometimes when you hit a car (with a missile) near the edge of the road, it will push it off the road, and it swerves right back on. It's really just a visual type bug, it doesn't affect gameplay. Maybe this one doesn't really matter?

3. It seems that if you play the game at full speed, occassionally the enemy car movement gets messed up - and they start completely off the road at the top of the screen. It doesn't happen very often, and I have no idea why.

 

Future Changes:

 

1. I may still work a little on enemy car movement, although it seems pretty good as is. Any thoughts or suggestions on this?

 

I'll update the first post with the new bin & source shortly.

 

Steve

Edited January 28, 2006 by Atarius Maximus

[vdub_bobby]

3.  It seems that if you play the game at full speed, occassionally the enemy car movement gets messed up - and they start completely off the road at the top of the screen.  It doesn't happen very often, and I have no idea why.

Did you see my post above? Is it related to that?

 

EDIT: Suggestions...

 

-Increase scoring rate when driving faster; decrease when driving slower.

-Does the difficulty increase at all? It should. Probably the easiest way would to make the enemies' missiles move faster. Other ways would be to increase the scrolling speed. Another way would be to change the enemy movement patterns. Maybe at first they just move straight down, then eventually, move L/R smoothly and predictably, with the current, random movement as one of the higher difficulty levels.

-Another big one: add in a way to repair your car; perhaps by picking up an object off the road or something; or just repairing at certain point levels (evey 20,000 points? Every 50,000?)

Edited January 30, 2006 by vdub_bobby

[+Atarius Maximus]

3.  It seems that if you play the game at full speed, occassionally the enemy car movement gets messed up - and they start completely off the road at the top of the screen.  It doesn't happen very often, and I have no idea why.

Did you see my post above? Is it related to that?

 

EDIT: Suggestions...

 

-Increase scoring rate when driving faster; decrease when driving slower.

-Does the difficulty increase at all? It should. Probably the easiest way would to make the enemies' missiles move faster. Other ways would be to increase the scrolling speed. Another way would be to change the enemy movement patterns. Maybe at first they just move straight down, then eventually, move L/R smoothly and predictably, with the current, random movement as one of the higher difficulty levels.

-Another big one: add in a way to repair your car; perhaps by picking up an object off the road or something; or just repairing at certain point levels (evey 20,000 points? Every 50,000?)

1009584[/snapback]

 

Great suggestions, thanks. I should be able to implement all of those ideas, if I can fit it all in the remaining ROM space. Repairing your car would probably have to be done at specific point levels. As far as picking up a powerup, I'm already using the ball object for the roadblock, and I don't think I can get a single pfpixel to scroll properly without leaving a trail of pixels behind it.

 

I checked your previous post again. It probably is related to variables not being set properly. I suspect it may be related to when I shift the X-position of the enemy car when one is hit -- it may be shifting it off the side of the road at the bottom, causing it to start off the road at the top.

 

I'm still trying to figure out the correct logic for blowing up the enemy cars. I've read and re-read the posts by batari and supercat and tried a dozen different methods, but I haven't figured it out as of yet. I need to be able to shoot either car and have it disappear, and then have the remaining car disappear too if it's shot before it scrolls off the screen.

 

If you can provide any further clarification on what batari & supercat have posted, that would be fantastic. I've stared at it for so long I'm getting crosseyed, I need someone else to take a look. Below is the very incomplete code I've got so far, which I was thinking I would use to replace what's in my existing "carhit" subroutine. I've tried lots of different methods to flesh out this logic, and nothing has worked as I planned.

 

  rem Z is NUSIZ1 flag - If z=0,NUSIZ1 is $00  // if z=1,NUSIZ1 is $01
 rem W is current Missile0x location
 rem U is Computer Car's X Position
 rem A is Computer Car's Y Position + 8
 rem scroll is Computer Car's Y Position
 rem
 if !collision(player1,missile0) then goto nocollision
 w=missile0x : rem set W to the current X position of the Player's missile
 a=scroll+8:if w > a then u=u+16 : NUSIZ1=$00 : z=0
  rem if the shot is registered >8 over from the enemy car, the right car's been shot
  rem I then set NUSIZ1 to 0, to remove a car, and shift the X position of the
  rem computer car 16 to the right.
  rem next line - if z is 0, then one car has already been shot.  I could put a statment
  rem at the beginning of the main game loop:  if z=1 then NUSIZ1=$01.
  if z =0 then: rem what do I do to remove the remaining car?
  if ? then ? :  rem what about resetting back to 2 cars if the single car isn't hit
                  rem before it scrolls off the bottom of the screen?
  score=score+1000 : missile0y=0 : q=0 : rem increase score, reset player missile.
nocollision

Edited January 30, 2006 by Atarius Maximus

[vdub_bobby]

Repairing your car would probably have to be done at specific point levels. As far as picking up a powerup, I'm already using the ball object for the roadblock, and I don't think I can get a single pfpixel to scroll properly without leaving a trail of pixels behind it.

Or you could use the enemy sprite. Or have random enemy cars turn into powerups when shot.

[+Atarius Maximus]

EDIT: Suggestions...

 

-Increase scoring rate when driving faster; decrease when driving slower.

-Does the difficulty increase at all?  It should.  Probably the easiest way would to make the enemies' missiles move faster.  Other ways would be to increase the scrolling speed.  Another way would be to change the enemy movement patterns.  Maybe at first they just move straight down, then eventually, move L/R smoothly and predictably, with the current, random movement as one of the higher difficulty levels.

-Another big one:  add in a way to repair your car; perhaps by picking up an object off the road or something; or just repairing at certain point levels (evey 20,000 points?  Every 50,000?)

1009584[/snapback]

 

I didn't really do any bug fixing on this revision - there's still plenty of them, but I did add a few new features based on your suggestions:

 

1. Point Scoring : 20 Pts per frame, -10 per frame when you slow down, +10 per frame when you speed up.

2. Difficulty levels have been implemented. The Enemy car color changes when the difficulty level increases.

--Level 1: Cars Drive Straight, change lanes very slowly. This goes for about 8 scrolls. (1 Scroll being the enemy cars have scrolled off the screen once). The first level is random in length, as Level 2 starts when one of the enemy cars touches the side of the road, which seems to happen by the 8th scroll most of the time.

--Level 2: Cars Start zig zagging in a predictable pattern. Enemy car color changes to yellow. This lasts from about scroll #8 until #21.

--Level 3: Cars start moving in a more random manner, similar to how the game was before all the time. The enemy car color changes to purple. This lasts from about scroll #22 until #30.

--Level 4: Cars still move more randomly, but now move and fire twice as fast. The enemy cars change color to red. This lasts from scroll #31 until the end of the game.

3. I'm still working on the power up and/or point reward system for repairing your car.

 

All of the bugs from my previous post still exist...shooting enemy cars still doesn't work properly, although you will score the proper amount of points. Resetting the game may also cause a problem intermittently.

 

Steve

Edited January 31, 2006 by Atarius Maximus