potatohead

Exactly right. That's a problem that happens when you are author and major playtester... Learning a lot here --don't know exactly what it's gonna be good for, but it feeds the soul well enough. The secret to level 4, as it currently exists is to make damn sure there is almost no ooze when it starts. Then it's pure survival at that point. Best way through is to prioritize your shots on one side of the screen, keeping all the ooze at bay as long as is possible. Once the ooze hits the bottom it will creep. Ideally you have managed to last until the end of the level with enough playspace remaining so that you can choose where to sacrifice your ship. Waste one ship to knock the ooze back off of the bottom and then take advantage of the next level to clear it back to a managable state. I really had a tough time figuring out where the right toughness level was. Earlier versions of the game were easier and likely closer to the right progression. I've some good ideas to make things easier and more obvious through gameplay without having to include a strategy guide kind of thing. The primary one is to make the levels cyclic. Easy, harder, harder still, then repeat with level 10 being a boss level that's really tough. That way the regular pattern will let the player reach milestones and understand the overall flow far better than they do now. The Bb environment does not allow for much graphically just yet, but there are no real gameplay limits that I can see, so that's the focus. Well, there is one issue --the paddle. Before I really call this done, I want to see if the paddle can be read somehow, ideally allowing for both play options. Ooze with the paddle could get just totally nuts in terms of speed and what the player experiences. Twitch games like this are my favorites. The game can be solid as it is, but that option is worth some work at the assembly level when I have time --simply because I want to play it! Thanks for letting me know I'm on the right track.

Same here. For what it's worth, I think I'll buy two of the first batch. Pester, pester, pester....

I'll read it. You forgot one other kind of writing: different. (which is not known good or bad until a sample is had!)

Is the paddle working in Bb now? Just wondering because I would love to add a paddle based option to Ooze.

Both of those versions are quite playable --maybe more playable than what ended up in the compo. You can find the last coupla revisions in this blog, and in the voting pack. The V1 Fully playable thread was incorrectly titled. Changes entered in the compo, were addition of ooze drip option, which really changes the game, starting the game by pulling joystick down and level tweaks. It's the level tweaks that I need to properly do, before Ooze is really complete. That's what the post was about. I had played the game so many times for playtesting that I lost the ability to really judge how it was going to come across. After doing nothing with it, for about three weeks, I went back to play and just hated the levels, particularly with no ooze drip happening.

Keep up the good work. I'm enjoying these.

Music would be good. I'd agree with classical. Love the sprites.

You are not the only one. I'm not ever going to play anything delivered via steam or steam like tech. ID has it right. Ship the game, do what you can to limit cheats & piracy and encourage users to get into the game proper. (mods, etc...) Linking all the users together with the developer is a mistake. So I miss out on a bunch of games. Would have missed out anyway as there is just no time to play them all.

The Genesis game Warpspeed had some similarities to Star Raiders. But it does strike me as odd that there have been no remakes for SR, especially considering it was probably one of the most famous computer games of the early 80s, and one of the very, very few to make the transition to consoles (2600 and 5200). It was in the top ten list for years and years. 952690[/snapback] Also strange to me is that Atari never ported it to any other system back then as an Atarisoft title either.... 953313[/snapback] There was a rumor that Atari was working on a remake for the Jaguar but it turned out to be Space War 2000. Battlesphere's Alone vs. the Empire mode is very similar to Star Raiders. What makes SR is the random element. Modern games of the same genre (think Wing Commander, X-Wing, and so on) are mission-based. Events are mostly deterministic. So replay value isn't there. It's just a matter of figuring out the right strategy to beat a particular scripted mission. The gameplay experience of Star Raiders is different every time you play it. I think InfoTari should remake it, but it's hard to preserve the gameplay when adding in multiplayer, and with a genre like this, people are going to pretty much expect multiplayer. 953317[/snapback] Interesting... I've always thought this game could be multi-player. The sticky part is syncing everybody up for a mission. Queue, say 4 players, then everybody starts with a common map and common goal, defeat the baddies. Players would be able to communicate with their sub-space radios, provided they are not damaged in combat of course. Maybe heavy damage sets off the homing beacon! Allow players to trade resources to help one another. One perfectly healthy player can give up their radio in trade for another players engine fix, for example. Then the two have to make it to a mothership. Over the network this would be cool. The number of baddies could scale according to the players in the mission. Everybody only gets one shot. No re-spawns. This would reinforce cooperation in the game. If you were talking about single screen versions, I agree multi-player isn't going to work well as the split screen would not be immersive as it is for just one person.

Ok, so do the emulators? Just wondering because my game has gotten fairly complex. Never thought about this. I figured it would crash, or distort in an obvious way...

My fave is the 8bit version though analog control would be nice. As kids, we would play it two player. One person running the joystick and the other running the keyboard. Getting the higher scores was easier because of the faster control possible. Plus it's a fairly unique collaborative experience. My kids will do this today when I drag out the machine. Good games are always good games.

Re: Cheats, none of these ideas are going to make one bit of difference. The high scores are an honor system thing. Nothing short of a real video capture is going to erase doubt --and even then there is doubt. Maybe scanned photos? As for disabling the print screen, use VNC to remote the computer desktop --done. Pausing? Run the whole works in a virtual machine --done. All kinds of fun can be had with patch roms too. I suppose one could get nasty and try the video overlay bit --like for DVD's. That's a lot of extra code that is rendered moot with a hacked or friendly driver. There is some little evil workaround for all of the cheat protects, why bother? Either there is some honor in the high score or their isn't.

Thanks guys! I was kind of thinking outloud --didn't expect an answer really. Glad you both commented. Later when I re-read this stuff, it's going to spark some ideas. In that vein, I find your perspective valuable. It puts options on the table now, that would not have otherwise been discussed. Thanks again!

Agreed on all points. I still think a 7800 Bb is a worthy thing to do. Some of the creative types, currently working with Bb would simply *love* that and I think we would see some very interesting new games as a result. If one could craft a 7800 kernel with a fairly coarse set of display pixels, or maybe just a nice set of sprites and leave the Bb programmer with 8 - 10K of solid code space, it would be just great to create games in. Such games would be able to feature interaction between a fairly large number of objects, compared to 2600 efforts. I'm kind of hoping to see new and interesting gameplay arise out of that someday. The SuperCharger remains an enigma to me. I want to toy with it, but the new supercat cart is really stealing it's thunder. I'm also not quite ready yet. I do see why it's out of place on the 7800 though. It's on my desk though, pestering me each day. Maybe maybe...

Didn't see comments until after viewing my latest post. To make a long story short, I agree!

Just had a chance to check this out. Pretty damn cool if you ask me. Bb continues to stretch it's legs!

You should be able to get that pretty soon from a different project in the oven. No promises yet, though. 941654[/snapback] All this hardware talk is pretty interesting! Looks like good times ahead.

I really like the idea of pages being controlled by ram accesses. Unless it ends up be seriously broken somehow, keep this feature please. The more I read about this cart, the more I want to get my hands on one!

Wait a while before allowing this? Allow the programmer to toggle the feature, once it's known safe?

Got the CD too. #96! Nice topic. I've wondered about this too.

Agreed. Your solution is pretty slick. Having subs only two levels deep is not that big of a deal, though it might be given the larger projects the additional RAM and ROM make possible. Still, ease and reliablity in page management is king. Using flags to handle game states is not too bad. Gets messy quick if one does not document things. When I wrote Ooze the second time, using mostly flags because of the gosub bug, I learned a few things. Multi-purpose subroutines are expensive in terms of space. This is the downside to flags. More stack capability would have allowed slower, but far tighter program loops. I don't think time would have been an issue though. It turns out that one can do a lot of little branches cheap. IMHO, it all comes down to program space. If space is tight, the stack really helps you out because you get the most for the address space. If space is not really the issue, the limited gosub is less of a problem because it then becomes possible to manage things on your own with few worries, other than keeping it right. I'm sort of a stack snob really. Miss it on the 6502 because it's so limited in the first place. A one page stack really sort of sucks because it's only good for subs and variable passing. Anything beyond that gets risky quick, compared to a real stack. Programming on the CoCo, with the 6809 and it's two very nice stacks was sweet. IMHO, the stack needs to be used sparingly on 6502 systems no matter what. There just is not enough of it. Far better to gain address space and use a pointer. That's just the way the CPU is. The 6502 is fast but quirky it seems. This forces some style choices. Largely ignoring the stack, but for times when it really, really matters, is one of them. Of course, there is the issue of normal RAM writes with supercats scheme. If we see working carts, Bb could then use the additional on cart RAM for storage, thus freeing up a lot of stack! I haven't looked at all the schemes, but the ones I did check out, made RAM writes some sort of hack. Funky addressing, counting cycles all makes the whole thing hard from a Bb perspective. Major changes would be required to get things working --if the RAM were to be used for variables & such. The user could always make a subroutine or function that handled these things.

Very cool! I'm actually interested in supercats scheme the most. I know we don't have hardware just yet, but when we do I think it's gonna be great. From a programming standpoint, it's got a lot to offer with the biggie being ordinary RAM writes. I'm thinking this will enable a fairly sane Bb / cart combination. Since I'm new, and only using some assembly at the moment, I'm going to defer to others here as to which scheme is better, popular, etc... Kind of looking forward to my next game after Ooze. Thanks a bunch for heading this direction.

I would like to see an 8bitter with an added chip or feature set to allow for homebrew / new games. Whatever they do, it should have a cart port and said port should be open. The homebrew scene is really good right now, but it really depends on old hardware. The FB2 brought a nice refresh, if a bit buggy, to the classic crowd and the price was good! $30 is a steal! IMHO, this is all about the classic feel. The 2600 embodies that, but is a bit limited. My FB2 has seen a lot of play from the kids and a few interested adults. Well worth the dollars. If the price were, say $50, but carts could be added and it brought a few extensions to the table, Atari may well find that they have opened a door long thought closed. I think the whole thing depends on expectations set. The FB works because the old Atari is remembered and it has a feel that is unique. The games have a real time element because of how the games had to be written. Rather than escalate this by moving up the chain to full computer capability, (400 / 800 style) I would add a coupla features to the 2600 way of doing things that enable better games that preserve the overall feel. IMHO, the 2600 defines classic. Go newer and the expectations quickly rise. Unless they are properly set, people won't get the same enjoyment out of the whole thing. Make the machine too good, and it then gets seen as modern and limited. Kind of like a game boy or NES that connects to the television. Maybe that's the way to go. I'm not sure, but it would not be the same and it gets a lot more expensive to produce. I would love such a system though as there are a ton of 8bit computer games that are very fun. How to incorporate them is the problem. Cart only keeps a lot of games off the table. Save states & other such things become a part of the equation, which detract from the simple, turn it on, choose your game and have fun factor. If it were me, I would keep the focus on 2600 style games. These games are simple, yet fun and can be rewarding. I would add a feature or two to allow better productions to happen and contract out a coupla of the better developers here to showcase the new stuff.

Why not just define all the sprite pieces and use an on-goto to sort 'em out at run time? Either way, the data sits in ROM, it's just how you address it. eg: player0: %00100010 %01110111 %01111111 end on bottomhalf goto 10 20 30 10 player1: %00100010 %01110111 %01111111 end goto skiphalf 20 player1: %00100010 %01110111 %01111111 end goto skiphalf 30 player1: %00100010 %01110111 %01111111 end skiphalf (rest of game)

Because they can't be pushed in quite the same way. They are flexible, but not in the same fashion. Expectations are higher too. The computers are capable of some pretty nice visuals. Maybe I'm going out on a limb, but the limits of the 8bitters is known. We have not yet seen all the 2600 can do. I'm not saying it's more powerful, but it is way more flexible than any other classic system. That flexibility really is the attractor for me anyway. Seeing the innovations year after year is just great. Look at the Boulderdash game posted here a while back. Holy cow! That's one powerful piece of programming. The end result would be trivial on the computers and that's what makes it so great to see on the 2600. There just is no environment like it.