A demake of the DOS intro for Ultima V, one of my favourite games of all time. You can watch the original intro here: https://www.youtube.com/watch?v=3XN1mdyvZvM
Holding down Button 1 (Z) will speed up the animation, pressing Button 2 (X) will skip to the next scene; otherwise this is non-interactive.
Turns out that 16x16 sprites blow out the spritesheet pretty quickly, so I had to pack extra sprites into map data and didn't have enough leftover space for fancy logo lettering; but I quite like how the demade titling turned out anyway. Otherwise I've tried to be as faithful to the original as possible, including reverse engineering the in-memory tile animations they used, which was a learning experience. I scored it using Stones rather than the original intro music though, because Stones is kind of the signature tune of the Ultima series.
The music only lasts for about 2/3rds of the intro and then lapses into silence until the sequence restarts; I could update it to segue into a second track, and I could also try some cart compression techniques to squeeze in larger title art. But I'm posting this now because I suspect it's as done as it'll get.
So I'm brushing up against the compressed codesize limit with a cart that's barely halfway towards the token limit. It sounds like this is unusual, and from what I can tell it's because I'm commenting the code fairly thoroughly.
And I have to wonder, what is the intent behind the compressed size limit? What is it still meant to accomplish that the token limit doesn't already?
The token count is a rough representation of binary or bytecode size, which was an authentic historical constraint for many systems. It's measurable from within the editor: a coder can see at a glance how many tokens they have left and how they are affecting that number as they type. While it's approximate, it's directly correlated to code complexity, and this makes it fairly intuitive to reason about. The steps for reducing token count are also intuitive: simplify code, improve code sharing, generate data rather than hardcoding it, do more with less.
The token limit defines a scope for pico-8 cartridges; it encourages creative solutions and algorithmic content generation, and it plays off the other cart limits by discouraging tactics like offloading data into code.
Compressed code size, on the other hand, is a representation only of how much entropy your source code exhibits, a limitation no developer historically suffered under. It cannot be easily measured as you make changes, and it has no direct correlation to the complexity of your program or the efficiency of your code; only to the volume of text and the amenability of that text to an arbitrary compression algorithm.
This doesn't foster creativity: all it does is cause unwelcome surprise and punish certain coding styles. Specifically it discourages comments and descriptive naming, which become barriers for anyone else trying to learn from your code. The compressed size limit doesn't even keep you honest; it's trivially easy to bypass with the aid of a minifier, at the cost of making your code unreadable and uneditable.
The compressed size limit does prevent you from packing your code full of string data, which ok fair enough; text storage was a huge constraint for early game developers and led to creative solutions like paragraph books and the z-machine's bespoke text compression format. But characters in text strings seem like they ought to count toward the token limit anyway - and maybe they already do?
A demake of MT-32 music tracks from Ultima VII, half-assedly arranged for pico8's 4-channel synth. This started out as a way to practice transcribing music by ear, but in the end I cheated and used the original MIDIs as a reference.
It currently includes only the diegetic music from the game, i.e. music that plays from instruments in the game world. I may try to squeeze in one of the longer themes from the game as well, though the cart is kinda tight for sfx space.