Redshirts

[jrok]

Hey gang,

 

I haven't updated anything in awhile, so I thought I'd post some progress on a game I'm working. I've named it "Redshirts" in honor of those Sci-Fi Kamikazes of legend, who would beam down to hostile worlds and meet their inevitable doom.

 

The basic idea is that a Captain Kirk-type sends his hapless "Away Team" down to various planets to accomplish missions. The planets are 6x6 grids randomly generated at the start of each level, with the mission objectives randomly placed on the grid. The mission objectives will vary from level to level, including various tasks such as locating downed shuttle crafts (as in this one-level demo), killing certain badguys, rescuing fellow crewmen, etc.

 

I settled on a display routines that allows for:

(2) 30hz multi-colored player1's for characters

(1) 30hz player0 for multipurpose (scenery, traps, effects)

(2) 15hz player0's for laser fire

 

There is still a lot of stuff planned for this game. The idea I'm striving for is a game that allows you to earn tons of bonus points for doing exceptionally brave, awesome, funny, and stupid things. But for now, this demo is just to test the basic engine with a few different kinds of randomly appearing baddies.

 

Here are the controls (revised):

 

Joystick:

• Move in 8 directions
  
• While holding the fire button, tap the joystick in any direction to perform a defensive roll (cannot be hurt by laser fire while doing this)
  
• Tap the joystick again while rolling to fire
  

 

Fire Button:

• Start game from title screen, and to advance past "Mission" and "Lives Remaining" screens
  
• Press and hold to lock your aim you laser in the direction you are facing.
  
• Release to fire the laser.
  
• Holding the fire button for a second, then pressing it rapidly enables "Strafing Fire" mode. The player can continue to move around while firing a volley of shots in the same direction. The mode ends after a second of not pressing the button, and the player goes back to moving and aiming normally.
  

 

Select Switch:

• For testing purposes on real hardware, pressing the switch changes the color of the background, allowing players to cycle through the entire TIA palette.
  

 

Many thanks to Rev_Eng for his wonderful title screen minikernel!

Cheers,

J

 

 

Latest version:

Redshirts3.bas.bin (Added collision detection and a few functions to ray objects)

 

Old versions:

Redshirts2.bas.bin (Player can roll into rooms; world-edge bugfix; Strafing Fire mode; revised female roll animation.)

Redshirts1_button_roll.bas.bin

Redshirts1.bas.bin (does not reflect controls listed above)

Edited December 1, 2010 by jrok

[disjaukifa]

Dude that game is awesome.

[TrekMD]

Cool game in honor of those Red Shirts! Awesome!

[+Random Terrain]

Sometimes when you kill a bad guy, the top 1/4 of the screen fills up with what seems like random playfield pixels. Is that a feature or a bug?

[jrok]

Sometimes when you kill a bad guy, the top 1/4 of the screen fills up with what seems like random playfield pixels. Is that a feature or a bug?

 

Hmmm... well, if there was overflow of the RAM I'm using to store P1 shapes and colors into the portion of memory allocated to the PF, that would make sense as a bug. Not sure how or why that could be happening, and it's not happening for me at all in emulation. Are you looking at it in Harmony?

Edited November 24, 2010 by jrok

[+Random Terrain]

Hmmm... well, if there was overflow of the RAM I'm using to store P1 shapes and colors into the portion of memory allocated to the PF, that would make sense as a bug. Not sure how or why that could be happening, and it's not happening for me at all in emulation. Are you looking at it in Harmony?

Nope, I don't have one of those yet. I'm just using Stella. It happened around 3 times if I remember right. I'll try it again and make a screenshot if it happens this time.

[+Random Terrain]

OK, this time it happened with the second guy I shot:

 

 

Wasn't expecting it to happen so soon.

[jrok]

Hmmm... well, if there was overflow of the RAM I'm using to store P1 shapes and colors into the portion of memory allocated to the PF, that would make sense as a bug. Not sure how or why that could be happening, and it's not happening for me at all in emulation. Are you looking at it in Harmony?

Nope, I don't have one of those yet. I'm just using Stella. It happened around 3 times if I remember right. I'll try it again and make a screenshot if it happens this time.

 

Don't worry about a screenshot, I believe you. It makes sense if there is an overflow of the Superchip RAM. It's just frustrating because I can't see how/where it could happen. Is your Stella Game Properties set to Auto-Detect the cartridge?

Edited November 24, 2010 by jrok

[+Random Terrain]

Is your Stella Game Properties set to Auto-Detect the cartridge?

Yep. Game Properties > Display tab > Format: Auto-detect.

[jrok]

Is your Stella Game Properties set to Auto-Detect the cartridge?

Yep. Game Properties > Display tab > Format: Auto-detect.

 

Weird. Stella 3.0, right? Also, when you destroy one of the robots, do you see an animation, or does it just disappear?

 

Thanks for your help, RT.

[+Random Terrain]

Weird. Stella 3.0, right? Also, when you destroy one of the robots, do you see an animation, or does it just disappear?

I see the death animation before it disappears. I'm using Stella 3.1.2. This time I got stuck in the pixels:

 

Edited November 24, 2010 by Random Terrain

[jrok]

OK, this time it happened with the second guy I shot:

 

 

Wasn't expecting it to happen so soon.

 

That's exactly what I was imagining, too. Basically, the first thirty-two addresses of Superchip RAM are reserved for storing the color and shape for the player one sprite. Almost all the remaining RAM is used to store the PF. So it looks like, for some reason, some of that remaining playfield RAM is being written to during the death routine. Of course - like all the worst bugs - it's not happening for me in either Stell 3.0 or Z26.

 

Does it happen to you during your own player death sequence as well?

Edited November 24, 2010 by jrok

[jrok]

Weird. Stella 3.0, right? Also, when you destroy one of the robots, do you see an animation, or does it just disappear?

I see the death animation before it disappears. I'm using Stella 3.1.2. This time I got stuck in the pixels:

 

 

Yeah, you would definitely get stuck in them. I'll try downloading 3.1.2 and try to reproduce the bug. Thanks again.

[+Random Terrain]

Does it happen to you during your own player death sequence as well?

Not so far. It's only happened after an enemy death sequence, but the screen changes fast after player death, so I may not be seeing it.

[jrok]

Does it happen to you during your own player death sequence as well?

Not so far. It's only happened after an enemy death sequence, but the screen changes fast after player death, so I may not be seeing it.

 

Okay, I figured it out (somewhat). I had to disable the explosion animations for the robot and snake-tailed monster, but the playfield bug should be fixed now.

 

Revised file attached here and on original post. Thanks again, man.

Redshirts1.bas.bin

[Piggles]

This is a lot of fun. As with all your games, your animations are fantastic. I like how each crew member looks different. You have a good eye for graphic detail. I suggest the laser beams contrast more with the background. I can hardly see my laser beams, making shots difficult to aim.

[iwan-iwanowitsch-goratschin]

This is a worthy sequel to Circus Galacticus! I really enjoy your games, they are great but please try to finish Circus first.........including a 2 player mode!

 

 

PLEASE!

[+Random Terrain]

Okay, I figured it out (somewhat).

Yeah, so far the problem seems to be gone, but there seems to be a new problem. Many times now when I enter a screen, instead of being in the middle or the opposite side of the screen, a bad guy will start out really close and kill me before I have a chance to react. Did you change how bad guys are placed on a new screen?

[abaudrand]

I'm impressed by the quality of your work... Great gameplay and great graphics!

[+Gemintronic]

Very, very awesome! I definitely see an evolution in your game engines. Although your instructions don't say it tapping a direction twice does a barrel roll AND fires. This is a good thing.

 

The player and some objects seem to flicker but it's at an acceptable level for me.

Edited November 24, 2010 by theloon

[+stephena]

That's exactly what I was imagining, too. Basically, the first thirty-two addresses of Superchip RAM are reserved for storing the color and shape for the player one sprite. Almost all the remaining RAM is used to store the PF. So it looks like, for some reason, some of that remaining playfield RAM is being written to during the death routine. Of course - like all the worst bugs - it's not happening for me in either Stell 3.0 or Z26.

This feature was added in Stella 3.1 or so, specifically for this reason (to help developers detect illegal accesses to cart RAM). I haven't looked at your code (so I can't say for sure), but another possibility is reading from the write port, which will randomize the contents of the write addresses. Maybe you're reading from the addresses only meant for writing?

 

There's a debugger option to detect that. First of all, make sure you have the latest version of Stella (3.3). Then, enter this in the debugger:

  breakif _rwport

If any read accesses are made to the write port, then the debugger will break and (hopefully) show you where you went wrong.

[jrok]

Very, very awesome! I definitely see an evolution in your game engines. Although your instructions don't say it tapping a direction twice does a barrel roll AND fires. This is a good thing.

 

Thanks! Ultimately, the way it will work is: first tap rolls in the direction you pressed, second tap fires in the second direction you tapped, so you can shoot in a different direction than you rolled. This would be ideal for diving out from behind cover to blast at someone.

 

The player and some objects seem to flicker but it's at an acceptable level for me.

 

Yeah there is some flicker. The most flickery thing are the laser sprites, which display every fourth frame. Hopefully I'll have real hardware to test out the flicker and color blend on someday.

[Brian O]

Great concept and execution! Can't wait to see the finished product.

 

-B

[jrok]

There's a debugger option to detect that. First of all, make sure you have the latest version of Stella (3.3). Then, enter this in the debugger:

  breakif _rwport

If any read accesses are made to the write port, then the debugger will break and (hopefully) show you where you went wrong.

 

Thanks Stephen. Yes, I do realize that it's a problem with my the somewhere. I was trying to do something a bit fancy with the death animations of a certain enemy, so for now I just, uh, de-fancy-fied it to fix.

[jrok]

Great concept and execution! Can't wait to see the finished product.

 

-B

 

Thanks Brian!