This new incarnation of Adventure Kit can be thought of as your own personal toybox, except these toys make old-school video games. Think in the style of the Super Nintendo, or the Game Boy Color – that’s what you’ll be working with. So what sort of toys are in the box? How does the whole thing tick?
ladybird: the core of Hounddog
ladybird will be the main component of the Hounddog engine that powers your game, the nucleus around which the other parts revolve. In essence, it’s a parameterized, programmable game engine, using Pixi.js under the hood. There will be layers on top of the raw
ladybird API, like…
snappy: a nice interface to talk to the engine
With a name derived from “Sn API” (I was thinking of tin’s elemental symbol – it should “do what it says on the tin),
kitsune: the Foxie interpreter and compiler
ladybird engine’s API. It’ll use
bella: the “disassembler” for Foxie and its compilations
A disassembler?! You betcha! This is a nice-to-have, to be honest, and definitely won’t be early on the agenda for Adventure Kit, but it would be really cool to have. See, with
bella, you should be able to turn the compiled, minified result of a
kitsune compilation, a final game, into Foxie code that you can modify! And wouldn’t that just be neat?
eris: Foxie’s error handling system, for makers and gamers
This is one more of those nice-to-have features that definitely isn’t going to be in v1, but it is something I want to account for as I build the initial system, so it’s doable later on.
eris will provide a better exception handling system, that can detect the error being thrown, and (this is the important bit) show something to the user while notifying the developer. Again, not essential, but nice. Let’s get back to the core:
packeederm: the automagic bundler system
packeederm will handle the bundling of assets, along with code, into a single script + data file that can be embedded anywhere. (Super proud of the name, just saying.) This part can get complicated, because we face this fundamental issue where you want a
.js file that can be put into a script tag, but you have assets like spritesheets that aren’t exactly efficient as a base64 string. Expect more posts on this, but in short, I’m seeking to replicate Pico-8’s PNG-based “cartridges”.
adventurekit: the CLI that brings it all together
So where does this leave you, the maker? Ultimately, you’ll be using the
adventurekit CLI script to generate your project. From there, there will be simple commands to run a server, build your bundle, and otherwise work on your game. It’s probably how you’ll end up accessing all of the tools listed above.
Why are things broken down this way?
For one, this division of responsibilities makes it easier to start small. More importantly, it allows people to do things like:
- Customize the build process and how it compresses assets
- Develop plugins for the Foxie language to add functionality
It just makes the system more modular, extensible, and possibly even reusable.
When is all this going to happen?
Obviously this is a mammoth, Herculean task, to build all of this…so I have to start somewhere.
The first part will have to be the
ladybird engine. This will include an extremely low-level API, to control the parts that are programmable or parameterized.
From there, I’d ideally like to start on
kitsune to build Foxie and
snappy is a layer that isn’t needed, one that can be provided by
ladybird natively? Seems reasonable.
Finally, I’ll need to get the
adventurekit CLI up and running, so that someone can run code that hooks into
ladybird, running the final game. At this point,
packeederm will sort of naturally bud from the
adventurekit CLI code…I’ll have to revisit that decision to split as well, to ensure I’m doing the “Right Thing”, as John Carmack would call it.
And as John Carmack would say, it’ll happen “when it’s ready!”, no sooner, no later.
What’s with the naming scheme?
I started out naming these tools after Disney cartoon characters, but of course, they copyright everything to death, and I don’t want to get sued. So, I chose new names, and some of them are kind of silly. You can’t sue me for that, but feel free to complain to the nearest person, pet, or plant.
Next up…building the
ladybird engine core, of course! This involves writing some Pixi.js code to get something on the screen, to start, and I think one of the first things I want to nail down is the asset pipeline. Expect more posts on that, but essentially, as a maker you should be able to put textures/sprites/etc. into a directory, refer to them in scripts, and have everything “just work” down to the bundling of the app. The bundling can come later, but loading and using assets is a core game dev experience I have to get right.
So, until my thoughts well into another wave of rant-y goodness, happy making!