Nearly 10 years ago, my daughter Jadzia wanted me to make a game called “Jewel Mountain.” One of my early ANSI experiments for the game was to make an RPG-style tile map in ANSI.

When I started it years ago, my initial idea was to adapt 16×16 pixel-art tiles to sprites made of ANSI text, and implement the map in 132×60 mode, since it’s higher “resolution” and the characters are square rather than rectangular. I made a working version of this years ago and some of you probably saw it. But eventually I regretted those design choices: The 132×60 terminal mode isn’t commonly used by most folks; and the 16×16 sprite size was just too big.

Do you enjoy my retrocomputing research on Break Into Chat? Please join my email list so I can share future projects with you. 📬

But Jadzia and I could never quite nail down the right story and goals for the game, and so we didn’t get much further than the tech demos. Though I did use some of the ANSI techniques to create a few cool animations for Blocktronics over the years.

Jadzia died in 2020. I discussed continuing the project with the family, and my daughter Josie especially has had some ideas for trying to finish it. I began revisiting some of those early experiments in 2022, but I realized recently that I never discussed it on the blog. So here goes.

My main work was redoing the tile map. It’s now built around 8×4 ANSI tiles in normal 80×24 terminal mode. I’m treating half-block characters as the equivalent of pixels, so effectively these are like 8×8 pixel tiles. The tile dimensions evenly divide into the screen dimensions, so I end up with a 10×6 tile grid, which is nice.

The main tradeoff of half blocks is that they have to be solid colors. ANSI gradient characters are full blocks, so I’m avoiding them in sprites, but using them in background tiles. Another tradeoff is that I can’t mask a half-block (making half solid and half transparent, letting what’s underneath show through). I can only mask a full character.

Speaking of sprites, I completely rebuilt my ANSI sprite system. On the old map, when a sprite moved to a new tile, I simply erased the old one and drew it in the new position. It was almost like it hopped from one tile to the next. This had a big speed advantage, which is important on a BBS, where latency can be a problem. But it didn’t look natural, and I wanted this to feel more like a real video game.

So I coded a walk animation, and moved the sprite one character/line at a time from the source to the destination, with arm and leg movement. I used the Frame.js optimizations I’ve come up with over the years to make the redraws as quick as possible.

But this walk animation work led to a mismatch with the map, which was still scrolling one full tile a time. The difference between the movement of the sprite and the map was quite jarring, and I realized I also needed to make the map to scroll finely.

It took some doing to get the two in sync, but eventually I succeeded. I now have fine map scrolling and an animated sprite walk, both of which are synced to each other. It looks really good!

If you’d like to check it out in SyncTerm or your favorite terminal, telnet to guardian.synchro.net. From the main menu, choose “Externals”, then “Jewel Mountain experiments” then “Jewel 5 – 80×24 map”.