Hackers and painters and pixels

How I got started with (hybrid) pixel art and more considerations on (learning) painting and programming.

In 2020, on a serendipitous whim, I motivated OK Feather to enter the Adventuron game jam. That tasked me with making pixel art for the game, which I didn’t have much experience with. I had tried a few years before following two of the most well known tutorials on the internet:

• Derek Yu’s tutorial
• Pixel Joint’s tutorial

Example from the Pixel Studio wiki, with lines, anti-aliasing, dithering, and color ramps.

But after hours then days of fiddling with individual pixels, I gave up, since my single sprite was far from finished and progress was seemingly following Zeno’s paradox.

This was actually the third iteration of that sprite, so it had already become clear that this method would never work. In particular the fight against jaggies was overpowering the form; each pixel carries so much information that focusing on them destroyed the big picture.

The artist has to be in control of the image at the level of the single pixel, and every pixel should be purposefully placed.

These tutorials¹ silently assumed some skills I didn’t have, and by focusing on “master level” output, it hampered my progress in making anything at all, even if it was mediocre work. My understanding on where pixel art can cheat or suck without it being a problem was also lacking. That means the weird ways perspective is often dealt with, or sometimes how actual proportions are distorted; in both cases, thinking in terms of traditional drawing was working against learning how pixel art works.

Working with no method

This time I decided to follow no method at all, and just approach it like any other drawing, just a smaller one. In particular I went with Krita as drawing tool rather than any specific pixel art tool, in good part because I love it, and because the pixel and dithering brush are good enough.

The two main defining features of pixel art are the low resolution, and the limited palette. The limited palette changes the way you think about colors, in a lot of cases with people working with predefined color ramps to find the right shade in different context (fully illuminated, etc). This different approach means that a different approach is also needed to keep saturation and contrast harmonious (unless the palette is so constrained that this comes for free).

So I took the Pico-8 palette, and used it as a starting point, without necessarily sticking to it. I let myself use any color I wanted, while just trying not to use too many. The issue that then came up was that characters would not pop out properly in front of the backgrounds. Either outlines can be used, or the background colors can be adapted in terms of saturation and contrast to be duller than characters. I went with the standard way that is used in paintings: add volumetric fog! (volumetric fog is a fancy way to say that the background is lighter and less saturated the further away it is because of the atmosphere) Of course it makes no sense, but it allows to have your cake (backgrounds that stand out on their own) and eat it too (by staying readable with characters and without outlines).

This proved useful as the sprites appeared in different contexts, for example the map could be called anywhere.

For the lines, I made crude outlines, and refined them as much as I could, simply limiting this process in time to avoid it becoming too painful. In many cases I drew my drafts at a regular size first and downscaled it, which feels more comfortable, but meant that subtle ‘gradients’ would be all other what would be flat colors in normal pixel art, and thus require more work fixing. These were not entirely fixed up so it’s easy to spot which ones were done that way.

As an aside, some last minute changes to the game meant that I had to make a few more sprites than planned, which made me depend more on references to speed up the process and meet the deadline.

The result is not exactly traditional pixel art, but that seems fine since now it is more of an arbitrary set of constraints. In other words, I managed to make pixel art efficiently in a few days by adopting the same iterative process that I normally use².

Programming the big picture

The ‘iterative method’ sounds very much alike rapid prototyping or the agile method, and it is easy to work with the analogies. Composition is like architecture, and rendering is like implementing functions. In both cases, as details get gradually filled in, some adaptations to the original plan are needed. It is important during iterations to take a step back and ensure that the details are not taking over the whole picture, that the overall composition is still working. In painting this is done with mirroring, checking the values, and ‘squinting your eyes’ to blur things out.

There are other analogies in the way that there are many dimensions to the work (color, density, saturation, contrast, etc) and because of their relationships to each other it is not entirely possible to consider them all independently. In programming complexity comes in different flavours, so it is important to make choices on to where and how these complexities are distributed. In both cases, in the beginnings it is extremely helpful to treat every problem independently, and with experience it becomes possible to work more intuitively and thus more holistically. In both cases, the perception of the painting or of complexity are human, and this is ultimately what matters. So other considerations about how perception works are also relevant.

In Paul Graham’s essay, painting is seen through the traditional lens, where the artist needs to switch between thinking in terms of paint chemistry at low-level and ‘painting’ at high-level. But if you start with digital painting the equivalent is to directly think of the physical properties of light. In a way pigments and HSV are abstractions that give a few primitives to work with to make the high-level process more manageable (‘add more cadmium yellow’ against ‘set to a lighter value and shift the hue’).

Learning from learning

Pixel art also offers its own set of primitives with color ramps, palettes, dithering, etc. If I had started with pixel art, these would make more sense. But because the activity is too close to painting, it is easy to get stuck in the wrong mindset, and confuse the abstractions and goals. Not unlike programming in a functional or object-oriented styles can clash, and while it is often possible to mix the two, it often makes things more complicated because it requires to shift mental gears at different levels, which thus requires to already have a good mental model of the whole. But when coming from the outside, the picture of the whole is the most challenging part to learn.

Because the ‘pixel art’ style is a lot about the polishing step, I sabotaged any possibility to have a good working process. It is important to remember what the goal is; pixel art in that case was about conveying the feel of the game, so even if changing the process meant sacrificing the possibility to make a ‘masterpiece’, it had no purpose otherwise.

There is analogously an iterating process on the theory, the practice, and the workflow. It isn’t possible to separate the tree entirely, because all shape your own individual understanding. This post itself blends ideas that I retroactively understood and ideas that naturally arose from the process. Programming rely on mathematical theories, the practical design, and their workflow of the programmers.

A science, an art, and a craft. I love to think about their relationships as they inform each other, and lets your brain naturally pick up patterns and ideas from the other domains. I think this meta-process can be applied to mostly any other domain, like woodworking, or cooking. It is a bit like how people recommend to learn a second language but for higher-level concepts.