95 replies to this topic

[jrok]

I've been taking a break from Armageddon Complex to try to write something a little less, well, complex. This game is more action-oriented, with a control schema that I based on one of my favorite games, "Berzerk." The setting is a futuristic gladiator tournament, where combatants duel each other to the death for the pleasure of the galactic empire. The game will comprise the player's fighting career, with the difficulty and rewards ramping up with each match.

I've attached a demo of the current engine. The blue character is controlled with the left stick. Holding down the fire button cause the character to stop, and simultaneous aim and charge up his laser gun. The longer the button is held down, the longer the laser beam he will fire when he releases the button. If the beam reaches it's maximum range or hits a portion of the playfield or the enemy character, its progress will stop and the beam will fade away. Once a beam fully disappears, the player may charge and fire a new beam.

The green character is controlled by "A.I.", such as it is . It's pretty meatheaded right now, so I'll have to figure out ways to trick it into looking smarter. There's no way I can hitch anything as smart as A* into Atari, but I will try to build a very simple short term memory for the dude so he at least doesn't make the same mistakes over and over. I've lent him a few supercharger variables as placeholders to ramp up his aggression and accuracy, but at the present it's sort of like handing a blind man a machine gun. You can shoot him, but for now hits just increment your score. He can shoot you too, but for now you are godlike and invincible.

I'm hoping to include a few different breeds of enemy and different arena types with traps and gadgets that you can use to help you win. Another thing I'm thinking of incorporating is a few different options for attack, based on how long you hold down the button and particular joystick movements.

• Short button presses & joystick movement : Perform a quick dodge or melee attack
  
• Long button presses & back/forth joystick movement : Throw a grenade

There's a bug in the game that I left in on purpose, since I think it might make for an interesting grenade effect. If you fire diagonal past either horizontal edge of the arena, a shortcoming in the beam progression routine causes what looks like a massive explosion on the other side of the screen! Hooray for cool looking bugs!

What do you guys think?

Cheers,
Jarod

UPDATE:

This game has changed substantially since this first-post. I've been posting progress on the Homebrew forum as well, so I will try to keep current updates consistent on both pages. Thanks to everyone in the bB forum for the all the helpful feedback and advice - Jarod.

Current Version:
 Circus_Galacticus_m1_d30_y11.bas.bin   32K   39 downloads

Edited by jrok, Sun Jan 30, 2011 5:20 PM.

[yuppicide]

Very cool. I like the sprites, but there's a lot of flicker though on Stella emulator.

Could be nice to have different rooms eventually. What's with the game name? I kind of like it, though, but here's what I originally thought of when I tried out the demo:

- The character reminds me of Tron. New Tron game for the 2600? I was picturing a second level where there's a bunch of platforms you must jump from one to the other. Sprite looks like it'd make a good jumper.

- Doom 2600? Change the second character to a Doom-like monster. Make it so you have to get colored passcodes in order to open certain doors and finally the elevator to the next level. Between levels have a cutscene of your guy riding an elevator sort of like "Cloak & Dagger".

- Not quite as intense button mashing gameplay, but maybe some kind of Smash TV for 2600?

I like you can shoot or throw grenades. I don't remember exactly what happened since I am at work right now, but each of the things should go different distances and have different power. Example would be that a gun can shoot farther than one can throw a grenade, but a grenade does more damage.

Good work. Like it so far.

[jrok]

yuppicide, on Tue Nov 18, 2008 11:48 AM, said:

Very cool. I like the sprites, but there's a lot of flicker though on Stella emulator.

Could be nice to have different rooms eventually. What's with the game name? I kind of like it, though, but here's what I originally thought of when I tried out the demo:

- The character reminds me of Tron. New Tron game for the 2600? I was picturing a second level where there's a bunch of platforms you must jump from one to the other. Sprite looks like it'd make a good jumper.

- Doom 2600? Change the second character to a Doom-like monster. Make it so you have to get colored passcodes in order to open certain doors and finally the elevator to the next level. Between levels have a cutscene of your guy riding an elevator sort of like "Cloak & Dagger".

- Not quite as intense button mashing gameplay, but maybe some kind of Smash TV for 2600?

I like you can shoot or throw grenades. I don't remember exactly what happened since I am at work right now, but each of the things should go different distances and have different power. Example would be that a gun can shoot farther than one can throw a grenade, but a grenade does more damage.

Good work. Like it so far.

Thanks man! I guess if I went the Tron route, I might as well abandon the whole laser beam thing and go with discs. But on the other I could reuse portions the laser routine to do the lightcycle levels, so that's a pretty interesting idea. I'm almost postive I saw someone do a 2600 Doom hack of something(?), but it might've been Castle Wolfenstein.

Smash TV was probably my favorite Robotron clone, and Robotron was probably my favorite arcade game, period. I have four flicker sprites available to me right now, including the player. I suppose I could beef up that number with the multisprite kernel, but I haven't tried to adapt my beam drawing routine to it yet, and I have a suspicion it won't work with a symetrical playfield. Absent that, I suppose I could use playfield pixels to represent the basic, swarming grunt-type enemies, and save the sprites for more dangerous foes. That actually might be kind of sweet. Has anyone ever done anything like that?

Yeah, I definitely want to try to do the grenade thing in my next build, maybe with a shakescreen effect. I'd also like to have two different modes (1 player and 2 player), but I might not be able to pack that much game onto a 16k romboard.

[jrok]

yuppicide, on Tue Nov 18, 2008 11:48 AM, said:

What's with the game name? I kind of like it, though, but here's

I was thinking it would be a word play on "Circus Maximus" which was the Latin name for the largest gladiator arena in Rome. My original idea was to make a sort of Combat-like game, with different selectable modes for different events. Like, Laser Duel would be one event, while another event might be some sort of futuristic chariot racing thing or an event where you have to survive waves of space monsters.

[Impaler_26]

I just played a few rounds and i like the concept of your game, i think this could become a fun to play game!

I was just wondering why you're using flicker when you only have 2 sprites on the screen at once?

jrok, on Tue Nov 18, 2008 6:24 PM, said:

Thanks man! I guess if I went the Tron route, I might as well abandon the whole laser beam thing and go with discs. But on the other I could reuse portions the laser routine to do the lightcycle levels, so that's a pretty interesting idea. I'm almost postive I saw someone do a 2600 Doom hack of something(?), but it might've been Castle Wolfenstein.

Another Tron game would also be nice. Someone else already made a Tron game with bB, maybe this gives you a few ideas for your version of Tron:

http://www.atariage....howtopic=103759
http://www.atariage....howtopic=105107
http://www.atariage....howtopic=123234

And is this the Doom hack you saw?

http://www.atariage....showtopic=75714

[jrok]

Impaler_26, on Tue Nov 18, 2008 3:08 PM, said:

I just played a few rounds and i like the concept of your game, i think this could become a fun to play game!

Thanks man!

Impaler_26, on Tue Nov 18, 2008 3:08 PM, said:

I was just wondering why you're using flicker when you only have 2 sprites on the screen at once?

There are actually four sprites on the screen, but I've repositioned the other two offscreen for now until I figure out what I want to do with them. But actually I was flickering even before I added in the sprites, since testing for both player and enemy beam and movement routines before each vsync was causing some scanline problems. Also, I wanted them to share sprite data, so this seemed a pretty straightforward way to do it.

Impaler_26, on Tue Nov 18, 2008 3:08 PM, said:

Another Tron game would also be nice. Someone else already made a Tron game with bB, maybe this gives you a few ideas for your version of Tron:

http://www.atariage....howtopic=103759
http://www.atariage....howtopic=105107
http://www.atariage....howtopic=123234

I'll have to check those out, thanks. I was a pretty big fan of the Discs of Tron arcade game, and gameplay wise I love the idea of hitting your opponent with ricochet shots.

Impaler_26, on Tue Nov 18, 2008 3:08 PM, said:

And is this the Doom hack you saw?

http://www.atariage....showtopic=75714

Yep! That's the one. Thanks. You know it's hard for me to think of "Doom" as anything other than a 3D game, since that was sort of its mark of fame. Unfortunately, most of those Atari "First Person Perspective" maze games usually turn out to be frustrating or boring or both for me. What might be kind of cool would be a "Battlezone" version that had the 3D feel but with simple obstacles/landmarks instead of mazes.

Cheers,
Jarod.

[Impaler_26]

jrok, on Tue Nov 18, 2008 9:49 PM, said:

Impaler_26, on Tue Nov 18, 2008 3:08 PM, said:

I was just wondering why you're using flicker when you only have 2 sprites on the screen at once?

There are actually four sprites on the screen, but I've repositioned the other two offscreen for now until I figure out what I want to do with them. But actually I was flickering even before I added in the sprites, since testing for both player and enemy beam and movement routines before each vsync was causing some scanline problems. Also, I wanted them to share sprite data, so this seemed a pretty straightforward way to do it.

Hm... i assume drawing the players shots with the playfield also takes up a lot of cycles...
But i think even if you would just use the missiles for the shots the game would still be fun.
Anyway i'm looking forward to see how this game develops....

Oh and IIRC Michael Rideout posted an example how to share sprite data in bB somewhere here in the bB-forum, maybe in the Combat DX thread... I'll have to look for it....

EDIT: found an example here: http://www.atariage....howtopic=122525

Edited by Impaler_26, Tue Nov 18, 2008 3:07 PM.

[yuppicide]

Why do you need to cram all that into vsync? Put some in there, some not in there. Either that or try to cut down that code some.

How about you do some kind of frame thing.. frame one in vsync is does something, on frame 2 it does something else, frame 3 the results of the first two frames are checked.. I'm not really sure how it'd all work out, but that's my theory.

jrok, on Tue Nov 18, 2008 3:49 PM, said:

There are actually four sprites on the screen, but I've repositioned the other two offscreen for now until I figure out what I want to do with them. But actually I was flickering even before I added in the sprites, since testing for both player and enemy beam and movement routines before each vsync was causing some scanline problems. Also, I wanted them to share sprite data, so this seemed a pretty straightforward way to do it.

[SeaGtGruff]

yuppicide, on Tue Nov 18, 2008 11:56 PM, said:

Why do you need to cram all that into vsync? Put some in there, some not in there. Either that or try to cut down that code some.

How about you do some kind of frame thing.. frame one in vsync is does something, on frame 2 it does something else, frame 3 the results of the first two frames are checked.. I'm not really sure how it'd all work out, but that's my theory.

jrok, on Tue Nov 18, 2008 3:49 PM, said:

There are actually four sprites on the screen, but I've repositioned the other two offscreen for now until I figure out what I want to do with them. But actually I was flickering even before I added in the sprites, since testing for both player and enemy beam and movement routines before each vsync was causing some scanline problems. Also, I wanted them to share sprite data, so this seemed a pretty straightforward way to do it.

You could also try moving some things into the vblank. bB lets you do that, but I don't think there's as much time available there as in the overscan. And you need to keep in mind that the vblank is between the period when bB does some of its screen updates and when the screen gets displayed, so there are some things you can't do during vblank-- or rather, if you do them then, they won't take effect until *after* the next frame has been drawn, rather than before. Here's an example:

   rem * test vblank

loop
   COLUBK = $00
   scorecolor = $0E
   score = 123456
   COLUPF = $46
   playfield:
   ............XXXXXXXX............
   .........XXX........XXX.........
   .......XX..............XX.......
   ......X..................X......
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   ......X..................X......
   .......XX..............XX.......
   .........XXX........XXX.........
   ............XXXXXXXX............
end
   COLUP0 = $1A
   player0:
   %00111100
   %01000010
   %10000001
   %10000001
   %10000001
   %10000001
   %01000010
   %00111100
end
   player0x = 1
   player0y = 8
   NUSIZ0 = %00000110
   COLUP1 = $94
   player1:
   %11111111
   %11000011
   %10111101
   %10111101
   %10111101
   %10111101
   %11000011
   %11111111
end
   player1x = 1
   player1y = 87
   NUSIZ1 = %00000111
   drawscreen
   goto loop

   rem * vblank subroutine follows here

   vblank
   COLUBK = $0E
   scorecolor = $00
   score = 987654
   COLUPF = $C8
   playfield:
   .....XXXXXXXXXXXXXXXXXXXXXX.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....X....................X.....
   .....XXXXXXXXXXXXXXXXXXXXXX.....
end
   COLUP0 = $24
   player0:
   %11111111
   %10000001
   %10000001
   %10000001
   %10000001
   %10000001
   %10000001
   %11111111
end
   player0x = 152
   player0y = 8
   NUSIZ0 = %00000000
   COLUP1 = $66
   player1:
   %11111111
   %10000001
   %10111101
   %10111101
   %10111101
   %10111101
   %10000001
   %11111111
end
   player1x = 136
   player1y = 87
   NUSIZ1 = %00000001
   return

The first half of the program is a simple display loop that sets the colors, the score value, the graphics, the positions of the sprites, and the numbers/sizes of the sprites, then draws the screen, and loops back.

The second half of the program is a subroutine (note how it ends with "return") that starts with "vblank" (note that it's a statement, *not* a line label-- i.e., it's indented). It does exactly the same kind of stuff that the loop does, except it sets different colors, a different score value, different graphics, different sprite positions, and different numbers/sizes of the sprites. Notice that this subroutine does *not* include a "drawscreen" command, nor is it called from anywhere in the loop.

When you run this program, the screen display ends up being a mixture of the commands in the loop and the commands in the vblank subroutine-- namely, everything in the vblank subroutine overrides the stuff in the loop *except* for the sprite positions and the score value. That's because bB sets the sprite positions and the score value during the first part of the vblank period, and then jumps to the user's vblank subroutine (if there is one). You can set the sprite positions and score value during the vblank if you want to, but they won't take effect until one screen later-- assuming you don't wipe them out before that in your display loop.

bB also clears the collision registers during the first part of the vblank, so you can't check for collisions during a vblank subroutine.

Note that you can define only one vblank subroutine-- but if you want, you can use an if or on...goto statement to choose between two or more subroutines depending on some factor, such as a frame counter or a game state flag (just as you can do in your main display loop if you want to).

Michael

Attached Files

•  test_vblank_2.bas   1.9K   137 downloads
•  test_vblank_2.bas.bin   4K   185 downloads

[jrok]

SeaGtGruff, on Wed Nov 19, 2008 1:57 AM, said:

Note that you can define only one vblank subroutine-- but if you want, you can use an if or on...goto statement to choose between two or more subroutines depending on some factor, such as a frame counter or a game state flag (just as you can do in your main display loop if you want to).

Michael

Thanks for the advice. I actually *am* using the vblank to do certain things, but I have the feeling that I am using it badly. Currently, my vblank does the following:

• Updates each sprite's current playfield position.
  
• Updates each sprites next playfield position based on their current directions.
  
• Reads the state of the each sprite's next playfield pixel based on the their current directions (for collision detection).

It doesn't seem like a lot of cycles when i describe it like that, but it works out that way because I'm changing the value of each sprite's Y playfield position based on the sprite's current direction. It seems awful and wasteful when I look at it, but If when I track their playfield Y with a universal formula, they end up getting stuck on collisions.

 dim sprite1dir = a; The 8-directional vector of the sprite
 dim sprite1ydir = b; Vertical direction (Up or Down, including diagonals) 
 dim sprite1xdir = c; Horizontal direction (Left or Right, including diagonals) 
 dim sprite1lastX = d; The last x coordinate before a collision
 dim sprite1lastY = e; The last y coordinate before a collision
 dim sprite1PFX = f; The sprite's playfield X position
 dim sprite1PFY = h; The sprite's playfield Y position
 dim sprite1nextPFX = i; The next playfield X
 dim sprite1nextPFY = j; The next playfield Y 

 dim sprite2dir = k
 dim sprite2ydir = l
 dim sprite2xdir = m
 dim sprite2lastX = n
 dim sprite2lastY = o
 dim sprite2PFX = p
 dim sprite2PFY = q
 dim sprite2nextPFX = t
 dim sprite2nextPFY = u

 const pfres = 24
 
 ...

 vblank
 sprite1PFX = (sprite1X-14)/4
 if sprite1dir = 0 then sprite1PFY = (sprite1Y-13)/4
 if sprite1dir = 1 then sprite1PFY = (sprite1Y-13)/4
 if sprite1dir = 2 then sprite1PFY = (sprite1Y-8)/4
 if sprite1dir = 3 then sprite1PFY = (sprite1Y)/4
 if sprite1dir = 4 then sprite1PFY = (sprite1Y)/4
 if sprite1dir = 5 then sprite1PFY = (sprite1Y)/4
 if sprite1dir = 6 then sprite1PFY = (sprite1Y-8)/4
 if sprite1dir = 7 then sprite1PFY = (sprite1Y-13)/4
 if sprite1xdir = 0 then sprite1nextPFX = sprite1PFX + 1 else sprite1nextPFX = sprite1PFX - 1
 if sprite1ydir = 0 then sprite1nextPFY = sprite1PFY + 1 else sprite1nextPFY = sprite1PFY - 1
 if pfread(sprite1nextPFX,sprite1PFY) then sprite1X = sprite1lastX : sprite1Y = sprite1lastY
 if pfread(sprite1PFX,sprite1nextPFY) then sprite1Y = sprite1lastY : sprite1X = sprite1lastX
 sprite2PFX = (sprite2X-14)/4
 if sprite2dir = 0 then sprite2PFY = (sprite2Y-13)/4
 if sprite2dir = 1 then sprite2PFY = (sprite2Y-13)/4
 if sprite2dir = 2 then sprite2PFY = (sprite2Y-8)/4
 if sprite2dir = 3 then sprite2PFY = (sprite2Y)/4
 if sprite2dir = 4 then sprite2PFY = (sprite2Y)/4
 if sprite2dir = 5 then sprite2PFY = (sprite2Y)/4
 if sprite2dir = 6 then sprite2PFY = (sprite2Y-8)/4
 if sprite2dir = 7 then sprite2PFY = (sprite2Y-13)/4
 if sprite2xdir = 0 then sprite2nextPFX = sprite2PFX + 1 else sprite2nextPFX = sprite2PFX - 1
 if sprite2ydir = 0 then sprite2nextPFY = sprite2PFY + 1 else sprite2nextPFY = sprite2PFY - 1
 if pfread(sprite2nextPFX,sprite2PFY) then sprite2X = sprite2lastX : sprite2Y = sprite2lastY
 if pfread(sprite2PFX,sprite2nextPFY) then sprite2Y = sprite2lastY : sprite2X = sprite2lastX
 return

The main idea is that a sprite's playfield position is the both origin of it's laser and the value used for collision detection. The sprite itself isn't used for anything - it's just a pretty coat. But the above looks and feels incredibly sloppy to me. I mean, I know that "sprite1xdir" and "sprite1ydir" are binary values, and should be nybbles, and there are some other ways I can pretty obviously save RAM. But what really bothers me about the above is how much division I'm doing, just for collision detection. I get the feeling I probably shouldn't be doing this stuff at all, let alone here in the vblank. Is there a simpler way to achieve what I'm going for?

Thanks,
Jarod.

Edited by jrok, Wed Nov 19, 2008 12:48 PM.

[SeaGtGruff]

jrok, on Wed Nov 19, 2008 10:58 AM, said:

I actually *am* using the vblank to do certain things, but I have the feeling that I am using it badly.

I haven't tried to follow all of your code yet, but I would suggest putting anything to do with collisions, sprite positioning, and the score in your main display loop, and use the vblank for anything else that will fit there, as long as it doesn't need to be done before collision processing, sprite positioning, and score updating.

One thing I see is that you might be able to simplify some code by replacing a series of ifs with an on...goto statement.

Michael

[jrok]

Okay, I have a new version, and here's what's in it:

• Both the player and the enemy can be killed. When either man is shot, a brief death animation plays, then the game resets.
  
• Improved enemy AI (there's still a ways to go, but he's a little trickier now, and can detect and dodge shots every once in a while).
  
• Incorporated Michael Rideout's method for variable playercolors to palette-swap the Hero and the bad guys. Hopefully, I can use this to create a bunch of different flavors of baddie without using up a lot of space in my shape bank.
  
• Added some sound effects (these still need a LOT of work.)

Now that there's actually a game here, I think my next steps will be to add some game progression to make the game tougher with each new stage. For this, I'm thinking of:

• Giving the badguy a number of shields/hitpoints that increments.
  
• Having the badguy's level of aggression ramp up
  
• Include two additional enemy types with different weapons/abililties.
  
• Changing the playfield layout and properties (Electrified playfield, Ricochet shots, etc)
  
• Using my two flickered sprites and the ball for obstacles or additional enemies (Gun Turrets, Hungry Beasties, Landmines, etc)

The size of the game is 32K, but I'm not using most of it and might downgrade to 16k again. Bank 2 is empty. Banks 3-4-5 are filled with the 48-playfield map routine I was using for Armageddon Complex, and I doubt I'll need 48 unique playfields for this game. Bank 6 is about two-thirds full, and contains my player control schema and my enemy AI. Bank7 is is filled with my animation loops and my player1color variables, and bank8 is about halfway-filled with my shape data and my vblank.


EDT:
Oh did I mention bugs? There are a few:
- I need to halt the progress of the beams at the edges of the screen, so neither combatant can exit
- There's still a few collision detection issues with the enemy, where he can get stuck for a few loops. Usually though, he just blasts his was out of it.

Cheers,
Jarod

Attached Files

•  Circus_Galacticus_m11_d21_y08.bin   32K   164 downloads

Edited by jrok, Fri Nov 21, 2008 1:18 PM.

[jrok]

I have a new update. You can read about the build on my blog for more details if you're interested.

Evil Emperor

A talking hologram that announces the start of each battle. Press fire to make to shut him up and get on with the fight. Later on, I plan on making him serve an "Evil Otto" sort of function when matches take too long.


Game Progression

• Playfields change as you advance through the game (only three so far).
  
• The enemy becomes more inclined to take a shot at you as you advance through the game.
  
• The score, playfield and enemy aggression reset to zero when you lose.

Bugs/ To-do

• Laser beams aren't stopped at exterior walls.
  
• Enemy is having trouble shooting diagonally.
  
• Playfields are are too limited/boring, need improvement
  
• Need to change colors/powers for enemies

Cheers,
Jarod.

EDT:
- Fixed a sound bug at the completion of battles
- Made the laser beams faster and more powerful
- MY TOP SCORE SO FAR= 1600. Can anyone beat it???

Attached Files

•  Circus_Galacticus_m11_d24_y08_rev.bas.bin   32K   151 downloads

Edited by jrok, Mon Nov 24, 2008 10:00 PM.

[yuppicide]

Great freakin game. Simple, yet fun. Sprites look great.

[jrok]

yuppicide, on Mon Nov 24, 2008 11:43 PM, said:

Great freakin game. Simple, yet fun. Sprites look great.

Thanks man!

EDT:
I think I resolved the issue with the enemy taking diagonal shots (new BIN attached). I'll have to work on the accuracy, though.

Out of curiousity, does anyone own a Cuttle Cart or similar device that wouldn't mind testing this program out on it? I just wanted to find out if it's rolling the screen. If so, thanks in advance.

Cheers,
Jarod.

Edited by jrok, Tue Nov 25, 2008 9:25 AM.

[yuppicide]

Send a PM to gambler172. I see him test out a lot of stuff. Maybe he'll do it. He tried out my Acid Fish game.

jrok, on Tue Nov 25, 2008 9:59 AM, said:

yuppicide, on Mon Nov 24, 2008 11:43 PM, said:

Great freakin game. Simple, yet fun. Sprites look great.

Thanks man!

EDT:
I think I resolved the issue with the enemy taking diagonal shots (new BIN attached). I'll have to work on the accuracy, though.

Out of curiousity, does anyone own a Cuttle Cart or similar device that wouldn't mind testing this program out on it? I just wanted to find out if it's rolling the screen. If so, thanks in advance.

Cheers,
Jarod.

[jrok]

yuppicide, on Tue Nov 25, 2008 10:36 AM, said:

Send a PM to gambler172. I see him test out a lot of stuff. Maybe he'll do it. He tried out my Acid Fish game.

Will do. Thanks for the advice.

[yuppicide]

Tried out the new version. Looking good.

Some things I notice:

1 - After you get shot and the death animation plays you can still move your character around. Doesn't really matter anyway, but I don't think he should be allowed to move when dead.

2 - Enemy can walk right through playfield and I can't. He should have to shoot through to get to me also, instead he walks right over it sometimes.

3 - When enemy shoots right side of wall, his shot will go through and hit the left side also.

4 - Your guy in the beginning with the flaming head reminds me of the guy in "Crazy Balloon" which was an arcade port done to the 2600 by Cybergoth. In some levels there's a guy blowing air at you. Maybe your guy can poke his head out and blow you around.

[jrok]

Thank for the feedback.

yuppicide, on Tue Nov 25, 2008 1:47 PM, said:

Some things I notice:

1 - After you get shot and the death animation plays you can still move your character around. Doesn't really matter anyway, but I don't think he should be allowed to move when dead.

Absolutely agree. I was trying to figure out if there was a way to get off one last "revenge" shot when dying, but he still shouldn't be able to physically move around. I will fix that.

yuppicide, on Tue Nov 25, 2008 1:47 PM, said:

2 - Enemy can walk right through playfield and I can't. He should have to shoot through to get to me also, instead he walks right over it sometimes.

I've noticed the same thing. The collision detection isn't fully resolved yet, that's for sure. I'm still working on some bits.

yuppicide, on Tue Nov 25, 2008 1:47 PM, said:

3 - When enemy shoots right side of wall, his shot will go through and hit the left side also.

Yep, that's a doozy. This is the result of returning values above 31 or less then zero for the playfield pixels when a shot goes past a wall. I'm working on it, I'm just trying to figure where in my program I would be the best place to ice off those kinds of shots.

yuppicide, on Tue Nov 25, 2008 1:47 PM, said:

4 - Your guy in the beginning with the flaming head reminds me of the guy in "Crazy Balloon" which was an arcade port done to the 2600 by Cybergoth. In some levels there's a guy blowing air at you. Maybe your guy can poke his head out and blow you around.

Hahahah, yeah. That would be hilarious. I definitely plan to use him during the match to f*** with you, shooting stuff at you and what not. "Blowing" you around the screen would be a nice addition to his bag of tricks. Great idea!

FYI, I have attached yet *another* build, which adds color progression to the enemy sprite and playfield as you advance. It also lengthen's the range of the enemies beam in addition to making him more aggressive as you get farther in the game. I think that's gonna be my last update today, because I have to get my butt back to work. Thanks for the encouragement.

Cheers,
Jarod.

Attached Files

•  Circus_Galacticus_m11_d25_y08_colors.bin   32K   137 downloads

Edited by jrok, Tue Nov 25, 2008 1:24 PM.

[yuppicide]

Is there a spot you're supposed to be able to kill the guy? I've noticed that sometimes it only kills him when I hit him dead center. Sometimes it'll register on the bottom portion near his feet, but not always.

Wonder if there's any way to access AtariVox from BB.. your guy in the beginning should give an evil laugh or something.

You ever complete a BB game for release on cart? I'd be interested in picking this one up if it came out.

Edited by yuppicide, Tue Nov 25, 2008 9:39 PM.

[jrok]

yuppicide, on Tue Nov 25, 2008 10:35 PM, said:

Is there a spot you're supposed to be able to kill the guy? I've noticed that sometimes it only kills him when I hit him dead center. Sometimes it'll register on the bottom portion near his feet, but not always.

Yes, there is a spot. The laser needs to intersect with the guy's playfield position. It's interesting you pointed this out, because its something that might change a lot before the game is done. Both playfield y position and collision detection in general are complicated by the fact that I am using 16px tall characters and no_blank_lines. I was actually thinking of contacting SeGTGruff about this, since he was so helpful in explaining the basics, but I want to try to figure it out for myself before I bothered him about it.

yuppicide, on Tue Nov 25, 2008 10:35 PM, said:

Wonder if there's any way to access AtariVox from BB.. your guy in the beginning should give an evil laugh or something.

Totally! I don't want to bite off more than I can chew right now, but I started reading up on the Vox a few days ago. I was thinking that if I am able to complete the game, I might look into it and see what it would entail.

yuppicide, on Tue Nov 25, 2008 10:35 PM, said:

You ever complete a BB game for release on cart?

I've never completed a BB game period. If I'm able to finish this one it will be my first, but like a lot of guys here I dream of being able to put something on cartridge.

yuppicide, on Tue Nov 25, 2008 10:35 PM, said:

I'd be interested in picking this one up if it came out.

Thanks, man! I feel like I'm pretty away from that right now. I'm still digesting the Stella Guide and SeaGTGruff's explanation of timing. It seems a little daunting sometimes. I get so close to having a well-timed program, but when I test with debugger I always seem to get a little "jump" to 263 scanlines in certain firing situations. If I'm really going to get serious about this hobby (and I think I am), I know I'll have to eventually break down and buy a Cuttle Cart so I can test this stuff for real.

Cheers,
Jarod.

[jrok]

Here's my latest build:

• Finally got scanline under control with a small kernel edit and some optimization of the player control scheme. The game runs at a smooth 262 except for overflows during the death animations, which I'll have to investigate further.
  
• Replaced left and right walls with a PF0=128 vertical frame in the vblank
  
• Set a limits on laser beams to stop their progress at the left and right walls (still working on stopping vertical and diagonal beams)
  
• Created a color phase animation for the combatants while waiting for a new match to begin.
  
• Increased hittable area of both combatants
  
• Revised AI routine
  
• Expanded number and style of playfields
  
• Expanded number of unique enemies

For me, the most exciting part was being able to finally get my core game routines to run at a reliable 262, since I was at the verge of giving up. I have lots of ideas where I want to take the game next, so its a big relief to know that, at the very least, I might still have a program that's functional.

Next:
Now that I can have scores of unique "looking" enemies, I really want to work on getting unique "acting" ones. I've left placeholders in my enemy data set that I will try to use as pointers for different weapons, and maybe even alternate AI routines. I have plenty of ROM left in my AI bank, so I just have to figure out what I want them to do differently that varies the challenge as you proceed through the game.

I also would like to add in a few new player control options, which will be pretty easy since I'm already tracking the time that the player is holding down the fire button. But I could use some advice:

Quick button "taps":
Which do you think would be more interesting and/or useful: a quick dodge manuever or a melee attack?

Overcharging the gun:
Should this produce a negative effect for the player, like the weapon becoming unavailable for a short period of time? Or should it be some sort of super-attack or manuever that can be stocked up like smartbombs?

Also, I've realized if I keep this a 32K game, I still have 2 completely empty banks to create completely alternate gameloops, to keep the player guessing about what's coming in the next level. For instance, instead of facing a lone gladiator with a laser beam, I want to create the following alternate round-styles:

• Fend off groups of alien wildlife that emerge from a pit.
  
• Battle a snakelike creature that moves like a Tron light cycle.
  
• Battle a killer robot that can teleport around the screen.

It's probably biting off more than I or bB can chew, but if I can squeeze even one alternate play-style in there I think I'll be happy with this project.

Cheers,
Jarod

Attached Files

•  Circus_Galacticus_m12_d4_y08.bin   32K   140 downloads

[ginnidog]

jarod.

I like the idea add ons :

1. Fend off groups of alien wildlife that emerge from a pit.
2. Battle a snakelike creature that moves like a Tron light cycle.
3. Battle a killer robot that can teleport around the screen.

Paulie

[jrok]

ginnidog, on Thu Dec 4, 2008 1:34 PM, said:

jarod.

I like the idea add ons :

1. Fend off groups of alien wildlife that emerge from a pit.
2. Battle a snakelike creature that moves like a Tron light cycle.
3. Battle a killer robot that can teleport around the screen.

Paulie

Thanks, man. Of course there will have to be a two player "versus" mode too, but I'm pretty sure I can just jam that into the banks I'm already working in.

Cheers,
Jarod

[yuppicide]

Wow!!!!!! I had a lot of fun playing this!! The sounds go great with the game. The players look great. I think I got up to 800 points where the playfield is totally blocked from getting to the other side and the colors change (black enemy).

I wanted to suggest that maybe the playfield "grows" back one piece at a time every so often, but I love the game as it is now.

Cram in a title screen with some music and you got a winner.

Still need to work on collision detection a bit? Sometimes when the enemy is facing down it doesn't register when I hit him.

I suggest once you finish up the game to find someone to work you in a nice title screen and music in ASM. This way maybe you can get something high res.

Edited by yuppicide, Fri Dec 5, 2008 10:39 PM.