🐣 Codename Babylon - Developer Log

[marquiskurt]

Seeking to take a break from the noise of your day-to-day life, you arrive to a strange research facility in the woods, not too far from the cabin you’ve rented. Naively curious by it, you enter into the facility and begin to uncover its inner workings and stumble across a sentient obelisk, caged in a glass room. Yet, everything you’ve seen and heard is unintelligible to you; every spoken and written word is in a language you don’t recognize. Can you learn the language, get to the truth about this place, and help free the obelisk creature?

Codename Babylon (actual name TBD) is an experimental metroidbrania^[1] puzzle game for Playdate that I'm developing. It takes inspiration from titles like Lorelei and the Laser Eyes, Chants of Sennaar, INSIDE, The Witness, and Severance.

This project is also the "poster child" of the PDKUtils and Renzo frameworks, which are used to help build the game^[2] and handle 3D graphics, respectively. (Did I mention this project is made in Swift?)

I started working on this back in November of last year, and I’ve been keeping a devlog on Discord. However, I figured I’d put something here too for greater visibility and reducing any dependency on Discord itself.

Update: I've moved away from discussing Codename Babylon on Discord and have instead opted to create a new Matrix room for this. For more realtime updates, join me at #babylon-pd:one.ems.host.

---

---

1. This part is still being debated in my head, but you could probs finish the game quickly if you knew the conlang beforehand ↩︎

2. PDKUtils includes tools like PDFoundation for fundamental SDK things, PDGraphics for performant graphics drawing capabilities, and PDUIKit, for rendering user interfaces. ↩︎

[marquiskurt]

So far, I’ve managed to get the following done:

• I have a proof-of-concept UI that I’ve built for the keyboard and general UI mechanisms. Although this isn’t as exciting, and there’s much to be improved with PlaydateUIKit generally…
• I have a very basic 3D engine working. It doesn’t have all the bells and whistles of a more general-purpose engine, but I can read a series of model files, apply perspective projections, and display them on the screen. Admittedly, it took quite a while to get it optimized, resorting to writing my own smaller graphics library and patching up how I’ve been handling the dither patterns. The prototype of my game used to sit at ~94% CPU usage, but I’ve managed to get it lowered to ~70% max.
  • Along with the engine, I’ve created a Blender extension, Renzo Utilities that lets me export entire models and scenes into formats my engine understands.
• I’ve worked on some of the basic components of the constructed language (conlang) that the game will use, such as numbering systems, general syntax and grammar, and the general morphology. I don’t want to give away too much yet, but it’s looking promising and far less headache-inducing than my previous conlang endeavors.
• To aid me with general development, I’ve also created an internal tool with Swift and SwiftUI called Broadstreet. So far it lets me validate scene files and provides a nifty number converter, but I’m planning to add more over time as I discover things I will likely want to have a tool for.

[marquiskurt]

After some discussion with a few dev friends, I decided that I would merge some of the libraries I have into a singular meta SDK called PDKUtils that combines parts of the graphics stuff in Renzo and the UI bits in PlaydateUIKit, simply so I don’t have to make several smaller packages. I’m slowly getting the documentation sorted, but this will be helpful in the future for developing Babylon.

PDKUtils Source: PDUniverse/PDKUtils: The missing Playdate SDK package for Swift. - SkyVault

PDKUtils Docs: https://pdkutils.marquiskurt.net

[marquiskurt]

I’ve managed to yet again gain some additional headroom! I’ve done some more things inside PDGraphics, the graphics portion of PDKUtils that significantly speed things up in my 3D renderer’s hot loop, including:

• To reduce the number of times I need to calculate a Bayer pattern for a specific brightness level, I create a small pattern cache (PGBayerPatternCache) ahead of time and pull from that. This gave me back around ~20% CPU.
• When migrating my Bayer pattern generator based on brightness (e.g., PGColor.dithered(by:), I made some internal values constant, which gave me back ~5-10% CPU.

[marquiskurt]

After some more fiddling around the past few days, I managed to get support for different materials working (i.e., model faces can be designated with their own colors) and an improved lighting system that also accounts for things like attenuation. Had to play around with all sorts of gamma corrections and updating the file formats, but I think I have it looking as best as I want to.

[marquiskurt]

The project continues on! I've been thinking a lot about triggers, and how I can incorporate them into the game (and Renzo, respectively). It took quite some time, but I eventually settled on how I represent triggers in the Playdate scene file format (.pdscene). This also gave me an opportunity to spruce up my Blender add-on, letting me automate some of the sausage making.

[marquiskurt]

Triggers now seem to be working correctly! I’ve written a new SceneTriggerHandler that handles trigger checks and calls out to a delegate to perform a requested action. Currently, I support two of the three actions I’ve written: invoking a debugger action, and changing the current camera in focus. Triggers are treated like axis-aligned bounding boxes (AABBs), and the handler tries to determine how the player is related to that bounding box.

I was initially worried about performance given the internal state tracking and collision checking, but it’s peanuts compared to the rendering engine itself.