|
I think the more compelling argument against the project trajectory being sustainable is the ongoing growth of the platform that's being built and the resulting terrarium problem. Uxn isn't just a 100rabbits thing now, but a community of collaborators...and the things that platform does are really pretty trivial "dawn-of-microcomputing" things in most respects. So you end up in a space where it could have been accomplished in an emulator and tooling that already existed, but this sanctified "simpler" codebase was made instead, and now it's seeing gradual, irresistible growth, such that it will inevitably go beyond the needs of its creators at some point if it continues like this. PICO-8, the original "fantasy console" billed as such, has also grown, its execution model has changed multiple times, it's added significant new features. At some point you will want to configure the emulator, and when you configure the emulator the uniform experience starts to slip away - allowing features for recontextualization is more accessible, more powerful. The quaint little terrarium you thought you had under your control grows back into the jungle of computing again. This is a quandary that has occupied my attention for the past year: what's actually sustainable in computing? But the answer, when I came to it, is simple: formats and protocols, all the way down. Endianness, word sizes, textual encodings, state machine I/O signals, and forms of structured data on up to parsable source documents of various kinds. Everyone's always like "just use JSON" or "just use a PNG" or "just write an HTTP request". Formats are where all the real power is, and they do things platforms can't. And the format's never really the whole codebase. Wherever you have "the code" you have the platform. If you just describe a "simple" stack machine's code and I/O and then proceed to build a massive amount of stuff on it, what you most likely have is an underdocumented platform. When you go to build a game on that, you still build an engine, and the engine implements some rendering algorithms, specifies a timestep, and reads some assets. That's a more completely specified medium that could be turned into a simple format of its own, which indicates that the fantasy console was just a method of constraining the engine. But you could start by defining the rules of a constrained engine instead, no? And that's kind of where my thoughts have gone. It's irrelevant whether it's on Javascript or hand-tuned assembly or a VM: the actual progress is made when you can stop indulging your inner Microsoft by building platforms, but it's so, so hard to avoid doing that. |