jrok

I disabled the scoring temporarily, so I could use the score to track the background color for those testing on real hardware.

Thanks for the feedback and testing, guys! Here's an updated version addressing certain bugs and points raised by posters, as well as some revised controls: Revised Controls: Move Joystick (no button) - Move the crewman in 8 directions as usual. Hold Down Fire Button - This locks the crewman's aim to the current direction. Release Fire Button - Fire the laser. Move Joystick with Button Held Down - Strafe the crewman in 8 directions without changing the direction he is aiming his laser in. Tap Joystick with Button Held Down - Perform a combat roll in the direction tapped. If the button is pressed, the crewman can roll in a different direction then the one he is aiming, along him to pop out from behind terrain shoot enemies. A second joystick tap or button release will fire the laser. Strafe Mode - If you hold the fire button for a second then rapidly press it, you will continue to fire in the locked direction while moving. Releasing the fire button for a second will return you to normal moving/firing mode. Bug fixes: Playfield bug on enemy death fixed. Improved collision detection with playfield. Player always starts in room 1 Player can roll into rooms. Color testing on real hardware: Select switch increments the background color and the score tracks background's decimal value. Redshirts2.bas.bin

The controls are sexy and the game plays really well with Cannibal Corpse in the background. You have the knack for getting maximum visual quality and gameplay from the standard kernel and it's fantastic. Thanks Piggles . Fred's standard kernel combined with a lot of the enhancements and advice other AA folks have contributed is really very flexible, I think.

Okay here's a revision of the last type of movement. Now, tapping the joystick in a direction only does a defensive roll if you have the button held down (strafe mode). Actually I think this is probably the best movement setup of all three, and I think I'm probably going to stick with it. With this version, you can change your aiming direction quickly without going into a roll if you don't hold down the button, making it easier to lock in a new direction. Obviously, the best control setup would be to have two buttons on the stick (one for strafing and one for firing, maybe), but that would require a Genesis joystick. Cheers, J Redshirts1_button_roll.bas.bin

Here is an alternate movement/firing method. Curious if anyone likes this version better: Move Joystick (no button) - Move the crewman in 8 directions as usual. Hold Down Fire Button - This locks the crewman's aim to the current direction. Move Joystick with Button Held Down - Strafe the crewman in 8 directions without changing the direction he is aiming his laser in. Release Fire Button - Fire the laser. Tap Joystick - Perform a combat roll in the direction tapped. If the button is pressed, the crewman can roll in a different direction then the one he is aiming, along him to pop out from behind terrain shoot enemies. Also, I've revised the terrain collision detection a bit in this version. Now you should be able to move smoothly along walls no matter which direction you approach them from by pressing diagonally against them. This should make it easier to slide around obstacles and find shooting angles. Cheers, J Redshirts1_alternate_move.bas.bin

Thanks!

I guess it depends on the kind of game. The important thing to remember is that you are just running the game as usual, except that five inputs will be automated: the cardinal directions of the joystick and the read-state of the fire button. Everything else is the same. When you think of it that way, it becomes more simple How you implement it could be really simple or really advanced. For instance, if you already have an AI opponent coded for a fighting game, you could re-purpose that enemy's code for an Autoplay "Player One". If most of your AI is coded in functions, then you could pass variables to those same functions to move the player's sprite without using up a lot of additional ROM space. Another way to autoplay would be to encode joystick "dance steps" in data tables, similar to the way one might encode music by moving an array pointer through it. The idea I think would be to again re-purpose as much existing code as possible, setting up constants that when the array pointer reaches them will execute various in-game subroutines linked to player inputs ("FireMissile", "Jump", "RunLeft" etc). I think the important thing is to code the gameplay first, and a simple solution for autoplay will probably present itself afterwards. The inputs for the joystick and fire button can even be mostly random, and still seem visually interesting. I guess the one good thing about autoplays is that the "auto-player" can genuinely stink at the game and the demo can still be effective... and even funny as you watch the Ghost Player One haplessly drive into pits or run headfirst into laserfire over and over. We've all seen these types of demos and attract-modes before.

You might remember that controlled randomness is at the top of my list of importance, but another thing that is high on the list is some kind of AI. I love 'smart' enemies, but I also love it when the program seems to be smart. I like it when the program is thinking ahead and looking out for the player, making sure everything is as fair as possible. It won't start you out in an impossible position where you'll die no matter which way you'll go or start out with an enemy that has a gun pointed at your head. It's kind of like treating the player like a guest at your home. You don't punch them in the stomach as they walk in (you wait until later to do that after they piss you off ). Well, it's not some Kobayashi Maru Test...or is it :) ? You don't die right away. You have time to react, and roll away from danger. Besides if you pay attention to exactly "where" the enemies start each time , rather than just plowing into a room at random, you can control whether or not the Damn Dirty Cheating Enemy appears next to you . This is literally controlled randomness, as far as I'm concerned. Random within a limited range, with the danger minimized by a little observation, forethought and planning. Oh but perish the thought that we should demand such things of our players! I forgot we were supposed to hold their hands and whisper sweet nothings into their ears Other controlled random elements include the map layout itself. The tiles are randomly positioned, but with a key to the pattern that allows you to predict which room is next. If you pay attention when you move across this "random terrain" you'll probably figure it out within a few games. And knowing what room comes next can lead to even *more* planning for how you want to enter the room. As for smart enemies, I think these are fairly smart. They can navigate simple terrain and locate shooting angles. They can't solve complex riddles or physics equations yet, but I'm working on it So, basically these elements you mentioned are already there, and can be discovered with a little patience and perseverance.

That's weird. Every time before, they were always in the middle or on the other side as if the program was doing it on purpose. I guess I got lucky. I thought you were kind of doing what I was doing in my program. In the crappy program I'm trying to finish, an 'enemy' drops in from the top semi-randomly, but it will not drop on the player. If the player is on the right side of the screen, the 'enemy' will appear randomly on the left side. If the player is on the left side, the 'enemy' will appear randomly on the right side. I thought about doing that, but it seemed like taking it too easy on the player. After all, this is a Sci-Fi suicide squad! However, that could be a good thing to implement when I integrate multiple levels. In the earlier missions, the enemy could be less likely to appear near you, and as you proceed through the game, they gradually become more likely (maybe capping the likelihood at 50% or something). Or another potential method might be to start with an empty room, and have the baddies enter it from the screen edge a second or two after you enter. This way, they could potentially attack from anywhere, including right behind you! Or it could be a mixture of the two - sometimes they are already in the room in one of the random positions, and sometimes they enter the room after a short delay. What do you think?

*FYI* For anyone playing the demo on real hardware, I made a version that allows you to cycle the background through the TIA palette, so you can find the best color to minimize the flicker. Just press the select switch to step through the palette (color shifts two values with each press). Cheers, Jarod. Redshirts1_colorselect.bas.bin

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? The bad guys appear in one of five random positions, depending on the layout of the screen. If you enter a room close to one of them, you had better roll out of danger ASAP! So, this not a bug. After all, I vividly recall entering some very dicey rooms in "Berzerk", and receiving a none-too-friendly reception from the robot occupants!

Thanks Brian!

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.

Thanks again. I've attached a new binary that allows you to select the background color by using the select switch (each press increments the background color by two, cycling through the TIA palette). Kind of curious if there is any luma and/or chroma that looks okay, if you or KevinMos ever have some time to play around with it. Cheers! Jarod. Redshirts1_colorselect.bas.bin

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. 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.

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

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.

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?

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.

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?

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?

Thanks for the feedback, SpiceWare. For the crew, I thought I'd just switch things up, and let the player's imagination do the rest. Ultimately, the crew members will be randomized as well. Do you mean I should use black or grey for the backgrounds? It couldn't be black, I guess, due to the black pants, although I could change those to red scale. I attached a version with a dark grey background and one a light blue one to this post. I'm a little curious how it looks, if you have some time. I don't have real hardware to test on, so its hard to visualize the mix. Cheers, J Redshirts1_darkgrey.bas.bin Redshirts1_lightblu.bas.bin

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)

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 "Redhsirts" 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 task 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, effect) (2) 15hz player0's for laser fire There is still a ton 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/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: Fire Button: - Start game from title screen - Click to pass Mission and Lives Remaining screens - Hold to aim your laser, release to fire Joystick(or arrow keys in EMU): - Hold in any direction to move - Tap in any direction to perform a defensive roll (cannot be hurt by laser fire while doing this) - Tap or hold while rolling to fire Many thanks to Rev_Eng for his wonderful title screen minikernel! Cheers, J Redshirts1.bas.bin

Another idea for a Game Mode: "Knight Rider" Mode 1) Change the snakes into locks of David Hasselhoff's hair. 2) When one hair surrounds another, K.I.T.T. engages his Turbo Boost and rockets across the screen. 3) Driving Level 4) Michael Knight Beat'em'up Level 5) Boss Battle! After someone codes all of that, you can just sit back and watch the profits roll in! Seriously, though, why do you want to write this for Atari 2600? It is a tremendously difficult system to program for. You'd probably be better off just learning your way around the Flash IDE and coding it in Actionscript 2.0 (which is a bit more forgiving for newcomers). Or even writing it as a Java Applet. Or in C++. Or as a regular board game. It actually might make an interesting board game.