Circus Galacticus

[jrok]

You're really kicking ass on this! Keep up the great work!

 

..Al

 

Thanks Al!

 

You know, I've been reading some documentation on the Vox, and it really seems like a very cool device. One idea I've been toying with is a layer of customization, so you can design a gladiator that suits your play style, balancing things like your weapon range, charge-up rate, shield strength, foot speed, etc. It think being able to save custom players in EEPROM would be a very nice option.

 

Jarod.

[MausGames]

Adding Vox support would be great, I hope you can use it. I agree that being able to save a customized character would be cool, even cooler if it's possible to level up. Saved high score tables are nice, too.

 

Don't forget that you can activate the missing missile sprite with ENAM0 = 2. Or it might be ENAM1 = 2, I can never remember. You might be able to use it for some sort of moving or stationary wall, or a border.

[jrok]

Adding Vox support would be great, I hope you can use it. I agree that being able to save a customized character would be cool, even cooler if it's possible to level up. Saved high score tables are nice, too.

 

Yes, and for a level of polish it would be nice to customize your costume as well (as long as I can reserve three variables for this). I haven't really looked into Vox in depth yet, let alone a bB implementation. Have you experimented with it at all?

 

Don't forget that you can activate the missing missile sprite with ENAM0 = 2. Or it might be ENAM1 = 2, I can never remember. You might be able to use it for some sort of moving or stationary wall, or a border.

 

Yes good point, Maus. Right now I'm reorganizing my memory allocation to allow for something like this (I was using the missile variables to store other values, mostly because I was lazily assigning variables to to stuff that would be better suited to bit operations). Missile0 would indeed be a very useful object to bring back into play.

 

Cheers,

Jarod.

Edited October 27, 2009 by jrok

[MausGames]

I don't even wanna know how you've managed to use over 75 variables already, I'd imagine that is insanely hard to track and manage. One thing I just noticed, if you use enam on a missile that corresponds to a multicolor player, the sprites colors show up in the missile bar at it's y coordinates. It's a strange effect, looks like a mirror or something I guess.

 

I haven't done anything with the Vox, I was interested in it for my virtual pet project but didn't get far enough with that to learn much about Vox support. Now I'm counting on you to do all the work, I'd still like to finish with vp game. What I end up doing depends on how popular the Harmony becomes. I'd rather learn to use it, since that would allow for sd pet transfer and things like vp-war battle tournaments. Depending on how far you'd like to go with things, you might consider supporting both.

[jrok]

I don't even wanna know how you've managed to use over 75 variables already, I'd imagine that is insanely hard to track and manage.

 

Well, not really. I reserve 19 vars to color player 1. Then there's four to track the XY positions of the two flickered players, four more to store their last known XYs and another four to track their playfield positions. Two more to track the direction each sprite is facing, and one to track the current animation frame of the sprites. So that's 34 variables right there just to get multicolored gladiators moving around the screen.

 

One thing I just noticed, if you use enam on a missile that corresponds to a multicolor player, the sprites colors show up in the missile bar at it's y coordinates. It's a strange effect, looks like a mirror or something I guess.

 

From what I understand, M1 is what is used to color P1, with the color change defined every other scanline, so when you enable the missile it will color all the pixels at the missile's X. It does rather look like a mirror or reflective surface. What I am curious now about is whether we can restrict the enabled m1's display to the player's height (minus it's Y). In other words, I'm curious if we could turn off the missile below and above the P1 sprite, before a drawscreen or during the vblank. Something like this might look a little like a shield:

 

 

 

I haven't done anything with the Vox, I was interested in it for my virtual pet project but didn't get far enough with that to learn much about Vox support. Now I'm counting on you to do all the work, I'd still like to finish with vp game. What I end up doing depends on how popular the Harmony becomes. I'd rather learn to use it, since that would allow for sd pet transfer and things like vp-war battle tournaments. Depending on how far you'd like to go with things, you might consider supporting both.

 

Sounds cool If more Vox's go on sale, I might pick one up as a Christmas present to myself (along with Juno First).

 

Cheers,

Jarod.

Edited October 28, 2009 by jrok

[MausGames]

I'm not sure what you mean by "19 variables to color player1", how are the colors/variables applied?

 

If you are not using the hidden playfield row at the bottom, you can use those playfield variables to track your player x/y coordinates. You are right that horizontal orientation can be done with a bit instead of a whole byte, so that will save you at least one. There is also a spare AUX variables I think.

[jrok]

I'm not sure what you mean by "19 variables to color player1", how are the colors/variables applied?

 

Maybe that was worded badly. What I mean is, I'm storing the color table of the player1 sprite in RAM rather than writing it to ROM. I've reserved sixteen RAM colors (p1color_row1 -thru- p1color_row16) that coincide with the 16 lines of a gladiator's shape data in ROM. For instance:

 

 dim p1color = a
dim p1color_row1 = a 
dim p1color_row2 = b
dim p1color_row3 = c
dim p1color_row4 = d
dim p1color_row5 = e
dim p1color_row6 = f
dim p1color_row7 = g
dim p1color_row8 = h
dim p1color_row9 = i
dim p1color_row10 = j
dim p1color_row11 = k
dim p1color_row12 = l
dim p1color_row13 = m
dim p1color_row14 = n
dim p1color_row15 = o
dim p1color_row16 = p

 

For general purpose, I could use this to define to color of each row as a hex or decimal number (i.e. "p1color_row4 = $CA" or "p1color_row4=202") and to perform color transformations in RAM (i.e. "p1color_row4=p1color_row4+2"). But for practical reasons, I reserved an additional three pointers for palette swapping.

 

 dim body_col = var13
dim head_col  = var14
dim hair_col = var15

 

That way, I could just retrieve one color for an enemy's outfit, then perform the gradient color changes (1) dynamically (2) only when necessary. For instance:

 

 
body_col = $D4
head_col = $EA
hair_col = $66

p1color_row1 = body_col
p1color_row2 = body_col
p1color_row3 = body_col
p1color_row4 = body_col + 2
p1color_row5 = body_col + 4
p1color_row6 = body_col + 4
p1color_row7 = body_col + 6
p1color_row8 = body_col
p1color_row9 = body_col + 2
p1color_row10 = body_col + 4
p1color_row11 = body_col + 4
p1color_row12 = head_col
if sprite2dir = 0 then p1color_row12 = hair_col
if sprite2dir = 1 then p1color_row12 = hair_col
if sprite2dir = 7 then p1color_row12 = hair_col
p1color_row13 = head_col
if sprite2dir = 0 then p1color_row13 = hair_col
if sprite2dir = 1 then p1color_row13 = hair_col
if sprite2dir = 7 then p1color_row13 = hair_col
p1color_row14 = hair_col
p1color_row15 = hair_col
p1color_row16 = hair_col

 

If you are not using the hidden playfield row at the bottom, you can use those playfield variables to track your player x/y coordinates. You are right that horizontal orientation can be done with a bit instead of a whole byte, so that will save you at least one. There is also a spare AUX variables I think.

 

I've been reorganizing and squeezing things down this week, and have found a bit more RAM. I think the "ideal" situation would probably be to define the final five rows of player1's shape data in RAM as well, to free up some additional ROM in my last bank, while adding additional flexibility to the player1sprite.

 

Cheers,

Jarod.

Edited November 2, 2009 by jrok

[MausGames]

I've been reorganizing and squeezing things down this week, and have found a bit more RAM. I think the "ideal" situation would probably be to define the final five rows of player1's shape data in RAM as well, to free up some additional ROM in my last bank, while adding additional flexibility to the player1sprite.

 

Thanks for explaining about the player colors. There are a lot of projects I've started that would greatly benefit from RAM player animation, but it's a little over my head still. By the way, I'm glad you are working more on this than your MIT game, I've never tried to tackle the ms kernel because I don't really like it.

Edited November 2, 2009 by MausGames

[jrok]

I've been reorganizing and squeezing things down this week, and have found a bit more RAM. I think the "ideal" situation would probably be to define the final five rows of player1's shape data in RAM as well, to free up some additional ROM in my last bank, while adding additional flexibility to the player1sprite.

 

Thanks for explaining about the player colors.

 

No problem. And remember, its not as if all that RAM is "gone" just because it's used it to color the sprite rows. I can still use a-thru-p to store temporary values before the sprite coloring subroutine is called.

 

There are a lot of projects I've started that would greatly benefit from RAM player animation, but it's a little over my head still. By the way, I'm glad you are working more on this than your MIT game, I've never tried to tackle the ms kernel because I don't really like it.

 

Have you checked out Michael's superchip RAM sprite demo?

[Animan]

This is by far the best Bb game i've seen in a while. CARTRIDGE RELEASE PLEASE!

 

Also, i've been learning how to program an Atari 800 lately, and have been interested in seeing how good this game would be on an 8-bit Atari. Could i have permission to port this to the 800 IF i ever am able to?

[jrok]

This is by far the best Bb game i've seen in a while. CARTRIDGE RELEASE PLEASE!

 

Also, i've been learning how to program an Atari 800 lately, and have been interested in seeing how good this game would be on an 8-bit Atari. Could i have permission to port this to the 800 IF i ever am able to?

 

I'll run it by my lawyers and get back to you.

[Animan]

This is by far the best Bb game i've seen in a while. CARTRIDGE RELEASE PLEASE!

 

Also, i've been learning how to program an Atari 800 lately, and have been interested in seeing how good this game would be on an 8-bit Atari. Could i have permission to port this to the 800 IF i ever am able to?

 

I'll run it by my lawyers and get back to you.

 

I mean, it's not that i will be selling my (no existent, yet) version (if i wanted to, i'd definitely get your permission before so), it's just a remake of the game, like how Activision had different people remake there games for other systems.

[GroovyBee]

How about making your own game for the 800 instead? Pick your own game idea and run with it and see what drops out at the end. You might come up with a winner too .

[jrok]

This is by far the best Bb game i've seen in a while. CARTRIDGE RELEASE PLEASE!

 

Also, i've been learning how to program an Atari 800 lately, and have been interested in seeing how good this game would be on an 8-bit Atari. Could i have permission to port this to the 800 IF i ever am able to?

 

I'll run it by my lawyers and get back to you.

 

I mean, it's not that i will be selling my (no existent, yet) version (if i wanted to, i'd definitely get your permission before so), it's just a remake of the game, like how Activision had different people remake there games for other systems.

 

 

The game is pretty far from finished. In it's current state it is still a pretty simple concept: "Shoot the Guy!" I guess I can't really stop anyone from making a similar game about shooting-various-guys.

[jrok]

Here's an updated playable demo. I'm not even sure how many incremental changes this is from the last one, but here's a general summary:

 

Title Screen:

• Press Select Switch to select which level to start at (levels 0-7 are selectable, out of 16 levels)
  
• Press Fire to go to the Character Selection Screen.
  

 

Character Selection Screen:

• Press the Select Switch to scroll through the available characters
  
• Characters vary by shields, range and speed.
  
• Press Fire to start the fight.
  

 

Fight Screen

• Press fire to Begin
  
• Hold Joystick to Move
  
• Press Fire to shoot.
  
• Hold Fire to lock aiming direction and autofire
  
• Tap Joystick to Slide/Roll
  

 

Post-Fight

• Press fire to return to Character Selection Screen (In this demo, you can pick a different gladiator for each match)
  

 

I've made the early levels a bit easy, although I added a few tougher guys towards the end. Ultimately, I think I can squeeze in about 42 preset matches, followed by eternal randomized title defenses. I still have quite a bit of work to do on obstacles and traps, but I thought I'd try to get some feedback on the new format.

 

Cheers,

Jarod

 

Circus_Galacticus_m1_d30_y11.bas.bin

Edited January 30, 2011 by jrok

[+Philsan]

Awesome, Jarod!

[RevEng]

Looks good, Jarod!

 

One nitpick - I'd prefer it if the character selection and level selection worked with the joystick too.

 

This one's ripe for Vox support. Did you ever pick one up, like you planned?

[+Philsan]

Like Mike, I prefer that all selections could be made with joysticks instead of console switches.

But if it isn't possible or you don't like it, no problem!

[jrok]

Awesome, Jarod!

 

Thanks

[jrok]

Looks good, Jarod!

 

One nitpick - I'd prefer it if the character selection and level selection worked with the joystick too.

 

This one's ripe for Vox support. Did you ever pick one up, like you planned?

 

Cheers, RevEng

 

No, unfortunately I haven't had the chance yet. Yeah, it might be a really nice touch to put in some synthesized taunts.

 

EDIT: I agree with you and Philsan. I'll try to include joystick control for the selection screen in the next build.

Edited January 31, 2011 by jrok

[CrazyChris]

Awsome game! It has been fun following the progress.

 

- Chris