Well, that's it. I can actually foresee slamming face first into the 16KB memory limit for a 1 page application. I've just started working on the text system for the "story mode" in the game (where the story of the game is told in the dialogue between you and the boss of whatever level you're in) and I'm nearing 11KB.

Know that I have to have boss and enemy image and script data for about 6 to 8 stages, each boss having its own portrait sprite and image data for each of its spellcards that it can use. Then there's your own characters, which I plan on including 6 to 8, each with its own portrait and spellcard images, and their own code. Don't mention anything about backgrounds, which there will be 8+, one for each stage, and maybe one for each of the boss fights. THEN, there will be the actual dialogue between you and the boss, which will vary depending on what character you select for the "adventure."

Then, there's the issue of having an actual title screen, which this game completely lacks at this point. Cramming it all in the remaining 5K seems unrealistic, so... now I have to figure out how to distribute all this data across two or more pages and still have the routines that need to access it still readily available.

BUT... on the bright side, the beta demo version that will release prior to actually writing a coherent story for this will remain as a 1 page, 16K application. I just want to let you all know that this game *will* end up being a 32K or (if worst comes to worst) a 48K app when all is said and done.

The secret is to move your ship so that your right two bullets are hitting but the leftmost one barely misses him. A hole in the tracking system allows you to do this, but only if you start the pattern on the left side of the rotating spiral.

... or just hold MODE down and press DEL to activate the bomb used to give you time to blow the enemy to smithereens.

The aforementioned hole is difficult to notice if you're not focusing (MODE key held).

The screenie explains it all.

http://i34.tinypic.com/2irvw53.jpg

I've got the enemies shooting around working, and I also got the strip of code that allows enemies to aim in your vicinity working. The result? Something that could end up being pretty freaking difficult if I were cruel enough to add in the circular bullet pattern so the aiming would require you to weave through it.

Why didn't I? Well... I wanted something easy enough to demonstrate what I wanted while not having to replay the thing a zillion tries to make it look 1337.

Next up: Boss and stage scripts.

Screen shot : http://i37.tinypic.com/2rxjjhx.gif

EDIT: Attached the binary to the post. Except it's more difficult since I was cruel enough to do what I said I wasn't. lol.

[...]
Right now, I'm wondering if I should have an ending to the game.
Originally, I was thinking of no level cap and just letting people play on until they get bored.
My main issue with an ending though is where should it be?

Also, after awhile I'm sure dungeon crawling will get a bit tiresome... especially since I have to account for characters levels. I could just set all creatures to the level of the character at the time they meet. If not, I'd have to have a dungeon for each level they get to.

In either case, creating quests and/or bosses wil be a pain with this whole random generation thing too.
Though, I'm just not sure which would be more fun. A fixed world with a fixed plot and a fixed ending.
Or random world, no plot, and no ending.

In either case it'll be battling monster after monster to level up and become more powerful.
Argh... my mind has WAY too many conflicts.

[...]

If you're going to have a dungeon level system similar to that of Diablo, you're going to want to tie in quests and bosses to your map level variable so that they can appear (doesn't matter where, just that they appear before the exit of that particular map) on specific floors in specific areas. Who said things like that should be *completely* randomized? Quests should appear on a very specific floor (or you could do it plus or minus one floor for a sense of randomness) and bosses too. Speaking of the difficulty of the enemies that appear in the dungeons, you could also tie that in with your map variable so that you can allow the player some breathing room.

If you've ever played Lufia II, or some of its sequels/prequels/whatever, most of them feature this "Ancient Cave" thing. The one in the game I mention is completely randomized and goes down 100 floors without anywhere to save and very few places to heal yourself (forget about mana. Only the items you find inside can help you). In this game, there are only stairs leading downward but none going back up, so forward is the only way to go until you reach level 20 to 30 where you'll find "Providence" which will bring you back topside. All acquired items in the dungeon are taken away from you (except blue-chest items) and your experience level is reset to when you first entered the cave (along with items you can't take into the cave). When you go back into the cave, you gotta start with EXP lv 1, on the first floor, with nothing but 10 potions and any blue-chest items you've found.

Of course, the Ancient Cave itself was meant to be the ultimate challenge in the game. You need not make your game as difficult as that. But... if you want players to make 6 hour long runs at a time as they shoot straight to the final floor, you can do just that.

Just make sure that when you reach the final floor, the game says it's the "Final Floor" instead of something like "Floor 100". It gives a sense of deep satisfaction to know you're so close to the end. Also, make sure that the final floor isn't randomized, but is a very specific shape and size. Perhaps that of a long corridor leading into a very large chamber. With candles lined up on the sides!

Well, anyway. Whether or not there's a fixed plot and/or storyline, there can most certainly be a fixed ending. I think it's more fun with a definitive ending.

... or you could also add in my Ancient Cave idea as a bonus for getting the player through the normal game. It'll be a way to throw in some bonus content throughout the whole thing.

If you notice, some of the tiles around the place move slowly. This is a cheap way to increase/decrease Mario's speed to help him align himself better to the music. Other than that, yes, it is a s***load of trial and error and more ways to make it look amazing and beautiful at the same time.

It's noted somewhere that the video took the creator around half a year (6mo) to create that beast.

Also, the thing might've been made easier by the possibility that there may have been breakpoints in the music to allow stages in the giant level to be tested individually. If I was creating such a stage, I'd at least like that amount of comfort.

Interfere? Heck no. That's not the purpose. Celtic III is a stand-in replacement for xLIB with a load of extra functionality. Doesn't fully work quite yet, but if your needs aren't too demanding ( DJ's games don't qualify), it'll work out just great without any modification to the syntax.

Another plus is that Celtic III comes with an autoinstalling program in case you don't want to leave the installation of the lib up to the user. More information and documentation can be found here : http://www.unitedti.org/index.php?showforum=62 . You'll be looking at "Progress..." for the most recent binaries. Also be sure to read through the topic, as it indicates known problems. If you experience problems, feel free to contribute.

Edit:

As far as list to string goes, the same can be accomplished with a matrix. If you store the resulting matrix to a program file, it'll likely take up less memory than having the matrix as a matrix in memory. Sure, it's not immediately usable, but it'll help save space.

But... if you choose to use Celtic III as the main lib, you'll also be able to use string tilemaps, where you can absolutely do away with the entire matrix idea. But... you'd want to ask a very experienced BASIC programmer if you want a halfway-decent explanation on how that works.