potatohead

You and I think alike in that regard. For what it's worth, to this day I *will* stop and play a defender machine at any cost, when I see one The hail mary is coded, just need to decide how to trigger it. I could link this to the target, or have a limited number of them triggered to a joystick down move.... The first two games you mentioned are the most addictive for me. Bought a Jag just for the Tempest 2000. I've two options for this. One being the unfinished hail mary feature, the other being the levels. One thing I wanted to do was cultivate that almost dead scenario, then provide some means of relief --if the player can just manage the situtation long enough. If the player runs out of hail-marys, then they can still work really hard to get through anyway. That's done through the levels and game parameters. Either way, there are two paths to completing the game. Not ready for that yet. Great idea though. It will need a custom kernel. That will happen at some point and I'll keep this in mind. The top of the screen remains unexploited in the current game iterations. Interesting insight. I've always called this the trance, but I believe it's the same thing. This is why I've stayed with the classics. Very few modern games evoke that special state of mind like the classics so often do. Of all the classic games, Kaboom! manages to do this in seconds. It does, and is appreciated! Edit: The latest version is on the thread Ooze v0.5 released.

Well, that's true, but I still think it's a combination of emulators (for people to quickly distribute and try out stuff) and burnt carts, rather than say development tools pushing the what's possible envelope, that set the non-supercharger course of this history. And in some ways I find the group that does everything without ASM more interesting...if you do everything tough in ASM, bB is basically just a big macro to save you from writing conditionals and the other easy stuff in ASM. 912436[/snapback] Agreed. That was all inclusive in my view. (carts, etc...) I think I'll end up being a mix of the three. Doubt I'll touch the kernel this time around. (Could happen though.) Having inline bits in the language is very cool. --and powerful. The language will grow to eliminate many of my current uses at least. Having said that, there is a real charm to how it works right now. It's close to the CPU --and I like that. It's very easy to think in terms of a simple language that runs really fast. As long as language development does not get in the way of that, I'm happy.

Exactly right. I'm one of the ones that bought the original CD. Very cool project. Have got a super charger too. (Isn't there some way we could make more of these?) I was excited about that too. --never happened. One biggie today is the development tools are much better than they were when Stella was launched. I dunno. My gut says the 2600 is just a bit too limited to allow this to reach a good potential. Of course we have been proven wrong before. I'm open minded on this topic.

I like that much better. If you go with that, will the ship flash or will there be a special sound? 912252[/snapback] I'll do something. Can't just take the ship. Just wanted folks to be able to compare both quickly while the idea was fresh.

New version of this in the Batari Basic forum. Didn't want to keep duping threads. Thanks.

That's done to compare the two ideas. Like this one, but no room for all of that.

You know I like it too. It only takes a moment to get that done, so here is a playable version with the bullet bounce.oozeV0.55.bas.zipoozeV0.55.bin.zip If the bouncy bullet is better, I can make a change or two and continue on that path; otherwise, no real harm done... There is no indicator, other than the lives display counting down on the left of the screen, so beware. --This does make the player keep better track of what they are doing for sure!

BTW: This thread is for any commentary. Hate starting a new one each time, but I suppose that's how it's done. Features, high-scores (since the game has an end, why not?), etc.. all go here. Anyone care to chime in on that? What's the usual way of handling game-iteration feedback? Development notes are both in the basic code, (Lots 'o comments) and in my Atari Age blog. You will see some assembly in there, but there is nothing that cannot be done with the language itself. I'm at the 4K limit, making new additions possible, but also demanding things get done the right way and the smallest way. (Still have a long ways to go on the latter.) The assembly is smaller, and in the case of clearing the playfield, faster. Probably will see more of it the next iteration.

LOL!! Blunt is totally good! No worries here. You've a solid point and I'll seriously consider it. Let's let some feedback roll in and go from there. I'm inclined to give you a really slow bullet instead of nothing --if that ends up being the better course of action, but something is gonna happen if you miss the ooze. Game balance is not good otherwise.

From the dotted line under his name, I think he is working on that. 912145[/snapback] I am...hold on a moment... All done.

Ok folks, I took your feedback to heart and rewrote major segments of this game. This version is fully playable, but does not yet have all planned features. Changes are: Levelups: There are 10 levels right now. I might consider adding more, but let's see how these go. Each level has a distinct play mechanic, ooze color and difficulty. Some are harder than others, some leave ooze behind for the next screen, etc... Ooze spreading: Before, if you chose to just sit there and camp out on the fire button, nothing bad happened. Now it does. The ooze spreads out when it hits the bottom. This slowly causes you to lose your playspace to the spreading ooze, or take a hit on your ship to go clean it out. Best keep the ooze at bay now. Accuracy: Missing the ooze results in a delay to your weapon. Also, it can affect your score as the score counter will not increment during the delay of a missed shot. Not too big of a deal right now, but when the bonus target returns, you just might find your bonus won't count for missed shots. Also, some levels are tough. Not being able to fire will affect your ability to keep the ooze at bay. For now, no target for powerups. Those are planned once I scrunch the code again. The infrastructure is there however and most of the powerups work. (Just no way to get them.) So, what I am looking for this time is the viability of these ideas. Given some tweaking, in terms of the level length and parameters, does this make for a better game experience overall? If so, I'll go ahead and get it done with the powerups, etc... If not... let's just say I'll think about it for a while! oozev0.5.bas.zipoozev0.5.bin.zip I've got a bit of work to do on game start and end code. When you power up, or start your emulator, the game just starts. Reset starts a new game. I'll fix this when other more important things are done. (Like having a real game to actually start!) As always, any and all feedback welcome. This is a lot of fun, honestly! Edit: Forgot. The level parameter data is stored in the leveldata statement, right after the drawscreen. (Well, close.) Feel free to tweak these for your own level combinations. If you find good ones, please share! The first parameter is the level time, second one is game tweak flags (fast, slow, etc...), third is the ooze difficulty (smaller is harder bigger is easier), fourth is ooze foreground color, fifth is background color, with the remaining parameters unused at the moment.

This could be done informally too. Just make a team and go for it, or offer to help out on a project in process. The community aspect of this whole thing would probably keep folks honest. (Or forever be in the hall of shame !)

What does that mean exactly? I know what each word means, but not in that order. 911366[/snapback] Sorry, that's way past any reasonable buzzword limit Right now ooze is a great example of a bb game as if bb was a platform. I'm not touching the kernel, am using inline assembly for speed / space reasons. I think it's gonna end up being a great game, but it won't do anything some other bb program can't do. For me, this is great. I can get a good solid game done and learn how the 2600 works without having to spend tons of time on assembly issues. What Glenn wants is things taken to the next level. Rough out the game with bb, maybe resulting in something like the games we have seen so far. Then, get into the kernel and carve out a custom environment that works for *that* game only. That's what a framework is. The result of that effort will likely be on par with pure assembly homebrew games visually. Bb can match homebrew games in terms of overall gameplay, but falls short in the visuals department. Some games are gonna work great anyway, others are just not. (Platform limits) Games that break this barrier will be treating bb as a framework, much like taking an existing assembly language game and building from there.

Glenn Saunders will pay. As to why, he wants to see more development in two areas: 1. Supercharger. We've lots of great homebrew games, but few supercharger efforts. With 6K of ram, lots of interesting programming techniques become available. Untapped potential. Games can be loaded as audio files to boot, making play on an ordinary machine + supercharger possible w/o having to have cuttle cart, etc... 2. Batari Basic. Chance to grow some new 2600 blood. BB used as a framework instead of a platform for game development. A bb program with custom kernel might rival pure assembly home brew projects while saving some time as well. Both of the cash prizes are about pushing the limits, doing new things and learning stuff.

I'm not sure I can get the paddle support in there right now. (maybe, maybe) Totally agree with overall game intensity. (It could get insane!) I want to try and do that. I do have powerups coded, levels and the ooze spreads when it hits the bottom, eventually trapping and killing the player that does not keep the ooze at bay. Once some play balancing and tuning has been done, I'll be releasing the next iteration soon.

The above isn't currently legal right now. But I can see the logic in being able to assign one bit to the value of another. So flipping a bit would have the following syntax when I implement it: d(1)=!d(1) I don't think this is too hard to do, so I'll see about slipping it in. You will only be able to do assignments, such as a(4)=c(3), for now. I will add operations (as and, or, xor) later. 909800[/snapback] That does a lot actually. Anything more messy can be handled in the usual way, IMHO with little penalty. (Or if there is one, inline assembly can mitigate that.)

I personally am not in favor of that idea. The best bb games are going to be a mix of bb and ASM, IMHO. Besides, with a year learning some 6502 assembly is doable. That's the beauty of bb really. The assembly can be taken very small steps at a time. First to save a little space, then to get things done faster, then to tweak the kernel, etc...

All great suggestions. Already yanked the Title. It was more to learn how it might be done in bb than it was a necessary thing at this point. Have some interesting powerups coded and working. Made the ooze splatter when it hits the bottom. This will trap the player, giving an incentive to actually keep the ooze up there. That does provide a clear goal with an actual penalty for not achieving it. This combined with different things that can happen (aggressive ooze, slow bullets, fast bullets, etc...) give some variety to the game play and some challenge if the right elements are present at the right times. Levels are going to be indicated by color and will have specific amounts of the stuff to clear along with specific powerups given. Giving the thought of the fuel being gone and the shooter ideas some thought. (Interesting actually) I'll post another version with some of these ideas soon.

Maybe we need a feature request thread too. This isn't a bug, but would save quite a bit. Can we get a bit toggle? v(x) = 1, 0 or flip Thinking about this a little more, can I use bit operations on just bits? Come to think about it, is there an eor operator. (Maybe I am thinking of xor) Is it legal to do? d(1) = d(1) [whatever eor , xor is) d(1) to toggle?

This would really crank up the complexity of code...intimidating to newbies to have this big old glob of ASM right there! And also it would lengthen it in general....I mean the ASM is never going to be huge huge, but still...there's something nice in the way a bB program listing is almost all game logic. 909296[/snapback] ...that's exactly why I asked for the option. For anyone getting started, the current structure is just fine, recommended actually. It's possible to write a few lines and get something to happen. That's BASIC and it should not change. I'm just looking forward to hybrid development. If one starts building a kernel, the portability of the bb program is then lost. (Unless the files are sent along for the ride of course.) That is followed by instructions and such detailing what to put where, etc... We have a coupla examples right now. The standard kernel has been fragmented into several kernels. At this stage, those are well represented by the proposed set options. Once one decides to start tweaking at both levels, one file would be easier to manage, IMHO. And still be portable. Think of it as a scaling feature. If folks are going to cross the road from bb to full on assembly, this step would be key. Also, this does not disturb the clean game logic aspect of things. That part of the listing, will remain unchanged. Put the messy stuff at the bottom. For those wanting to use the IDE, there are advantages as well. One window, one rom image...

The BB program. In otherwords, have everything in one big file? I've been thinking about this for a little while now. The paddle issue led me down this path. If a person wants to go the hybrid route, or include special kernels, routines, etc... Those files must be edited. Since BB really runs everything through DASM, including the kernel would make for a perfectly portable package. If you have the source file, you have the game period. We already have a coupla games where specific kernels are being used for paddle, etc.... If we do this now and folks learn how to work this way, the overall batari package will remain simpler overall and games written today while the language is still seeing improvements have a higher chance of working tomorrow without having to carry around lots of kernel baggage. Thinking along the lines of: set kernel inline set headers inline ---------- Basic Program lives here------------ rem basic program might have it's own inline assembler code as well asm lda b sta c end -------------- Kernel and headers live here -------------- Lots of assembly stuff EOF. I know it seems wierd, but it will have some serious advantages once people start tinkering around with their kernels. Also, if another machine is targeted someday (which I eventually want to do), everything is there as well, making things simple for learning tweaking purposes. I'm not saying change the way things are now, just asking if this might be possible to add, that's all. I would sure love to be able to work this way in the near future.

Just gave this a go tonight. Thanks for all your hard work guys. I had a lot of fun stepping through my game, watching what happens exactly when. Learned a ton already. Having everything integrated sure is nice. GUI sharp, clean and responsive. Whoever chose the color scheme and overall layouts --thank you for that. Easy on the eyes and very easy to process what is happening. Can't wait for the source level debugger. Was playing with the step, scanline and frame functions. Very nice display of in-program action. The cycles make sense to me, while on a scanline. Is the graphical display supposed to reflect actual on-screen changes when step is being used? I didn't see any updates until I chose either scan or frame.

Interesting. I'm fairly sure it's not the game code posted here. Just to confirm, are you able to run other atari bin files besides the two for this game?

Have you tried other games? The bin files posted are known good.

I've done Atari Crystal Castles on one credit. I've no idea how much I spent getting there, but it does have a very nice "you win" screen at the end. Level 10 is just crazy.