Monthly Archives: February 2016


This week I decided that my game levels needed to have a background layer as well as the normal front tile layer I’ve been using. This solves a couple of problems: First, it lets me add a lot more detail to levels in their early state, giving me enough tools that even without adding any special-case animations or placed graphics I can make a robust and interesting-looking area with just tiles, something that I can build off of as the game progresses. This also gives me the option of making the character collide with the background tiles instead of the foreground tiles, which opens up a bunch of interesting options for presenting different areas in distinctive and novel ways, or even having events in-game trigger a transition between which layer is the active collision layer.

I’ve got the bones of the system in place now, I just need to spend a solid day debugging it – which is no biggy, except for whatever reason fatigue has really been catching up with me this week. I don’t know if this is just a sleep debt I’ve been accruing or if some seasonal changes have been getting me down or I’m just feelin’ sleepy, but for whatever reason I’ve been sleeping later and waking up more tired and generally not motivated to work. Anyway, in short, this has been progressing a bit slowly. Whatever.

Anyway, after this is done I rough out a few tilesets to be background tilesets, which are probably going to just be the same as my rough front tilesets but with darker and less saturated palettes swapped in. Then, once that’s all in place… I guess it’s back to building levels for a while. I think I’m basically going to be bouncing back and forth between building levels out, making tiles for the levels, and making improvements to the level editor for a while until everything feels like it’s approximately what it wants to be, at which point I’ll go back through and add detail, enemies, and scripted events to the levels. Somewhere in that process I’ll start going through these rough tilesets and start adding detail to them as well, so that when I create the final look of the levels there won’t be big fields of uniform green but grass and leaves and such.

AnxEdit progresses as well, albeit slowly. It’s possible now to dynamically change the root directory of an animation easily and quickly and there are now several ways of adding frames to the timeline, either creating blank frames, copying frames, or importing them – the next step being to actually create the import tool that will handle that.

I feel like there’s a hole in the way we discuss soundtracks. We talk about using certain instruments or techniques to evoke certain kinds of emotions and associations without ever talking about the specifics of how we do that and why it works. I can’t tell if there’s some big conversation going on about this I’ve somehow managed to miss or if this is just something that somehow doesn’t get talked about, and a quick google search has turned up nothing, so let’s just get into it and if it turns out this is actually its own field of study with its own terminology then I’ll just have to look like an idiot later.


So we’ve been trying to use music to evoke complex ideas for some time. Symphonic Poems, symphonies created to evoke a given piece of art or poetry through music, stood itself apart from earlier forms of music, which were either meant to accompany the opera or ballet or were meant to be purely musical exercises, not related to evoking any emotion or idea in particular. Of course, once we had film, we found that it was kind of weird and awkward to sit there and watch something in spooky silence, so we started playing music to accompany it, and soon the music also included rough foley effects. This was the precursor to the modern soundtrack, the music that accompanied non-musical action, baked straight into the movie – not singing, not dancing, just a couple having a heartfelt conversation about where their lives are going or a man walking away from an explosion.*

Music, even without lyrics, has symbolism. The most obvious form of this is mimicry: If you want to evoke an icy environment, use crystalline sounding instruments like chimes, or thin windy instruments that sound like the wind through the snows, or abrupt snapping percussion that sounds like ice cracking. The second form of this is onomatopoetic, using sound to evoke an environment or action in a less direct way – this can be difficult to quantify, but the famous Jaws theme is an outstanding example, the slow insistent motion evoking waves and the gradual crescendo to something faster and more insistent evoking something terrifying moving underneath them. The third, and probably actually the most common, is the associative: We associate sexy ladies with saxophone solos because we associate saxophone solos with sexy ladies. Among other things, this frequently provides a handy musical shortcut to communicate what era a flashback or period piece takes place in, though anything past 80 years ago is likely to be interpreted by a modern audience as “I dunno, in ye olde days sometime.”

A curious effect of the last is that, because it’s quite easy to create an association like this, the composer can create her own internal symbolic logic. For instance, Peter and the Wolf gives each character their own musical instruments and theme. Giving a character their own theme or leitmotif is a popular composer’s choice, something that can communicate bits of plot very easily, such as by using variations on a character’s theme during a scene where they appear in disguise. This was actually used often for humorous effect in the comedy series Arrested Development, establishing a short musical sting for a particular character/plot element and then playing it at unexpected moments when that element came up later in discussion (it may have been that part of the reason for this show’s lackluster success were that many of its jokes were too subtle to register as jokes to an audience not paying attention.)

Maybe a big reason this doesn’t get talked about much is that, as with the Arrested Development example, no matter how much the composer thinks about this, no matter how hard they work on it, few in the audience seem to notice the effort. The early areas in Monkey Island 2 have a lovingly crafted adaptive score, where each character has their own variation on the main town theme, with characteristic instrument choices and a bunch of detailed musical transitions, and these are sometimes reprised in later parts of the soundtrack – it’s unlikely we’ll ever see its like again in a game, since it was such a massive effort for a result that almost no one noticed. Inception cleverly used a musical motif, slowed down progressively, to viscerally communicate an idea about how its world operated – a motif since appropriated by other films going for that ‘epic movie feel’ without any appreciation for the original symbolic logic of its use.

Maybe most audience members just don’t give a shit about soundtracks.

The thing is, if soundtracks have meaning, it’s possible for soundtracks to have unfortunate and unintended meanings. I saw the play The Curious Incident of the Dog in the Night-Time, a play about an autistic teenager: The soundtrack seemed very intentional, using arpeggiatic constructs to evoke a sort of mathematics-tinged outlook and loud overwhelming distorted sounds to evoke the idea of being painfully overstimulated. It also had a kind of glitchy aesthetic to it, which struck me as odd. Was this intended to suggest that he was like a computer? Or, worse, a poorly programmed computer, or a malfunctioning one? Well, most likely it’s just that the composer associated these sounds with math and rational thinking, but in that specific context it had some rather unfortunate implications…

To me, anyway. I’m the only one who notices these things, apparently.

*I may be entirely off-base as to the musical history here. As I said, I wasn’t sure what search terms to use to do more research on this stuff.


The bulk of this week was taken up by completely overhauling the game’s tile system. I’ve created a new template for all future tilesets: Because this is standardized, I’ve updated the in-game collision data to match the template, which means that by default everything that matches the template will have collision data matched to it, something that will allow me to build levels much more quickly. This also means that, since the game knows what tile graphics match which collision data, I may be able to create functionality to automatically add variance to which tiles are in use, a quick way to spice up levels and avoid an overly repetitive look. It also means that creating tools to change which tile bank a selected range of tiles use is a possibility, so I can quickly shift an area from, say, grass to dirt. I haven’t quite settled on how these would work in the interface yet, but they’re ideas I’m keeping in mind for the future.


This template also introduces some new tile types. The 1:3 slopes should just work right away, since they’re not really very different from the 1:2 slopes, just with different values. More tricky are the combination platform tiles, which I introduced to handle situations where one-way platforms are attached to slopes, which was a problem with the earlier tiles. These are completely unimplemented as of now: They should be easy in principle, but programming the collision was such a pain in the ass I’m loath to touch it again.

Now that I have this new template, I’m working on building out very rough placeholder tiles. A lot of these are basically just recolored versions of the template – green for grass, brown for dirt, a slightly different brown for wood – but I’m also trying to build a few of the transitional tilesets, which involve a bit more care and style, since the ways that the transitions happen between grass and dirt, or grass and stone, are different enough to be a distinction that’s important to make. I know this because I just tested out the grass/dirt tiles earlier today and realized I’d ignored a bunch of obvious tile types I’d need. Once I get those transitional tiles looking alright, though, I can use them as an aid to planning what I need for the others – and that’s really the idea here, to get enough of these rough tiles in place that I know what to expect when creating more detailed variations, and so that when it comes time to add detail I can just quickly load the game up and see what’s working and what isn’t rather than having to try to build something with tiles only to find out after maybe hours of work that something’s not right.

AnxEdit is also progressing well: I fixed a bunch of bugs, got the addition of new frames to an animation working, and added the ability to playback the animation as I work on it.


We are writing the ghosts that haunt us. We write them out onto the page hoping that they might continue long after we have gone. Someday they will haunt the world, but for now they just haunt us when we close our eyes, and we consider ourselves lucky for it.


To haunt is to become attached to a place. This usage predates the ghostly association. When we create, we’re building a home for the ghosts that animate us, spirits of persons who never existed from worlds that were never born. A little creative exercise or exorcism. It’s that or live with them indefinitely. When we finally get them out of our head, though, usually something else moves in soon after, and the process starts all over again.

When we publish them, something changes, solidifies. They become frozen in time instead of constantly shifting with us, anchored in place instead of sailing on our ship, and we find we start to drift away from the spirit that once animated us. When we come back to visit, or when we speak to someone who met the ghosts we left behind, someone who maybe even loved them, it’s easy to be dismayed at how wrong, how grotesquely naive or superficially knowing that which we once dedicated ourselves to now seems. Also, sometimes, it’s easy to be amazed at how good they are, at how this aspect of self which seemed dull and uninteresting at the time gleams with even a light patina of age and distance.

Even after we sink they carry on, if anyone cares to listen. They keep on speaking, advocating for us, or a frozen state of who we were. Audio logs left for future players, trying to catch them up to a plot that moved on without them.

These ghosts are our terror and our consolation. It’s crushing to have any insight into how things might be other than they are because it casts this world’s flaws in a light that shows detail. But it’s also a way to envision worlds that might be better, or worse, or just stranger, and share that. Our ghosts breed, symbiotic with us, trading ideas and visions for sustenance, and it’s a bargain we gladly make because it’s the only hint of immortality we can find. It’s a pathetic vicarious immortality, perhaps, but we settle for the best immortality we can get.


After a bit more programming work, I’ve finally got the core game to a point where I can spend some quality time actually building content. In this case, I’ve been working on building the first areas of the game.

Actually, before that, a bit more about that programming work. A big obstacle to my work flow at the beginning of the week was that whenever the player entered a level it stopped to generate a navigation map for the enemy AI to use. On a small map that’s no big deal, but especially these early areas tend to be vast mostly-empty expanses of rolling hills and the like, which completely destroy the nav map generation algorithm just due to sheer landmass. Something clearly had to be done. Thus, I created a button specifically for generating nav maps, and made it so any generated nav map will be automatically saved alongside the level.

I also quickly ran into some critical issues with the flood fill algorithm, an extremely helpful tool for building levels quickly, especially in the early stages. First, there was a bug which was causing it to hit an infinite recursion when it hit the edge of the map, which was clearly just a dumb fuckup on my part. However, making the function recursive in the first place was starting to seem unwise — not only do recursive functions give incredibly unhelpful errors which made the debugging of the above problem take about five times as long as it should have, but filling large areas of level seemed to be causing stability issues as well. It was only a few minutes of work to rewrite the code to be non-recursive, and it’s fast and stable now.

So, once I got that done, I started working on the starting areas.

LevelBuilding00 LevelBuilding01

I think my tilesets could use some work. I mean, obviously I’m not planning on using the monochromatic grass and stone tiles here, but I mean more fundamentally – I tried to cram too many different things into one or two tilesets, and now it means that a lot of the tiles I expect to have aren’t there. There’s no smooth stone slopes, just steps. There’s no transition tiles with stone on the inside and grass on the outside. Lots of stuff like that which I expect to be there, which should be there, and probably would be if I’d planned this out better. Therefore, that’s going to be my next step: Planning it out better. Basically, tomorrow I’m going to build a list of all of the tile types I’m going to expect to need and assign each one a number. So grass is bank 1, dirt is bank 2, cut stone is bank 3, rough stone is bank 4, dirt/grass transitions are bank 5, etc. Hopefully I’ll have enough banks to go around – I have 255 set aside, which sounds like a lot but I worry they will go quickly.

That does need to be the immediate next thing I do though, because the sad reality is that any work I do building the levels before then is going to be broken when I end up rearranging all the tiles into new banks. I don’t like wasting work, even though this level building work has been one of the most effortless, fun, and hypnotic tasks I’ve had on this project. Once I know what tiles go in what bank, I can fill them with placeholder tiles so I don’t get bogged down. Once I have the levels sketched out with placeholder tiles and every placeholder tile is firmly in its place, then I can start adding detail, since I’ll actually know what I need.

Aside from the work building levels, AnxEdit is progressing as well. I added working framerate controls and improved the registration point editing to handle multiple frame reg points better.


It is truly extraordinarily ugly, I must admit, and I may have to do something about that, but if it works then that’s my main priority.


What role should frustration have in the player’s experience of a game?

It’s a tricky question. For a while game designers assumed the answer was ‘none’, that frustration was an inherently unpleasant experience with nothing to offer, that it stood opposed to everything that players play games for. This opinion seems to have eroded over the years, as attempts to reduce player frustration ended predictably in tepid, milquetoast game experiences.

This question is made more complex because frustration is such a personal reaction  The game can present the challenges and the unpleasant surprises, but whether the player finds them frustrating is a matter just as much of their personal outlook as it is of the content of the game. Some people get frustrated by even the slight puzzling challenges of a narrative adventure game, while others find the die/restart loop of ultra-hard ‘maso-core’ platformers relaxing. Sometimes these may even be the same people! In fact, being frustrated has as much to do with how hard we think something should be as it does with how hard we think it is. Thus, the unexpected challenge presented by the narrative game feels like an affront, while the repeated deaths of the hard platformer feel like, well, pretty much what the player signed on for when they booted up the game.

One reason why Dark Souls has done well from being difficult is because it’s extraordinarily up-front about being difficult. This has a number of unfortunate side effects, such as its more ignorant or obstreperous players believing that because they’ve beaten a video game they know what real adversity is or putting down players of other games as being somehow lesser gamers – or, conversely, the game’s reputation scaring away potential players who might otherwise be amenable to its patient and minimalistic, if unforgiving, approach to gameplay and storytelling. Demonstrating to people up front what they can expect from your game, what kind and what degree of challenge, is a way of nipping unpleasurable frustration in the bud, of saying beforehand “if you’re having trouble here, it’s because you’re trying to do something hard, not because there’s something wrong with you.” That is, at least, on the first playthrough: After a hiatus, I’m always dismayed when I come back to Dark Souls and find that all of the things I’d remembered being easy have suddenly become difficult again. I was supposed to be good at this, dammit!

Thus, as designers, we can reduce player frustration, not by making everything easy, but by making it clear what is going to be challenging and why. Which answers one question, but leaves another open: Players are still going to be frustrated, even if you make efforts to reduce this, but can frustration be a rewarding experience itself? I would contend so, for the same reason that it’s impossible to completely remove frustration from the gameplay experience: Being frustrated is a big part of life, and learning how to cope with that in a safe environment can be useful and interesting – even, dare I say it, fun. Working past the frustration, finding the calm within the storm, not just solving the problem but addressing the anger that is keeping you from solving the problem, these are moments of epiphany that games can offer.

Conversely, as a player – no, rather, as a person trying to solve a problem – avoiding the expectation of being great at something, avoiding the belief that something should be easy for you, is the best way to avoid frustration. This is, I believe, why humility is a virtue: It lets you approach problems as they are, difficult or easy, without preconceptions as to how hard they should be. Come to that, it’s also why confidence is a virtue, since if you believe something is too difficult for you that is also an obstacle to performing well. Confidence and humility, together, let you tackle a problem as it is, serene in the knowledge that you either will or won’t be able to solve it, and the only meaningful way to find out is to give it an honest try. These two concepts, believing in your ability to handle what’s coming and knowing that there are things that you will find difficult or undoable, are difficult to resolve, but powerful in tandem.



Well I just spent a week getting something I had working before working again. I’m sure this is a common programmer experience but still: Goddammit.

The good news is, I guess, that the code is more elegant and straightforward, rescalable and debuggable. In fact just in the process of testing my changes to make sure they took I found a couple of little bugs I’d missed before. So that’s good! It’s all good, really: Sometimes you just gotta go back and fix some shit, even if it’s tedious.

Anyway. Now that that’s taken care of, finally, I can start doing some level building and I can go back to working on AnxEdit. This is going to be the first real test of my idea of working on parallel projects, and we’ll see how it goes. I’ve been working on being more consistently productive (a white board is involved) and I’m feeling the simultaneous stress and reward of doing so.

Something I’d like to look into more is getting the game starting faster. Right now it takes about 30 seconds to load up on start, which is a lot considering how bare bones it is. I think the main reason for that is that I’m currently loading up separate images for each frame of animation: Even though the amount of data being loaded isn’t massive – less than 30 megs, in fact – I think the fact it’s all individual files is incurring a lot of overhead. I’ll be testing to see what takes up the most resources in terms of load time, but it would really speed up my testing loop if I could get the game starting faster.

It’s a happy coincidence, then, that one of the things that AnxEdit is going to handle is recompiling animations from separate frames into sprite sheets! However, somewhat less happily, as I just realize, I haven’t been planning on any tools for sharing one sprite sheet among multiple animation files. I think this is something I can just take not of when it comes time to create the actual image recompiling tool for AnxEdit, and allow for group recompilation of animations to and from sprite sheets.

Over the next week, then, it’s back to AnxEdit and into level creation. I’d like to build out the terrain for the first area and create a list of image assets for placement in the foreground and background. And, realistically, I’m probably going to end up doing lots of little programming tasks on the main game as well, as I discover little bugs in need of fixing and maybe spend a bit of time figuring out the aforementioned startup woes. Sounds fun, anyway. At least it’s not getting something I programmed a year ago running again.