any idea when we'll be able to try it for ourselves?

i like it! only problem is you can see the target sometimes when he's walking on the top row (the top of his head appears through the bullets)

another way you could do it:

3 bytes
1 byte = starting location
1 byte = current location
7 bits = distance of the gap being traversed
1 bit = direction

having the text being displayed every frame severely slows down your program. i *think* that axe might even use TI OS' routines for text display on the graphscreen.

"getting used to it" is going to be a part of it no matter what programming language you choose, whether that's TI Basic, Axe, C, Java, ASM or any other language. i'd be lying if i told you it's easy to learn axe. but it's probably a hundred times easier to learn than assembly, no offense to the ASM coders on here. however, if you're "used to" TI Basic, and want some speed/fancier graphics, you could use Xlib or Celtic.

quigibo, i noticed that
3->{L1}
->{L1+1}
->{L1+2}
is more optimized than
3->{L1}
Fill(L1,3)

when is the point where the latter becomes more optimized?

first, i'll define what a tilemap is. a tilemap is usually a 2-dimensional list (like a matrix) of numbers that map a tileset into a graphical map. what's a tileset? a set of graphics to use. the tilemap in axe is just a list of bytes. so the following could be a tilemap:
[0101010101]
[0100000001]
[0102020201]
[0101010101]
say we wanted to display this tilemap. the tile 00 will be a white square, the tile 01 will be a black square, and the tile 02 will be a white square with a black outline.
here's the code.
.PROG
[0000000000000000]->Pic1
[FFFFFFFFFFFFFFFF]
[FF818181818181FF]
[0101010101]->GDB1
[0100000001]
[0102020201]
[0101010101]
For(Y,0,3
For(X,0,4
Pt-On(X*8,Y*8,{Y*5+X+GDB1}*8+Pic1
End:End
DispGraph
Repeat getKey
End

this is very, very simplistic. note that each tile number takes up a byte. meaning you can have 256 different tiles. some tilemappers use half-bytes, or nibbles. you can then have only 16 different tiles, but your map is twice as compressed. many others also use RLE compression, which is a compression technique that instead of storing each tile as byte, would store the frequency of the tile in a byte, and then the tile in the next byte. so our example would become the following:
[06010300020103020601]
which would be read as "6 tile number 1's, 3 tile number 0's, 2 tile number 1's, 3 tile number 2's, 6 tile number 1's."