@stevon8ter: I couldn't run it .__.
@Yeong: I think we shouldn't have background sound, but we could incorporate sound/music as a non-crucial part of the game. For example, we could have a "radio"  in the game that plays from a random playlist.
@Matrefeytontias: That looks nice o.o If you could make it so that it can start of a position (x1,y1) and stop at position (x2,y2), that would be great o.o (This would be so that we can have the laser be fired from the player and have it hit the opponent, or miss and shoot off the edge of the screen.)

So it will be like Symbolic, but maybe more stuff?

@aeTIos: He means using the compression algorithm I gave. '.' corresponds to the two-nibble value $F0

I'll describe it here, since I don;t think I ever released the idea, just the code. Basically, it works like this (there are two methods)

I first designed this algorithm using Celtic3+BASIC, using the idea of how common certain letters were in the English alphabet. I arranged them in order and threw in some numbers and punctuation, so I could compress my most common messages:
ETAOINSHRDLCUMFGYPBVKWXJQZ,?!.0123456789/-:'
Note that the first character is a space. Now, in the actual message, any time one of the first 14 characters appear, it will be assigned a nibble 0~D. If anything after that is used, (say the 23 character in the list), it will be a two-nibble value, starting with E or F. You can subtract 14 and add $E0 to it (essentially, add $D2 to the original value). In this way, text will take at the worst 100% the original size and at the best 50%. However, because the first 14 characters are the most common to appear in an English message, it averages around 60% compression. For example, here is the message, "HELLO!" (this works best with larger messages):
NOTE: We start counting at zero.
H is the 9th character, so it is one nibble, $8
E is the 2nd character, so it is one nibble, $1
L is the 12th character, so it is one nibble, $B
O is the 5th character, so it is one nibble, $4
! is 30th character, so it is two nibbles: $EF
Combining the nibbles, we get 81BB4EF, but we need to store bytes, and this is an odd number of nibbles, so we pad it with a 0. This is why a space is the first character, because decompressed, it would put a space at the end in cases like this.

Anyways, that is 4 bytes, compared to 6, so compression was about 67% In BatLib, to make sure the extra space at the end wasn't in the output for decompression, I compress data and store the original size as a two byte value in the beginning.

Now, why did we use 46 chars? The first 14 are used as 1-nibble values. A nibble can be 16 different values, so this leaves two extra nibbles for our "extended" chars. So 2*16=32, which means we can have 32 two-nibble values and 14 nibble values, totaling 46. Indexing at 0, we have chars numbered 0 to 45, which in hex is 00h~2Dh. If you look at what we add to find the value of 2-nibble chars ($D2), it is actually not a coincidence that it is the value 2D with its nibbles swapped

So what if we want to compress something other than text? What if it is arbitrary data? Basically, you need to scan the data to figure out which byte values are used, then you need to arrange them in descending popularity (I call this a "compression key"). Find your cut-off value (the number you add to get the two -nibble values) and this will also tell you your cut-off for one-nibble/two-nibble values. Because this will use a unique set of chars in some order, you will also need to include the "compression key" so that you can decompress. If the data isn't large enough, the compression key plus the compressed data will take up more space than the original.

I used this in BatLib to compress some internal data, like the main menu (the bitmap was compressed a few hundred bytes, including the compression key). You can also apply this algorithm several times in some cases to further compress the data. I got one tilemap to compress down to 12% of its original size, with each of the compression keys included!

EDIT: This is the relevant code in BatLib for most of the compression/decompression functions:

Well, I figure that if we use an app, we can have more code space (16KB and an 8KB program). We can still use axioms and use an app

I'll take this conversation over to the Coding topic, since it will be important for others.

Oh, okay. And I was thinking that using an app, I could write routines to directly access the data in archived appvars. This would help quite a bit with map data, tile data, and sprite data. I could maybe make a command to copy a sprite from archive to a location in RAM (that way it can be accessed by the main program).