Sorry, no demo today.  It's never guaranteed that I'll be able to get to a TI-Connect capable computer while grounded, so I'm afraid I don't have new screenies or a new demo.  Friday is probably the day to get a new demo.
However, I'm growing increasingly more concerned about this project.  Today, I added some basic drilling animations for one direction, which took up about 1,000 bytes.  However, I currently have 3,000 bytes worth of space remaining in the app to fill with stuff, and two more drilling directions would sit me at 1,000 bytes remaining.  The surface buildings will probably take up 2,000 bytes in images and code, and the main menu will probably take up about 2,000 bytes in images and code, so I had to take out the drilling animation.  That leaves me with very little wiggle room to add more features, unfortunately.  Plus, Motherload is pretty darn optimized.  I also only have about 100 bytes of RAM available, which I need to use for storing cargo, as well as information about how the user has upgraded their craft.  I'll need to find some corners and cut them, but hopefully I'll be able to crank this out with a reasonable feature set.

you might do what I am doing with my Pokemon game.

I currently have over 10k bytes of sprites so far (still increasing)
I have it stored as an archived app variable.

I know it is a pain making people to have more than one thing in their memory, but it can be a life saver.

Accessing files like appvars is difficult considering that all RAM from 0x8000-0xBFFF is inaccessible, and most OS routines are not able to be used.

Hmmmm that does pose an interesting problem.  Basically you are needing all 100% of code and data present to be stored in the App itself?

That is correct.

You can't use files if you are using an app!???

If yes. Oh S*it

You can't use files if you swap in a spare RAM page and take control over the whole calculator, which I do.  I can't use very many OS routines this way.

Hmm...How much of the drilling animation could be reused? Right now, it seems to be size over speed for them, so having them as several subroutines (esp. particles and such) might decrease the space. Can you do sprite flipping, to shave it to 2000 bytes?

Just some random thoughts.

Well, digging as it is right now is just removing the tile from the map and letting inertia or gravity carry you through the tile.  The drill requires me to take more control over the digging process.

Hmm....What about having no change in the player sprite, just some particle effects? Dirt flying, etc. should only take one animation, with several particles, but they behave in the same way, falling in an exponential curve downward over the dirt chunks. The digging itself is also only one process, not three. No idea how big they would all be, though

Thanks for the advice, but that would probably be even bigger.  I'll take it under consideration.

Hm. A couple of sprites (3-4?) could show the motion pretty accurately. It would be choppy when starting and stopping though, but it would give more depth to the game IMHO.

I'm currently using 3 sprites for animation I've also been doing some optimization, and have so far gotten rid of 1,000 bytes of program without losing any features.
Also, new demo!  This version fixes the bug where you could only go down to about 100 feet.  A new bug sets the current limit at 342 (you can go further, but the map is corrupted and I'm not responsible if your calculator eats your babies).  This one also has damage implemented, so try not to hit the ground too hard.  The GUI is also being fed live data every 8 frames, though if your hull reaches zero or your fuel runs out, nothing happens.  Also note the increased speed when scrolling down, with the new optimized method for doing so.

Perhaps that would be possible if the majority wasn't code.
Although I have thought of several h4x to get two pages.