Art Design

I feel like these monthly devblogs have been getting away from me a bit. From now on I’m going to just nail the date down here and say I’m going to always have these up by the 10th, since that gives me plenty of time to recover from the traditional rent panic and wrap up whatever loose ends I want to have before the post goes up.


I guess the first thing that should be said is immediately after spending last month’s DevBlog complaining about being unable to increase the framerate, I went and did the extremely obvious thing that I mentioned in that post and that,  unsurprisingly, boosted the framerate massively. It’s still not a stable 60 frames a second, but it gets there on some of the more bare-bones levels and is stable above 50 on some of the more complex ones so it’s fine. Of course, I immediately tanked that framerate back down to 30 or so by engaging in a month-long project to add a sweet water effect to the game. In fact, the entirety of the last month has been spent on working on this sweet water effect.

This effect is achieved with a combination of copying and flipping the screen buffer, overlaying a texture on top, applying a displacement map on top of that to warp the image, and then running that through a color matrix filter. I’ve fixed a lot of the slowdown by cutting the draw area down to just the section of screen that needs to be drawn, rather than drawing the whole screen worth of water and then masking the parts I need out, but it could still use some more optimization. I’m a bit frustrated that this effect is taking so long to get working, during which I’m not making ‘content’, but I’m also pretty happy – this water effect is actually something I’ve been thinking about for a long time, and honestly now that I’ve got something in place I can think of a lot of rather interesting applications beyond the obvious. The ripples and displacements might be applied to make grass ripple in the wind, the reflections can be used for other reflective surfaces, and the improvements I’m making to the particle system to allow entities (like the water) to spawn particles for special effects will have limitless applications.

There’s still some work left to be done here. I have the architecture in place to add splashing effects and whatnot as entities enter and exit the water area, but these effects have yet to be tested or implemented. With that major revision done, further work on the water system will probably mostly be in the vein of tweaks and refactoring, which I can do gradually as needed over the life of the project. Some glistening white areas might also be nice, but I’ll probably add that to a wishlist for later. Next, I’ll be focusing on really building out the first few areas of the game and ensuring the first couple enemies function properly. i am, of course, months behind the project planning schedule I had earlier devised, but at this point I’m just trying to maintain morale and make steady progress – I can see about working harder and faster as I gain aptitude with (and slowly improve) my tool set.

In a bit of a weird spot right now. I’ve been working on doing the animations for the first and likely most complex non-boss enemy of the game, and I’m starting to feel a bit depressed about it. Working on a bunch of very simple very similar pictures for a few weeks tends to get old, even if you feel proud of the result. I ran into this same issue working on the main character animations, and now as with then I’m going to have to figure out more kinds of work to mix in because this is starting to undermine my motivation to work on the project. I need to remember never to leave myself on the same animation task for more than a week or so, since it tends to do terrible things to my morale after a little while.

Because these guys aren’t quite symmetrical, but I didn’t want to create left and right facing versions, some interesting properties emerged. The most noticeable of these is where they actually momentarily drop their knife and then catch it in their other hand in the running turn animation, which nicely adds to the frantic and panicked feel of the animation and swaps hands so that when they run the other direction it looks natural. The strap holding up their clothing also quietly changes shoulder, and the light shifts to the other side of them, during the turn. I think these weird fudgings of reality will largely be invisible in action, but it was an interesting problem to figure out as I went, since I hadn’t really considered it before.

I had originally planned to make several different shapes of mask for these guys, but I think that’s something I’m unlikely to do now. To create each mask I’d have to do a bunch of drawings of the mask facing in different directions for the turn, add code to make it draw in front of or behind the head based on where they are in the current animation, and make sure the movement perfectly syncs up. That’s possible, but seems like a lot of work for something that might not look very good. Alternately I could just make a bunch of different animations for different masks, which, again, I don’t think will be worth the effort. That said, there are alternate versions of this enemy with different capabilities, so when I make them I can make their masks look different, which will be more communicative and less labor intensive than what I was planning on doing.

That’s mostly it for the last month, though I also did some miscellaneous work fixing bugs in path-finding, improving the cave tileset and building out the caves. The particle system is basically functional but is still not really an improvement on what I had before I started in any way, remaining extremely buggy when run in multi-threaded mode while still not quite performing as well as I’d hoped – for reasons which, as yet, remain mysterious.

I think for the next week or so I should focus on getting all of the editors working  so that I can spend some time detailing the levels, adding foreground and background elements, generally making them feel finished – or as finished as they’re going to get until I finish making enemies for them.

I like these animations, but they’re not much to show for the better part of a month or work. I don’t know what to think about that: It doesn’t feel like I’ve been slacking. Maybe these guys were just difficult to animate.


I’m doing a terrible job of sticking to the schedule I came up with. I keep getting sidetracked by new tasks, improvements or things I forgot to put on the schedule. This last month, I finally got around to looking up what sorts of multi-threading solutions are available in Haxe/AIR. It turns out that Adobe AIR has supported multi-threading for a while now, with an implementation that is both very straightforward and kind of frustrating. AIR’s version of multi-threading is: Load another AIR program into your running program, and pass values back and forth. Simple enough in concept, but it still has all the traditional concerns of multi-threading with sharing resources and managing access.

So, much of this past month has been taken up with trying to get my particle system, the most demanding discrete subsystem of EverEnding, running in a separate thread. It took a lot of thought and experimentation to figure out a way to restructure a system which had presumed open access to a shared memory pool and make it run remotely with operations mediated by a single point of communication. After a week or two I got it running, but… not especially well. The benefit of the new system is a bump from 45fps to 50fps, which is not as dramatic or life-changing as I’d hoped — plus, for some reason, there are spikes of 30-50ms, which make the overall effect still somewhat disjointed and unpleasant. Still, I think these problems will be fixable, though it may be tricky to figure out exactly how they’re manifesting.

Aside from that I’ve mostly been working on building out the last section of the first area, the caves. I think I’m finally starting to nail down a paradigm of tile design for this game, based around the idea of areas which are lit, areas which are dark, and areas which are somewhere in between. Lit areas are mostly on the upper right and dark areas mostly on the lower left, with various transitional tiles to make them flow smoothly from one to the next. The cave tileset is starting to come together, though certain tiles still need some work. The background could use some improvement as well.


Also, looking back through my daily devblog notes, apparently I worked on collision in February as well. Strange, it feels like much more than a ago now. Well, most of the collision improvements are in place and working, but in the process some things broke, so those will need to be re-fixed. It’s basically guaranteed that any time I work on collision code I’ll end up frustrated.

So what’s next? I’ll probably focus on developing the level architecture and tilesets until I’m completely done with the caves, then go back and focus on populating this first area with enemies and details. Along the way somewhere I’ll spend a few days fixing all the things I broke getting the new particle system implemented and see if I can fix weird glitches there, as well as maybe a bit more collision work (sigh).


A work of art is both a single object and a collection of individual choices – sentences in a novel, assets in a game, instrumental parts in a piece of music, each of these is added and shaped with intent to achieve the overall goal of the piece. This is pretty self-evident, but often is not explicitly thought about by the creator during the creation. In some ways, it’s better not to think about it – for reasons I’ll get into in a moment.

You have the theme or message or whatever of the work: Sometimes you know exactly what this is, sometimes you have to hone in on it carefully in the process of working on the piece. With each new stroke you add to the composition, you can choose to support this theme, to add to its message by echoing it; you can contrast with this theme, to push against it and by so doing ground and emphasize it; or to layer new elements onto the theme, add details that seem completely disconnected but add complexity.

Say you have a picture of a gigantic statue: To support how gigantic this statue is, you could add comparatively tiny human figure to show how it dwarfs the scale of humanity; to contrast, you could add a field of stars behind it or pull the viewpoint back, to show how even the greatest creations of humanity are minuscule in the greater scale of the universe; or you could add something different, a mural or a small scene between characters or some strange creature, to show that the story of this statue and the world it lives in is more complex than we might at first imagine.

Naive artists will, given the choice, always pick the first of these. I have been this kind of naive, and still often discover this kind of naivete in myself. It makes sense: I’m an artist, I know the impression I want to create, I should use everything I have in my toolbox to create the feeling I’m going for. And yet, most of the time, this kind of approach leads to something which feels flat, manipulative, and obvious. All bombast, all sorrow, all silliness, with no leavening by contrasting or diverging emotion, will inevitably feel flat and numbing.

This is why I said it’s probably better that most artists don’t think explicitly about their high-level intent and how to achieve it most of the time: The mindset of trying to achieve a specific emotional impact is difficult to separate from the mindset of how to most effectively bolster that tone in each particular instance. Much better to take freely from the chaos of the mind, to harness opportunities to create threads that flow alongside, flow against, or flow perpendicular to the main thread of the narrative as they occur to us.

However, for those of us who have a hard time not thinking about intent, have a hard time getting out of our heads and have a hard time not hammering the same points home with each individual component of a work, it might be worth it to keep these three thoughts in mind: Support, Contrast, Layer.

A tapestry is not woven out of only threads in parallel.


It’s been kind of a strange month for the project. I’ve made next to no progress on the task list I’ve created for the game, but I’m still largely satisfied with the work I’ve done. That is to say, I’ve been putting a lot of time in on things that it hadn’t previously occurred to me I would need, so I can’t really cross anything off a list when I get it done, but nevertheless the tasks I’ve done needed doing.

So, what are these tasks?

  • Created a system to modify hue/saturation/brightness of animations, and implemented controls for this into existing particle systems and associated editors, as well as creating a similar system for modifying tileset colors
  • Fixed up the detail editor to make it more flexible and easy to use, including the ability to modify multiple details at once
  • Created a seeded random number generator so particle systems that use random numbers will generate consistently from one play to the next
  • Created a simple collision system for particles, which can be used to make them only spawn on top of tiles or perform special behaviors when they collide with tiles
  • Added the ability to have particle behaviors that only trigger once on spawn rather than updating continuously
  • Collision improvements and implementation of water tiles and combination platform/slope tiles
  • Fixed the way perspective is calculated on details to center the vanishing point rather than have it locked to the upper left
  • Stripped out a non-functional zoom in/out system in favor of a much simpler one that actually works

With all these color controls I have a lot more ability to customize areas without creating all-new assets

On top of that I’ve been building levels out, which is on the list but also takes a long time to make progress on. It’s really difficult to say much about the process of building levels, because 90% of it is just spent on making sure tile boundaries line up and making tiny aesthetic tweaks. In that way it’s a lot like working on the animations after I created prototype animations: All of the concept is mostly there, I just need to elevate it to finished quality.

I’m getting close to the end of my ad-hoc list of unexpected and unscheduled problems/improvements, so I ought to be getting back to the game schedule soon. Worst case scenario is I’m a month behind of where I wanted to be: Best case scenario is that I end up making up the time I lost by leveraging some of the improvements I’ve made. We’ll see. In any case, I’m probably going to be spending the coming month or two getting early-game enemies fully animated and operational. The first couple of enemies will be the most difficult by far, I believe – after those are complete I should be able to copy and paste from them for almost everything I’ll ever need an enemy to do.



I’ve been watching old videos of the original The Binding of Isaac, and it’s strange looking back. As many huge improvements as Rebirth, the remake that came out a couple of years after, made to the base game, still it feels like something was lost in translation. Several things, actually…

Maybe it would be best to start with talking about all the reasons people generally regard Rebirth as categorically superior to the original. The first game had notorious framerate issues, many items didn’t work properly with each other, and it was built using technology that made it impossible to expand – many people say it reached the limits of Flash, Adobe’s multimedia tool, but Isaac was actually not just built in Flash, but built using Actionscript 2, the version of Flash’s scripting language that was deprecated in 2007. Since I’m building my own game in Flash (technically AIR, the standalone equivalent), this is a narrative that I feel compelled to correct whenever it comes up. Rebirth could have easily been built in Flash. But I digress: The point being, Rebirth fixes all these issues, so when viewed entirely within the scope of the shortcomings of the original it definitely seems like a superior game.

Looking back though, something seems off with what we have now – and it’s interesting to examine why that is. There are aspects of the design, art, and music that just fail to click in quite the same way.

The least contentious of these is the music. Nearly everyone preferred the music from the original game, composed by Danny Baranowsky, to that in Rebirth, composed by Ridiculon (Matthias Bossi and Jon Evans). The new soundtrack actually does some cool stuff, with music layers that fade in and out based on what’s currently happening in the gameplay – but this actually undermines part of what made Danny B’s score so amazing. With parts fading in and out, it becomes necessary to create a consistent base track for these to play on top of, which makes it impossible to construct an overall narrative flow to the music. Consequentially, Ridiculon’s music is background music in the truest sense, just providing accompaniment to the experience of the game, whereas Danny B’s score actually defines the tone of the game and creates its own narrative high and low points which interplay with the gameplay highs and lows to create a more complex experience. Combined with a generally more melancholy and creepy tone, it makes the overall musical experience of playing Rebirth rather lacking comparatively.

Aesthetically, I have a bone to pick with the game similar to that regarding the defamation of Flash. When they announced that Rebirth was going to have a “16-bit” art style, I thought that was a peculiar choice, but was willing to see what they came up with. What they came up with was, unfortunately, kind of a pathetic excuse – which seems harsh, but I promise I have a reason for saying that.

First, let’s talk about the art in the original. Isaac used vector art, a specialty of Flash: Vector art is a style of rendering that stores images and a set of drawing instructions, a list of lines and colors. This is a powerful tool because these instructions can be easily rotated, scaled, color-shifted, and so forth with no loss of quality, but it pays for this in making detailed art very processor intensive. Rebirth, conversely, uses raster images for its assets: Raster images are what we’re generally used to working with in photoshop and other editors, just a grid of colors which can look realistic at its native resolution but looks notably blocky at lower resolutions. 16-bit games used raster images at a set low resolution to create a crunchy but vibrant look that is still beloved today. However, the entire design of Isaac was based around arbitrarily scaling and coloring assets which, as mentioned, works a lot better with vector images than raster images. However, for whatever reason the Rebirth team didn’t want to work with vector images, so to conceal the shortcomings of scaled, rotated, or otherwise processed raster images they used super low-resolution raster images and called the resulting look “16-bit”.

This is kind of insulting. There’s no coherence to the resolution – even when the pixels align along the grid the objects that own the pixels move with subpixel accuracy, creating a smoothness that’s impossible in a true 16-bit environment, and as game objects scale up or down in accordance with the mechanics they turn into grotesque pixellated bullshit. Also, because they use such low-res assets, there’s no room for detail in any of the enemies: The original enemy designs, though crude, have an expressiveness to their lines that makes them creepier and more compelling. While pixel art has a great deal of expressiveness in its own right, within the context of Rebirth that expressiveness is curtailed by being constantly squashed and stretched, one of the ugliest things you can do to pixel art.


The design issues with the game snuck up on me. In general, the gameplay choices made in Rebirth are very smart, limiting boring and overpowered tactics in favor of more interesting and aggressive ones, expanding the possibility space for encounters by adding lots of new items and enemies and rooms, and generally spicing thing up by adding new interactions. However, something weird started to happen as more and more items were added. I first noticed it with the item “Gimpy”, which is… exactly what it sounds like.


…And this comes to a fairly fine point about what Isaac is and is not. The Binding of Isaac has a lot of kind of gross and shocking content, but all of it is contextualized by the understanding that this is a child’s conception of the world, and all the weird gross things in it are exactly the sorts of weird gross things that kids tend to develop obsessions with – bodily functions, deformities, and so forth. Up until Rebirth, Isaac items tended to fit one of three themes: Everyday objects granted extraordinary significance, religious symbols, or video game references. These make total sense from the perspective of a weird shut-in kid who only knows his toys, the random things he finds, and the creepy religious stories his family tells him. But once you add S&M gear to the mix, it no longer becomes about expressing Isaac’s character, about life in the mind of an isolated and possibly abused child, but just about being weird and gross for the sake of weird and gross. By itself Gimpy is just one item, but it indicates an overall trend away from being expressive and meaningful and towards adding stuff to the game just for the sake of having it there.

In the end, Rebirth’s flaws are covered up by the simple expedient of repetition. Once you play the game for a thousand hours, you don’t care that the music lacks narrative flare, you don’t even hear it any more. Once you play the game for a thousand hours, you don’t notice that everything is in a different resolution – the game just looks the way the game looks, why would it look any different? Once you play the game for a thousand hours, you don’t see a gimp mask, you see a way to restore health in difficult situations. You see the frame rate stable at 60 frames per second, you see the hundreds of weird and interesting item interactions. It may have made total sense to prioritize the things they did in developing the game: In so doing they’ve made a game that people who love Isaac can play for thousands of hours and still enjoy.

However, they’ve also made it so the chill I felt when I first played the game, the genuine sense of visceral discomfort and confusion and striving understanding, are now obscured behind a layer of generic video game.


It’s been a bit of a slow month for work on the EverEnding project for reasons which are largely obvious. About 10 days of the last 30 were taken up with a big holiday trip, under which circumstances I wasn’t really able to find the time and energy to work on the project – and, what’s more, left me tired and inert enough that I didn’t get much done for a while after either. That being said, progress is starting to be made, and certain foundational parts of the game are coming together.

So, to start with: The main character animations for chapter 1 are pretty much all done. I say ‘pretty much’ because I’m confident that as time passes I will notice improvements that need to be made, possibly even new animations that need to be created. However, for the time being that all-important part of the project is complete.

Once I achieved that, I turned my attention towards various outstanding programming tasks that have been on my to-do list for some time. I finally found and fixed a very annoying bug that was causing entities to self-replicate when I saved a level I was editing, which was causing massive slowdown since the entire lighting system was getting duplicated several times over. I found and fixed another bug which was causing the background layer of levels to not match the size of the foreground layer, and also created a player profile system, which should be able to handle saving and loading all the necessary information for game progression alongside all of the player’s controller/keyboard binding information. Somewhere in the midst of all this, I built a bunch of assets for the early areas of the game – mostly pretty simple ones, which makes them excellent test cases for the kinds of improvements I’ll need to make to the details system to get levels looking the way I want them to.


I’m noticing something strange now that I’ve finished the main character animations: Even though I frequently found the work tedious, having something straightforward, relatively brain-dead, and indisputably important to the core of the game to work on was actually incredibly useful. When I was feeling tired or dull or confused it was still totally feasible to get good work done just by focusing on creating animations. That is not to say that animating is easy or stupid work, but I’d already planned out all the animations such that easy and stupid work was mostly the only kind left to do on them to complete them. Now that I don’t have these animation tasks to rely upon, I feel a bit cast adrift on the gigantic task list that is this project.

Oh well, I’m sure I’ll hit a new rhythm soon enough. I think building out the levels may be similarly straightforward and rewarding, though the level editing tools may need a bit of improvement before I can dedicate myself fully to that work. Perhaps those improvements should be my first priority, then, after I get the core game systems I’m currently focused on up and running.