This past fall, I started work on a fantasy console project, titled Galapagos. I am inspired a bit by PICO-8, by Ming Mecca, by old research operating systems like Plan 9 and Oberon, and by various old computer aesthetics outside of the typical NES/C64 look, like the PC-9800 series and Hercules monochrome. It is an extension of things I’ve written about in this blog: an integrated system that expresses my thoughts about creativity, with some pragmatic compromises made where needed.
Principles Defining Galapagos
Musicality. Working with it should feel like playing an instrument. Features making the system scalable and extensible come second to making definite trade-offs that shape your work, in the same way that writing for wind instruments is different from writing for strings. These trade-offs describe different “evolutionary paths”, hence the name Galapagos came to mind as a way of suggesting alternate histories of computing and showcasing pasts that we never had. The final result should allow for real “play” and a feeling of freedom, where most game making tools fall into the production-consumption cycle. Also, the built-in synthesizer should sound pretty.
Linearity. Behavior that leads to modes, special cases and interdependencies will mostly distract from doing design work. This goes for both user interface concepts and the underlying implementation. So, when I need ideas for UX, I look for a way to describe a linear default, where a “turn of the knob” is all that is necessary to change the configuration. Where it’s reasonable to do so, linear behavior is exposed as an abstraction over some more raw, low-level system.
Sustainability. A system that can last for a long time: This means being somewhat conservative in certain respects and applying “boring” technologies to do heavy lifting, so that their likelihood of lasting is greater. It also means defining performance in a conservative way and enforcing various maximums so that software written for Galapagos is not too sensitive to the implementation. Generally speaking, trying to make the spec tight where it is reasonable to do so, and permissive where the details are too likely to change. Sustainability is not a “write it in Rust” optimization challenge, so much as another way to think about enforcing limits.
All of these principles are aspirational, and they have points of conflict and areas where my ability to execute won’t match up. But together they are helping me define the system at a high level.
Some Work-In-Progress Technical Specifications
- Premade “hardware modules” that allow the system to be configured within limits. For example, higher graphics resolutions or larger addressable palettes can be added with a module, at the expense of module space for sound channels or total software size. This is intended to provide an interesting spectrum of technical decisions.
- Multiple resolutions, with a maximum of 640x480 to allow readable 80-column text.
- Graphics are drawn using subsets of a reconfigurable palette:
- The basic system allows for scaled and rotated sprites of 4 colors at a time, with color key transparency.
- The default palette comes with the first 16 colors defined for a “green and amber monochrome” look.
- An offset can be applied to the palette to allow the 4 colors to address different locations within those 16 colors, as well as user-defined colors.
- This means that even with the base system, games using all 256 colors are possible, but you have to always work with groupings of 4, which guides your color usage and asset design towards the typical recommendations for pixel artists to use fewer colors total.
- 16, 64, and the full 256 colors can also be addressed at a time, but this requires extension with modules.
- Options for texture-mapped 3D will also be provided. The 3D offerings will be tuned around finding a pleasant trade between scene detail and asset size.
- Tools for working with each of these options and creating assets will be provided.
- Synthesizer voices start with 2 channel sound and can be extended with modules.
- Synthesizer voices have a voice programming system allowing fine-grained definitions of parameters and envelopes. Knowledge of this system won’t be required to make sounds - a sound engine with UI for making synth patches will be provided - but there are opportunities for doing some lower-level synth coding.
- Each voice has a configurable oscillator: single-cycle wavetables, PCM sample playback, and the Plaits macro-oscillator modes are planned.
- Sequencing options are work-in-progress. I’m currently debating between MML, tracker, and monome-style options, and may come up with some hybrid.
- Programming is done with Web technologies, since the runtimes are extremely common, and many other languages treat these technologies as compilation targets:
- WebAssembly (planned)
- Both options will impose limits on code size and resource usage, and I will look into possibilities for mixed codebases.
- Calibration of elapsed time against a benchmark suite is planned as the main way of imposing an overall CPU limit, rather than a “hard” limiter based on custom runtimes and instruction counts. This gives the implementation a lot of flexibility, and reflects emerging expectations about low-level performance today, where the last few percentages depend on poorly controlled factors like ambient CPU temperatures and OS schedulers. Modules may be applied to bump up the limits for applications that want to do something CPU intensive.
- Operating system with some notion of an internal database for software and assets.
- Intended to enable custom tools, so that when a game calls for custom assets, you don’t leave Galapagos to build them. This also allows “no coding” game maker tools to be built on the platform.
- The file format, called Softcard, is a readable text file format and will allow you to use your preferred code editor as well as the built-in editors.
- A GUI system will be available to help with building tools. It’s designed for immediate mode layouts, and will include buttons, lists, drop-down menus and toolbars, and monospace text rendering with word-wrapping support.
- Like every other fantasy console, a text editor will be included for coding, and its functionality will also be available as a UI element for your own programs.
- Some planned features for connecting tools to each other, making them less standalone and more reusable. My goal is for it to feel similar to connecting a chain of FX pedals to your instrument.
I am using a system of rough “doublings” of scope for each major milestone, which I call the “project spiral”:
- One and a half weeks (December 4, 2018)
- Three weeks (December 14, 2018)
- Five weeks (December 28, 2018)
- Eight weeks (January 18, 2019)
- Three months (Saturday, February 23, 2019)
- Six months (Thursday, May 23, 2019)
- One year (Saturday, November 23, 2019)
- Two years (Saturday, November 23, 2020)
As the time horizon goes farther out, the focus of the plans changes.
Although some prototyping got underway in August, the first real “milestone” started in November and ended on December 4th, after making a demonstration game for Ludum Dare. The second concludes with this posting. Schedule doubling is a mechanism for limiting how deep I go with specific project features, giving me some ability to correct course to hit each milestone at a larger scope. By two years out, the internals should be close to locked, and most of my efforts will go instead towards tools refinement, communicating about the project and fleshing out more of the added-value features: a forum system, sharing software, etc.
I will first make Galapagos available through a Patreon page in the February 23 milestone, as a donation incentive, and grow availability from there. Following PICO-8’s approach and starting it as a closed/commercial project will help me to actually get the code into a polished, usable state, but what I plan for February and the months following that will be more like “preview” builds, something I can use to get feedback with, with no guarantee of forward compatibility. As I get more confident about the design it’ll become easier to focus on making releases.