Another option for maps that gives you much more flexibility is using brushes. Each tile can take up the same size or you can create a table (i don't know how you'd do this in Axe):
.db 1,1,1,1,1,1
.db 1,1,0,1,1,1
.db 1,1,1,0,1,1
.db 1,2,2,2,1,1

.dw tile0addr
.dw tile1addr
.dw tile2addr

;first byte (.db) = list of actions:
;bit 0: passable
;bit 1: reduce random battle counter (things like grass or cave floors)
;bit 2: 2nd action (when you press 2nd some action pops up)
;bit 3: walking action (when you stop on a tile: doors, teleporters, etc)
;bit 4:
;bit 5: [whatever else you want]
;bit 6:
;bit 7:
;second byte = sprite number
;third byte+ (optional) = extra data (action number, text address, etc.)
tile0addr:
.db %00000001 ;not passable
.db 0
tile1addr:
.db %00000100 ;passable
.db 1
.db 0 ;we'll say action 0 = display some text
.dw text
tile2addr:
.db %00000010 ;passable, reduce random battle counter
.db 2

EDIT: This way you can also reuse tilesprites for many different tiles and give them different actions/properties.

Honestly i don't know how you could tackle any large project away from the computer. Lots of Axe and BASIC programmers have done it, but personally i couldn't imagine keeping track of a project that has several tens of thousands of lines of code.

About the 68k calcs, it's not that nobody likes programming them, i think they're fun and, while i haven't jumped into it as much as say z80 or ARM assembly, m68k assembly is pretty interesting. The instructions are pretty flexible, (compared to the z80) you have tons of registers, lots of instructions you wanted on the z80 (a div instruction?!) and introduces some important concepts in a lot of other languages that you don't have in z80, like sign extension and differentiating between addresses and data. You've also got lots of conditional tests at your disposal. Really i think it's just that there's not that large of a community around anymore, though there still are lots of really knowledgeable people around willing to help out and answer questions. If you go back five or ten years you'll find tons and tons of amazing projects (seriously, have you ever checked out all the 68k games available at ticalc? )

As for Axe, to run Axe programs you don't need the application on your calc, you might need a shell, though. Most 83/4/+/SE programs are written for a shell, however, so most people who play games will have a shell on their calc. I'd go so far to say that most people would actually rather use a shell to run a program than have to use the Asm( token (unless they're using zStart/NoShell/DoorsCS's run from homescreen feature). Though if i could i'd push you towards z80 asm, nowadays there are so many resources available, libraries, etc. you could probably write an entire game not knowing a single bit of assembly

On the 83+ in most cases you aren't going to need super huge numbers, generally 16 bits will be enough and if you need extra precision you can hack it together using an extra byte as a decimal (instead of .00-.99 you'd have .000-.255). If you need larger numbers you can handle that a variety of ways. You can take advantage of OS routines or write your own, but unless you're writing some sort of math program i can't imagine you needing more than 3 bytes (>16,000,000). Handling 3-byte numbers is pretty simple and not much slower than 2-byte numbers (for most operations). On the Nspire i imagine you've got support for 32-bit numbers with the ARM processor, if you need larger numbers i don't think it'd be difficult to handle them yourself..

I'm not quite sure how your trainer system works. It sounds like you have to walk on top of a trainer to battle them? What is TrainerNumber? You use one variable for every single trainer? One way you could do it would be to use a single tile for every trainer, say tile 85. Then you could have a table listing the coordinates of each trainer and possibly a pointer to the trainer's sprite. Actually, you really don't even need a special tile, especially if you divided your maps into smaller pieces. With each map segment you would pass a pointer to a table that contains the coordinates of the trainers. When the trainer is on screen, just subtract the trainer coordinates from the map coordinates and draw them. You could use the same table for NPCs, and since in each little map section (each town/route) there won't be that many trainers/NPCs, you could load the table into RAM and change the coordinates as you please without worrying about modifying the data in your program. That way you could have NPCs that walk around, trainers looking in different directions, etc.

I can't remember anymore, it was the first time i'd seen it though. I think i actually already found one of those "secrets" you were talking about by accident Since then i always try to keep one in my pack "just in case"!

This game is great! I should be sleeping now but i've got to see if i can get past room 35 first  I generally only make it to room 10 or so, though sometimes you get a nice set of items and some early level ups.

EDIT: Yeah, the squid/octopus guy totally schooled me in room 27. Now let's see if i can go to bed...

Speaking of which, when does the z80 assembly portion start?

Btw, with RLE it doesn't matter how many tiles you use, what's more important is the repetition of those tiles. Even if you have hundreds of tiles, there are likely places where you use one tile maybe ten or fifteen times (or more). In some of my maps, 3700 byte maps were compressed into just over 1000 bytes. So 29000 bytes of map data were compressed into just over 10000 bytes. If there's lots of repetition in your maps, RLE can be very effective. You can also play around with vertical RLE and horizontal RLE to see which way your maps compress best. For example, a map like this:
.db 1,1,1,1,1
.db 0,0,0,0,0
.db 1,1,1,1,1
.db 0,0,0,0,0
would have horrible vertical compression but decent horizontal compression, whereas a map like this:
.db 1,0,1,0,1
.db 1,0,1,0,1
.db 1,0,1,0,1
.db 1,0,1,0,1
would compress really well vertically but not horizontally. If your maps didn't use more than 127 tiles, then you could use bit 7 to mark that it's just one tile. Normally you would do something like .db 1,tileNumber, which actually adds a byte. I do: .db tileNumber+$80, which is the same as the uncompressed size. That way your RLE-compressed maps will never be larger than the uncompressed versions.

Also, for a game with very well-documented code, check out Robot War: Project Darkstar. I've also got lots of little code/programs i've written that are commented that i'd be more than happy to share/discuss with you or anyone.

I'm excited to hear what your next project will be, this one definitely turned out great Any hints as to what it might be?

About mouse support, what do you even need it for? I don't think it's really a priority, especially if that takes time away from your next project!

For me (84+SE: 84/128) it fills up the left side of the screen and then prints AAARGH! I've attached a .8xp file for anyone who doesn't feel like typing all that into the calc and probably typing it in incorrectly

EDIT: And i assumed the "inc a,(4)" was supposed to be "in a,(4)"

It's much better now that you can see all the words! I finally managed to find all the words, it took me just over 15 minutes, about 8 minutes trying to find the last word (ATOP ). I really like the timer as well, it's a nice feature. Do you have any other features you plan to add? I think it's seems pretty complete/ready for release

I know it's a port of another game, but one thing i really liked about a lot of these style games was having to get X amount of points within a certain time limit to advance to the next set of letters, kinda like this one here: http://www.wiredarcade.com/game/1772/Word-Ruffle.html