Art Design

Well, I keep on getting distracted, but the distractions are all part of the project itself. There’s a distinction between the process of making a game and the process of making the game engine, the game editor, the game tools, even though these are a prerequisite – and, clearly, I’m more willing and able to focus on those right now than I am on making the game itself. I think this is okay for the time being: Part of what I wanted to do with project is to let myself go where my enthusiasm guided me to go, and clearly right now that’s in working on the tools. Now, whether that’s just because I’m more intimidated by the idea of working on content stuff, well that’s an open question. Eventually I’m going to run out of tools to work on, so I’m not stressing out about it. Yet.

Anyway. What are these tools he keeps talking about?

Well, first, I’ve got a somewhat working version of the room creator I was talking about last time. I got the solution to the point where it did maybe 80% of what it was supposed to and then tabled it, since I didn’t want to get sidetracked for too long with nothing to show for it.

You can see that some of the logic is there, with it placing the walls and some of the tiles connecting the angles correctly, but there’s a couple of tiles that are incorrect and some that just aren’t getting placed. Part of this is just the order tiles are getting placed in right now: Since each tile has to fit with each other tile, the tiles that get placed first don’t have to meet as many constraints as the ones that get placed last, and often end up being incorrect. Obviously I have to iterate through the placement more than once, but how do I know when I’m done? How do I know which tiles I still need to match with and which are now outdated by the new placements on the second loop? This is probably a problem that’s been solved, so maybe I can look it up. That may be another reason why I set the problem aside – it didn’t seem urgent to solve any more, now that the remaining issues were relatively small and easy to describe. Most of the time, at least when it comes to programming, a sufficiently detailed description of the problem contains a solution.

After getting that sort of working-ish, I focused on creating the entity editor. Once I can build levels and place entities, I basically have everything I need to create a game. However, there’s a huge range in what constitutes a level and what constitutes an entity, and some big decisions need to be made in order to meet those simple requirements. Up front, though, I had a pretty good idea what an entity was supposed to be: I want an entity to be an object with, most of the time, a position, dimensions, and behaviors in the game world. With a bit of shuffling UI around, I came up with this entity editor:

The top bar is a toolbar where I can drop any entity I want to use more than once and save it for later. The top-right is an editing window where I can rewrite any of the entity’s scripts, and the bottom right a selection window that I can use to look at and edit any of the entity’s properties. What is going to be interesting as this progresses, I think, is that any one of the entity’s properties could be a script, could be a script that rewrites another property to be a script, could be a script that copies another entity into a variable which gets used by another script to spawn versions of that entity, and so forth. What I want here is a system that eradicates as many barriers as possible between creating, editing, and scripting entities. To begin with, I used an XML-based scripting language since that saved me a lot of the trouble of parsing the scripts, since I could just use Haxe’s built-in XML parser. However, I’ve decided instead to roll my own scripting language – after some misadventures in using a very full-featured Haxe parser, which I guess we’ll just consider research now, I decided that my needs were simple and specific enough that I should really just make my own.

While I initially considered making a new simple animation system, I decided that too much good work had gone into the EverEnding animation system to discard it completely. However, the rendering paradigm I used for that project was completely incompatible with the standards used in OpenFL – one of the big reasons I wanted to step away from that project for a while, since bringing it up to those standards was a huge logistical pain in the ass. This was, therefore, an excellent opportunity to work on something that could benefit both projects. The necessary approach was so different that, in the end, I had to fork the class, but when it comes time to work on EverEnding again I can work on integrating both versions together in a way that captures the strengths of both. For now, I have a fast and efficient way to render every entity I want to the screen.

Aside from this stuff has been some minor progress in other areas, like making decisions on what the tileset should look like, fixing bugs in the collision code, and making a rough character sprite for use in testing. However, if you’ve been following the project, you might have noticed streams abruptly ceased a couple of weeks ago, which is rather contrary to my original concept of the project as something which I worked on entirely on-stream. Unfortunately, I came to a point where a few aspects of my life and this project came into conflict with one another: As I alluded to in my Problem Machine blog post a couple of weeks ago, I tend to have sleep patterns which could be generously described as ‘erratic’. I’ve been trying out ways to restructure the way I live and work in order to help address this issue, and one of the biggest changes I’ve made is to try to get a few hours of work done immediately after waking up, before taking a shower or eating breakfast or anything. So far I find this approach tremendously beneficial, starting my day off on a good precedent and ensuring that even if later on I do end up feeling fatigued or depressed I still have a few good hours of work done, relieving much of the pressure to do work that was keeping me up later and later at night. Unfortunately, while it’s a bit stressful to stream myself work, and it’s a bit difficult to get used to waking up and working right away, the idea of waking up and streaming working right away is just too much to countenance at the moment. With time, this may be something I can approach – it may be helpful to get away from my conception of streaming as something where I need to have a constant running commentary, for instance. Or maybe I can just eventually get to the point where I’m more comfortable vocalizing my thoughts immediately after waking up. At the moment, though, trying to do two things which aren’t readily in my nature at the same time just felt like too much. Hopefully, in time, the dev streams will return. In the meanwhile I’ll probably continue streaming gameplay a few nights a week, though this past week I have been remiss due to fatigue.

That just about does it for this month’s update. Next, I plan to finish this scripting system, fix the remaining issues in the room generation code, and probably start building out the first few rooms and entities and some more finished looking art. I think by next update we may be able to start getting into actual content, rather than tools – but who knows what rabbit holes I have left to fall down?


The new project is underway. I frequently miss working on EverEnding, and so far I haven’t gotten to do the sorts of things I really came to this project for, but I’m also getting really excited about some of the ideas I have for the future while I lay the necessary groundwork to proceed.

So, what have I been working on? There’s a lot, really. I got the basic collision system up and running, though that part is still glitchy as hell. I’ve created a simple but potentially very flexible scripting system which I’m going to use for all entity behavior in the game, which is going to make modifying entities in the editor largely a matter of literally copying and pasting the behaviors I want between entities and should make saving and loading pretty straightforward. However, the bulk of my time so far has been taking up on developing tiles, tools and editors for using them, and an understanding of how they’re going to be implemented in the game.

This is the tileset I’m testing with right now. It’s pretty ugly and rough around the edges, but right now I’m just trying to figure out a way to make all the tiles that I need for the game world fit into the minimum possible amount of space in a format that makes some degree of visual sense. If you do any art yourself, you may have noticed that the perspective here is, to put it mildly, kind of messed up. I’m working off the model established in the tilesets of the early Legend of Zelda games, particularly Link to the Past. The angles don’t really fit together or make sense, but it still creates a cohesive space for the player to navigate without obscuring anything the player needs to see. In the long run, the Escher-esque nightmare presented by this kind of world design may work in my favor, since I want the world to seem kind of surreal – but more on that later.

The big issue I’m facing at the moment is creating a tool to automatically fit these tiles together. There’s a small immediate and a big future reason I want to do this: The small reason is that figuring this out will allow me to build tools into the level editor that let me really quickly make rooms and connect them in a way that looks natural without having to individually place a bunch of tiles. The big future reason is that eventually I want to be able to generate rooms entirely using code using the same algorithm, and create procedural environments for the player to navigate.

That segues nicely into what my plans are for the project. Actually, none of these are plans yet, these are just ideas for now – plans will mostly wait until I have a playable chunk of game and can begin making hard decisions about what works and what doesn’t, what’s feasible and what isn’t. The setup I want to explore, here, is being trapped in a big creepy house – there are other people here, and it’s a bit up in the air how long they’ve been here. Some of them talk like they’ve been here a few days, some of them seem like they might have been here for centuries. Everything is blocked off in different ways though, bricked and boarded up, papered over, hidden behind secret passageways, and in order to begin to find your way out you need to explore and find tools both to open up passageways and to fight off the creatures that have taken over parts of the house.

That’s the basic idea. Let’s call that tier 1, where I just make a little Zelda clone and call it a day.

Here’s a more interesting version of that idea that I’ve been playing with. There aren’t monsters in the house, but in order to actually make progress you find different beds to rest in. Each bed you rest in puts you into a dream where you play as whoever the bed belonged to, and in reliving their story you can perhaps change it, and by so doing change the state of the house. Or maybe you just find the tool you need in the dream and bring it back directly, or perhaps you are able to recruit an NPC by telling them something they’d forgotten a long time ago. The dreams, of course, are infested with weird nightmare monsters, and you need to be able to defend yourself in the dream, so procuring equipment is still necessary.

That’s tier 2. This would be a much more substantial project, but I think there’s room to do some interesting things here.

I have an even bigger idea, though, and this is one that could get really out of hand. Take tier 2, but each dream world contains other beds, and you can keep pursuing nested dreams deeper. Past one or two levels, dreams begin to be procedurally generated, but the resources you get in each dream can be brought out of them and used to progress through the next. The game becomes an adventure game containing a roguelite, where progressing through the roguelite sub-game allows you to progress naturally through the world of the main game. Eventually, perhaps, getting lost in these many nested dreams could become a genuine danger.

Tier 3 is fun to think about, but for now I have to focus on tier 1 – or, really, tier 0, which is building the toolset that will allow me to build tier 1. That’s where I’m at right now, but if progress continues at this rate I should be able to have my toolset done by the time of the next devblog and can really start building out the most basic version of the game.

Work In Progress

I’ve been trying to stream more. So far I just stream myself playing lots and lots of video games, which is… nice. It’s nice to have a reason to play games, because a lot of the time, without any direct impetus, I will just not do that. I do have concerns about whether this is a good use of my time and energy, whether I’m burning valuable mental and physical resources I could be using on my writing or developing my game. I worry about whether I’m making myself enjoy games less by playing them for an audience or whether it’s pushing me towards a narrower band of games. I think these worries can be adequately combated by the knowledge that if I were not streaming I’d be worried just as much about how I’m not putting myself or my ideas out there enough, not playing enough games to stay abreast of the trends and ideas, and that I was generally shrinking back into silence and isolation.

The grass always looks greenest on whichever side of the fence we have most recently vacated.

Okay then: Say I want to keep doing the streaming thing, but I want to try to channel all this time and energy into something that advances my ambitions of being a Well Known Creative-Type Person. At that point the obvious thing to start doing is to start streaming creative work as well as gameplay. This is eminently logical and also obviously terrifying – or perhaps that’s overstating the case, but it is at least intimidating, for several reasons. One reason is that a huge part of creating something is not having any idea what you’re doing and going down a bunch of dead ends before you begin to catch a hold of what kind of thing you’re actually creating. This can be an uncomfortable process here, at home, by myself, but the thought of exposing that process live on-stream? Oof. On top of that, it’s always deeply frustrating and depressing to me when I put a lot of work into something and share it and it gets absolutely no reaction: Streaming myself working would both amplify the amount of work I’m putting in and give me real-time feedback over how many (or few) people actually are interested and watching. It’s hard to believe that this would be conducive to creating more or better work.

Being okay with sucking at things was a necessary step for me to start actually improving – in particular with art, accepting that most of my drawings would be bad, at least for a while, was the only way I could silence my internal voices long enough to start drawing. Conversely, with music and writing, I think I benefited a bit more from a sort of blissful ignorance in not being able to see as clearly how not-great my early work was… it’s always easy to make yourself feel either good or bad about your work by when comparing yourself to different artists: Just choose whether to view yourself as a big fish or a small fish by calibrating the size of your pond as necessary. It’s easy to be the best writer in your class: It’s hard to be the best writer at your school. Of course, ‘best’ doesn’t mean anything in the first place, but try telling your brain that.

My perception of the inadequacy of my earlier work is a double-edged sword: I can be proud of how far I’ve come, but at the same time it leads to acute worry that I’m actually still incredibly far behind some hypothetical future me. How can I possibly put my work out there when I’m so much worse than I might hypothetically be in the future? How can I share work that isn’t my best work, even if this better work is entirely hypothetical? If I put any of this temporally inferior work out there now I’d only be embarrassing myself.

So, if I want to stream my imperfect creation, I have to not only be okay with sucking, but be okay with sucking publicly. I may suck less frequently now than I used to but every piece of music has a point where it sounds like crap and every portrait has a period of time where it looks like some grotesque misshapen caricature. In the past the main thing that has made me feel okay about these moments is that I was the only one who ever saw them: That’s a tough security blanket to burn.

Along with these doubts other doubts like to surface. I wonder if I’m actually as creative as I think I am, when it feels so much of the time like my work feels so constrained and fuzzy and meandering, when other peoples’ feels so extravagant and full of color and detail and purpose. I doubt whether the things I make are intrinsically interesting to people who are not myself, if there’s a gap between my idea of art and what audiences want to see, whether as I improve my ability to hew closer to my own creative ideals the actual output created by that work will become less interesting and my skill will only alienate me further. I doubt that there will be any place in the world that can accommodate the entirety of what I am or want to be, and I know that other people split themselves up into pieces and find places for parts of themselves bit by bit and I wonder why I find that so difficult.

Being full of doubts and questions is something that I have to resign myself to, the same way I had to resign myself to being bad at art to become better at art. The only way to find my way is to accept that I am lost, because otherwise I will march confidently off in the wrong direction forever, just like almost everyone else seems to end up doing.

I’ve been playing Cuphead. If you’ve somehow managed not to hear about this game, Cuphead is a 2D platformer styled after the cartoons of the 1930’s – although I frankly think it manages to realize that aesthetic far better than most of the source material it pulls from. It’s also punishingly difficult. Cuphead is impressive both how good it is and how much worse it would be if it was any less beautiful than it is – I have never seen a game rely on aesthetic quality to this extent, and it is fascinating to me that it does, and that it does so so effectively.

These aspects, beauty and difficulty, lean on each other like a pair of cards, prop each other up to create an incredible experience. This super-hard game would actually just not work if it wasn’t so incredibly beautiful in every respect, visually and aurally – the losses and restarts, the trial and error, cheap shots and bullet hells, would quickly become tedious. Some people would still enjoy it on those merits, but it certainly wouldn’t have found the huge audience it has now. At the same time, if the beauty was all there was, if there wasn’t this sort of punishing difficulty, the game would feel like fluff, would show up and disappear in an instant and would leave no lasting impression – though, of course, this version of the game, too, would find its own following. However, because the game is so brutal, you’re forced to really look at it, really closely look at everything that’s happening on-screen, lest you be caught off-guard – and, because you’re forced to look at something so damn lovely, it’s hard to actually be mad at what happens next – which is usually that you get your ass kicked by a medusa or a bird or something.

I find that idea, that sheer aesthetic beauty can be a core component of a game’s design, very interesting, because that’s not how we tend to think about the audio-visual component of games. There’s a lot of discussion over exactly how and how much the narrative and the design of games are discrete from each other, but it’s largely taken for granted that the aesthetic quality of the experience can be evaluated more-or-less on its own merits.

When we discuss the cross-section of aesthetic and game design, it’s usually about how the art style of the game realizes the core goals of the game’s design – not about how the game’s design enables the core goals of the game’s aesthetic, or in how the sheer quality of that aesthetic presentation can make the design goals click. Despite being a tremendously conservative game in many ways, Cuphead has thus exposed a huge gap in how we talk about the intersection of visual and mechanical design in games – or, at least, a huge gap in the way I’ve seen people talk about them – as, rather than a gaming experience enabled by an aesthetic layer, being an aesthetic experience enabled by a gaming layer. It’s an inversion of the way we usually think about what a game is.

I am curious to see what sort of impact this game has, a few years down the line – on video games in general, but also on the way I think about games. It’s strange to me how a game so straightforward could contain such revelatory implications.

It hasn’t been an especially productive month for the project, but things are grinding forward. I decided I was still dissatisfied with the performance, even after all the improvements I made to the particle system a year or so ago, and so I’m working on getting the project running in OpenFL, an open-source project that emulates Flash/AIR’s API but builds in C++ and tends to be faster. This isn’t really a smooth process, since there are a few Flash features that didn’t get ported and the ways file i/o and multi-threading are approached are very different. The file system stuff is no big deal, and I believe I’ve fixed the issues emerging from that already, though since I’m still working on the other stuff I haven’t been able to build the game to test those fixes yet. The multi-threading thing is more difficult but I think I’ve got a handle on it now, and the challenging part is mostly sequestering my Flash multi-threading code away so that I can write the special cases that change from platform to platform without turning everything into a total spaghetti mess. The features that aren’t supported… might be an issue. The only one I’ve found so far that looks like a big deal is that OpenFL currently has no equivalent of the DisplacementMapFilter, the processing effect which I used to make that water effect I was so proud of and which I also would like to use for a few other special effects. I’m going to have to look into creating a replacement – which sucks, but might end up being a blessing in disguise, since this will be a fairly natural way to explore the wide worlds of shader programming and, indeed, of contributing to open source projects if my solution ends up being of sufficient quality to submit as an OpenFL component.

Aside from this, I mostly worked on building the behaviors for the Feral enemy type which I shared a few sprites for last week. These behaviors are mostly finished now, but haven’t been tested yet since I didn’t have a complete set of sprites to test with – not strictly necessary, but since most of the code is reused from existing enemy types I’m not worried about any major malfunctions. I also realized a substantial obstacle towards completing the first area of the game was that I just wasn’t really sure what the space was supposed to look like. I had some vague ideas, but I didn’t know what the area’s history was supposed to be, what really was going on there now, or what the symbolism of it was. I spent a bit of time writing out some notes on it, and I’m confident that when I get the game working again and return to develop this area I’ll have a lot to work with.

My work is basically cut out for me now. Get the game building in OpenFL, handle any new bugs, rewrite the display code as necessary to take advantage of the improved performance. It’s always a bit of a drag getting railroaded into one big task that has to be done before I can make more substantial progress, but in this case there’s no way around it – particular as, in the interim, something weird has happened with my development environment to make launching the AIR version seemingly impossible. While I’m sure that will all get ironed out eventually, in the meanwhile it leaves me no avenue to working on the AIR version of the game, so really all I can do is drill in on the OpenFL port. Soon, at least, I’ll be able to take advantage of this tedious chore to tackle a field of programming I’ve been wanting to study for a while: Shaders.


Well this is probably going to be a short one, since for 20 of the 30 days since the last DevBlog I’ve been busy with writing and for the other 10 I’ve been trying to catch up with all the other stuff I didn’t get done while I was doing all that writing. The two avenues I’ve made progress on are in developing the Feral enemy type and in improving the camera system.

I posted the concept art for the Feral a little while back, and I’ve since been poking and prodding at getting some sprites done for it to add to the game.

I’m not thrilled with these at this point: The look of them is good, but the animation still feels extremely stiff for the most part. I’m having difficulty with handling the sorts of subtle motions I want this creature to make when it’s not being aggressive, and making them read on a fairly low-res sprite. I ended up tabling that work when I returned to the project since, as I’ve discussed in the past, I tend to find animation frequently turns into a demoralizing slog for me. So, to get myself back into the project and to build up a bit of momentum, I’ve gone back to programming work.

After a few days, I have most of what I think should be a functioning behavior set for the Feral, but I haven’t tested it yet – mostly, honestly, I just wanted to get the code to build so I could work on other parts of the project for a bit. Still, it means I’ll probably be able to get the Feral up and running in fairly short order, and that hopefully will increase my enthusiasm for creating and polishing the necessary animations.

More recently (ie just now) I’ve been working on the camera system. I went back and read a rather interesting Gamasutra article that exhaustively explored the different approaches to 2d camera systems and, while doing so, revised mine. In fact, I revised my camera system several times over, trying out different ways to move the camera or to determine where I was moving the camera to. I’ve mostly settled on a system where it offsets the camera based on the character’s facing enough to see what’s ahead and moves the camera faster based on how far it is from it’s desired position (without modeling acceleration), but there are a few instances where the camera jumps around in a rather unappealing way left to be dealt with.

I’m still getting used to working on the project again, and of course there’s holidays coming up to be a distraction, but spending a little while away from EverEnding has given me enough perspective to know that it’s not force of habit, or some inane belief that just finishing this one thing will make me rich, or certainty that it will somehow change the world, or some other bad reason that keeps me working on this game. I still love the version of it I have built in my mind, and I still want to try as hard as possible to bring that vision to fruition, and especially to see what it slowly shapes itself into along the way.


Way back when I started this blog, one of the first essays I did was about conceiving of a game as the combination of three related spaces – physical, mechanical, and narrative – and gameplay as the act of allowing the player to explore these spaces. I think this perspective is still useful, though sorely in need of revision now, five years later (I’ll likely return to it at some point in the future). However, whenever I think about how different games emphasize one or the other of these attributes, whenever I try to draw a hard line between where one space begins or ends, I run into a bit of difficulty making that division. The mechanical and narrative spaces are fairly easy to delineate – one is the actions you can take in an environment and how that environment reacts to those actions, the other is the story that is told about those actions and the context in which they take place. However, the physical space, which one would expect to be the most intuitive of the three, is a bit more difficult to delineate – and I think it has to do with how we create physical space in games.

The problem I keep running into is that the physical space of the games is actually created by means of mechanical and narrative elements. The mechanical aspect of the space is your ability to move around on some parts of it and to have your movement blocked by others, and the narrative aspect is the colors and textures and what they suggest about the world you’re in. Together they create something that feels like a chunk of physical world to explore, but there’s nothing actually physical there. A sense of physical space is created, but it is not separable from the mechanical and narrative elements that contribute to it – not in the same way that the mechanical and narrative elements are separable from each other.

It may be extremely obvious that the physical reality of the game world doesn’t exist, but it’s suggestive that we create the illusion of a physical reality through recreating the parts of reality which interest us most as humans. That is, when we encounter an object, our concerns are a) what can I do with this? And b) what does it mean that this is here? This, of course, has very little to do with the actual material world, where objects are made of many different bits and pieces, covered with bits and pieces of everything else, subjected to forces we have an incomplete understanding of. What’s noteworthy is not that we are simulating a reality, but that we are simulating outwards in, out from the superficial aspects we find ourselves most interested in, down into the more fundamental aspects such as mass and warmth only as we find those necessary to power the superficial simulation.

Tangentially, I am now quite certain that if we had any way to simulate texture and taste in games we would have done so long ago, as these are also superficial aspects of great interest to human perception.

It’s fascinating that we so many of us consider what we’re doing to be realistic. What we do with games is render exclusively that which can be seen: every 3d object is an empty shell, every character who is modeled is simply their exterior with nothing inside, and interior parts only created as they become necessary to render when they are ripped apart from the exterior (a common scenario in games). We see what a human, or a house, or a rock, looks like, and reproduce what we see, when that is inherently only the most superficial possible version of that thing.

Something from physical reality is translated into signals for our brain, is stored as a symbol representing that object; then our brain conducts our body to create an object that can reproduce those signals in another brain. That is what we call art – or, at least, representational art.

So, with games, we started from the simplest version of the most superficial reality, and from there we’ve managed to make more detailed and convincing forms of that representation. Perhaps we could simulate a reality based more on what we know to be there than what we see to be there? Even a primitive simulation of a more complete reality could lead to new and interesting artistic pursuits. Or, perhaps, since we are unmoored from the physical basis of reality, we could create a simulated world far wilder and stranger than we can while paying lip service to material reality.

Mostly, though, I just find it amusing how much we like to act like we’ve come anywhere near a reality simulation when our approach is in essence purely superficial. How very human of us.