jrok

Demon Attack ends at level 85. Lord knows I learned that the hard way.

Triangle?

Yessir Jarod, If Nukey could remove the weather elements and turn her black and white with a Fonz logo I would say he should have a pack of 'moking 'baccer and a French harp due from me Wp For the sake of more faithful port, I guess the the extended play feature should also match up with the metric listed on the flyer: 10 points per second at low speed 20 points per second at top speed Extended play every 1000 kilometers (Is Fonz from France now??? Ayyyyyyy!) The only trick is, how were the scoring speeds differentiated? Was there a certain kilometers-per-hour threshold you had to cross before the double-scoring kicked in, or was it just when you are running at the absolute top speed? And, if so, what was that top speed, and what was the threshold for "low speed"? In other words, was there a speed limit that did not give you any points when you went beneath it? I honestly don't rememeber, not even with Motocross. One last thing... I think for some sort of historical context, the game should include a pair of adjustment functions that mimic these godless features from Sega Marketing: "To increase the challenge, the size of the bikes can be regulated by the operator. Game time is adjustable from 45 to 100 seconds." So, if my calculations are correct, some absolute scoundel at the local five-and-dime could pretty much rob your quarter if he wanted to. At 45 seconds, you'd basically have to run the course at top speed (which you probably couldn't even reach until the fifth or sixth second of play?) and you'd have to do it 110% of the time without crashing in order to extend play. It kinda makes me wonder... what if Fonzie himself wandered into the lobby of a Denny's at 3 a.m. and fist-bumped the Fonz machine? Would he be able to fonz-ify the space-time continuum to achieve "110%" of the top speed?

Why should this be sold at all? It would be much better as an open, evolving binary, so that composers can continually update their own versions with new songs. Besides which, the concept isn't even ours. It wouldn't be right to sell it.

Fonz and Motocross are exactly the same save for cabinet art. No Mame for Moto either. Wp If there's no additonal gameplay, then I would think Nukey's Enduro hack is just a black and white color test and a scrolling Fonz logo away from winning, hands down. I don't think anyone can top that. Give that feller a harmonica.

What was the gameplay like in Fonz? Judging by the only grainy shot of the cabinet I've seen, it sort of looked... well almost exactly like Motocross? Was Motocross also a discrete circuit unit? Has it been mamed?

Are you kidding? The Fonz could jump a shark on a broken tricycle... while doin' three chicks. Ayyyyyyyyyy!

Eyyyyyyyy! Sit on it! Fonzie.bin

Well a tech demo, anyway... Better late than never! EDT: Okay, now that I got my bad Knight Rider joke out of the way, here's the real deal on this game. The gameplay will take place on a medieval battlefield. Your mounted knight will knife through the enemy ranks like a runningback, slashing at footmen with his sword and jousting enemy knights he comes across. The movement is 3D-ish, although the gameworld isn't a contained space right now, just a limitless, axononmetric plane. In this build, I've included a sample sprite of a line of enemy soldiers that respond to the movements of the gameworld. They are also an "eternal" line for the time being, but the goal is to pull array data for that determines the length and depth of each rank. I sorta like the effect so far, but it would be much better if I could turn the battlefield into a gradient plane (i.e. playfield lines become brighter as they get closer to the foreground). Right now I'm trying to figure out a way to store both the playfield rowheights and colors in RAM. If I could do that, I may even be able to incorporate scaling horizon elements, which could be sort of cool Latest version: KnightRider_1_10_09.bin

I'm starting to get really freaked out by the sheer number of licensing discussions that I've encountered on the developer boards. [rant] Ironically, isn't this sort of mentality that caused the video game crash? Lack of imagination? Reliance on brand-recognition to artificially spark interest? Isn't it supposed to be about the gameplay? Isn't it supposed to be about the fun?? Why try to win support by saying your game is based on some copywritten TV show? That's not programming... it's marketing. Let's try for a new twist, or an unique game mechanic. If you make an enjoyable game, no one will care if you call the character "Hominus Erectus III." Let's not let this hobby become some absurd microcosm of what's wrong with the REST of commercial gaming. [/rant]

Actually, after re-reading this thread I have to confess I'm a little confused. Why are we even talking about graphics for Guitar Hero? If anything, games like Guitar Hero, Rock Band and a whole host of Wii titles have proven what all us AA geeks already knew: games should be about fun not graphics. In some ways, Guitar Hero seems like the perfect Atari port. Even though it runs on monster hardware, the graphics are minimal - really almost an afterthought. The enjoyment in the game is all about the interaction: with the music, with the instruments, with your friends. The commerical game actually could be a 2600 display and not lose one ounce of fun. In fact, depending on taste, an Atari port could actually be even more fun in a kitschy, Karaoke way, even for non-Atari fans. Open Source Pong : I'm not trying to be rude or discouraging or anything like that, but I personally think you might be approaching this port backwards. You might want to consider starting by composing a couple of songs, rather than concerning yourself with the display or interface or how you are going to make the fret boards. The music is what would drive the programming effort here. Atari music is an art all unto itself (and one I'm pretty terrible at, as some recent experiments have proven. ) It might be helpful to read some of what Paul Slocum has written about Atari music. Also, you should play around with Random Terrain's excellent Music Starter, since you want to approach this with Batari Basic. Try your hand at just one song first, even if its a simple one. Once you've programmed a song, you'll probably have also learned more about the way that sequential data arrays function in the Atari framework. After all, a successful port of this game will ultimately have to work like one of those old fashioned Player Pianos, with the data in the music array directly governing what's happening on the screen. In other words, the song should control the game, rather than coding the song as an isolated element and than hard-coding the movement of the chords themselves to try to match up to a song. Again, none of this is meant to be discouraging. I really do think Guitar Hero would be an excellent port, but it is a deceptively simple game and might not be a good choice for a first time programmer. It absolutely worth exploring though, perhaps by using the team approach. Not only would it be a fun game, but if its well-constructed it could be a great community project, giving some of the great Atari composers an ongoing workspace to showcase their amazing work. And if anyone else is up for it, I wouldn't mind participating and helping out in any way I can. Except for writing the actual music... I'm as tone-deaf as a cactus in a parking lot. Okay, that was my $0.03. Cheers! Jarod.

That's not exactly correct. The ball share's the playfield's color (COLUPF). Missile0 share's player0's color(COLUP0), and missile1 shares player1's color(COLUP1). Personally, I wouldn't use the sprites or the missiles or the ball for chords. I would use the playfield pixels for the chords and the ball or a missile for the guitar pick. That way you'd still have four free objects to use for other purposes or for polish. Just my $0.02 Jarod.

Holy Toledo!

I've been giving some serious thought to developing some sort of a Superman vertical shooter for the 2600. Obviously, if I ever tried to sell such a project, DC would have their Legion of Super Litigators get all medieval on my a$$, so this would be a binary-only sort of project. Actually, since Supes is a cuddly, kindly sort of hero, the game probably wouldn't have a large degree of violence in it. Sure he could murdalize a few evil robots now and then, but I can also see a lot of defender-style rescuing going on. I put together a couple of sprites... Any thoughts? Cheers, J Superman_and_Brainiac.bin

Out of curiousity, what inspired you to start homebrewing? For me, I think it was a love of retro graphics. I work in the motion graphics industry, and I spend most of my days managing the obscene amount of the technical minutae that goes into modern animation, so I guess I just found it really fun and relaxing to fiddle with Atari's minimalist display.

Thanks. I don't really plan on throwing out the baby with the bathwater, I guess. What I've been experimenting with lately is whether I can draft two or three unique A.I personalities - the current one being one of 'em - and then switch them up depending on the gladiator you are facing. Hopefully something like that would make it a player less likely to approach each level the same way, and maybe spend a few seconds to try to figure out which persona he is up against. Nonsense. Conquest of Mars is about as fine a homebrew as I've ever seen - light years better than anything I'm doing here. If you read some of his other reviews, he often sounds a little sissified, trashing any game that he can't immediately master no matter how great it is. Here's an easy game for him: buy a bottle of tequila and copy of Die Hard and drink every time someone drops an f-bomb. I'll call it "Live Free, Drink Hard." He'll probably be too loaded to play Smurfs Adventure afterward, but hey at least my game isn't too hard on his poor wittle fwingers. Will he give me an A+ for that??? (BTW those laser gates were ROCK HARD but definitely NOT impossible) That's totally ingenius, man. I'll definitely try to rig something like that up. Thanks!!! Jarod.

First of all: THANK YOU SIR. This is the most detailed, helpful feedback I've gotten on this game so far. Okay, onto it! EDIT: I had to try one more game and managed 2020. Holy mooseapples!!! You know, I've played all the enemies (being the programmer, I am able to cheat with impunity), and I'm sort of proud you found those particular men tough. Thats really the point where I start upping the anty on some of the AI as well as the tangibles like range. It feels good to know that they are giving some headaches even to someone as skilled as you. Haha, Ghostbusters, yeaaauuuhhh. I'm a New Yorker so they'd shoot me if I didn't get that one. Literally. Excellent point. Will do. Shhhh!!! It is absolutely a scoring exploit, and it is there on purpose. There are actually a couple of other scoring exploits in the game right now, and I will try to add several more before the game is completed. Personally, I was sort of a scoring fanatic back in my arcade days, trying to figure out secret ways to game the system and rack up points, so I'm a big fan of adding secret bonus scoring elements into games. This is exactly the sort of ramp I'm trying to balance right now, and your insight on this is invaluable (especially since you apparently, well, kick ass at this game). As I'm sure you've noticed, the gladiators get a bit more aggressive as you progress, get a longer ranged weapon, have more hit-points, are more likely to seek the higher ground, etc. The brute force method you mentioned just sounds like a great tactical idea to handle those early guys, and I honestly didn't even think of it when I was programming. But (hopefully) the later guys will see you coming and blast you. This was a great comment, BTW. It really is making me think about how I want to fine-tune the AI. Thanks! These two are known bugs, although I'm not sure if I want to fix the first one and I have a gameplay element in mind to replace the second one. Basically, when both gladiators die, the gladiator who got shot first loses the match, which I'm not sure I hate since it could be a sort of happy surprise! The second is a bug for sure, and is related to the way the current kernel is set up (no playfield pixels in the left and right 10%). The thing is, I don't want you to be able to shoot in the safety zones anyway, but I've been racking my brain trying to thing of what else you could do there when you press the button. Playtesting (especially by bada$$$ mofos like you) is definitely going to help determine that. A Defender-style Teleport to a random area, maybe? What sort of action would be useful, yet risky? Again, this is the most feedback I've ever gotten on this game. Thank you. If the rest of your comments are any indication, I predict you will probably figure this one out too! Cheers! Jarod. P.S. TVGC bites the big one!!!

heh-heh... you said flesh.

I'm not sure it's really meaningful to compare entries against all different systems. If a 4K game on the C64 behaves identically to one on the 2600, should the latter get more credit for doing more with less? How much? Given that many people have different biases toward different systems, I think it might be better to have separate contests for different platforms. I agree. I've written 1K and 2K games in flash that I was quite proud of... but it makes absolutely no sense to compare a 1K ROM that's backed by 2.3G RAM and an Athlon dual processor to one that's running with 128 bytes and a 650x. That's not even "apples and oranges"... more like "apples and thermonuclear warheads." And I don't think its something you can handicap or weigh by degrees either. Hardware just matters. Hardware is just part of the game. Chess is a "zero-K" game, and I think its much better than "Elimin8!" but I wouldn't compare those two either. just my $0.02, Jarod.

Well, I managed to get by the gladitor with the blue hat, followed by the non-complete monster level, then the guy in the dark gray/brown? outfit, and then the huge thick guy (forgot what color he was). Looked like one of the backgrounds repeated too (looked like the one from level 4). Anyway, a new high score: heheh - yup, you are officially better than me now. 920 is my high score so far.

Thanks, man! Yes those bugs that you and Yuppicide mentioned are definitely valid and reproduceable. I just recently got an AA bugtracking account, and I'm going to start adding all of them in ASAP. The bug of moving past the bottom barrier was enough to fix ("the doctor said "Don't move your arm like that"), but the sticky lasers is proving to be more tricky. If I can't fix it adequately, perhaps I can come up with one of those typical Atari "Evil Magic" explanations for it in the manual. How about "Occasionally when a laser beam grazes a Gladiator, it will melt off portion of his armor, leaving behind hunks of impassable metallic residue." I managed to work on the Monster Level a bit last night. It's still too buggy to show, but the basics are. Player is armed with a laser whip instead of a gun. Maximum of two Monsters attack at any given time. Monsters have a "charging" attack that must be evaded. A field of deadly Plasma appears in random locations during play. Monsters can be destroyed with multiple whip hits or by being led or steered into Plasma. P.S. You have almost matched my own high score now. When you reach the character after the second "boss," I think we will be tied. I might have to tone that dude down a little, because I think he is verging on "impossible." Cheers, Jarod.

As for Mr. Maus - I know everyone has said it a million times, already, but you have actually released completed games. He has released the same number of games as me and just about every other homebrew programmer on this website - ZERO. Add to that the fact that your so-called "crappy" game happens to keep appearing on the weekly "Most Played" Atari Games list (alongside other "crappy" games like "Adventure")... well it seems to me that you should be giving us advice about game design, not the other way around. Cheers, Jarod.

All that flicker just for a line which is only virtual for gameplay? Well, no, I was just suggesting it as a thought experiment. As I said above, using the playfield pixels for drawing both lines and completed shapes seems to me like the most efficient way to get the job done. Qix was a pretty game to watch in the arcade thanks to the minimalist vector display, but its got to be the gameplay we are hunting here.

Yup. You can draw one pixel/object/line without problems (5 objects in total). For more pixel it becomes more complicated and less flexible. That said, what do you think would be a good way to approach drawing a seamless "dynamic" horizontal line without using the playfield pixels? What about a sprite shape that incremented from $00000000 to $11111111 while alternating between NUSIZx = $5 and NUSIZx = $7 until it reached 32px wide? With 20hz flicker, could you then get something approaching a transversal, single-pixel line?

Actually, maybe we could even spare the use of a missile in that setup. Instead of using a graphic to represent the player, we could simply flip the pixel behind the "lead" pixel. That way, when the player is slicing or tracing the edge of a completed shape, he could gauge his position with a black pfpixel.