potatohead
-
Content Count
4,794 -
Joined
-
Last visited
-
Days Won
16
Posts posted by potatohead
-
-
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.
-
I will also be blunt. Don't f*ck with my fire button. It reminds me of the quote I have on this page: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.
-
-
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 !)
-
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.
-
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?
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.
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.)
-
Might I suggest that all batari BASIC games not include any ASM editing thatthe game must be made entirely from bB and no extra kernals/etc other than
what is built in to batari BASIC?
If you can code ASM, maybe you shouldn't be entering the bB contest
(by this I don't mean, just because you can code in asm, don't enter this contest. Just, if you can, don't adjust your bB code at the ASM level)
We can wait for Batari to create a "contest edition" bB and then it must use
code created with that particular edition.
/justthrowinideas
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...
-
You know what, I see a lot of TEMPEST in this gameplay. And some Centipede. It also reminds me of the breakout section in the Tron arcade game.The problem I see in the gameplay right now is you wind up cutting a channel directly above yourself and just make sure you hit the fuel guy and that's it.
I don't think the fuel meter adds anything to the game. I think it would be better to just do it like a straight shooter where you avoid getting hit.
But there needs to be a way after the ooze paints itself all the way down the sides to cut away at it.
Either that or you should introduce scrollable pockets (i.e. bubbles) in the ooze so that the screen can open up enough for the player to get in and cut away at it.
I do think the game needs powerups or something else to jazz it up. The fuel guy is sort of like the spider in Centipede.
I think there should be some way to clear a wave and some different sort of wave inbetween, like just going against another sprite or two.
I think you should take out the title screen and add some more features once you decide what will work.
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?
-
The BB program.In otherwords, have everything in one big file?
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.
...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?
-
-
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.
-
Also, I'm curious how everyone is using Batari BASIC-- that is, on what kinds of computers, compiling manually or with a batch file, etc. For example, I'm using Windows, and the 2600IDE program.
This might need to go in a seperate thread.......
I'm using Win2k and doing everything from the command line. I do all my testing with z26.
Running Linux right now. (Mandrake 10.1 i586) No ide, just basic program in kwrite window (because it shows whitespace), open command shell and run script. I'll keep another kwrite window or two open to cut 'n paste code chunks. Using Random Terrain's help file in another window.
Will have IRIX up this weekend. (SGI)
For controls, I've got a PS2 dual shock connected through one of those little USB thingys.
-
We are going to be able to do some cool stuff with batari Basic because the result is fast! I tried using a bunch of for-next loops in a row to try to slow the test program down, but it's still lightning fast. How do you slow the game down for testing? Say you want to have the program wait for one or two seconds after pressing down on the joystick, how would you do that?Thanks.
I use delay counters, but not how you would think. The for-next loops you inserted really just consume inbetween frame time. Since your game still runs, you didn't consume enough to break anything. Remember the difference between this basic and an old 8bit basic is that the program runs every 60th of a second. If you take longer than that, in your gamecode, you won't get enough frames to display a stable picture.
One good way to see everything happen slowly is to use what I call a skip counter. The program has to loop 60 times per second, but it does not have to do everything each time. That's the key to getting a nice slowdown. You set a counter and decrement it once each frame. When it hits zero, you do everything, if it's not zero then you jump over all your game code. That way, the picture still gets drawn every 60th of a second, but your game only runs on specific frames. The end result is a slower game with a stable picture.
Try something like this:
(Set the delay where you set other things at the start of your game)
delay = 10
gameloop
(This is where you set your player positions, etc...)
drawscreen
(Your game code lies after the drawscreen for the most part)
delay = delay - 1
if delay <> 0 then goto skipaction
if delay = 0 then delay = 10
(your game code goes here and only gets executed every 10 frames)
(nice and slow, try smaller numbers for faster, bigger ones for slower)
skipaction
goto gameloop
-
I'll second that.
How about a general keyword for this kind of thing, followed by a list of arguments?
config
kernel <x>
smartbranching on
memorymodel 4k
end
That sort of fits with some other things in the language, cutting down on the number of different structures one has to know at least...
I can see the logic in not using smartbranching in a rem, but I'm still thinking of the best way to do things.
Includes and some other compiler directives (like dim) do not affect the bB-to-asm compilation. smartbranching does affect the bB-to-asm, as will a future directive (a few revisions away) to specify optimization for speed or space, or to build an 8k bankswitched ROM (a few more revisions away).
I like the idea of dim and include on their own rather than in a config block, and the others above could be passed as command-line arguments or allowed to be defined as special settings. Maybe a "set" command could be used to define things, kind of like setting an envorinment variable:
set smartbranching off/on
set romsize 2k/4k/8k
set optimization size/speed
If it's done this way, you can actually turn these on and off on the fly. For instance, if you want some code optimized for speed and some for space, you could change the optimization several times.
I'm liking the set operator for all of these options. Being able to do things on the fly makes perfect sense where the 2600 is concerned. Games with different screens could use different kernels, for example. In this way bb might really make managing all of that quite easy actually.
For what it's worth, both syntax ideas allow for these things, but your use of the set operator is less overall parsing and typing / formatting for the developer. Better overall, IMHO.
Come to think of it, the overall concept of an environment is making a lot of sense actually. Set is familiar and easy. Why not? However it works, I would love to see everything necessary be part of the program source code file. Nice and self-documenting and easily packaged, etc...
-
I've been playing this one on my CC2. This is a great concept for a game and you have done a great job with it so far. It reminds me of the game Ram It.If you have the space, here are a few suggestions:
--As the game goes on (say every 2000 points increased in multiples of 2... 2000, 4000, 8000, 16000, etc...), speed up the ooze until it gets to the point where it is franticly fast. Right now, I'm able to keep a small box free of ooze, stay in that box and play more or less forever.
--There are 2 binaries of this one so far, one with the moving coin and one with the stationary coin. The moving coin makes it more of a challenge to hit. Have the coin appear then go back and forth a few times, then disappear if it does not get shot.
--As time goes on, maybe the ooze can change colors.
Great game. I'm looking forward to the final version and eventual cart release.
All credit for initial game concept goes to Mr Davies in the tutorials thread. With all the ideas suggested so far, I think it will end up pretty good. Have you tried the harder setting? Left difficulty triggers that. (Might be too hard though.)
Thanks for all the great input! I'm glad you guys like it and getting others to talk about their game experiences really helps to make a great game.
right now, I'm doing a rewrite to free up some space for new features. Look for a new version soon.
-
Yes that would be some very nice improvements!Hope to implement them when I have some more time for it, am making very long hours at the moment with my (vacation) job
I think the convertion of binary numbers to the editor shouldn't be so hard and the playfield editor should be also ok. But I haven't had much succes creating a search function, yes the searched word will be found but to make the textedit window scroll down to that word is a bit harder, but its possible
Other things to add could be an internal help file, replace function, perhaps some shortcuts to functions, etc.
Also I was thinking of a quick insertion function for (long) words/functions like COLUP0, COLUBK, player0x, gosub, return, etc.
Sounds good. Since these programs are pretty small, a search is lowest on my list of importance, although it would be nice to have sooner or later. Right now if I need to find something and can't see it, I paste the code into Notepad and use its search box.
Man, I use the search in kwrite all the time. (Linux, shows whitespace.) Great for learning if and where variables have been used. Also good for snapping back and forth between subroutines.
I don't use an IDE, but others will probably want these things as their programs grow.
-
I'll second that.
How about a general keyword for this kind of thing, followed by a list of arguments?
config
kernel <x>
smartbranching on
memorymodel 4k
end
That sort of fits with some other things in the language, cutting down on the number of different structures one has to know at least...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Ooze v 0.5 released.
in batari Basic
Posted
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!