Monthly Archives: November 2015


I have gotten very very little done over the last couple of weeks.

I don’t feel super guilty about it or anything, because I’ve actually been pretty busy, first with a road trip to visit family and then with Thanksgiving itself, which also involved visiting family, as well as feasting myself into a coma, as is traditional. Any spare time I’ve had has mostly been filled with resting up or fulfilling obligations which have accumulated in the meanwhile, leaving me very little time and energy to work on the game.

Oh well.

Anyway, I got the spear-throwing entity mostly working: The main part that doesn’t work yet is the angle of the spear itself, the problem of which actually sent me down a real rabbit hole of code design that inspired yesterday’s post, since it meant I needed to completely rethink some aspects of my animation system’s design. In particular, I’ve had to think a great deal about how rotation works within the context of a series of bitmap frames: What point does the image get rotated around? What’s most intuitive? What’s most useful? Will the decision I make here make it impossible to do something important with this tool in the future?

What I ended up deciding, as alluded to in my last post, was to keep things as obvious as possible. That means that, as is traditional, the bitmaps are drawn starting from the upper right corner, and all rotations start from there: By going in and changing the frame offset to center the bitmap, it can rotate from the center point, and by shifting it to the bottom center I can rotate it around that point, et cetera. I’d originally made it so rotating it just rotated the bitmap around its center, but that means that the individual frames, if they have different offsets, don’t rotate around the same reference point and quickly become misaligned. This was an instance of what I was writing about, of skipping to ease-of-use while disregarding the importance of clarity in the basic interface.

So, what I’m going to have now is an animation system that’s a bit more of a pain in the ass when it comes to certain common tasks, but with complete transparency so I know exactly what I need to do to make it work. The drawback to this is that I now need to go in and update all of my animations to deal with this more straightforward approach, which is becoming a common enough task that I think it’s really becoming time for me to create a tool specifically for editing animations. I think over the next week, if I can get my lazy ass to work, I’ll be splitting my time between developing such a tool and starting in on building some playable areas of the game, since I’m getting really tired of the kind of fiddly work it takes to get these entities working.

Over the past few days, I’ve been thinking about my animation system. I’ll get into the decisions made regarding that tomorrow, but I want to get into the process I used for making those decisions, and what it means to design something to be used. Usability is important for this animation system, along with essentially all the programming I’m doing on my game: Since I’m the one who’s going to be stuck using it, I want to be sure I get it right.

So, what makes a given tool useful?

Well, first and most obviously, it has to Do The Thing. What The Thing ends up being can actually be difficult to determine: Usually it starts off pretty small – for instance, showing a sequence of images with a set timing between them and then either looping or stopping upon reaching the end of the sequence – but often it ends up growing to encompass other related tasks – such as scaling and rotating those images, offsetting them in relation to each other, or synchronizing sound playback information to them. Whatever it is, though, it has to work, consistently, reliably. If it doesn’t work it has to not work for obvious and clearly understood reasons.

Which brings me to the next layer of usefulness: It has to be possible to tell it how to Do The Thing in unambiguous terms. Every control the user touches should have an obvious and intuitive connection to its functionality in the tool, which means using the most obvious and literal labels, means not anticipating your user’s needs and taking extra steps without notifying them, means keeping the external representation of what’s happening as close as possible to whatever’s happening internally. In other words, the KISS principle, “Keep It Simple, Stupid”.

Just as the first layer, has to be in place before you can create the second, that second layer, a clear and unambiguous interface, has to be firmly in place before you can make the tool easier to use. All of those ideas about automating the most common uses of your tool? They go in now. Essentially, now that your tool can Do The Thing, and the user can tell the tool to Do The Thing, you can create meta-tools that the user can tell to tell the tool to Do The Thing(s). If you want to, say, automatically create a templated document, that’s something you can do once and only once the first two layers are in place – though it still has to be clear to the user how the automated system is doing what it’s doing and what that means in relation to the second layer interface. It’s probably most helpful to communicate this as an external meta-tool helping them get going rather than something innately a part of the main tool, so that they understand that there’s nothing being done by the automated process they couldn’t do themselves – the metaphor of a configuration ‘wizard’ is a very clever one in this regard, communicating that it’s just a useful process asking what they want in plain language, rather than being the only way to access the desired functionality.Now all of this may seem obvious, or like an overly complex way of describing something simple, but I’m using this approach in order to describe something that I’ve seen go wrong with a lot of software design: It seems like a lot of developers like to try to skip over that second layer completely, disabling the user’s ability to tell the tool to Do The Thing, in favor of more ‘powerful’, but abstract, third-layer tools. However, that’s building on quicksand, asking a user to try to control something which they have no real idea what it’s doing. Sometimes, even worse, developers prioritize the third layer over even the first – so you end up with a tool that can’t even Do The Thing properly and, what’s more, because there’s no connection between the first and third layer you can’t even tell why The Thing isn’t getting Done.The purpose of tools is to be used, and anyone qualified to use the tools should be able to do so without any special meta-tools. These features, wizards and helpers and auto-fills and second-guessers and context-sensitives and so forth, are to introduce the unexperienced user and to expedite the experienced user, not to conceal the actual functionality of the tool. Don’t make your tool useless by making it presume to know what its use will be.

Some people make art like glass, venting their heat against the earth until it gives way, melts and fuses, and giving it shape through the circumstances of wind and breath that brought it into being.

Some people make art like a diamond. The tension in their chest and throat just gets greater and greater until the dust in them compresses into something hard, perfect, shining, and full of facets.

Some people make art like a pearl. They take a fragment that hurt them a long time ago and coat it bit by bit until it becomes something beautiful, soft, precious, but not forgetting the sharp edges that once made it cut

I guess I’ve been all of those to one degree or another. Mostly, nowadays, I find myself making art like a bad tooth: It hurts coming out, but not as bad as it did when it was in, and after I just leave it there on my pillow and hope that somewhere out there there’s someone willing to pay for it.


Well I was supposed to put up a devblog yesterday, and through a unique cocktail of procrastination and forgetfulness I didn’t get around to that. So here it is a day late.

Part of the reason is I wanted to get something more done before I posted anything. This has been a week of nibbles, little bits of work, of popping open my IDE and solving one small problem and then deciding fuck it I’m done. Partially this is good old fashioned laziness, a genuine desire to just fuck off and play video games or read or whatever instead of working on the game. Partially, as well, it’s because the programming that needed to be done to get this enemy type up and running was a bit logistically complex – problems that weren’t difficult per se, but that needed me to decide exactly how I wanted to handle them in the way least likely to break something or make something I want to do later more difficult.

I got all that stuff done, just not much else. I did take a little side trip and modify a function I created a while back to cyclically automate changing numbers a whole lot more powerful: I wanted to use it to create a constant rotation for certain thrown projectiles, but the way it was coded it only supported automating the values in different variations on a sine wave. I went ahead and replaced the sine wave with an arbitrary wave form, so that, for instance, I can have the rotation go from 0 to 360 degrees and then reset using a saw wave motion.

So at this point I have all the code and animations to make the entity work in place: What’s left is to test them and make sure they actually work. Then I start in on, uh, one of the things I mentioned having to do next last week.

Also, this week I’m going to be going on a trip — it remains to be seen whether those long train rides will let me get some productive work in on the game or whether the overall hubbub and distraction of travel will destroy my creative output, but, um, it will be something different for sure.


This is a horror story.

I missed my chance. It was Halloween a couple of weeks ago. But, you know, this isn’t the right kind of horror story for Halloween. Halloween is a time for the not-quite-scary, the weird and surreal and unimaginable, the watered down horror that is the fear of the unknown. That stuff is great, but it’s not scary. Monsters are physical by nature, creatures with beating hearts and blood, and can be fought the same way as anything else. Ghosts can’t be fought, but are inherently reassuring: Is it so bad getting murdered by a ghost, really, given that the existence of the ghost is evidence of an afterlife? It’s kind of flattering, really, a ghost trying to kill you. Kind of an invitation on a ghost-date.

This is the story of the last lie you ever tell yourself.

“This is safe. Someone would have done something about it if it weren’t.”

The truth is, the structures we live in are rotting away, moment by moment, in real time. The difference between a home and a ruin can be subtle. Sometimes people live for years in a house before they find out it wasn’t safe, before the banister breaks or the floorboards give way, before the picket white fence splinters into wooden stakes and tetanus nails. We don’t notice. Our homes stay familiar to us, platonically unchanging, even as their hearts rot.

It probably won’t be your home, but it could be anything. Anything could be unsafe, so everything is unsafe. Do you really want to lean on that railing? Are you confident in those stairs? How about that bridge?

Yeah. We like to talk about fear of the unknown a lot, but it’s the fear of the everyday, the tedious, the prosaically awful deaths that lie around every corner that we don’t talk about. This fear is too much to think about. When a mine fire starts under a town, we take every opportunity to ignore the problem, pretending it will fix itself, until the town dies. We let our bridges and freeways decay, fall apart, borrowing the convenience of today against the disaster of tomorrow. We let corporations ignore safety regulations and call it ‘disruption’, call it good for the economy. We bury our fear, ignore our fear: The fear that literally any object in the world, with a slight shift in circumstances, could be fate’s murder weapon. The perfect crime: Gravity, with the loose brick, on the way to the bus stop.

This is so horrifying we create a kind of taboo around speaking about it, particularly the young: We deem it ‘uncool’. It’s uncool to be concerned about whether you know how to get out: The cool kids burn alive, screams exhale smoke, hands pushing against solid wall trying to find a way through. It’s uncool to use a seat-belt, the cool kids are ejected from their vehicle and have their bones scraped away to bloody fragmentary paste against the intersection asphalt. It’s uncool to–

Yes I know, I sound like a caricature of a grouchy safety instructor. The thing is, I can envision each of these tiny tragedies in detail, feel the breeze of them as I pass them by, premonitions of a fate that lies in potentiality. I am cautious by nature – not least because I am a large person, and therefore the chances of something collapsing under my weight are higher, and the force of my fall will be more damaging. At thirty-two-feet-per-second-squared, every pound of force becomes that much greater an impact.

The scariest thing to me about an old haunted house isn’t the haunt, it’s the house.

There’s actually a horror movie about this, sort of. Final Destination frames the horror of accidental death as the act of the malicious spirit of Death personified. The trick is, Death always gives a warning, some little clue that something is about to go bad – a premonition, a creak of aging wood, a breath of cold air. Whether by sportsmanship or by supernatural contract, Death provides advance notice of his arrival. And, in this, Final Destination pulls its punches. It codifies into law our reassurances, our guarantees against our fear that we will be safe: “It won’t happen to me.” we say, “I’m careful. I’ll notice there’s something wrong. I’ll notice the cracks, the dust, I’ll hear the creaks, the pops, I’ll be ready to move, I won’t panic.”

And that’s the last lie you ever tell yourself.


Spent this week just going through the animations for the mask entity and changing them to be holding a spear instead of a knife. Very boring work, but necessary if I’m going to make the alternate spear version. Fortunately this is pretty much the only version that’s exactly the same but with a different weapon, so this tedium ends here. I think there’s just one or two left to do, then I create the actual animation files and implement them in game, then I actually implement the attack. I can probably get all the animations in today and program the attack tomorrow, which will wrap up this alternate, giving me three versions of the enemy: Basic, spear, and rock thrower.

After that, I have a few options: I could work on the next version of the entity, which is going to be an animal rider, fairly simple in terms of programming but an interesting animation challenge since I haven’t animated a quadruped before – I could go back and work on the player character animations, going in and nailing working out all the alternate versions, setting registration points, creating a death/failure animation, and generally preparing to create final frames – or I could start in on a whole new enemy type, spend a bit of time designing its looks and behavioral patterns, see what code I can adapt from the mask entity towards this other one.

Dunno! Looks like I have a couple of days to think about it while I work on this other stuff anyway, so no big rush.


The problem with dialogue system components in RPGs tends to be that they’re components in RPGs.

I’ve been playing Fallout: New Vegas: This game, like the earlier Fallout games, is premised on making important dialogue choices which can have a big impact on how the rest of the game plays out – the name Fallout, itself, being a double entendre for the aftermath of a nuclear war and the aftermath of a difficult choice.

As with all Fallout games, you have stats which govern how skilled a speaker and negotiator your character is, and these govern what you can and can’t say in dialogue trees. Unlike earlier iterations, you can see in the dialogue menu which skill is being tested by choosing a particular dialogue option, along with whether or not it will succeed ahead of time. Together with the fact that you always get an experience bonus for passing a skill check in dialogue, this has a couple of unfortunate effects:

First, the dialogue option for a failed skill check will almost never be triggered by any players. Even if the dialogue choice for a failed skill check seems reasonable to the player, and even if the consequences of it are more interesting, no one will ever select that choice if they can possibly avoid it. This kills an entire alternate dialogue branch for each skill check, and allows the player to game the system in strange ways, like spotting an option that’s too demanding, leaving, killing a few monsters to level up, and coming back with an improved speech stat.

Second, the player will always choose a choice that uses a skill check. Not only are these usually guaranteed to solve the problem at hand, they also give a small experience bonus for passing the skill check. This discourages the player from choosing the option that seems best to them in favor of choosing the option the game tells them is best, removing an opportunity to make an interesting choice by essentially making the choice for them.

Now, the problem isn’t that certain dialogue choices are rewarded and others aren’t: The idea of choosing to do something because it will create an advantage for the player, potentially at the cost of screwing over another character, is integral to the idea of Fallout. The problem is that some of these rewards are part of the narrative universe of the game and others are not: I feel like a heel extorting extra money out of someone who I’ve done work for, but I feel like an idiot for passing up the free exp I can get by passing a check of my barter skill.

A similar problem came up in the Mass Effect series. In the first game, you can increase your ‘paragon’ and ‘renegade’ skills – essentially good cop and bad cop dialogue choices – the same way you’d level any other skill in the game. This means that, if the player wants to, they can max both of them out, opening up all possible dialogue options and allowing the player full rein to choose whichever they prefer. However, in later games you only get paragon/renegade points by choosing the associated dialogue options, which creates a good cop/bad cop feedback loop. Thus, if you want to be able to choose the goodest good cop actions or the baddest bad cop actions, one or the other of which will be necessary in order to achieve optimal outcomes in later scenarios, you have to ignore your own moral compass or role-playing desires and always choose to be the badass or the softy.

These systems were all made with the best of intentions, and there were other good reasons, in terms of streamlined design and player feedback, to make these decisions – however, when carelessly implemented, they end up undermining the greater design goal of naturalistic and compelling player choice.


Spent the first couple of days this week working on the character design. Once I got the idea down I stopped work on the picture, so it’s still kind of sketchy – which, with the digital painting style I was using, mostly means blurry and not very well defined. Maybe I’ll finish the picture up sometime and make it nice enough to show off, but for now it’s served its purpose of helping me figure out what the character looks like.


I decided that the clothes were distracting and made the character seem less, rather than more, supernatural, as well as more artificial. I eventually settled on a pretty normal human face because everything weirder I tried just ended up looking kind of goofy, and replaced the glowy eyes I had before with stone eyes, which reinforces the idea of a living statue made out of natural materials, which is in a rough sense what she’s supposed to be. In the end, I feel like I have a character who looks decidedly more than human without being showoffy – something I tend to find tedious, when people just try to communicate power through lots of glowy lights and oversized gear and whatnot.

Anyway, with the design finished, even if the painting of the design wasn’t, I went back and revisited what I was working on before, the spear-throwing version of the entity. I mostly just worked on the attack animation, which I actually really enjoyed since it’s an interesting movement that turned out pretty well. I really wanted to sell the power and impact of this attack, since it’s going to be a one-shot attack that leaves the enemy as the basic knife-wielding version after: I need something very obvious and telegraphed, but that moves fast and hits hard, and I think that this animation will work, albeit possibly with a bit of timing tweaking.


So probably what’s up for this week is doing the other animations for the spear version of the enemy, which are mostly just the normal walk/run/turn animations but holding a spear instead of a knife, then trying to get the enemy implemented in-game – the actual behavioral part should be easy, just the basic version of the enemy with a few more lines about when and how to use the spear attack, but creating the spear attack itself will actually take a bit longer, since it’s the first projectile I’ve made that needs to orient the animated object along the path it’s moving. There will probably be many more like that in the game, though, so it’ll pay to do it right.

I think I also want to do a thorough breakdown of what needs to be done for me to finish the first chapter of the game. It doesn’t necessarily need to be in-depth – I can figure out what specific entity animations I’ll need when I get to each entity – but a list of what areas need to be created as maps, what area assets need to be created, what entities need to be finished, what coding needs to be done, etcetera.  I want a road map so I can really get a sense of how close or far I am, and come to the project each day with a sense of direction rather than figuring out what I’m doing anew every few days. Maybe even something I can put up on my wall so I don’t forget about it.