Goal-Setting, December 2020

So, since I last updated about where Galapagos is going, I went and made the pinball prototype. It exists, and you can download and play it, and now I am returning to work on Galapagos stuff, which has meant getting more specific about what I mean when I say I'm working on formats.

The primary thing I'm doing in this direction is a binary format. The spec is still shifting around but it looks roughly like this:

• Built-in "division types" - primitives for numbers of various sizes, strings, byte arrays, and hierarchical containers. The primitives are not aiming for a comprehensive coverage, instead they encompass sizes and formats that are conveniently accessible. So, there are signed 32-bit ints, but not unsigned ones, because many programming environments don't support them easily. Unsigned 8-bit and 16-bit ints are supported, on the other hand. There are big integers(this is mostly straightforward), but not big decimals(too many ways to encode them). Space is left in the spec to add more of these types, but what's there will suffice for the small-scale "source" documents I'm aiming to cover.
• User-defined types that inherit from division types or other user types, with string fields to annotate. This lets you tag data by defining a type for it, which allows you to add a layer of metadata to the structure to aid parsing and versioning of data. These types are defined per-document in the header - I was playing with something more complex but reverted back to this idea.
• A language for selecting and referencing data within the document. This is not something intrinsically supported when the data is deserialized, rather it would exist as a user type that is commonly supported in libraries. The trick to this is in recognizing that a reference like this is a "binding", rather than a "division", and so it's less durable, for the same kinds of reasons that pointers and web links aren't durable.

I'm also simultaneously exploring procedural music systems using Sonic Pi. What I want to do in future iterations of the pinball game is to start working on theming and part of that is to have some music in various styles. While I've composed my own music in the past, one barrier for me is simply in the high amount of labor needed to tidy up arrangements. This labor is based mostly on application of principles found in music theory, so what I'm aiming for is not really "have the computer make the music for me", but "have the computer automate the application of each principle". In practice this is being done by taking references and reverse-engineering parts of them. I realized as I started on this that this work feeds back into some of my original goals for Galapagos in the sense that it is a useful tool, on its own, to have libraries of this kind of thing. They aren't going to be general-purpose libraries, but they could provide a decent starting point for anyone willing to play with code.

I also realized while talking about this to friends yesterday that this work has proceeded in a circle: One of my entry points to Galapagos was the idea of creating a "multicart" that covered many classic games including elaborations on key features, because - and this was what provoked it - most examples of classic games stop right at the moment that a basic example exists, and this was always a source of frustration to me as a new game designer; I wanted something more comprehensive, that bridged the gap between the toy example and the hand-wavy "it's more complicated in production". I got into the idea of fantasy consoles because it made sense to have a sustainable environment to work in, but the platform itself turned out to be a rabbit hole into the inner workings of software platforms, which led to data formats and languages as the common bridge points between platforms. The question of "why is making games hard" is really just pretty darn huge, and it does have some meaning at each of those levels.

So, Galapagos isn't one project, it's all my projects: they're all studies in the makings and workings of games, and I need to embrace a multi-layered approach to it - not inventing everything from scratch, nor going super deep on any one thing, just finding leverage where it appears - and trust that while I won't get any one layer exactly right, the connections between them will start to appear.

I might get around to updating the landing page to reflect this at some point.