I ended up spending about half of May visiting family, since I finally got vaccinated, so I don’t have a ton of new progress to share right now – but I do have a number of new ideas, and there’s plenty to talk about that I didn’t get to in the last DevBlog.

Right before I left, I took a dive into completely reworking the map editor… again. This was a fairly successful redesign, and I was able to fix most of the bugs during the trip – enough of them, anyway, to make building levels possible. What I eventually realized with the map editor is that I’d made a huge mistake in how I’d engineered it: I was duplicating data. I don’t know if this is considered classically bad programming practice – I have heard many many injunctions against reproducing code, but relatively few against redundant information. In my experience, many bugs seem to emerge from conceptual ambiguity over which part of the code is meant to “own” data and which are meant to request it: When that flow is confused it can be easy to end up splitting up the relevant information between different parts of the program, making it almost impossible to keep track of what the data is supposed to be. This is all a bit vague, and I may go into more detail in a future programming essay, but the upshot in this case is that information about the size and shape of each room on the map existed in two places: In the visible tiles on the map and within the rooms themselves – actually, technically, it existed in three places, since in addition to the rendered tiles the world map also held a grid describing what those tiles were supposed to be. Part of the reason why this part of the project went so far out of control was just because every change I made had to be synced between these different components, and each individual necessary change became easy to overlook – effectively multiplying the work I had to do several-fold and making it much easier to make stupid mistakes. Having realized this structural issue, I completely overhauled the whole setup, deleting a significant portion of the code I’d created, to create a system with a clear and stable relationship: The role of the map was just to be a tool to conveniently display rooms and provide tools to create, delete, and resize those rooms. With this in mind, it becomes much easier to understand what needs to be done at what step, what part of the program holds responsibilities and data and what part is tasked with merely accessing and presenting that data. There are still a few improvements to make – the map doesn’t always display the tiles it’s supposed to, and some of the auto-generated placeholder rooms are slightly erroneous – but, because the important data is now that which is contained within the rooms themselves, I can just manually modify those rooms as needed to accomplish whatever I’m trying to do in the moment. When I find the time and motivation to revisit the map editor, I can fix those few remaining issues.

That accomplished, it was time to start building the levels in earnest. This turned out to be a bit more artistically challenging than I’d expected: Part of why I chose this extremely simple art style was to make it faster and simpler to generate assets – which has indeed been the case – but sometimes it still takes a while to figure out the visual language of an area. The first section of the game, immediately after the player leaves the starting room, are the city streets. Right away I ran into an art problem: This game is a 2d platformer, but a street is by definition something which is long and more or less flat. While the world the game takes place in is not in a great state, I didn’t want to break the terrain apart like there had been an earthquake, so I had to consider how to make the streets feel fairly grounded and realistic while still interesting to play. The first thing I realized is that this visual language immediately began to make more sense if I made the ground level represented by the center of the street rather than the sidewalks – though I am of course more accustomed to walking on sidewalks, centering the action on the street meant that it felt intuitive to have parked vehicles block the player’s path rather than merely being background or foreground elements. I also looked at how a number of other 2d platformers had solved this issue, and pulled a few choice ideas I noticed – vents, balconies, and awnings could all add vertical variation to the flow of the streets. Finally, I also created a wooded park section to break up the urban area, which changes the feel of the area as a whole and makes it all feel less repetitive.

Building the levels themselves, though, is going quite a bit slower than I’d expected. After quickly slapping together a fairly enjoyable demo level I thought “well, that went very smoothly, I can just assume most level development will go about the same way.” It turns out, however, that there’s a big difference between throwing together a small and abstract environment where you can test out a few enemies and player abilities and creating a realistic slice of world which is still composed to allow meaningful gameplay. The level of attention and detail required for even relatively small and straightforward areas can be significantly greater, and I frequently need to stop developing an area to create new tiles to fill it out and add details.

Because this month was so busy, I’m still quite a ways away from building that full-featured vertical slice of the experience I was talking about last week – but I’m not as far away as I was worried I would be! The general room layout of the first section of the game is done, and going through and adding details to each room is a lengthy but enjoyable process which I’m comfortably pushing forward on a bit at a time every day – perhaps not as quickly as I’d wish, but steadily. Some additional programming work will need to be done to set up some special interactions and a multi-layered map system (something which I added some framework code for while working on the map editor but didn’t wholly implement) – this sounds very sophisticated and impressive, but in this case it just means the world will have some doors in the background which you can enter to go into a back room. Mostly the remaining work for this section is just building more rooms, along with a couple of enemies and a boss fight.

While I was traveling, though, I had a lot of time to think about what the total scope of the game is and what I’m trying to convey with the experience, as well as fleshing out some ideas that had been rattling around in the back of my head. Surprisingly, these ideas didn’t balloon the project out of control, as I’d been concerned they might – the scope of the project increased somewhat, but not drastically, and I have a pretty good idea of the total arc of it now so it’s unlikely to expand much further. All of my games end up somewhat themed around death for some reason, except in this case where the game is really really themed around death – around all existence and personal experience, all possibility and memory, converging to a single point like the tip of a needle. There’s other elements I can pick out, absurdity and greed and self-image, but death is what the story is about. Still, there’s no reason to make it bleak or dreary! I hope to include plenty of humor with the sorrow, and plenty of inspiration with the existential horror.

f you’d like to help support this project or my writing, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

Subtlety is overrated. I find I have less patience these days for slow burns and coy insinuations, for quiet stories that never quite go anywhere or actually say anything. When I was first studying writing and art, I resisted the idea that everything had to have a “message” – and I suppose I still do, confronted with that framing. No, not everything need have a message, in the sense of a little moral written on a slip of paper, made to be read after cracking open the stale pastry of the story itself, but all art must have a perspective, a set of values, some understanding it wishes to convey. Art is communication, and communication absent content is mere white noise.

I don’t think everything must be bombast and pedantry, but I find the presumed literary merit of allusion over elucidation implausible. Perhaps this all seems a misguided complaint in an era of action-blockbusters which are anything but subtle in their presentation, but even these are increasingly often assiduously scrubbed of anything that might be misconstrued for a perspective or rebellious streak of moral philosophy. This is similar to the modern plague of so-called “unbiased” reporting, and is problematic in much the same way – that which purports to be without bias, that which purports to be without message becomes, perhaps unwittingly, replicator of existing biases and messages. Once you scrub away any overt viewpoint, all that remains is that which evades notice, the insidious default, the ghost of the status quo.

If, as an artist, there’s something you feel strongly about, then it’s your duty to convey that feeling, one way or another. You can hem and haw however you like deciding the most effective ways of communicating what you care about, you can swap and rearrange where and when you integrate what matters to you, but what goes in must be precious to you, must hold meaning – or why would you bother in the first place?

However, while I argue that it’s a waste of time being needlessly and obtusely subtle about your beliefs, about the core animating themes of your work, I do think there’s also such a thing as nuance – and that this is actually often what we’re deriding when we deride works as ham-fisted, maudlin, obvious, or manipulative (and the rest of the time what we are deriding is probably a young and inexperienced artist’s inability to convey emotions and beliefs except through cliché). Nuance is that which adds complexity to a work, which deepens its meaning – and, while being overt and obvious with your beliefs might at first seem to work against this purpose, the only way you can discover a deeper understanding is by starting with bold strokes and then filling in the space in between – by declaring a bold thesis and then afterwards exploring its manifold implications, rather than starting from contextless events and eventually building to something that maybe looks like an idea if you squint hard enough.

Another caveat to this perspective is that, while I feel the artist ought to express their beliefs and emotions as powerfully as they can, many beliefs and emotions are confusing, contradictory, and not easily described. This is, as far as I’m concerned, all the more reason to immediately exorcise those beliefs which can be understood and described onto the page, the better to dig down deeper into them and approach the ineffable contradictions and confusions lying just beyond.

Sadly, the art that gets mocked as empty pretentiousness is all too often that which has a strong message conveyed through unusual aesthetic and narrative styles – rather than, what is much more common and beloved, stories about nothing in particular told in the most conventional ways possible, and which usually garners all the praise which might be expected.

If you enjoyed this essay, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

There are certain ideas that I find myself endlessly revisiting, ideas so flexible that I end up appealing back to their analogies on a weekly basis. One such idea is that of Zeno’s Paradox, which goes thus: In order to travel a given distance, we must first travel half that distance, then half the remaining distance, then another and another and another half – so how is it that we ever reach our destination, given this infinity of halves we must traverse? This is perhaps a bit of a silly question, but the underlying concept of continuum, of an infinitely divisible whole, is the foundation of calculus. Just as often, though, I imagine this parable in a more literal and literary sense – each destination we have we must reach by successive half-measures, each journey beginning with a single step.

This has lead to the formulation of what I like to call “Zeno’s Pep-Talk”: In order to travel a given distance, all you need to do is to travel half that distance twice – and in order to do that, all you need to do is travel half of the halved distance twice, and so on and on, increasingly tiny distances that you could traverse easily and at any moment while hardly noticing. The same is true of any large endeavor – it can be regarded just as easily as a succession of narrower and narrower slices, each individually trivial to tackle. This can be helpful for regarding large monolithic tasks – though perhaps less so for those already requiring many discrete steps, since slicing those up into a manifold array of smaller steps may only serve to make the problem more, rather than less, intimidating.

Some flexibility is required. Learning the route must come to be understood as a necessary part of the journey. All those little tasks that break down into littler tasks will have to be found and tagged like endangered animals along the way. This can be a dizzying number of things to keep track of – but, once again, the mere tasks of understanding, cataloging, pondering, and planning that you’ve probably been doing all along the way without even noticing are all a part of this vast progress bar. In many cases the solution to a tricky problem can be reached simply by describing the problem in sufficient detail.

All for one, one for all: Every division contains infinite sub-divisions, every set of contiguous divisions comprises a whole, and the eye is a lens that can choose which of these to perceive at its own leisure. My tendency is to knit together, to combine ideas like Lego, one to the next, until their combined mass becomes too much for me to handle and I get overwhelmed. Others tackle little ideas one-by-one as they arrive, and perhaps find them easier to work with but are never quite sure what it all adds up to. Some dream of forests, some dream of trees, but eventually to understand the landscape around you you will have to learn both.

Everything is conditional. Planning how to proceed is only progress if one subsequently proceeds to proceed; planning a route is only part of the trip if the trip is taken, a journey of a hundred miles only begins with a single step if a hundred miles of subsequent steps are taken afterwards. That’s not strictly true, though: What if somewhere along the way you find a better plan, a better route, a better place to be? You’ll be glad to have taken that journey step-by-step, and to perhaps only need to travel fifty miles after all – which that first step will serve just as well as a basis for and which, if it is in the end unsatisfactory, can itself serve as the first step on a longer journey, piece by piece, half by halved half by halved half-half.

If you enjoyed this essay, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

We’re running out of time, or time is running out on us. I have a problem with boundaries – not with interpersonal boundaries, but with perceiving divisions in a continuum. How do you decide where a river ends and the ocean begins? How can you tell the difference between a minute and a lifetime?

Like many people I sometimes find it helpful to work towards a deadline. This is, I am coming to realize, less about creating a sense of urgency than it is about creating a sense of quantity. When time is limited it is precious, when it is precious it must be budgeted – without any concept of deadline, it becomes impossible to evaluate what’s worth spending time on, what’s worth caring about. At many points in the past, when I found myself confronted by these issues, I would choose defiance against time’s ultimate authority: “It will take however long it takes” I’d declare, with no perception of how long that might be, and once again I’d push it out of mind, pretend once more that I didn’t belong in time’s domain, wasn’t a tenant in its crumbling building.

Defiance is an approach that is frequently more narratively pleasing than it is pragmatic. At some point negotiations have to start – we call this the “bargaining” phase. The costs of doing things “properly” – rather than quickly, effectively, efficiently – begin to become apparent. Wheels that seemed worth reinventing begin to appear actually perfectly satisfactorily circular and, like in figure drawing, the overall impression and the silhouette comes to be more important than the fine details.

Meanwhile, at the other side of the spectrum of respect for time’s power, obsessing over every second, attempting to optimize every moment, quickly becomes a problem as well. The anxiety over time well spent comes to be quite a time-consuming hobby in its own right, and often quite paradoxically it begins to eat away at ones ability to actually utilize these acknowledged precious moments.

I find myself caught between these twin sentinels, always lying, always telling the truth. I have to slow down and hurry up, be recklessly cautious, calculatingly intuitive, minimalistically outrageous. It is small surprise that most large creative projects are collaborative – division of labor is valuable to be sure, but perhaps equally valuable is the division of perspective, of having one person with an eye on the clock, another with an eye on the purse strings, and yet another with an eye on the art itself. That adds up to three eyes, which is more than most folks have readily available. Us lonely solo artists hang in there just as well as we can manage, trying to see from multiple perspectives at once, using every smoke and mirror we can find along the way.

At the end of last month’s update, I mentioned that my entire work schedule was being taken over by starting a game jam project called “Join the Madness”, and that this project’s scope threatened to balloon way out of control. Well, balloon it did, and what was once ambitiously hoped to somehow be a three-week project has become something more like a three-month project – and that’s a pretty ambitious estimate. Making a Metroidvania within the scope of a game jam is a tricky proposal, even if the game jam is relatively lenient on time (as this one was). It’s been done well before, but I have to assume that those developers had more self-restraint than I do, because no sooner did I start on the project than my mind was flooded with ideas for it and I felt compelled to realize them to the best of my ability – an urge that consistently gets me in trouble when it comes to art.

For those who are unfamiliar with the jargon, a ‘Metroidvania’ is a genre of game where the player finds additional abilities as they progress and these abilities allow them to explore progressively more of the world – so, for instance, they might find the ability to swim and be able to explore an otherwise inaccessible water section. Going into the jam, the only seed of an idea I had was that I wanted to work on some sort of fast-paced action-packed platformer, where you had to deal with complicated rooms full of enemies. There was initially no reason to make it a Metroidvania – the reason it became one, though, is because while I love having abilities like double-jump and wall-climb, I also wanted to be able to design challenges around the player not having these abilities. Making the game a Metroidvania isn’t strictly necessary even then: You can give the player abilities without making them tools for exploring a map. However, I have enough affection for the genre that once the idea emerged it was impossible for me to put it back away again – even as I knew it effectively threw any hopes I might have had of finishing the project on schedule directly out the window.

I started thinking about what Join the Madness might be: The premise emerged, that one by one people in an unnamed city keep disappearing – and gradually, so gradually that it takes a while for people to notice, a tower begins to grow from the ground with the faces of the people who disappeared embedded into the walls. It keeps growing in height and circumference, and surrounding buildings get pulled in and absorbed into its mass, and every day more people go to the tower drawn for reasons they don’t understand. The player character wakes up one day certain that they are the one chosen to bring an end to this madness, and set out to the tower to destroy it.

The concept and tone of this are definitely influenced by my recent playthroughs of Bloodborne and a couple of the Skautfold games (themselves clearly influenced by Bloodborne). I find myself strongly drawn to the ideas of surreal cosmic horror, which I have been in one way or another since playing Alone in the Dark and the Silent Hill games. I also found myself very intentionally pulling tonal and design elements from Metroid and the much-maligned second Legend of Zelda game, both game experiences I find very mysterious, abstract, and compelling. Since coming up with the concept I’ve also come up with some more ideas I’d like to tie into that, some characters I’m excited about writing, and some narrative themes that seem to clearly be emerging – but I’ll wait to talk about those until I have more to show.

I don’t remember quite how I ended up with the art style I settled on – I think I was originally just planning on keeping a small color palette, influenced by other pixel art games, most notably Loop Hero – but once I started building a mockup in black-and-white I loved the feel of that so much it became the game’s aesthetic. Currently, everything in-game is one of four colors: Pure white, pure black, pure red, or dark gray. Each of these serves a specific role: White is interactible sections like terrain and enemies, black is background, gray is detail to convey the space, and red is blood – which is thematically tied to healing effects and successful attacks. I initially had a script to dynamically change these colors based on a palette, but a collaborator on the project pointed out that it would make more sense to create a post-processing effect that just swaps the colors out after rendering. Thus, each room in the game can have its own unique palette, and this can even be animated over time. I don’t know what all I’ll end up doing with this, but the possibilities are fascinating. A variant on this idea I’m tossing around in the back of my head is to replace each color with textured pixels, so I could render a background image through them or something, but this is an idle thought for the time being.

One of the most gratifying aspects of the first couple of weeks of development was having an opportunity to really make use of my sprite shaders, which I’d spent the last few months on, in an immediate and practical application. The ability to quickly and easily experiment with different modes of color and lighting was exactly as useful as I’d hoped it would be, and I quickly got some ideas for additional fixes and features – such as the dithered lighting mode, necessary for maintaining the stark art style while having lighting effects. I also found out that I’d overlooked major issues when I started trying to create the first project build, and found out that it had so many shader variants that it would have taken literally days to compile them all – a helpful object lesson in the difference between the shader_feature and multi_compile key-words! I would have been incredibly embarrassed to have released them with that mistake, so in the end I’m glad that I wasn’t able to get around to it.

Speaking of which – I need to figure out when I am going to get around to it. I’m still frantically working on this project as much as I can, and having a very hard time fitting anything else into the schedule, as evidenced by how far behind I was on last week’s essay and this DevBlog. To finish the sprite shaders up I’ll need to review my changes and make them a little bit more robust as well as complete the documentation, which is now out of date in addition to the other edits it required. This is also going to be a rather busy month in other ways as well, since my vaccination is finally completing soon and I’m going to be immediately leaving on a trip to visit friends and family. Most likely I will only get a chance to publish to the asset store around the start of next month, unfortunately.

The biggest obstacle I’ve encountered on this project so far was the map editor I mentioned in passing last month. What seemed like a straightforward problem became a tricky problem – what seemed like a tricky problem became a tangled nightmare. A day’s work became a week’s work, and when the entire project is intended to take less than a month (as it once did, though that seems so long ago now) these kinds of setbacks become incredibly stressful. The reasons it got out of control were, in order: The difficulty of working with Unity’s Tilemap system, the challenges of representing a coordinate grid where y is up with a list of objects where y is down, the additional difficulties of figuring out Unity’s custom EditorTool sytem, and finally eventually just a bunch of normal bugs which I was largely able to solve in a few hours.

It works now, mostly – though when I tried to get screenshots, it kept getting errors, so apparently it still needs some time. Let’s not speak of it again.

Two rooms still technically counts as a map

Rather, let’s talk about the project’s audio. Since I chose this very restrained pseudo-retro visual style, I looked into how I would approach emulating NES-style chiptunes and, to a lesser degree, sound effects. I ended up gravitating towards a similar set of solutions as the Shovel Knight team described: Approximately emulating the NES’s number and variety of sound channels (four channels, one noise channel, one triangle wave channel, and two square wave channels), but occasionally allowing myself to use a channel beyond the original set of four. I was not scrupulous enough to look up what waveform the expanded chipset NES carts actually had access to – I just wrote a piece that needed an extra square wave, and decided not to worry about it. Similarly, I found a somewhat expanded port of the old sound effects creation program SFXR to Unity, which I implemented into the project early on – however, much of the code ended up being unsuitable, so I ended up stripping out pretty much everything except for the core synthesizer logic and replacing it with my own. I may end up stripping that out as well and making my own sound effect synthesizer asset later, but this is a diversion that will surely have to wait until after this project is complete.

Since this was a game jam, I made an open invitation to anyone who was interested in working on the project, and someone took me up on it, offering to do any extra programming work that I could use on the game. I’m not very experienced at working with other team members, particularly from a leadership position, so I definitely feel like I could have done a better job coordinating our efforts: I offered him the UI programming, since it had to be done, was relatively separable from the rest of the game so our efforts wouldn’t interfere with each other’s, and it wasn’t something I had a strong sense of needing to be done a specific way I’d have to communicate to someone else – or so I thought, anyway. I sent a mockup of what the inventory screen might look like, and he ended up implementing that directly as the inventory screen – which unfortunately meant that when I created the final inventory screen art, he ended up having to redo some work. Each asset created, I’d end up needing to rewrite pieces of – not through any fault of his as a developer, but just because the game it needed to interact with was so rapidly in flux that I was the only one who was really in a position to know how it would fit together. It worked out okay, and I’m grateful for his help, but it certainly gives me pause when considering how to work with teams of potentially several people in the future! It is, perhaps, a discrete skill-set I will have to learn.

There’s a lot more to talk about on this project, but I’ll leave it at that for now since most of the rest of it regards design work which is still largely in flux and untested. I’ll probably be talking about it more for next month’s DevBlog! In the meanwhile, I’m hard at work getting everything put together for a viable vertical slice, a full-featured subsection of game, for later this month.

If you’d like to help support this project or my writing, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

An idea which many artists at first rebel against, but are generally forced to accede to, is that of constraints breeding creativity. It can be galling, to one who considers themselves creative, to admit to all the confusion and terror that the white page or blank canvas can bring. All you have to do is make something, right? You’re supposed to be good at this, right?

Well, sure, but when starting form a blank slate you’re effectively doing several creative tasks simultaneously. You’re coming up with an idea, coming to understand how the idea might be expressed, and laying the aesthetic groundwork of that expression all at the same time. Sometimes it works just fine – most of us start by creating this way, after all, before we ever learn better. Eventually, though, when you try to sustain creative production and your vision and your capabilities expand, this starts to become a liability. Eventually, through happenstance, you will likely start a piece with some constraint – topic, format, style, whatever – and, most likely, to concede that this restriction, which seemed would be so burdensome, actually is making this much easier for you. Thus it has become something of a truism that constraint breeds creativity – but it’s worth examining the reason, or reasons, why this might be the case.

Each decision we make is made within a particular context – and, when it comes to art, each element of a work is placed relative to its sibling elements. Thus, figuring out the placement of this first element can be very difficult: You can try to place it carefully, attempting to account for the placement of all future elements, but this quickly becomes overwhelming to account for. Alternatively, you might just place it haphazardly, by whim, and then try to arrange around it later – but this might not work out, since by the time you begin to notice fundamental issues in arrangement it may be too late to fix them. Having a format to adhere to makes this much easier to approach – rather than placing this first element in the void, absent any context, you are instead placing it within a framework, one where its role is explicit and understood, where you don’t need to hold the entire possibility space of what this work might be in order to be able to craft a single piece of it. The form provides a guarantee that, as long as you adhere to its strictures, you’ll end up with something that at least kind of works structurally, and can focus simply on how the pieces fit into that structure.

Much of the time, a similar process happens in the artist’s mind even when they’re working outside of a formal framework. Before first touching ink to paper, the artist conjures to mind a feeling, a style, a direction, a set of founding principles to which they can hold and which will contextualize everything they do, even down to the first element placed, the interruption of the serene white page. Whether they are constrained externally or internally, formally or informally, the artist much choose the shape of their vessel before they begin pouring, lest they like Ikarus become overflown.

However, there are other benefits provided by constraint. Those of us who are tormented by perfectionist tendencies can find great relief in a context where perfection is categorically impossible – I mean, perfection is by definition always impossible, but overtly and undeniably so – where the most that can be striven for is approximation, imitation, and suggestion of the artist’s vision. This is, I believe, much of the enduring appeal of toys like Lego and Minecraft, even among older audiences – they provide the tools to very rapidly build the approximation of an idea, but granulated enough to make any ambitions towards high-detail realistic representation ludicrous. It is unusual for an artistic format to be as restrictive as Lego or Minecraft when it comes to fine detail, but regardless of its hypothetical extents adhering to any creative format will force you to abandon the shining unalloyed vision of your minds eye and begin to make compromises. Things stop being quite as you imagined, and begin to take forms dictated as much by the circumstances as by your whims. This is tremendously freeing – rather than trying to achieve an impossible ideal, you are instead trying to express your ideas imperfectly through a limited medium and skill-set. This was always, of course, the case – but the change of format forces you to admit it, at least for a time, until the mind adjusts and the ego catches up. Also, while it may hurt your pride to realize this, being forced to make these compromises usually tends to make your work better, integrating reality and adding texture and nuance, the sort of process that Bob Ross liked to call “happy accidents”.

Both this externally imposed context and this forced departure from your artistic instincts can be uncomfortable and challenging, but they can also be incredibly fun, forcing you to apply your skills in ways you’d never thought of before – and they will make you a better artist. Eventually, though, all too soon, you’ll be back where you were before, firmly constrained to the bounds of your new personal aesthetic, now grown into the shape of whatever mold you’ve poured it into – and so we must always seek new frontiers, new uncomfortable shapes to bend ourselves into, lest we become locked in place, mere parodic self-portraits.

If you enjoyed this essay, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.

I think a lot about what’s right. Not necessarily what is moral, just, factual, or ethical – though frequently those as well – but what fits, what makes sense, what’s appropriate, what’s useful. I think as much about what I should want as about what I do want, and more about what I must do than what I might do. Everything is a web of dependencies, and if I do the wrong thing it all might come crashing down – or so it feels.

I don’t know if, until recently, I recognized this pattern or identified it as a potential problem – but now that I can see it I see it repeating everywhere. So much of my talent lies in taking an idea, worrying at it and about it, dissecting it, observing it, understanding where it connects to other ideas – all because, if I fail to do so, I will be cursed with a fragment, a failed and incorrect idea. I obsess until I can describe it, how it connects, what that means, what it implies. Some people find this trait of mine very tedious. At times I am one of them. It’s a quixotic and asymptotic quest, anyway: Nothing is ever quite complete, quite correct. There are always gaps, and the better I get at it the bigger those gaps seem.

Now that I’m trying to actually finish projects, the true toll of this quirk is coming into focus. I keep redoing functional work because it’s not correct, tackling over-scoped tools and components because I want to do things the right way, and – sure, sometimes the right way is great, but there’s a reason the army does things the army way instead of the right way. Sometimes the right way is the wrong choice. Correctness is very seductive, though – “if I do things the right way,” I say to myself, “then it will be more reliable, more useful – heck, maybe so useful I could sell it on its own!” To an extent, it can be hard to argue against that: all of these things are at least partially true. Where is that extent, though? If I do this every time I build a tool or a component, I’ll never be able to finish anything, eternally chasing rabbits down holes, quixotic, asymptotic.

There’s a trick to it that I’m trying to learn – to figure out how to aim for the just good enough version to start, and then refine it piecemeal only when I see it again and it no longer seems good enough. I always feel like doing this will mean a lot of wasted effort, since redoing it will always require more raw creation – that is, re-programming a tool will require writing more code than if I did it right the first time, or re-drawing a piece of art will require spilling more digital ink than creating a single satisfactory piece. Not all work is equal, though: If you use a version of a tool that’s somewhere between just good enough and not quite satisfactory for a while, you have a much better idea of what needs to be done to make it actually good – and have a largely functional basis to build that idea off of.

Still, it’s so difficult to walk away from an idea that isn’t yet what it could be. What is the role of an artist if not to realize an idea to the fullest extent that can be imagined? If there’s a future where I have a chance to reevaluate, though, then there’s also a future where I have the opportunity to rethink, rebuild, and make things better. Every step forward is a loss of balance, and every loss of balance is a leap of faith.

When I can stand to, I think about the future. Seldom the future of the world at large – that’s entirely too complicated and distressing right now, although I do try to stay aware of opportunities to do what I can, where I can, to improve things. What I mean, though, is that sometimes, occasionally, I look up from whatever I’ve been working on that day for long enough to wonder where I’m actually going, where my life is leading.

This, too, is a complex and worrying question, such that I’ve generally chosen not to ask it often – or to, when I do, respond to myself with unhelpful platitudes such as “you can only know once you get there” or “opportunities will probably arise as long as you wait and work and pay attention.” I’m certain several of the posts I’ve written here boil down to me telling myself basically that – but, while I still feel like most of the time it’s more useful to focus on the immediate than to stress out about the future, it also tends to result in a certain lack of perspective. I’m relatively happy in life being an isolated weirdo, but as time goes on and I become, if anything, only more isolated and weird, it’s worrying to extrapolate that out towards a weird and isolated future.

Yesterday, I re-watched the Muppet Movie for the first time in a while. This movie has always emotionally resonated with me, but never more so than now: Kermit admitting to himself that he’d let himself believe the dream as inevitable when it seemed like it was about to fail; Gonzo reminiscing on the joy of a facsimile of flight, the closest he’ll ever get to a yearning that’s impossible to physically realize; the songs of seeking for an impossible and undefinable connection, the contact between those who dream out loud, those who sow dreams, and those whose dreams grow from those seeds – these moments are more immediate and poignant to me than ever.

When I’m isolated so much in my own mind – and these days, being obviously isolated in more material ways as well – the promise of a connection made through art, of being a vector through which people can glean entertainment, happiness, and maybe the inspiration to sprout some dreams of their own is one which is deeply compelling to me. It feels at times that such rainbow connections are the only ones left to me, that I’ve constructed a life where more prosaic connections are unavailable and I’m left grabbing at rainbow straws. Much as the starving artist is an archetype which continues to exist despite – or perhaps because of – it being clearly exploitative and hazardous, so too is the emotionally-starved artist. There is a belief that the only artists who deserve respect and regard are those who earn it, who’ve “made it” – the attention economy, like the actual economy, is harsh and tuned to only bestow its bounty on a chosen few – and, in most cases, which few primarily depends on luck, timing, and of course wealth and connections (of the non-rainbow sort).

I don’t know whether or how I’ll really be able to make it work as an independent game developer. I’ve lasted this long at it frankly not due to any real success, but due to an ability to live on a shoestring budget and a small degree of family wealth – enough at very least to not have to worry about being made homeless by unexpected expenses. That’s not really making it work, that’s just not letting it break. These days I’m starting to think a lot more about what an actual life doing this, actually making and finishing and selling things will look like, and it’s not easy to envision – because, one way or another, I have a terribly hard time actually making that connection, putting that work out there, finding other people – whether audiences, clients, or friends.

Nevertheless, I’m still a believer. One day I’ll find it.


Well, I’m done with the sprite shader project – sort of! As you may have noticed, I haven’t announced its release on the Unity Asset Store or, indeed, anywhere. This is because while I did indeed finish the project itself (mostly), I have not yet quite finished all the secondary materials such as tutorials, trailers, documentation, and the store page. All this likely won’t take too long to make, but as soon as the month ticked over to April it all went on the backburner – for reasons I’ll get into in a bit.

First, I addressed a problem that had been sneakily sabotaging me for months – that of normal facing. In case you’re unfamiliar with the terminology, the “normal” is the vector directly perpendicular to a surface – so, for instance, on a perfect sphere every normal on its surface would point directly away from the center. Since sprites typically face the camera directly, their normal would usually be pointed directly at the camera – or, from the camera’s perspective, the vector (0, 0, -1). Of course, it also doesn’t matter much what a standard sprite’s normal is, because it never uses that information for anything – normal information is mostly used in lighting calculations, and standard sprites are unlit.

My sprite shaders, however, are not unlit – one might say they are indeed quite lit. This meant I needed the normal, which is easy to access in the shader – but not, it turns out, in an entirely consistent fashion. All my shaders can do is interpret what a renderer is sending them – and, unfortunately, the way Unity’s built-in 2d renderer types such as SpriteRenderer, SpriteShapeRenderer, ParticleSystemRenderer, and TilemapRenderer choose to do this is not entirely consistent! Some of them cleverly face the normal towards the camera regardless of their orientation – which would be great if it were consistent, but it’s not. Because of this, I need all sorts of special case code to flip normals around if they’re facing in the wrong direction, and all of these require trial and error to determine because Unity’s renderers are basically black boxes. These values are only made more unpredictable once you start including variants for GPU instancing and support for Unity’s other rendering pipelines, all of which can also change how renderers handle normal facing!

I also discovered while testing that my code for expanding the vertices of the sprite to accommodate becomes very unreliable among many circumstances I hadn’t thought to test for. Here, as well, the differences between 2D renderer types become tricky, and when combined with the challenges of GPU instancing and alternate pipelines becomes downright unmanageable. For the above reasons, to cut down on excess complexity while I get the core of the shaders stable, I’ve decided to disable instancing and URP support until after release. This is a little disappointing since I’ve put so much work into getting these working, but it should make for a fast and impressive 1.01 patch a few weeks post-release, and I gather an asset that gets patched frequently is one that is more appealing in the store anyway.

I also realized fairly late on that I’d carelessly only been testing using square or near-square sprites. This was effectively simplifying all of my rotation calculations – and thereby covering up erroneous assumptions I’d made. After realizing my mistake, it took me a couple of days to figure out how to adjust the aspect ratio of the rotation – and, once I did, I also lost several days in a highly characteristic manner, getting sidetracked trying to further improve that rotation code in consistency and efficiency.

The final major improvement I made on the code side came when I realized that I had included several prefab objects using the shaders to help people get started, but that the interface for the sprite settings script didn’t actually handle prefabs well at all. While Unity’s editor is pretty good at handling direct changes to properties, I am using a custom editor to add and remove values to and from a hidden list – that is to say, the displayed values didn’t exist as far as Unity understood, so it had no way to relate them to the values contained in the prefab the object was instantiated from. In order to fix this, I had to recreate much of Unity’s prefab-handling behavior from scratch – something I was annoyed to need to do, but quite proud to find myself readily capable of doing.

It was nearing the end of the month at this point, and there was still much left to be done – and, as I said, much of it is still undone now, a little ways into April. However, while I may not have these tasks done, I did make progress on most of them: The documentation is written and converted to html, ready for uploading but for a few edits for aesthetics and clarity – and having a website ready to upload it to that won’t change its formatting. There are no tutorials made yet, but I have finished the demo museum scene, which shows a comparison of all the different draw modes of the sprite along with six demo effects and brief descriptions of their implementation – since the tutorials will all be on recreating these effects, this actually is a sort of progress on that task. Finally, even though I have yet to even start building the store page or the trailer, these will likely be largely sourced from the documentation and tutorials respectively – so, all in all, I’m not as far away as it may at first seem.

I’m so close to completion! Yet I haven’t worked on the project for a week now, because all of my attention – and I do mean all of my attention – has been taken by game jamming. A year and change ago now I was in a similar situation, participating in the last ever Idle Thumbs community game jam, Wizard Jam 10. Since then, one of the alumni of that illustrious pod has continued to stream on Twitch, and now the community around those streams, of which I am also a part, has started a new annual spiritual successor jam.

This is kind of a perfect storm for me, coming at a time when I feel creatively frustrated, have a new asset I need to test in a live environment, and have a bunch of complicated collision and map logic I need to write for my main project – giving me a much more immediately interesting way to pursue all these things and explore some interesting ideas. The premise of the jam is to base each project on a line from this channel trailer – I’ve chosen “Join us for the madness” and am creating a horror Metroidvania whose scope already threatens to get way out of control. I will obviously write about this project much more for the next DevBlog – for now, I’ll just leave you with a screenshot demoing an effect I’ve already been inspired to add to the sprite shaders: Dithered Lighting.

As I’ve written about extensively for the last few months, I’m currently in the process of creating a tool to go on the Unity Asset Store. Every tool carries within it a set of standards and expectations. Sure, everyone knows what hammers are and what they’re meant to be used for – but a specific hammer, its size and shape and heft, change this meaning and purpose slightly. Even within the subset of hammers meant to drive nails – which is, on reflection, a fairly narrow category of hammer – each has different sizes and shapes, suitable for hammering different sorts of nails even as they remain broadly similar. Each tool carries an implication of purpose that shapes the result of whatever it’s used for, in addition to whatever the properties are that actually make it useful.

As the saying goes, when all you have is a hammer every problem looks like a nail – even though a hammer can be used for many purposes, the form of the hammer communicates that it is meant to be used on nails. This is also true of digital tools – each 3D modeling tool may serve much the same purpose as another, as may each paint program, as may each digital audio workstation. These all might have exactly the same capabilities as their peers – yet also each have a distinct emphasis and style, and each communicates certain expectations of how they ought to be used, which shapes the output users will generate using them.

A common example of this dynamic might be the hard division between the perception of what a game made in the Unreal Engine looks like vs what a game made in Unity looks like: While these engines have, broadly speaking, similar capabilities, the set of default tools and materials and lighting models are significantly different. These different aspects make certain types and approaches to development more (or less) approachable and appealing, thus shaping in aggregate that sorts of games most likely to be developed using them.

This isn’t really noteworthy viewed from the outside – every artist learns that different tools can serve different styles, even as they appear to do more-or-less the same thing in more-or-less the same way. Where this can get a bit strange to think about, though, is when you’re in the position I am now: When you’re building a tool, you are also potentially constraining the possibilities of all art that might one day be made using that tool. My instinct is to keep expanding the tool’s capabilities further and further, to make it able to do anything that one could conceivably require of it, and this is a dangerous instinct for several reasons. First, as I’ve discovered the hard way over the past few months, this can lead to A Lot Of Work: Each new idea for what a tool might do leads to, not only figuring out how it might do that, but the cleanest way to expose that capability to a prospective user, and how to efficiently implement these behaviors internally. Second, if you create a tool that can do anything, it is crucially similar to having no tool at all – there are few obstacles to creativity so formidable as the infinite possibility space of the blank page. Ideally, a tool will be easy to use in simple, obvious, clear-cut ways, but also afford experienced users the ability to quickly and intuitively experiment and iterate on an idea. This is, anyway, the philosophy I’ve pursued in developing my current project.

Creating a tool like this is similar to creating a game – not just an art, but a second-order art, a meta-art, creating an experience for those creating experiences and trying to guide the generated output somewhere interesting and, hopefully, useful. There is a responsibility for the artist, to keep the impact you can have on the world in mind – and, likewise, for those of us who build tools for artists, that weight exists at one layer of remove, to mind the impact we might have on our artists.

If you enjoyed this essay, please consider supporting me on Patreon. Support at any level lets you read new posts one week early and adds your name to the list of supporters on the sidebar.