Working in 1-bit for this game has been interesting. Going in, I thought my experience with Obra Dinn would let me cruise through the visuals. Typical devlog setup, so let me describe in detail how wrong that thought was.

Turns out that rendering 3D content in grayscale with realtime post-processing to 1-bit is a totally different thing from making well-crafted 2D art. Most of my existing skillset and pipeline has been almost useless.

Some reasons why my previous encounters with 1-bit haven't translated well:

1 With 3D content, moving the camera around is a critical part of understanding the scene in front of you. With 2D, you need to be able to quickly and easily interpret only what you're seeing on screen right now. Also the Playdate screen is 2 inches across, so legibility is already a challenge.

2 The handling of 1-bit generally and the art style specifically in Obra Dinn was built on technical engineering-based solutions in pipeline features, geometry handling, and post-processing. Getting the look I wanted involved lots of programming and a comparatively little bit of art. For 2D on the Playdate, there's no geometry, no post-processing, and no pipeline complexity. You really just make 1-bit images and the hardware blits them onto the screen. Without adding some stupidly over-engineered programming steps I'm honestly a little lost here.

3 While I was careful with dithering in Obra Dinn, working and presenting only 2D art makes dither patterns an even bigger issue. The small physical size of the screen means that dithering actually works well to re-create grayscale tones but stylistically I don't think the best use of 1-bit is to simulate 8-bit grayscale. I'd rather make something that's enhanced by the limitations rather than pressed up against them. And that means really thinking about each and every pixel. At 400x240 it's just high enough resolution to make that a lot of thinking.

4 As a specific hardware issue, the Sharp screen suffers from strobing when flipping pixels on/off. This isn't normally perceptible except when scrolling a dithered image. The consequence is that any image that will move needs to either have a static dither pattern applied post-move (hard) or be more carefully designed to persist its pixels as much as possible in the direction of movement (less hard).

5 The tools for working directly in 1-bit aren't that great. Using grayscale is much, much easier in every single modern content creation tool. I made an effort to use classic Mac System 7 tools but let me tell you a little story about unlimited undo: I need it and those old programs don't have it. With modern tools like Photoshop and Blender I have systems and scripts to manage and preview images in 1-bit but it's just clunky enough to keep me unsatisfied.

For Example: Pie Scene

There's pie in this game. I only barely know why. Another one of those bright ideas that could work but also maybe not. Anyways there's pie right now and building this one scene of a pie sitting on a table is a nice illustration of my challenges with 1-bit in 2D.

After ruminating on it for a bit I concluded that obviously the best way to do this was to model it in Blender and render it out. I need multiple variations of the scene and just moving the objects around in 3D and re-rendering is super easy.

 Creating the scene in Blender

Blender is a great program. I wasted years turning the grindstone in Maya for Obra Dinn and everything I did with that painful old app is easier and more sensible in Blender. It's not perfect but let's be realistic here. A proper endorsement: If you're working in 3D, use Blender.

My goal was to take my previous 1-bit 3D techniques into Blender's renderer. It was surprisingly easy. First, Blender's got a great material node system. This let me apply vertex colors to define how objects should create outlines.

 Blender's material editor

Next, it's got an amazing Compositor. Again node based, you can process the rendered image however you want before generating the final output. Very simple to split out the lighting/shadow pass and to reproduce Obra Dinn's edge detection logic.

 Compositor nodes for edge detection

There's even the incredible ability to define per-object parameters (Shader AOV) that come through as masks for compositing. Maybe that doesn't sound impressive but let me tell you that shit is beyond handy. In my case, it allows me to set a property on each object that defines which dither pattern is applied to it in the final image. Obra Dinn's renderer had one bit reserved for one special object type -- Blender gives me infinite bits for as many types as I want.

Put that all together and I get this:

Whoops, I hate it.

If you could move around here in 3D it might come together, in a way. But this is 2D and what you see is what you get and what you get, here, sucks. The result feels like something created in a much more powerful environment (true), scaled down, processed, and squeezed into a static image (all true). There were a few old Mac games created this way and I never quite clicked with that style.

A little desperate, I tried different changes like roughing the shapes up, introducing small errors -- stuff make it feel more hand-made. Of course none of that worked so the next step was to give up all my special engineering shortcuts and use actual hands to make it.

Actual Hands

I ditched Blender and just sketched the scene in grayscale using Procreate for iPad. Drawing perfect ellipses is awkward, straight lines are easy, and the pen/eraser/layers/undo/etc in Procreate are all excellent. Patterns are done by importing a full 400x240 image of the repeating pattern and masking the layer.

Dropping this directly into 1-bit isn't half bad...

...if a bit basic. Needs some precision and extra details. So over to Pixaki, also for iPad, to retrace everything. Pixaki has great ellipse support, worse layering, and is overall better tuned for low-resolution pixel work. No pattern fills though, which is a drag.

 Retraced and cleaned up. Patterns drawn by hand.

And finally into Photoshop for more layer-based patterns and a perspective distort on the tabletop.

 Added details and patterns

Ok that feels like a better fit with the limitations. The perspective on the objects is a little off everywhere, which should make it clear that no one with excessive drawing skills was involved.

Even though I used three different apps to get the end result, drawing it by hand was just slightly quicker than modeling the scene in Blender. Makes sense but the plan is to have this pie get eaten gradually so the balance will shift as I draw more variations.

Why the Trouble

I had a wonder about why my first instinct was to model this relatively simple scene in 3D, and not to just draw it by hand. Surely most artists would just draw it. Partially because I'm just not a super great artist. Mostly though I think the answer comes from how I approach production in general.

Basically, I don't have the bandwidth to draw lots of detailed stuff while also doing everything else to create the game. I'm always looking for efficiencies and shortcuts that explicitly avoid the "just buckle down and power through it" techniques you need for most good art. I'd rather work out a stylistic shortcut that saves me time. I've done that successfully in other places for this game, it just didn't work here. The idea that authoring in 3D would make the variations easier couldn't overcome the lame result I guess.

Whatever lesson I'm learning will hopefully stick with me for the rest of the project. There's very few platforms that are more constrained than 400x240 1-bit, so even the "power through it" stuff isn't that bad.