Coming in for Round 43

I had a fairly successful LD 42 - I haven't finished the game I started for that one yet, but I actually pulled it out and did a little bit of work this morning as a way of getting my brain started for the day.

Last time around I did a very detailed blog with all my game making wisdom. If you'd like the short version of that, I wrote up a separate article on my personal blog that deals with the basic idea: Coherency. The article gives you a framework for testing your game ideas(or any other creative things) before you get into the weeds of making it, and I have gotten a lot of positive feedback about it.

In my last game I used PICO-8, and had a good experience with it. But I am actually starting on my own fantasy console now, Galapagos. It is early enough in the going that I have nothing released and only a few locked down specs, but LD is an unmissable opportunity to give it a workout. Here's what I would call a pre-announcement announcement to give you an idea, though half of this stuff I haven't even gotten to yet or is littered across little prototypes and not in the working codebase:

  • Based on three broad principles to set goals and constraints:
    • Sustainable design: what would a lasting, energy efficient console look like? How could I make it so that tooling made for the console is reusable by others?
    • Linear paradigms: make the workflow very directed start-to-finish instead of jumping around, with visual metaphors to match, use list data structures, etc. Aim for linear expansion of game scope, instead of Moore's law doublings.
    • Evolutionary tradeoffs - you can install "modules" to add a degree of customization, but instead of being able to "max out" the system, you have a total constraint on how many modules/which types of modules you can use, hence the name "Galapagos" - explore different evolutionary tradeoffs along a spectrum.
  • Coding:
    • Both Javascript and Web Assembly programs are supported. I haven't gotten to the latter yet.
    • Some APIs for the requisite matrix/vector math etc. included
    • Various CPU, memory, and program size limits will be enforced(still unspecified) to meet the sustainability principle. Modules can be used to expand these limits.
    • Galapagos runtime is implemented in Go, using "raylib-go" for most I/O and "beep" for audio.
  • Graphics:
    • Smallest mode: 480x320, 4 colors palette in classic "amber monochrome" style (I might add more modes with wider and smaller aspect ratios)
    • Biggest mode: 640x480, 16 colors palette(customizable RGB; extends the 4-color default to green/amber with some additional hues) with built-in support for color fades. A size that is comfy for 80-column coding and lets you make PC-98 style graphics.
    • 40 and 80 column monospace bitmap fonts using UTF-8 codepoints between 0-255, i.e. enough to edit Unicode documents while not necessarily rendering them properly.
    • Some support for immediate mode drawing functions and common geometry operations - 2D and 3D shapes, scaled sprites, and others. More like a scenegraph than a traditional framebuffer system. (These APIs might be pushed into modules, so that you can experience more "from scratch" and "weird hack" coding.)
  • Audio:
    • A small "beeper" style oscillator by default, with a few preset timbres. Spend modules to get more voices.
    • PCM sample oscillator module so that the game can announce "YOU WIN" and play orchestra hits
    • Plaits macro-oscillator module for high fidelity and experimental sounds, voice synthesis, etc.
    • Programmable synth envelopes, advanced modulation possibilities etc. - design still WIP
    • Music Macro Language for small tunes and SFX, in the future most likely a music tracker
  • Tools/Formats/IDE:
    • Built-in code editor and JS REPL.
    • "Softcard" system that stores everything in a sectioned UTF-8 document. Cards can contain arbitrary(textual) data.
    • Additional editors can be written as softcard programs, and broadcast their compatibility with softcard chunks for automatic usage.
    • Softcard programs can communicate with each other with a Plan-9 style "expose everything as files" strategy. This will appear in visual form as a set of cards progressing left to right, with the earlier ones able to send to the later ones.

palette.png palette tests

gal40.png WIP 40-column font based on Hack

Anyway, what I do during LD will probably be extremely simple, more like a tech demo than a fully designed game, and only use a fraction of all these features. But it'll be good to try to get to a first release.