[WIP] [PORT] Beyond Parsec

[KevKelley]

Game Title: 

 

Beyond Parsec

 

Gameplay:

 

This is a port of the 1988 Texas Instruments 99/4a game by John Phillips that I wanted to try making for sometime. As some may know the TI 99/4a was my first computer.  I never had this game but had played it a couple years ago when I bought a FinalGROM cartridge and thought it was awesome. I had also tried to figure out how to make this work and originally thought about simplifying gameplay but eventually landed on using DPC+ and after reading in the forums (I think it was a Robot Zed thread) I decided to experiment using the DPC+ stack. 

 

The basic idea is that there are ten asteroids and two spaceships.  Each player controls a spaceship and can move back or forth and fire.  You can fire at the asteroids to make them accelerate or decelerate in either direction, shoot the opposing player, or crash into the opposing player, all while dodging asteroids.

 

Here is a quick video of the gameplay test where I have all the asteroids moving: CLICK HERE

 

This game is not finished.  Right now I have preliminary code for the asteroid movement but I notice that the scanlines jump to 263 every once and a while when the laser is fired but I noticed when I remove one collision statement detecting the laser hitting the asteroid I don't have an issue apart from the asteroids moving really slowly.  There are some tweaks I need to make before I continue, as right now the player just has to be on the same y-coordinates as the asteroid and fire but I want to make the collision more precise, and this kind of ties in with the first issue I am having.  I am still trying to hammer out those details but it is exciting to see all the moving parts.

 

I also need to program the city at the bottom of the screen, the second player firing, and the spaceship collisions. Those shouldn't be too hard once I get the movement worked out and hope I can figure them out in the next week or two.

 

If I get all that taken care of I want to try to add a little bit of a twist to this game, maybe by adding either more obstacles, gun turrets at the bottom of the screen, teleporters, or random enemy spaceships.

 

I am including the .bin and the .bas in case anyone wants to peak under the hood. 

 

 

 

BP_2023_03_21_10AST.bas BP_2023_03_23_8AST.bas BP_2023_03_23_8AST.bas.bin

BP_2023_04_01_8AST_b.bas.bin

BP_2023_07_29_8AST_g.bas.bin

BP_2023_09_25_8AST_g.bas.bin

Edited September 25, 2023 by KevKelley

[KevKelley]

Whenever I watch @ZeroPage Homebrew I always love when James tries to guess what sprite is what. I like to do the same as it is fun to see how programmers use what the Atari has to offer. 
 

I will state what is what in this spoiler in case anyone was curious. 
 

Spoiler

Both spaceships are player0. 
 

All of the asteroids are copies of player1 (in DPC+ player2-6).

 

The laser is missile0. 
 

I have ten asteroids, of the 10 asteroids I alternate every other asteroid and they are drawn every other frame. This is to get the asteroids as close as possible. The spaceships are player0 to prevent any additional flicker.

 

Yet to be programmed will be the city, which will probably be a mixture of playfield and a couple copies of player1 and if I make a modified gameplay option I plan on using player7-9 and the ball.The enemy laser will be missile1.

 

Edited March 13, 2023 by KevKelley

[+Karl G]

That's pretty cool! I'm looking forward to seeing this one develop more. I tried to find videos of the original game, but I've not found anything that shows more than a couple of seconds of gameplay, unfortunately. The concept seems pretty simple, but fun though.

 

Here's some tips on not running out of cycles (easy to do with DPC+!). I'm sure you know some of these already, but just for reference:

• It's cool to see you making use of the DPC+ stack, since that is underutilized. Since stack access is a bit slower, I would suggest using regular variables instead for some of your more frequently-accessed variables like for swapping the player position variables, though. You have 26 regular varables, 8 more from var0 - var8, then one more that is unused in the memory map, so you can do more than you are doing now without having to use the stack for everything.
• Add a frame counter variable, and have some game logic and/or collision checks happen only every other frame to save cycles
• When checking for multiple conditions where only one can be true, it will save cycles to skip redundant checks. For example, you have:

 stack 198
 pull player0x player0y

 if joy0up then player0y=player0y-2
 if joy0down then player0y=player0y+2
 if joy0left then player0x=player0x-2:REFP0=8: n{0}=1
 if joy0right then player0x=player0x+2:n{0}=0
 stack 200
 push player0x player0y

 

I would change that tho the following to skip redundant check, and also to avoid an unnecessary stack push in case there's no change in the player's position:

 

 stack 198
 pull player0x player0y

 if joy0up then player0y=player0y-2 : goto _do_save_p0_position
 if joy0down then player0y=player0y+2 : _do_save_p0_position
 if joy0left then player0x=player0x-2:REFP0=8: n{0}=1 : _do_save_p0_position
 if joy0right then player0x=player0x+2:n{0}=0
 goto _skip_save_p0_position ; player hasn't moved
_do_save_p0_position 
 stack 200
 push player0x player0y
_skip_save_p0_position

 

[KevKelley]

3 hours ago, Karl G said:

That's pretty cool! I'm looking forward to seeing this one develop more. I tried to find videos of the original game, but I've not found anything that shows more than a couple of seconds of gameplay, unfortunately. The concept seems pretty simple, but fun though.

 

Here's some tips on not running out of cycles (easy to do with DPC+!). I'm sure you know some of these already, but just for reference:

• It's cool to see you making use of the DPC+ stack, since that is underutilized. Since stack access is a bit slower, I would suggest using regular variables instead for some of your more frequently-accessed variables like for swapping the player position variables, though. You have 26 regular varables, 8 more from var0 - var8, then one more that is unused in the memory map, so you can do more than you are doing now without having to use the stack for everything.
• Add a frame counter variable, and have some game logic and/or collision checks happen only every other frame to save cycles
• When checking for multiple conditions where only one can be true, it will save cycles to skip redundant checks. For example, you have:

 stack 198
 pull player0x player0y

 if joy0up then player0y=player0y-2
 if joy0down then player0y=player0y+2
 if joy0left then player0x=player0x-2:REFP0=8: n{0}=1
 if joy0right then player0x=player0x+2:n{0}=0
 stack 200
 push player0x player0y

 

I would change that tho the following to skip redundant check, and also to avoid an unnecessary stack push in case there's no change in the player's position:

 

 stack 198
 pull player0x player0y

 if joy0up then player0y=player0y-2 : goto _do_save_p0_position
 if joy0down then player0y=player0y+2 : _do_save_p0_position
 if joy0left then player0x=player0x-2:REFP0=8: n{0}=1 : _do_save_p0_position
 if joy0right then player0x=player0x+2:n{0}=0
 goto _skip_save_p0_position ; player hasn't moved
_do_save_p0_position 
 stack 200
 push player0x player0y
_skip_save_p0_position

 

Thanks! I will have to see if I can either record my system or find an emulator and record longer gameplay. I could only find the videos that are like 20 seconds so I want to make sure if there are more gameplay elements that I need to account for. 
 

I did wonder, by slower, do you mean accessing the stack takes more cycles? I wasn’t sure if it did or not but I initially used the stack after reading posts from @Sprybug that I thought it may be something of use for this game. I kind of did something similar but with variables for my Red Light Green Light game, where I saved and read variables to alternate sprite positions. Starting this game I didn’t know how many variables I may use and my initial thought had each asteroid using 5 variables so I didn’t want to box myself in a corner.
 

I also didn’t know if pushing multiple things to the stack at once saved any cycles or was more of a benefit. 

 

I do use the w variable for my timer and currently use it to switch which group of asteroids and player is loaded. If I fix my collision detection and make some of the improvements you mention I can’t imagine this game requiring much more. I had been looking at the code to see how I can simplify things more. I felt reusing player0 and the five virtual sprites made things a little more manageable. I had thought about using missile0 for both ship lasers to save more as well but once I get the asteroid code done I’ll try to figure out the player movement. 
 

I think having everything moving around will be exciting and offer some frantic gameplay. I was just happy I got all the asteroids moving independently. 

[+Karl G]

Yes, I did mean more cycles when I said slower. Also you are right that pushing and pulling multiple values is a lot more efficient than doing them separately. If the game works out fine without any of my optimization tips, then all the better, but you mentioned reaching 263 scanlines, so I thought I would give some tips on how to use less cycles per frame. Having that many moving objects is cool, and I bet the end result will be a lot of fun.

[KevKelley]

2 hours ago, Karl G said:

Yes, I did mean more cycles when I said slower. Also you are right that pushing and pulling multiple values is a lot more efficient than doing them separately. If the game works out fine without any of my optimization tips, then all the better, but you mentioned reaching 263 scanlines, so I thought I would give some tips on how to use less cycles per frame. Having that many moving objects is cool, and I bet the end result will be a lot of fun.

I will definitely use some of your tips. A lot of time I kind of program real quick on my lunches and test it fast and then spend the rest of my day trying to figure it out. Part of me thought the scanline issue was a result of collision detection between missile0 and player1 and since all the sprites are copies this may be resulting in a lot of unnecessary checks occurring simultaneously… or at least that’s my guess.
 

But every little cycle saver helps. Some things I never changed in the past only because I never needed it. But this explains some of the code I had copied when learning. 

[KevKelley]

So I think I got the scanline issue under control by getting rid of my numerous redundant checks for the asteroids, I wound up checking the coordinates 6 times.  I added a few gotos to skip over the checks not needed and no more scanline issue.  The next thing I need to figure out is fine tuning the collision as for some reason when I try to skip over the detection for each asteroid it kind of has a stop and go effect. I also need to figure out how to get the second player shooting in without using too much but I think this is well on track. 

[KevKelley]

So my goal now is to try and make the collision for the second player’s laser and the asteroids. Considering the size of the code, I want to try and see if there is a way to utilize the collision for both lasers. I figure I have to have the missiles draw every frame so they can detect a hit with every asteroid or opposing players. Not sure if something like this could work. 

[+Gemintronic]

On 3/14/2023 at 8:09 PM, KevKelley said:

So I think I got the scanline issue under control by getting rid of my numerous redundant checks for the asteroids, I wound up checking the coordinates 6 times.  I added a few gotos to skip over the checks not needed and no more scanline issue.  The next thing I need to figure out is fine tuning the collision as for some reason when I try to skip over the detection for each asteroid it kind of has a stop and go effect. I also need to figure out how to get the second player shooting in without using too much but I think this is well on track. 

 

I've used a system for both 2600 and Genesis games that splits soft collision checks between frames.

 

temp2 = counter&7

on temp2 goto p0p2col p0p3col p0p4col p0p5col p1p2col p1p3col p1p4col p1p5col 

 

That means collision is less accurate since each object isn't checked every frame, but.. cycles!

 

[KevKelley]

1 hour ago, Gemintronic said:

 

I've used a system for both 2600 and Genesis games that splits soft collision checks between frames.

 

temp2 = counter&7

on temp2 goto p0p2col p0p3col p0p4col p0p5col p1p2col p1p3col p1p4col p1p5col 

 

That means collision is less accurate since each object isn't checked every frame, but.. cycles!

 

This is interesting! I still haven’t fired up my TI to see exactly how the game plays (it’s been a while) but I don’t think precision is a huge deal with the asteroids. I also imagine collision not being checked every frame not to be a huge deal, since the laser is a wide missile so at some point it will traverse through a sprite. 
 

I guess one of the big issues I was finding was that of space. I have the collision detection for player0 and the asteroids, with each set of 5 asteroids taking up over 3k. I use missile0 as the laser and it is checked every frame so it will hit every asteroid or player, since they are flickered.
 

I did experiment yesterday flickering the missile as well and have it be used for both players so I could reuse the collision statements in the 2 banks… but then the issue I get is the missile detects collision for every other asteroid. I had thought I could make some checks and then substitute those checks in my collision statements, so I could define a variable and then replace the checks I currently have with that variable… but so far each time I tried has not had the desired results. I know I am probably missing something simple and I’ll eventually figure it out. 
 

I could just use two more banks for the collision detection for player1. That would be the easiest solution, since I know it works so I could be done with it and then shove title screen in the nooks and cranny but I also want to try and add an option for additional gameplay elements that may take up a little more space, like at least a kind of 1-player mode. 

[KevKelley]

I have a few more ideas I want to explore before I take the easy way out. As frustrating as it is it is also kind of fun to figure it out. 
 

Even typing this out I had a thought as to why my previous attempts failed so I will test that too!

[KevKelley]

So after a little work, I simplified some of the code and tried to eliminate much of the redundancies.  I have both players able to fly around and shoot and the asteroids move around back and forth.  I am hovering around 265 cycles so I am just looking to see what else I can try to fix to get this thing working well before moving on.  I uploaded a new .bas and .bin in the first post. 

[+Karl G]

Although your use of the stack is excellently done, I think it's just too many cycles to have that much stack access every frame. Here's what I propose:

 

• Reduce the number of asteroids to 9, and space them accordingly. Instead of flickering half of them on and off every frame like you do now, display them all at once using the normal position variables for virtual sprites 1-9
• Dim normal variables for the second part of the asteroid's 8.8 X position variables. For 9 asteroinds, this will be 9 variables needed.
• Dim normal variables for the asteroid velocities. For 9 asteroids using 8.8 variables, this will be 18 variables needed
• Dim normal variables for each player position. This will be two more variables.
• Here's the fun part: Instead of using a variable to track the direction of the asteroid, take advantage of the fact that there are only two possible directions, and the fact that for DPC+ virtual sprites, the reflect bit is both readable and writable as bit 3 of NUSIZx. You would set the reflect bit if e.g. the asteroid is going right, or clear it if it is going left. When moving each asteroid, you would check bit 3 of the appropriate NUSIZx variable to see if you should add or subtract the velocity to/from that asteroid's X position.

All of the above would require dimming 29 variables out of a total of 36 DPC+ variables available (26 A-Z, 9 var0-var8, and one unused in the memory map). Not only would this be a ton faster without all of the stack access and swapping things around every frame, but it would also look better by completely eliminating the flicker of the asteroids. I think your current system of flickering player0 is still good though to have a consistent leverl of flicker for the players that doesn't vary with the players' positions relative to the asteroids.

[KevKelley]

1 hour ago, Karl G said:

Although your use of the stack is excellently done, I think it's just too many cycles to have that much stack access every frame. Here's what I propose:

 

• Reduce the number of asteroids to 9, and space them accordingly. Instead of flickering half of them on and off every frame like you do now, display them all at once using the normal position variables for virtual sprites 1-9
• Dim normal variables for the second part of the asteroid's 8.8 X position variables. For 9 asteroinds, this will be 9 variables needed.
• Dim normal variables for the asteroid velocities. For 9 asteroids using 8.8 variables, this will be 18 variables needed
• Dim normal variables for each player position. This will be two more variables.
• Here's the fun part: Instead of using a variable to track the direction of the asteroid, take advantage of the fact that there are only two possible directions, and the fact that for DPC+ virtual sprites, the reflect bit is both readable and writable as bit 3 of NUSIZx. You would set the reflect bit if e.g. the asteroid is going right, or clear it if it is going left. When moving each asteroid, you would check bit 3 of the appropriate NUSIZx variable to see if you should add or subtract the velocity to/from that asteroid's X position.

All of the above would require dimming 29 variables out of a total of 36 DPC+ variables available (26 A-Z, 9 var0-var8, and one unuzed int he memory map). Not only would this be a ton faster without all of the stack access and swapping things around every frame, but it would also look better by completely eliminating the flicker of the asteroids. I think your current system of flickering player0 is still good though to have a consistent leverl of flicker for the players that doesn't vary with the players' positions relative to the asteroids.

These are all great. I am hesitant only because I don’t want to do a big rewrite yet. I kind of want to keep the 10 asteroids to try to be as close to the original as possible. I just got it down to 262 cycles and it only jumps to 263 or 264 so I think I can get it closer with a few more tweaks. 
 

I do love the creative use of the reflect bit. I had considered something similar but I couldn’t figure out what to do if the asteroid was still, which is why I landed on using a variable. 
 

I have some down time tonight so I hope to relax and play around with this some more. Perhaps I can mix some of your solutions into the game. I think one big issue I found was I had a lot of unnecessary stuff that I was able to eliminate. I just hope there is a little more I can fix before I start over. Lol

[KevKelley]

…now I did test with two less asteroids and I did not have many issues so if I do scale down some of the asteroids I can resolve some of the scanline issues I was experiencing.  

[KevKelley]

So after playing around I was able to clean up the code and move all the asteroid collisions into 2 banks. I made one with all 10 asteroids.  It runs at 262 scanlines until someone fires and then it jumps to 263/264.  I couldn't quite get it down anymore and so I left it at that for the night.  

 

The other file takes away 2 asteroids, so there are 8 but there do not seem to be any scanline issues. 

 

So now the question is do I try to somehow make 10 asteroids work or do I reduce the number of asteroids to 8?

 

If I reduce to 8 I would probably change the spacing in between the asteroids. This may also work to where I can add some features to the game for a kind of bonus level.

 

I also have to add the city on the bottom. That will probably utilize a mixture of two sprites and playfield but I do not envision that taking up much.

 

 

BP_2023_03_20_d_2.bas.bin BP_2023_03_20_d_2.bas BP_2023_03_20_f_6ast.bas BP_2023_03_20_f_6ast.bas.bin

Edited March 21, 2023 by KevKelley

[KevKelley]

So I updated the first post with a a couple .bas and .bin files.

 

One is just the base 10 asteroid version that I left off on but the other file is the 8 asteroid version, complete with ships exploding and respawning and switch reset. I feel the 8 asteroid version can be justified because while the original had 10, the TI 99/4a is notoriously slow so many of the games don't seem to quick.  The Atari on the other hand is fast and the sprites are a bit larger so having a couple less but things moving a bit quicker might be of equal balance.

 

Each player can fly in four directions and shoot left or right.  Getting hit by a laser, colliding with an asteroid, or hitting the city will result in death. I have yet to program the player collision to where you can kamikaze the opponent.  

 

I originally made a fancier city using a couple sprites but I forgot that since the sprites were copies if the second player dipped into the skyline and fired the laser would triple as well.  I am still torn between making the city as it is now with a couple distinct buildings that are like abstracts of the original or if I should instead layer a silhouette of a city skyline using the playfield and background and then maybe use a sprite for some little details.  I also tried to work out the collision for bother players, since I alternate frames for each asteroid. I accomplish this by using the ball since I draw both missiles and the ball every frame.

 

There are some minor issues I had noticed, like every once and a while the lasers disappear after respawning but they still seem to make sounds.  Sometimes they come back after respawn.

 

Another known issue is sometimes the asteroids seem to get stuck by either slowing down a bit with a shot before speeding back up but then their top speed seems to top off.  If shot from the other direction and then back on the other side it seems to get unstuck so it makes me think that something isn't getting reset or a variable isn't properly turning over. I haven't figured this one out either but the basic gameplay is kind of set and it is looking cool.

 

 

[KevKelley]

So I figured out the asteroid issue - I had a couple collision statements separated from the rest so it seemed like it would only work as intended every other frame. 
 

Still working on the disappearing laser. 

[KevKelley]

While I changed the collision a bit with the lasers so that things work better, I am still a bit stumped as to why sometimes when you respawn your laser sounds but does not appear.  I looked at the debugger and it would seem that the missile is somewhere but where I do not know. Is something not being reset?  Is something being skipped some of the time?  

 

The respawn code is part of each player's movement, so drawn every other frame.  

 

 if !n{4} then goto CCHEK1
 if !n{6} &&  player0y>=210 then player0x=6:n{6}=1:AUDV0=0:goto P0_MOVE_PUSH ; reposition player to respawn site
 if !n{6} && player0y<210 then player0y=player0y+3:AUDC0=8:AUDF0=player0y/8:AUDV0=5:goto P0_MOVE_PUSH ; fall to planet burning 
 if n{6} && player0y>160 then player0y=player0y-2:AUDV0=5:AUDC0=12:AUDF0=player0y/4:goto P0_MOVE_PUSH ; change from burning sprite back to rocket 
 
 if n{6} && player0y<=160  then AUDV0=0:n=0:m{0}=0:goto P0_MOVE_PUSH ; fully respawned and ready to go
 player0y=player0y+2:goto P0_MOVE_PUSH
CCHEK1

 

The only thing I can think of but can't seem to work out is that since it is drawn every other frame that something is getting missed somewhere.

BP_2023_03_28_8AST_b.bas

[+Al_Nafuur]

 

11 hours ago, KevKelley said:

 if !n{4} then goto CCHEK1
 if !n{6} &&  player0y>=210 then player0x=6:n{6}=1:AUDV0=0:goto P0_MOVE_PUSH ; reposition player to respawn site
 if !n{6} && player0y<210 then player0y=player0y+3:AUDC0=8:AUDF0=player0y/8:AUDV0=5:goto P0_MOVE_PUSH ; fall to planet burning 
 if n{6} && player0y>160 then player0y=player0y-2:AUDV0=5:AUDC0=12:AUDF0=player0y/4:goto P0_MOVE_PUSH ; change from burning sprite back to rocket 
 
 if n{6} && player0y<=160  then AUDV0=0:n=0:m{0}=0:goto P0_MOVE_PUSH ; fully respawned and ready to go
 player0y=player0y+2:goto P0_MOVE_PUSH
CCHEK1

There is a warning about not having a space before and after each colon:

https://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#whitespace

 

Also instead of testing n{6} four times you can just split the two blocks like that:

 if !n{4} then goto CCHEK1
 if n{6} then N_6_SET

 if player0y >= 210 then player0x = 6 : n{6} = 1 : AUDV0 = 0 : goto P0_MOVE_PUSH ; reposition player to respawn site
 player0y = player0y + 3 : AUDC0 = 8 : AUDF0 = player0y/8 : AUDV0 = 5 : goto P0_MOVE_PUSH ; fall to planet burning

N_6_SET
 if player0y > 160 then player0y = player0y - 2 : AUDV0 = 5 : AUDC0 = 12 : AUDF0 = player0y / 4 : goto P0_MOVE_PUSH ; change from burning sprite back to rocket 
 AUDV0 = 0 : n = 0 : m{0} = 0 : goto P0_MOVE_PUSH ; fully respawned and ready to go
 
 player0y = player0y + 2 : goto P0_MOVE_PUSH
CCHEK1

 

[KevKelley]

6 hours ago, Al_Nafuur said:

Also instead of testing n{6} four times you can just split the two blocks like that:

I had made that change… but then my son started doing something and I couldn’t figure out what he changed so I reverted back to a previous save. I kind of make the code real quick and then clean it up but this is definitely a fix I need to do. I posted this after I gave up for the day. Lol

 

I also forgot about that whole white space thing. Does the absence of spaces really make that much of an issue? Or only sometimes? 

 

 

Edited March 29, 2023 by KevKelley

[+Al_Nafuur]

1 hour ago, KevKelley said:

I had made that change… but then my son started doing something and I couldn’t figure out what he changed so I reverted back to a previous save. I kind of make the code real quick and then clean it up but this is definitely a fix I need to do. I posted this after I gave up for the day. Lol

 

1 hour ago, KevKelley said:

I also forgot about that whole white space thing. Does the absence of spaces really make that much of an issue? Or only sometimes?

Only sometimes, but to avoid any issues I try to always put spaces between the variables, the colons and the commands. This helps the bB parser to split up the stuff and figure out what you want and of course it helps people reading the code.

 

[KevKelley]

So I think I figured out the disappearing missile.  

 

The players are each drawn every other frame.  When they crash it is at player0y+3 but then it raises at player0y-2 and when respawning it checks to see if the player is greater than a certain number so after testing it kind of seemed as if when crashing at certain heights, after the descending and ascending things just didn't quite level out and reset.

 

So I added one part to the respawn code by setting the final player y-coordinate:

 

 AUDV0 = 0 : n = 0 : m{0} = 0 : player0y=160 :goto P0_MOVE_PUSH ; fully respawned and ready to go

 

It seemed to work and each respawn I had conducted the missile was then present.

 

I suppose I could have also changed the line above to be equal to or greater than 160, as when I tested that it had also worked.

 

if player0y >= 160 then player0y = player0y - 2 : AUDV0 = 5 : AUDC0 = 12 : AUDF0 = player0y / 4 : goto P0_MOVE_PUSH ; change from burning sprite back to rocket 

 

I suppose just how I had it go up and down and every other frame what seemed random really wasn't.  It just that every once and a while the spaceship would not rise up to the correct coordinate and things get reset.

[+ZeroPage Homebrew]

ZeroPage Homebrew is playing Beyond Parsec on tomorrow's ZPH stream LIVE on Twitch, hope you can join us!

 

Mon Apr 3, 2023 | LIVE @ 6PM PT | 9PM ET | 1AM GMT

WATCH LIVE: https://www.twitch.tv/zeropagehomebrew/
WATCH LATER: https://youtube.com/zeropagehomebrew/

 

Games:

• Space Taxi (2023 WIP | 2600) by Jeff Haber @Just Jeff
• Berry Fun! (2023 WIP | 2600) by Mike Littau @littaum
• Beyond Parsec (2023 WIP | 2600) by Grocer Games / Kevin Kelley @KevKelley
• Carrot Kingdom (2021 | 2600) by Joseph Nesbella @Jinroh

 (WATCH AT 1080P60 FOR BEST QUALITY)

 

 

[KevKelley]

Great program @ZeroPage Homebrew!

 

Thanks for playing!

 

A couple of the things have been fixed (or getting fixed) in newer versions. It looked like you had a slightly older one with the disappearing missiles. That has since been corrected and was a result of some things not getting reset based on the player coordinates at point of impact. As for the speed up asteroid, that is mostly fixed but I think that is a similar issue. 
 

As @Karl G mentioned, debugging 2-player games can be hard but on the plus side for this game, since the players are both player0 it simplifies things as a fix for one fixes for both. I do use separate missiles and the ball for collision to deal with the issue of half the asteroids and players being drawn every other frame. I had also just added player collision with each other. 
 

I have also been tweaking the city a bit to make it look a bit nicer. 
 

I still have to play the original to compare gameplay but I think the 2-player version may be close to complete. While my to do list is still one I want to accomplish, some things have changed. Mainly I had originally shared a missile when starting and I didn’t use the ball yet… 

 

I have already started work on adding different options, such as adjustable player or asteroid speed. While I don’t have the ball or missiles anymore I can utilize additional sprites and place them at the top or bottom to avoid flicker. I also want to add occasional power ups. 
 

As for a single player mode, what I was thinking was try to have the player move and shoot at the player and perhaps do a check on the asteroids and depending on their distance and direction maybe change the computers movement. 
 

Another single player idea I was thinking of was maybe have something like a moving target fire or maybe a moving goal that you must shoot the asteroids into. 
 

I’m sure I can come up with a couple single player options. The main thing for me was keeping the 2-player mode as close as I can get to the original.