jrok

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.

Thanks. For the borders, I'm just setting PF0 to 255 every other frame. I've experimented with larger hit areas, but it doesn't have the same feel for me. Maybe I'll post a "head-to-toe" hit area binary at some point just to get a sense of how people feel about it. But it just doesn't feel like a pitched, touch-and-go battle to me. Yes, it's intentional. Actually, as I progress farther in the game I find it invaluable for quickly escaping and finding good angles on the tougher enemies. Ultimately, I might tie this into a full melee combat mechanic. I'm pretty undecided on that at the moment. Well, there will definitely be multiple weapon types for your enemies . I'm experimenting with two alternate enemy types at the moment, one of which uses a "bouncy" gun. I don't really want to post something like that until I can figure out the proper AI and leveling. The "sword" woould be an alternate atttack for the player, once the implementation feels good. I am thinking about player customization and a two player deathmatch mode, though, so that might be a good opportunity for weapon variety. Cheers, Jarod.

I played this game at Disneyland (Aneheim) back when I was stationed at Ft. Irwin in 1991. Great game, I would love to own it. Wow, for a "rare" game, Time Traveler sure has been mentioned a lot on this thread.

I think it's not just the lack of RAM or ROM that we are talking about here, but also the timing and hardware object limitations for drawing that many independent, multitasked sprites on a line. I mean, if you don't care at all about accuracy, I suppose you could just change all the Galaxian graphics to bees But Galaga has a lot more going on "horizontally", particularly when the enemies are entering formation and during the Challenge Stages. Not saying it's impossible, but it's certainly not just a "hack" of Galaxian. I imagine it would be rather difficult game to accurately port to the 2600.

New Version: A few minor bugfixes as well as some variation in the terrain/obstacles. In addition to an alternate layout, I've also added some initial shield barriers to some of the levels. I'll expand this sort of thing in later builds. *In the pics below, laserfire can pass through the "Shooting Ports", but gladiators cannot. *Some levels will begin with some shootable "shield" terrain already in place. Gladiators can pass through this material, but it will block shots until it is destroyed CG_10_25_09B.bin Cheers, Jarod.

Ok, this new version includes the Harmony Cart fix (hopefully), a few minor bugfixes as well as some variation in the terrain/obstacles. In addition to an alternate layout, I've also added some initial shield barriers to some of the levels. I'll expand this sort of thing in later builds. *In the pics below, laserfire can pass through the "Shooting Ports", but gladiators cannot. *Some levels will begin with some shootable "shield" terrain already in place. Gladiators can pass through this material, but it will block shots until it is destroyed CG_10_25_09B.bin

Thanks batari I replaced the include file, found and deleted the bogus register read and then re-compiled. New binary attached. CG_10_25_09.bin

Thanks, dudeness. I agree. It would be pretty cool if the game made fun of you if, for instance, for fighting like a chicken instead of a robot. Green Guy just wants a hug. There are a few big guys along the way, who will eventually function as bosses. For the time being, they just have more hit points and are releatively more aggressive. The bosses will eventually have different AI, weapons and a few different sprite-sets, but for now they are just big blobby butted versions of the regular guys. This is mostly a rough proof right now, just to nail down collision boxes and what not. Ultimately the layouts will be more flexible, and the obstacles themselves will have different properties on each level (reflective shots, guided shots, traps,triggers, etc) I played the first few chords of "Stairway" last night. I think. I was drinking pretty heavily. Thanks. Looking into it. Hey, maybe I can use the lower left status bar for that! Hmm. This shouldn't work, yet on one side of the screen it does! Of course, that wouldn't help you on the later levels, when those safety zones turn into death rays quicker than you can say "those safety zones turn into death rays." But I'll look into it ASAP... it's defo a bug, thanks. It's weird. I never once blew past a score, but apparently this is still a problem. I'll check it out. Cheers! Jarod. *** OK! I fixed the safety zone bug now. They should disable your weapon completely (although you can still quick dodge inside them. New file attached. Thanks again Strum! Jarod CG_10_24_09_new.bin

Attached is the latest production build of the game. I have revamped and redesigned a lot of the original gameplay elements, as listed below. Changes: Probably the biggest difference is the way that obstacles are handled. I'm now using sprite based obstacles instead of using the playfield to draw the arena terrain. This has the obvious advantage of allowing for laserfire that is different color then the terrain (which was a bit distracting given how much blasting was going on!). A less obvious advantage was that I could do away with all that nasty playfield-reading for collisions. For now the obstacles are indestrucible and static across all levels, but that will change eventually to incorporate things like "reflective scenery" (for angled/bank shots) and other alternate game mechanics. I've begun implementing a secondary manuever for the gladiators. When you just quickly tap the button (as opposed to holding it down to charge your gun), you will leap in the direction you are facing/moving. For now it functions mainly as a quick dodge or charge, but you might notice there's a sword drawn in front of your player sprite when you do this. Ultimately, I'll use this to incorporate a bit of simple melee combat. Now that the obstacles are sprite-based, I've simplified the "safety zones" on the left and right to simple shafts of color. More importantly, you can now use them to wrap the screen, creating a opportunity for a quick escape or sneak attack. Three red dots in the score area track your shield strength. There is a bar on the right that... well, it doesn't track much of anything right now. The hittable areas for the gladiators has been expanded. Aiming at either the head or the chest should produce a hit most of the time now. I've kept (and actually expanded) the "bug" where glancing hits melt off parts of the player's shielding, which creates trails of temporary cover around the arena. In heated battles, quite a bit of this stuff falls around, providing opportunities to create "sniping holes" like in the original version. When the Emperor comes on to announce "overtime", all of the terrain obstacles disappear. The program is really quite different in many subtle ways too. I've tweaked the AI somewhat, and I've ramped up the overall speed of the game, particularly when it comes to the speed of laserfire. I've also tweaked the graphics, sound, colors and animation in many places, including a new color logic for the backgrounds and a clearer hit animation. I'm really psyched about this project again. Cheers Jarod. EDT: Here's some pics of the new version. Also, if you downloaded the version I posted a few minutes ago, you might want to redownload and replace, as I fixed a small big with the player's hittable region. Cheers. CG_10_24_09_new.bin

I was thinking when I first played this that something as simple as "bonus score while moving" would really deepen gameplay a whole lot and make it more competitive. Cool.

Actually, just because it was so easy I went ahead and fixed this now. I also altered the color of the "shield residue" that's left behind form glancing hits, to hopefully make it a less confusing gameplay element. Cheers, Jarod. CG_10_24_09_new.bin EDIT: I neglected to reset the score on new games. So, I don't want any smartypants submitting hi scores for the previous version (LOL). New version below (with new score graphics ) EDIT: I expanded the hittable regions of the gladiators, to make for shorter ,more brutal contests. (*fixed)

Good call, yeah. There is a lot of garbage like that to sweep up right now before I start actually "designing the game." I guess my big benchmark now is to get this core engine running very smooth, and then hunt down all the little beetles and gnats.

That's this: In other words, glancing hits peel off some plasma from your shielding that sticks around until shot. This actually happens more now then it used to, because I like the effect. You can walk through this stuff, but it will block a shot. There is a "sweet spot" that is hittable at all angles. With some practice you will find it. Also bear in mind that the enemy can block your laser with a laser shot of his own (and vice versa).

Wow, just about ten months since I updated this. I'm really truckin' on this project! Anyway, there have been a bunch of big changes: Probably the biggest difference is the way that obstacles are handled. I'm now using sprite based obstacles instead of using the playfield to draw the arena terrain. This has the obvious advantage of allowing for laserfire that is different color then the walls (which was a bit distracting given how much blasting was going on!). A less obvious advantage was that I could do away with all that nasty playfield-reading for collisions. For now the obstacles are indestrucible and static across all screen, but that will change eventually.... I've begun implementing a secondary manuever for the gladiators. When you just quickly tap the button (as opposed to holding it down to charge your gun), you leap in the direction you are facing/moving. For now it functions mainly as a quick dodge/charge, but you might notice there's a sort-of-sword drawn in front of your player sprite when you do this. Ultimately, I'll use this to incorporate a bit of melee combat. Now that the obstacles are sprite-based, I've simplified the "safety zones" on the left and right to simple red shafts. More importantly, you can now use them to wrap the screen, creating a venue for a quick escape or sneak attack. Three red dots in the score area track your shield strength. There is a bar on the right that... doesn't do much of anything right now. The hittable areas for the gladiators has been expanded. Aiming at either the head or the chest should produce a hit most of the time now. I've kept (and actually expanded) the "bug" where glancing hits bleed off pieces of the player's shielding, which creates temporary cover around the arena. In heated battles, quite a bit of this stuff falls around, providing plenty of opportunities to create sniping holes like in the original version. The program is really quite different in many subtle ways too. I've tweaked the AI somewhat, and I've ramped up the overall speed of the game, particularly when it comes to laserfire. I've also tweaked the graphics, sound, colors and animation in many places, including a new color logic for the backgrounds and a clearer hit animation. I'm really psyched about this project again and can't wait to wail on it more. Cheers Jarod. *EDIT: Minor sound bugfix and altered color logic for shield trails. **EDIT: I neglected to reset the score on new games. So, I don't want any smartypants submitting hi scores for the previous version (LOL). New version below (with new score graphics ) ***EDIT: I expanded the hittable regions of the gladiators, to make for shorter, more brutal contests (*fixed). CG_10_24_09_new.bin

That really is a fantastic looking game--I hope you are able to finish it someday. For some reason the audio is completely screwed up when I play the above video. It has no relation at all to the audio when playing the game in an emulator. ..Al Jeez, you're right Al. The sound is totally hosed. Maybe I screwed something up when I recompressed(?). I didn't have access to sound when I posted. Darnit all.

ACA Capture Pro and Stella seem to work very well.* I made a video of a game I'm working on. http://www.youtube.com/watch?v=GZNBjw0c-4g *Note: I recorded with the Microsoft Video 1 codec, but then did bit of additional compression (to H.264, square pixel 640x480).

This is great, guys. Big thanks to Michael and Jeff! Here's my contribution. It's the beginnings of a potential title screen for Circus Galacticus. One thing I did different was to self-contain the asm subroutines within a batari loop, so I could more easily make color changes on every frame. WARNING: This binary is a tad psychedelic, so if you are prone to seizures you might not want to check it out. Jarod. bitmap_CG.bin bitmap_CG.zip

Or they could attempt to get permission to actually publish it under the name Prince of Persia. You never know until you ask. I vote "King of Kazakhstan."

Robotron always sort of reminded me a zombie flick, with those big, (relatively) slow herds of red guys closing in on you.

I rather liked the "lock-on" missile mechanic. Other than that it was pretty unimaginative.

Thats awesome! If you like maybe send a pm to groovybee and discuss graphics and animation with him. The more help we get with this the cooler it will be. Welcome aboard jrok! I think that a design document for a game that fits the machine's capabilities needs to be on the table before graphics are started. For example, if you wanted a 1000 enemies on screen at once its not going to happen . You read my mind. Actually, I just assumed graphics and animation would be tabled at least the design doc had been written and perhaps a rough engine had been hammered out. But I'd be happy to work up a few samples once you had a tile size, resolution and framerate you were happy with. The offer will still be on the table whenever that happens. Oh, and I'll be happy with just 500 enemies per screen

It's really great that this is happening. It sounds like a very exciting project, and the action/RPG model seems appropriate. I wouldn't mind at all contributing some graphics and animation work. Cheers, Jarod.

I don't expect they are talking about "generating" passwords at all, but rather having a static system of set codes that correspond to all the variables local to play (i.e. Swords and Serpents, Metroid, etc). I imagine that this would include all possible stats and customization, and would allow for "cheat codes" if you could crack the cypher.

How soon we forget... FerTari: The Atari Ferrari

Gingerbread Man and Dungeon are great games, independent of "how" they were programmed. Robert M is working on an excellent unnamed shooter that I am sure could be compared favorably to 90% of assembly VCS games when it's completed. The various proto-stages he has released are a great example of how to really push the boundaries of the canned kernel. Most of those boundaries don't really exist anyway, when you take a closer look at what's going on under the hood, or check out some of the great threads in this forum where heavy-hitters like batari, supercat, SeaGTGruff, Nukey, CurtisP and others crossover to give great advice, insights and examples. The forum itself is actually a real treasure trove, and sometimes I have a feeling that if more basic programmers spent more time spelunking what is already here and less time posting new topics/questions, the average quality of these games would go through the roof. Also reading Andrew Davies ASM programming tutorial is a great idea, even if you don't understand all of it and have no plans to wade into writing a kernel from scratch in pure assembly. Just understanding the bare bones of what is at work can give you a good starting context for programming for the VCS, even if its in basic.