I am now officially back from vacation, so here goes (be prepared). First off, though, I like your game!
I completely forgot to add in a description of how maps are stores, so I will try to do it properly here First, each tile is stored as a single byte. The byte tells which tile to draw using the tile set you define. You can use the program I gave to make the tile set, too (it will be in the proper format for tilemaps). Tilemaps can be variable sized as long as it is big enough to fit the screen (8 down, 12 across). To edit the tilemap, I used this code in my map editor:
If getKey(9
int(G+C+X+W*Y+B/8,F

err, sorry, I accidentally clicked to submit the post. Continuing:

G points to the map data
C is the x-offset into the current region displayed
X is the x-offset into the map data
W is the width in tiles of the map
Y is the y-offset into the map
B is the y-offset (in pixels!!) into the current region displayed
F is the tile number to write

So if you want to use a 128x128 tilemap, you would need 16384 bytes of RAM free. I hope this helps a bit more?
EDIT: Also, I have been playing with GramCrft and I like it! You should post a new topic about it sometime!

Indeed it will That is the exact code I use in the editor, so feel free to change it up as you need and use your own variables. The tiles are stored row by row, so an offset of 2 into the tilemap data will change the tile on the top row, 3rd from the left. (the first tile is 0). So if you wanted to change the tile below that and the map had a width of 20, you would change byte 22.

EDIT: Also, I am looking at your code, and your technique is quite good so far ! I will see if I can find things to be picky about Still, I am glad you search for the labels outside of the loop, that is good coding practice for Grammer

Hmm, found stuff! lets see, if you want to optimise for size , you can remove ending parantheses and whatnot (Grammer ignores them, anyways). Also, doing If A means "If A is not equal to zero." That is a trick that is valid in Grammer and can save a few bytes. Also, If !A means "If A is equal to zero."

Also, you have If J>0, that can be shortened to If J

(I should make a document shortcuts and whatnot sometime)

EDIT2: Oh, I see... Grammer doesn't do much with signed numbers.  -1 is seen as 65535, so -1 is greater than 0 .___.

I think I am about to complicate matters .__.

But I'm still kind of new to this data editing stuff with appvars and hexcode and stuff like that. So are appvars solely hexadecimal? And when I create a new one is it just a series of zeros until I write other data to it?

Appvars are whatever you want it to be. However, in Grammer, you have a few ways of editing them, including writing bytes to it through hexadecimal and numbers. For example, if Z points to the appvar:
int(Z,37 will write to the first byte of data the value 37.  The number is 0 to 255 and can be a variable.
Z[(111213 will write 3 bytes to Z in hexadecimal. They are 11h, 12h, and 13h. in decimal, that is 17,18, and 19.
Z[77,23,47 will write three bytes to Z, also

And there are a few more ways to do this. Basically, if you write a byte at Z+13, when you read it, it should be the same.

As for creating new vars, the data is filled with all zeros until you write to it It used to contain data that was not necessarily all zeros, but  changed that, so that is a good question.

And are tokens one byte each?

Not all tokens are 1 byte each. Some are 2 bytes
I am curious about what you are going for here

You say the tilemap data is series of numbers, so is it 0000 for four tiles or 00000000 for four tiles? And is zero the first tile or no tile at all? And do I need to convert the hex to token? I plan to store everything in appvars.

Hmm, tilemap data is a series of bytes. So however you want to think of bytes is how tiles are stored. If you think of them as two hexadecimal digits smushed together, then 00000000. If you think of them as just solitary bytes, they can be 0000.

0 is the first tile, indeed. And there is no need to write hex or tokens as you can just do something like int(Z,0. However, if you have the data sitting somewhere you can copy it using the solve(1 command. It might be a bit tricky, though.

To save space, how can I have no tiles at a position, without having a blank sprite in the tileset? Or do I need to do that, have the blank sprite as the first sprite?

You will need a blank tile in the set it does not need to be the first sprite, technically, but I normally do that. If you make it the second sprite, for example, then to write a blank tile, you would use tile 1 instead of tile 0.

Awesome! I was worried
If you just want to read it (and not write to it) you can copy it to a var using solve(0. So for example, if your appvar is called Data, you can do:
solve(0,"UData","V.
That will copy to a tempprog (that is what the V means) called "." Temp programs are automatically deleted by the OS, so it won't clutter up RAM. if you want to edit it, you will need to have it unarchived

You can also copy portions of a variable to RAM instead of the whole thing using two optional arguments to specify the size and offset

Okay, for your first question, you would have to copy the var to another var and then get the pointer to that var in RAM. In your example, it would use V as a pointer to the name of the var to copy to. You could do this:
solve(0,"UData","V.→D
D will point to the newly created var

As for the sprite editor, the actual sprite data starts 4 bytes in The first 4 bytes hold the data for the size and number of sprites so that the editor can read them properly. So what you can do, if the sprite file is the appvar TILES:

4+solve(0,"UTILES","V:→T

I hope that helps!

It is indeed in the readme Also, Apparently Ɵ' will contain the size of the created var O.o I didn't even remember adding that

Awesome! I am sure people will enjoy larger maps