Category Archives: Games

Animating on uneven surfaces

One of the looming technical challenges in Sun Shy is getting a character to look right as they run and jump around. For most of our game’s development, our character has looked like this:

We’ve known for a while what we want our characters to look like – the player character of Sun Shy is to be a long-legged satyr-looking biped creature. Here’s some very old concept art from Halley that gives a bit of the vibe:

As a programmer with no artistic skills, I consider artists to be wizards of some kind, so I feel a lot of trust has been placed in me when I’m trying to recreate something like the above feel with code. There are various stylistic choices that can be made to make this kind of thing easier – give your characters short legs and take very fast, short steps, for instance, or giving them feet with no legs (like Rayman). These are/were all certainly options, but thanks to the support of Creative Victoria I have time to try doing it the hard way.

This post is a long one, and I don’t even really get to the bottom of it here. I’m sure I’ll be talking about animation-related things again in the future.

A note about game design philosophy

One part of this process is something we consider non-negotiable – visuals are in service to gameplay, not the other way around. We tuned the player controls so that they feel right before we started thinking about animation, and if it turns out that the way the player controls is impossible to animate without it looking goofy, we’re going to have a goofy-looking game and that’s just the way it is. At no point will we allow any of the systems mentioned in this blog post feed values back into player movement. This is mostly a game design thing – if the player wants their character to do something, but the character can’t do it because their feet aren’t in the right place, and the positioning of their feet is controlled not by the player but by our animation code, that’s not fair to the player. Also, what feels right and what looks right aren’t necessarily the same, and given the kind of game we’re making, the first one wins. I’m not trying to impose this rule on all game developers everywhere, and there have been some pretty notable games that go the other way (the movement in the old Prince of Persia games was animation-driven and worked pretty well, for instance), but it’s how we’re doing Sun Shy, and probably how all Snake Hill games will be done in future.

There’s also a technical reason for this. The systems described below can be expensive, and we want to be able to turn them down or off if necessary. Not just in a ‘turn down the graphics settings’ kind of way – if there are a hundred entities walking around, and only three of them are on screen, we want to only do the complex footfall calculations for the three that are visible, and we don’t want that change to affect movement. It also means in networked situations, the client can do their own local footfall calculations rather than needing to sync it over the network.

Inverse kinematics and foot placement

There are two parts to this problem – where to put the feet at any given time, and having done that, how to draw the leg. The second problem is solved with something called Inverse Kinematics, often abbreviated to IK. Today I’m just going to be talking about foot placement, because the IK part of this took place outside the Creative Victoria research. It does have a few interesting things to be said about it, though, especially because the creatures we’re animating here have two knees per leg – I’ll be writing a blog post about this later on.

A straightforward attempt at foot placement

The first attempt we made to have feet get placed coherently was vaguely inspired by David Rosen’s GDC talk about procedural animation in Overgrowth. (I say vaguely, because they’re really not terribly similar, and I don’t want to implicate David in the fact that this technique didn’t work for us.) Our plan was essentially to create an ellipse, roughly where the player’s feet should be, and move two feet around that ellipse. We would then do a ray cast straight from the player’s hip to the current foot location, and if it hit something, place the foot there.

This method was initially quite promising. The foot isn’t really planted, so this system doesn’t guarantee a lack of foot skate, but if you base the rotation rate of the ellipse on the horizontal velocity of the character you can make it look pretty convincing. It even looked pretty good while the player was airborne without any further work – they’d kind of flail around in the air, but while it looked a bit comical, it was okay, and mostly not broken.

Endearing, but kind of dodgy. Any initial promise this showed didn’t really materialise when we tried to polish it, though.

The problem proved to be the ‘mostly’. The last 10% of quality here was elusive – sometimes foot skate reared its head, so we made a system to actually lock the feet to world space when they hit something, then lerp them back to the ellipse when they stopped hitting something. That ended up having feet sometimes get located weirdly up on ledges when the player was running towards a step and then stopped at the last minute. We also needed to do some raycasts to determine where the centre of the foot ellipse should be, and then some smoothing of those values so it wouldn’t pop when the player walked over a ledge.

Ultimately the system became incomprehensible. I ended up with variable names like footGroundedHeightSmoothedFudgeMultiplier, and trying to fix a given problem involved way too much trial and error. Worse, fixing one problem would often break something else. In other words, all the problems that usually come up with badly written code. This is what inspired the next attempt – a system that, whether or not it works, might at least make sense to me rather than being a bunch of hacks hanging together in strange equilibrium.

The Analytical Approach

So, what’s the opposite of the above ‘make something up and hope it looks kind of good’ approach? Simulate everything! You can probably guess from the number of subheadings that this is the approach that eventually worked, or at least currently shows the most promise. Mentally, I broke this part of the task up into three sections:

  • When a given foot should start a step (timing)
  • Where that foot should be stepping to (foot placement)
  • How it’s going to get there (stride shape)

I won’t be going through these in turn, because it’s not the order I actually solved things in the end.

Stride shape

The shape a footstep takes is probably the least analytical part of the process. Basically, it’s a spline – the foot moves along it. Formally, it’s a cubic Bézier spline – the same things that you draw with in vector art programs. This isn’t even remotely based on a physical system. This kind of spline has four control points – the first and last will be the location the foot is coming from and the location the foot is targeting, and the second and third will determine the shape it follows to get there. So far we have adjusted this basically by eye, and it’s been okay, but it’s a future target for tweaking to make things look nicer after other parts of the rendering (such as bringing in actual skinned character meshes) have been polished.

Using splines here has a few major advantages. Splines are very predictable – we can decide exactly how long we’re going to take to traverse the spline, and then ensure that it happens, by simply ticking our T value appropriately. This means we can look ahead and say “We need this foot to be at this location exactly this many frames in the future”, and it will definitely happen. Somewhat more complicatedly, it also allows for retargeting of a step – we can get the parametric form of a spline and take its derivative to get its velocity at any point. This means that if the player is half way through a step and they need to put their foot somewhere else instead, we can create a new spline from the current position to the new target without any discontinuities in velocity or position (which looks unnatural)

Foot Placement

This turned out to be one of the biggest, trickiest parts, but it also has some of the most actionable advice for anyone out there attempting a similar system. That advice is: Prediction is king.

Our initial plan involved predicting where the player would be by using simple dead reckoning – that is, we just take the character’s position and velocity, and if we want to know where they’ll be in n seconds, we assume it will be currentPosition + currentVelocity * n. This will be accurate assuming our velocity stays constant

Because we’re using splines for our stride shape, we can dictate exactly how long a given stride is going to take – so when a foot determines that it needs to initiate a step, we know exactly how far in the future it’s going to land. So we simply predict where we’re going to be at that time, and do some raytraces down from there to find an appropriate target for the foot to plant. This is going to be great.

Turns out, it isn’t great, because dead reckoning sucks. Behold:

Essentially, any time our character would have a path that wasn’t totally linear, such as running over a bump, the system might fail badly. Any time it happened to initiate a foot step while on the upward step of a bump, it would say to itself “Well, where am I going to be when this foot needs to land… IN THE SKY APPARENTLY” and then start flailing as though it had just run off a cliff (I regret that I didn’t save any gifs from this period, and I’m too lazy to go back through version control history for them, but it was mostly less hilarious and more just broken-looking).

Biting the prediction bullet

It became apparent that we were going to have to do this properly. We were going to have to simulate ahead of time where our player’s character is going.

At this point, I realised there wasn’t anything in between the half-arsed ‘project velocity forward’ method, and a complete ‘predict by simulating the player’s movement for a little while into the future’ solution, so that’s what needed to happen. This seems like it would be straightforward – or rather, it seems like something your engine would do for you, so you wouldn’t have to worry about it. Unfortunately, that’s probably not true.

The reason it’s not always true is that physics engines don’t always let you say “Hey, this one single rigid body, could you simulate it in isolation for a few seconds, then throw all that information away and go back to the current frame”. For instance, I believe Unity has a function Physics.Simulate() that allows you to look ahead, but you can only do this for the entire world, not a single object. I believe Box2D could be persuaded to do something similar, but I think this would only be acceptable for a relatively simple game (in terms of physical complexity) – Sun Shy can easily have dozens or hundreds of rigid bodies present, and thousands of pieces of static collision geometry, so I don’t think this would be very feasible.

This leaves us with the not-terribly-fun option of recreating a simplified version of our own physics engine so we can run our own look-ahead simulation each frame. Remember that this doesn’t have to be perfect – and indeed, it can’t be because the look-ahead can’t know what the player will input. In our case, we have to reproduce simple physics, as well as the scripted game entity behaviour described above (the circle cast down and the foot spring and all that). Simple physics is done something like this:

position += velocity * deltaTime;

velocity += force * deltaTime / mass;

The force comes from gravity and whatever controller forces we have cooked up. Proper physics people call the above technique ‘Euler integration’, aka the least accurate kind of integration, but for our purposes it’s acceptable.

We also have to attempt to reproduce collision response. This is a bit hairy, but bear in mind that we can still use our physics engine’s collision query, we just can’t simulate – so we can check if a collision will occur in the future, and just cancel the velocity in the direction of the collision normal by using vector projection. This isn’t perfectly identical to what the physics would do for collision response, but in practice it turned out to be okay.

It turned out to be invaluable for tweaking this mini-simulation to draw the line of predicted positions, as well as kind of reverse-breadcrumbs every ten frames or so to show where the player is predicted to be at frame 10, 20, etc. In theory, if you get things perfect, the circles should be stationary except when something unexpected happens (like the player jumps or changes input direction).

Note that the blue bits of the line correspond to the points in the prediction when the player’s ‘foot’ is touching the ground, and the red parts are parts when the player is predicted to be airborne. This turns out to be helpful later on.

Also, note that this prediction isn’t cached in some fancy way – we’re calculating about sixty frames into the future, then throwing it away and redoing it, every frame.

Footfall placement for ‘free’

Now that we’re basically running a mini local version of the player update step to predict the player position, it turns out we get something else of value here. Our player update step involves circle casts downwards to look for a base of support – so in addition to our array of future positions, we can record an array of future support locations. We can use these as potential places to put our character’s feet! Even better, these positions have the following advantages:

  • Already calculated
  • Definitely correspond to where the player is standing and has a sensible place to put their feet – it won’t report a footfall location at the bottom of a narrow gap or something like that.
  • Tends to favour high or upward-facing surfaces, as feet usually would.
  • Comes complete with surface normals, so we can look for more suitable options based on surface orientation.

Visualised, here’s what our footfall predictions end up looking like:

Not actually for free, though

Not so surprisingly, there’s a little bit more work to do here.

Look at that last gif. If we took the next two yellow circles as the timing for our next steps, and the corresponding furry yellow normals as the place to place the foot, we’d be in reasonably good shape, right? But look closely. Unfortunately, this isn’t possible – and worse, it’s impossible for a somewhat unfixable reason. The yellow circles happen at evenly spaced intervals in the future, and sometimes, those intervals happen when they player is airborne. Sometimes we’re properly airborne – like, we’ve run off a cliff or jumped or something – but other times, it’s just a slight hiccup in the shape of the ground we’re running across, so there’s nowhere to place your foot for a bit. So, what do we do?

The way I’ve gone here is to take the yellow circles as a place to start searching in our prediction array. Searching back from that point suggests taking a short step – like how you might take a shuffling step or two if you’re running up to an edge you have to jump off, just so you have your strong foot land just on the edge. Searching forward in the array corresponds to delaying the step. This is more ‘dangerous’ because if we delay a step too long, it can look unrealistic – anyone can take arbitrarily short steps, but as steps get longer they start to look physically impossible. Ultimately I ended up searching backwards about five frames and forwards up to about eight, but these values will vary wildly for different implementations.

I did a lot of experimenting here to get things to look right, and if I tried to recount every detail I’d never finish this article. However, there are two pieces of information I came away with that I can share to save some time for anyone attempting something similar:

  • If you have to shorten or lengthen one step, you shouldn’t have that affect the timing of the steps after it. It seems logical to do this (ie the next step happens three frames early, so subsequent steps will all happen three frames early to keep the timing right), and not doing it will mean a short step tends to get followed by a long step. I think that’s just how bipeds work. I’m no animator, so I can’t fully justify this, but delaying subsequent steps when you take a long step just made things look off to me, in a way that was immediately fixed when I removed that feature.
  • When you’re searching for an ‘ideal’ foot placement, it can be good to have a scoring system, where you award a footstep candidate ‘points’ for things. The system I used awarded points for being close to the ideal timing (the yellow circle), for the normal was facing more upwards, and for being physically higher up. This effectively caused footfalls to favour the tops of rocks and other obstacles. If you character runs up and down smooth slopes, though, you might want to de-emphasise the favouring of high ground.

With that all put together, here’s a visualisation of the strides themselves. The actual control points can be kind of made up. There are a few tweaks I gave mine, the subject of another post perhaps, but it’s mostly just taking a pre-built roughly square shape and shearing/scaling it to fit the vector from the foot origin to the foot target.

So now, we can add actual foot steps! This is where our previously mentioned inverse kinematics setup can finally show itself.

Suddenly it looks like a creature! This was the first time I really thought this might be doable, and I can’t fully describe what a relief that was.

Getting airborne

This is, for a nice change, relatively straightforward. When the player is in flight, I simply positioned their feet on the outside of a circle below their centre of mass, with the angle determined by their direction of velocity. We then squash the circle to make it an ellipse, and that’s it! The maths looks like this:

And the results look like this:

We want to scale and cap the magnitude of the velocity here so that our feet don’t end up in crazy locations when the player is falling very fast, too. There are lots of things that require you to basically mess with numbers ‘to taste’ when you’re doing what is effectively procedural art, and this is one of them.

This brings us to the next logical step, which is transitioning between running and being airborne (and vice versa). This is roughly the current stage of my research. By predicting future footfalls, we can actually get most of the way there fairly easily – detecting being airborne is simply a matter of noticing when the system can’t find any appropriate foot placements for a given foot. If that happens, I simply interpolate from the current foot position to the elliptical airborne foot positions, as described above. In the other direction, as soon as the system does detect a foot placement again, that means we’re about to land, so we start stepping towards that point. So long as we set up our stride spline so its initial velocity matches our character’s flight velocity, the transition is smooth – again, more on that in a different post.

So that brings us to the current ‘state of the art’, as it were – our best bipedal character, running a little obstacle course I put together. Note that this entire animation is the result of just running to the left – we’re not jumping or anything here.

My personal verdict? I think this is getting there. It’s not perfect, but for situations that are basically describable as ‘running along flat-ish ground and occasionally going over a drop off’, I think it’s pretty solid. At this point, while there are a few features still to add, I’m going to come back to tweaking after we have character models in and I can get a good look at a more final version to judge what needs to be done.

Lies, Damn Lies, and Tech Demos

It pays to be careful of articles like this. If you’ve ever had the experience of trying to implement a game-related algorithm based on a whitepaper or similar thing, you’ve probably had the experience of learning that actually there are huge, gaping flaws in the technique that the author conveniently neglected to mention. Even as someone who plays games and follows early press for games with cool new tech in them, you’ve probably felt that sting of noticing that things were a little on the optimistic side when they were presented at E3 (or whatever). With that in mind, there are a few things I should mention about the above techniques.

This isn’t a perfectly complete guide

I’m not confident that many people really read all the way through this kind of blog post, and I’m even less confident that anyone is going to sit down and actually implement this from start to finish. But if I’m wrong about this, and that enthusiastic person is you, be aware: Putting this technique in your game will be an adventure. This post is already way too long, and I’m not a good enough writer to fully elucidate every little detail that went into this experimentation without writing a lot more (which I hopefully eventually will). Getting this right – or at least, as right as it currently is – has been one of the more challenging pieces of development in Sun Shy so far, and I can’t really recommending attempting it if you’re not up for a bit of experimentation.

The algorithm isn’t perfectly complete yet either

There are a few situations that this doesn’t yet handle, which I’ve kind of glossed over. Our character doesn’t handle disappearing or moving foot supports yet (if, for instance, they dig out from under their own feet). Our character sometimes looks a bit weird when they turn around and change direction. We haven’t handled jumping yet. We sometimes get some weird leg shenanigans when the character lands from a high jump, or runs up a steep slope.

I’m about 80% confident that, when all is said and done, and we have a much more tweaked version of this, it will look good about 98% of the time. That last gif is an honest one – that’s how it looks when it runs situations that it has already been designed to handle, and I think it looks pretty good – when we have real character art, I think it will be pretty sweet. However, I don’t want to pretend that the algorithm never does something that looks a bit weird, nor am I certain that all those situations can be stamped out by the final release. I’ll definitely be posting more about this as I keep working on it.

Coming up next…

These last four posts have been so tightly packed because I’m terrible about procrastinating about blogging, and these represent the bulk of the research worth writing about for (my part of) the Creative Victoria project. So the next post probably won’t come in the next couple of days, but I do intend for there to be another one.

I still haven’t talked about how three-section inverse kinematics works, and I glossed over a lot of the details of using splines for stride shape – especially the bits about deciding the shape, and calculating exact velocities to get continuous motion on the feet when you have to interrupt a step. I also didn’t really talk about retargeting steps, because figuring out how to get that to look good is an ongoing process – it’s definitely necessary, though, because the best motion-prediction algorithm still can’t always guess when the player is going to change direction. I’m also going to have to talk a bit about standing still, changing direction, and eventually, dealing with situations like fighting or taking damage. So, file this under ‘ongoing research’. But it’s been a lot of fun to work on, and I’m mostly optimistic about the tasks ahead.

Classifying Sun Shy’s Environments, Part 2

The last post was about classifying areas inside caves as rooms, where the joins between the rooms were, and where we might spawn game features such as loot, boss fights, or NPC dwellings and the like. All our examples were based on an abstract shape, though, which was rather smooth. Notably, unlike any surfaces in Sun Shy. However, this is not a problem limited to Sun Shy – any game world with a grid of any kind, including oldschool 2D games with bitmap-based destructible terrain (like Worms), can potentially suffer from this problem.

A quick recap. Have a look at this image:

This is roughly what a ‘flat’ piece of ground looks like in Sun Shy. Because of the irregular grid, this is as flat as it gets. This is an area that we might hope to identify as flat ground, that a player might walk across. They certainly can walk across it – the control system described here allows it – but let’s look at the naïvely calculated normals:

These normals are all over the place – occasionally one points straight up, but lots of them are pointing in weird directions. We need a way of smoothing them out, to get the broad sense of the direction of the surface.

In the case of Sun Shy, it makes sense to look at the ‘normals’ for the tiles, rather than the boundaries between the tiles (for most purposes, the tiles are the things that have information attached to them, so this is useful for navigation markup and the like). If it sounds like nonsense to have a normal associated with a tile centre, that’s because mathematically it is – but, let’s go with it for now.

Here’s a zoomed in section of the above Voronoi tessellation.

We’re going to calculate the ‘normal’ for the tile right there in the middle. We’re going to do it by looking at the centre point of every neighbouring tile that has dirt in it, here noted in red:

We then calculate the average position of those neighbours, and draw a line from that average position, through the centre of our main tile. That’s our tile normal!

As we can see here, this is a pretty good result – if we apply the same approach to all the empty tiles here that are next to filled tiles, we see things are looking pretty good:

Looking pretty good, but not perfect. After all, this is as flat a surface as the tile grid can possibly provide – we should be able to recognise it as such, in spite of some inevitable lumps. To solve this, I’ve simply averaged the normals of every tile with its direct neighbours. Instead of drawing another version of the above diagram, I’ll show this in action in Sun Shy.

Seen here with blue lines representing the initially calculated normals. I know the colour makes this hard to see – you can get a higher resolution version by opening the image in a new tab.
Seen here with red lines representing the smoothed normals.

Although we’re never going to get the normals uniformly pointing straight up, here, I think they’re looking pretty good – those red lines pointing upwards come close enough to representing what I would intuitively call the direction of the walls/floor/ceiling.

From here, it should be pretty straightforward to grab adjacent tiles with a sufficiently upward-pointing normal to define a floor area, which gets us the rest of the way we need to classifying the rooms from the previous post as walkable or not.

What about games that aren’t Sun Shy?

Indeed, the big point of this work has been to find techniques that can be applied outside of Sun Shy, and this post has mostly been specific to Sun Shy’s irregular grid set up, which pretty much nobody every uses. This technique actually has some value in unexpected places, though.

If you’re making a square grid game, you’re not going to have any trouble identifying floors or ceilings or walls – those directions can be represented on a square grid perfectly. However, sometimes you want to recognise other patterns, especially if your tiles are very small – for instance, the size of a single pixel. Let’s say you’re making a worms-style game – tiles get dug out by explosions, and when that happens you simply have a big 2D array of booleans that has a circular chunk cut out of it, like this:

Naturally, detecting collisions with this is no problem – you take a position, look up to see if that ‘pixel’ is black, if it is, that’s a collision. Easy! But what if you want one of your weapons to be, say, a laser cannon that reflects off what it hits. (A better example is probably a grenade that bounces around, but I don’t have the parabola drawing skills for that.) So you want it to do something like this:

How do we do that? Clearly, we need a surface normal, but the actual ‘geometry’ only has vertical and horizontal edges. That’s where (a modified version of) the above algorithm can save us. What we need is to take a box of pixels around the pixel we’ve collided with. Within that box, we’re going to obtain the average location of all the black pixels, and the average location of all the white pixels. Then, we simply draw a vector from the average black pixel position to the average white pixel position, normalise it, and that’s our surface normal.

It should be noted that if you’re looking for anything mathematically correct, you probably shouldn’t be using a grid of bools for your collision system. But if you just want things to look reasonably decent, this system works quite well. The bigger the box you use to average the pixels, the more broad patterns this will pick up on, and the more finer detail will get lost. It’s also possible to precompute the normals of a shape like this, and only update areas that get affected – this could speed things up a lot if you’re doing a large number of collision checks every frame (for instance, if you have lots of particles that are bouncing around in the environment).

Note that you do need to check for a broken case here – if you have, for instance, a collision grid that is organised like a checkerboard for some reason, and your box is an odd number of pixels wide/high, this technique will cause a divide by zero error when you try to normalise the vector at the end. There are other situations where this could conceivably happen, but only cases where there’s no good value for the normal anyway. Even so, if it somehow comes up, better to have some weird normal calculated than throwing an exception or crashing.

Next time…

The last big piece of research I carried out was about getting a character to animate convincingly on irregular surfaces. This one got complicated. I’ll be writing a bunch more about that soon.

Classifying Sun Shy’s Environments

A big part of making a procedural environment is coming up with the shape of the world. There are lots of ways of doing this, from using Perlin noise to make a mountain range to simulating plate tectonics for continents and island chains. This article is about the step that comes after that.

Say you use a fairly well-trodden algorithm to generate a cave system – there are lots of articles around for using Perlin noise as a basis for this – and now you have a cool area to explore. If you’re making a game about exploring a completely inorganic and empty cave system, that’s all you need. But, what if you want there to be a bit more life in these caves? What if you want there to be creatures building homes in them, or big spacious areas with monsters in them guarding treasure?

We could approach this from two directions – we could build the cave for the event, or we could build the event for the cave. Because we want to adapt to both procedural and player-created environments, we have chosen the latter approach. In other words, we’re creating the environment, then looking for places where a monster might want to build a home.

Of Tiles and Flood Fills

A theme that will recur a bit here is that of flood filling. This is usually thought of as a tool in a paint program – you get out the paint can tool and click somewhere, and that area gets filled with the selected colour. Specifically, ‘area’ here is defined as “everywhere you can reach from the originally clicked pixel, without stepping outside the originally clicked pixel’s colour”. I won’t spend much time talking about how this works – I assume most people are familiar.

So, suppose we have a world of tiles, every tile either blocked (with dirt or stone or whatever) or open (empty). We might want to find, for instance, areas that are completely unreachable to each other – ‘rooms’ of connected open tiles, that have no path between them and other such rooms. Hopefully, you can imagine that this is doable with a flood fill – if I gave you a bitmap that looks liked this:

With not too much time faffing about in a paint program, you could classify different rooms like this:

Now that we have that classification, what can we do with it? Well as it stands, not a great deal – it’s nice to know that the orange room and the green room can’t touch each other, I suppose. But there’s nothing here to tell us that that big orange room is actually kind of a couple of distinct areas – meanwhile the light blue and the orange room, if you could just dig a little hole there, could be joined.

Of Distance Fields and Dijkstra’s

A good thing to know about if you’re a game developer is Dijsktra’s algorithm. It’s conceptually related to the idea of flood fills, and in some cases it’s just a slower version of A* search, but it let’s you do something kind of cool. Instead of finding a path from a point to a point, it lets you find the optimal path from every point to a point. This can be handy if you have, say, a horde of enemies all chasing a single player. It does this by creating a sort of expanding frontier, starting from a given point, and as it grows outwards it records the shortest path from the starting point to every point it reaches. However, there’s no reason it has to start from a point – you can always start Dijkstra’s from multiple points, to generate (for instance) a map of shortest paths to the nearest health pickup spawn point, or whatever. Seriously, it has a lot of potential uses – if you’re a game developer, I recommend having a good look at the wikipedia page for it if you’re unfamiliar.

In this case, we’re going to use this mutated version of Dijkstra’s to find a map that contains the shortest distance to a blocked tile, for every open tile. It will look something like this:

Now we’re getting somewhere. Since these examples are based on a random noise image, rather than actual screenshots from Sun Shy, it’s a bit less tile-based than the real situation. But, you can see here that the darkest grey areas are open tiles that are close to walls, etc. It turns out that this has a name, so instead of referring to this as a weird mutated Dijkstra’s search, we can call it a Grassfire transform, which sounds cooler anyway. As an aside, this is kind of related to the field of algorithms called Skeletonisation algorithms, and while that’s not exactly what we’re doing here, makes for interesting reading relating to procedural generation in general.

Room size and open spaces

Let’s have another look at that coloured diagram from above:

If we were looking for a a place to spawn an epic boss battle, what is the right place? We’re going to need a lot of space. A reasonable first thought would be to classify the rooms by area – simply counting up the pixels. Unfortunately, this method kind of sucks. I haven’t actually counted the pixels, but if we look at the above image, it looks to me like the orange room is the biggest one, and maybe it’s a good place for a boss fight but it isn’t enormously spacious at any point. The bluey-purple room in the top left has quite a few pixels, but is very skinny and has no high ceilings. The pink room is not huge, but it’s round and you could fit a larger thing in there. In general, the point here is that a long skinny area can have a lot of tiles in it, but it doesn’t really have a lot of room. A big monster can’t stand up in there, there’s not space to fly around, etc.

Now, let’s take another look at the grassfired version of the caves:

Now, we have a simple method of finding big open spaces – look for specks of white. Long skinny rooms end up mostly dark grey, because they’re not appropriate for boss fights (or whatever). The bigger our space requirements, the more iterations of our algorithm we can go through to ‘grow’ out from the walls.

Door ways and digging sites

Often, games need to be able to classify areas as discrete rooms. For instance, management games like Rimworld sometimes have to divide areas into rooms for things like whether a rotting corpse in the corridor should contribute to someone’s bad mood amount their bedroom decorations. Happily, these things are doable using the simple flood fill approach described above – simply count doors as walls for purposes of blocking the flood, and you’re good to go. However, when it comes to classifying places where creatures might like to build things, this doesn’t help us. We need to decide where to put the doors, rather than reacting to where the player puts them. So, what we’re going to do is the same old flood fill classification approach, but we’re only going to flood areas that are above a certain level of whiteness – that is, our flood fill won’t just be stopped by blocked tiles, it will also be blocked by tiles that are open but very dark. We get something like this:

We can see that most of the rooms are still considered a single room according to this approach, but the spindly formerly-purple room in the top left has been split into three small rooms, and the huge orange room is now considered two. Naturally, we could tweak the threshold of wall proximity (effectively, changing the grey darkness threshold for the flood fill to be blocked by) if we wanted to count bigger or smaller openings as doors.

Finally, we can re-flood from these colours, now getting all the open spaces. So long as we do all these flood fills in parallel, the distinct rooms’ colours will butt up against each other, showing us the place where a door should go:

A room-separating door could be placed anywhere that two non-black colours touch.

Finally, we can continue this flood fill a bit further, beyond the open tiles, and into the blocked tiles. If any differently coloured rooms touch during this stage, instead of finding a door, we’ve found a place where we can tunnel between the two rooms. The more steps we go through expanding in this way, the longer the tunnel is that we’ll have to dig. For instance, above, the cyan and bright green rooms are coming very close – if we expand outwards a little bit, this is what we find:

Note that we’re not really expanding these caves, this is all exploratory. What we’re actually going to end up with when this is all done is something like this:

Coming up next…

This is all well and good, but we’ve ignored a little thing called gravity. In other words, this all makes a lot of sense for a top-down 2D game, but we’re overlooking the fact that these rooms don’t necessarily work for a platformer, since the doors are in the ceiling and there’s no space to actually walk around. I’ll talk about how to do those things a bit in the next blog post.

Platforming in Sun Shy’s Weird Environment

One of the strange things about Sun Shy is that, like many games, its world is built around a system of tiles – but unlike most such systems, the tiles are irregular. Most (grid-based) platformers use a square grid, lots of strategy games use a hexagonal grid. Meanwhile, Sun Shy uses a Voronoi tessellation. There are a bunch of reasons we chose to go with this, and I’ve grown attached to it now. It’s not the easiest thing to work with from a programming point of view, but today I’m writing about the challenges of working with it from a game design point of view.

For anyone who likes reading wikipedia articles on algorithms, this is a Voronoi tessellation, based on a set of points created with a Poisson disc distribution, and then relaxed a bunch of times with a thing called Lloyd’s algorithm.

Problem Number 1: No flat surfaces

You can build artificially flat floors in Sun Shy, but from the tile system alone, you never get a flat surface. This means ‘flat’ in the sense of ‘horizontal’ (ie not sloped), as well as ‘flat’ in the sense of ‘a straight line’. This raises a bunch of issues for a platforming game, most of which amount to throwing out a bunch of tried-and-true techniques.

First off, it’s not trivial to determine the difference between a floor, a wall, and a ceiling. Of course, for a given surface, you can look at the surface normal and see if it’s pointing upwards, and that’s fine. But if you define a floor as simply being ‘any surface whose normal vector points within a certain angle of upwards’, then… well, look at the picture above. There are A LOT of floors, each of which is tiny and surrounded by ‘walls’. This isn’t terribly useful if we’re talking about navigation, or deciding where the player can stand/walk, or where the player can construct a building. If we’re going to have wall jumps in our game, how do we decide when that’s possible?

Problem Number 2: No fixed sizes or distances

It’s nice to be able to talk about distances/sizes in a game in terms of tiles. For instance, being able to say “our character is two tiles wide and three tiles tall”, or “this entity can jump at most six tiles high”. While it’s not unique to Sun Shy to not have that luxury – lots of games don’t have tile systems at all – it does get dicey when combined with player-created environments, because you can wind up with doorways that the player can almost-but-not-quite fit through, or end up stuck in, or whatever. Closely tied to problem number one, how many tiles can the player step up without jumping, and at what point does a step become a wall?

None of this constitutes a technical problem – you can just throw floating point maths at this. The trick is from a game design perspective, making systems that don’t end up becoming less fun because (for instance) it’s hard to reliably judge whether you can make a jump or not.

Sun Shy’s current player movement model

There are a few things to consider here. First off, Sun Shy isn’t a physics game, but it makes use of a physics engine, and we want our player to be able to exist comfortably in that world. We want our characters to react to, say, falling rocks in a reasonably convincing way, rather than having to write a bunch of weird special case code for that. That means our character is going to be a rigid body in a physics engine, and to move them, we apply forces and impulses.

Second off, we want someone familiar with 2D platformers to be able to control it without relearning everything, so nothing too weird. Our character is going to have air control, and they’re going to jump higher the longer you hold the jump button down, even though these things make no physical sense. Also there won’t be unusual mechanics like, say, the ability to trip and fall. On the other hand, platforming is just how you get around in Sun Shy – it’s not the focus of the game’s challenge – someone not terribly familiar with platformers should be able to succeed at the game. We’re not making Super Meat Boy or Celeste here.

With that in mind, the model we’ve currently landed on is what I’m going to refer to as the ‘hovercraft model’. The player has two parts – a rigid body with a collider on it, and a ‘beam’ firing down. The beam is wide, represented with a circle trace (like a ray trace, but instead of moving a point along a line, we’re moving a circle along a line) pointed straight down. It’s a fairly short trace – comparable to the length of the character’s legs – and if it hits something, then that is what the player is currently standing on. If it hits nothing, the player is airborne.

A crucial part of this is the leg extension distance – that value is used to determine the force applied to the player vertically. Without this, the player is nothing more than a circle that falls on the ground – this is the ‘hovercraft’ part that pushes the player upwards. I modeled this similar to a spring – the more ‘compressed’ it is, the stronger the upwards force. At a certain level of compression, the extension counteracts gravity – if it’s more compressed than that, the player will tend upwards, and if it’s less compressed, the player will sink down a bit. This gives us a nice springy look to landing from a jump, that will help us make the animation look nice later.

This is the model we’ve been working with for a while. Here is our character in action.

Known problems and future challenges

For what we’ve got going on so far, this character model works pretty well. However, there are a few known issues and things that aren’t quite right (yet).

  • This doesn’t deal with moving platforms at all. If a platform moves left or right while the player is standing on it, it will just move away without them. We’re not actually anticipating having moving platforms in Sun Shy at the moment, but we do have things that work similarly (such as collapsing environments/rubble that you can climb on and it shifts underfoot). So far, it hasn’t been a noticeable problem in these situations, but we’re keeping an eye on it.
  • The player runs at the same speed on flat ground or on a hill. This is a little bit weird – basically, if the player runs up a hill gentle enough that they’re not hitting their face on the wall, they will go at the same horizontal speed. This actually means they’re faster running up a hill, because they have the same horizontal speed plus the vertical travel. One solution we’re experimenting with on this is to have the player’s horizontal speed suffer when their foot spring is very compressed – because going up a hill, they spend more time in that state.
  • The player is very ‘compressed’ running up a hill, and very ‘stretched’ running down a hill. This may or may not end up looking weird when we animate the character.

Currently I don’t think any of these problems are insurmountable – we’re pretty happy with where our character is as a first pass, but of course will keep tweaking things as the game evolves.

Coming up next…

Snake Hill Games has spent the last little while working on a research project for Creative Victoria. The content of this blog post isn’t part of that – we had already developed this stuff before that project happened – but it’s closely related to the project, which was about general technical and design challenges facing a 2D platformer in an irregular, procedural, or player-created environment. Next up, I’m going to be talking about classifying the environment for various navigation/AI purposes. After that, I’ll be talking about the daunting process of trying to get a bipedal character to animate nicely in this environment.

Sun Shy

As promised, here I am talking about our new game project! Sun Shy isn’t far enough along yet for a proper trailer or much fanfare, but it has lots of cool tech in it that I want to talk about, so I need to at least mention the game first. This post is meant less as a marketing pitch and more as the beginnings of a development blog. Hopefully it will give a bit of an idea of what we want the game to be.

Sun Shy is, or will be, the following things:

  • A 2.5D platformer
  • About exploring, finding resources and other treasures, and building a home/workshop/base
  • Focused on simulation and systems
  • About crafting and automation

We want Sun Shy to make the player feel like an engineer when they’re building their home, and an adventurer when they’re away from home.

Right now, Sun Shy looks like this:

Hanging out in the tiny hovel that I built in two minutes so I could take this screenshot.

Most of our development work so far has been building the engine, so it’s pretty bare bones at this point, but I think the bones have promise. The engine is almost at the stage now where we can switch to adding content and gameplay, and things will start looking a lot more fleshed out.

Half a third dimension

Sun Shy controls and mostly looks like a 2D platformer, but there’s a good reason we describe it as 2.5D. The game world consists of two ‘layers’, back to back, that the player can swap between and explore. We’ve put together a quick video that should explain this a bit better:

We didn’t want to go all the way to a 3D game, but working in strictly two dimensions can be restrictive in terms of the player’s machine design, building layout, and so on. Hopefully this system will be a happy medium between the two, and we think it looks and feels pretty cool, too.

Feeling like an engineer

This is what the simulation focus is all about. We want the home/workshop to feel active and functional, like a machine.

To this end, we have a already implemented the core functionality of a gearing system. Crafting will be done at stations, and later in the game this process can be automated. Sophisticated crafting stations will require power, and power will be transmitted mechanically, with gears and pulleys. This video shows a gear assembly in action:

Here we have set up a hand crank and geared it way down – you might have a set up like this if you need to do something that requires a lot of torque, but your only source of power is yourself. Of course, if you have something slow but powerful (like say a wind turbine) and you need to power something quick (like a lathe), you’d want the gear ratios the other way around.

We have a bunch of systems like this implemented or planned, all with the goal of making your home, workshop, and garden more interesting. Needless to say, we’ll be talking a lot about more about this.

Feeling like an adventurer

We hope to make exploration challenging as well as rewarding, with the player needing to prepare for travel, set up camps or outposts in distant lands, and think carefully about navigating different regions. We want travelling to feel like an adventure. Different regions will provide differing levels of difficulty, and a core element of player progression will be their ability to physically move through the world. Getting this part of the game right is going to be less about fancy engine technology and more about getting the design right. We will soon share some thoughts on how we hope to do that.

Sun Shy’s status

Sun Shy is an ambitious game, and we have plenty of work still to go. Rather than attempt to enumerate every part of the game here in the introductory post, we’ll be fleshing out some of our features, design choices, and programming misadventures in future posts. We hope that over time, we can communicate some of our passion for this project, and that you will all become as excited to play Sun Shy as we are!

Coming out of Hibernation

So it’s been quiet out here since my last post, almost two years ago, about finalising Sprite Lamp. One of the things I mentioned is how bad I am at interfacing with the world through social media, and I think my lengthy silence bears that out. However, some things are happening! And some of those things involve being a bit more talkative on the internet. So this is me trying to get back into the swing of things. Each of these things will be getting a Proper Post in the near future.

New game project

It’s been a while since I was working on Sprite Lamp full time, and we’ve been kicking around/playing with a few ideas for Snake Hill Games’ next project in the meantime. I don’t know how this goes for most developers, but for me, this process usually involves building a few demos or other bits and pieces, seeing what seems good and/or interesting, and eventually settling on something to focus on.

Long story short, we’ve settled on something. It’s called Sun Shy, and it’s getting to the point now where I should probably start talking about it in public. Soon (tomorrow), I’ll put up a big, proper post. For now, I’ll just say that we’re hoping it will appeal to people who enjoyed games such as Factorio, Terraria, and World of Goo (yes, I realise they are three very different games). We’ve been chipping away at bits of it for a good while now, but not full time and not consistently, so it’s still early days – I suppose I would say it’s part way between a fairly well-fleshed-out tech demo and a pre-alpha game. It’s quite tech-heavy, so there’ll be plenty to say about how we’ve been approaching various challenges in the game’s development.

It’s still Saturday in America, which I think means I have to post a screenshot.

A screenshot of a 2D platformer. The scene is mostly made up of dirt caves at night. Two candles on stands illuminate the environment. The main 'character' in the middle is a placeholder graphic of two spheres.

New team member

Snake Hill Games has historically consisted of two people. Sprite Lamp was developed mostly by me. Anyone who used it or saw anything about it will also have come across the artwork associated with it, such as that demo zombie, which was by Halley Orion. Since then, though, Snake Hill games has grown! A friend of mine by the name of Dr Ahmad Galea, hot on the heels of finishing his physics post-doc in the faraway land of Norway, has decided to join me in the exciting endeavour of game development. Sun Shy is going to be a bit heavy on simulation, and having Ahmad around to help me with the maths that I’m not up to is going to be great.

Creative Victoria

For those who don’t know, Snake Hill Games is in Victoria, which is a state in Australia. There’s a group called Creative Victoria that funds various arts stuff here, including research. Since games are a subset of art (apparently that discussion is finally settled), that means they fund games research. With this round, that includes us! The grants aren’t to work on a particular creative project, but the research can (obviously) have relevance to projects, and our research is about coming up with AI and animation techniques to deal with difficult 2D platformer environments. The animation stuff will mostly be about irregular environments (ie generated run cycles for bumpy floors, that kind of thing) and the AI stuff will mostly be about procedural and/or player-generated environments. You can read the announcement of the various funding recipients and their projects if you like.

Since it’s publicly funded research, of course, part of it is about contributing to a public knowledge base, so we’ll be documenting any useful techniques we find/develop here (as well as blogging about any pitfalls, false starts, and general failures on our part). More coming, on this front.

Website plans

I’m painfully aware that this website could in general stand to be improved . We don’t have a great deal of web development expertise between us right now here at Snake Hill Games, but since I’m going to have to post a lot more in the coming months, we intend to put our heads together and figure out how to make things at least a little bit nicer.

Sprite Lamp, lessons, conclusions, and the future

So, it’s been a little while since I’ve written about Sprite Lamp (or anything). There’s still activity at my end, mostly in the form of responding to email requests for tech support and other advice. Sprite Lamp is now out and about on the three desktop operating systems, and I thought I’d mention a few things that have happened, reflect, confess one or two things, and talk about the future.

Cool things

Unity shaders

First off, Sprite Lamp’s Unity shaders have always been a bit of a thorn in my side – always mostly working, I’ve never been quite convinced that I am doing things the way Unity wants me to. Well, thanks to an email from a customer prodding me to fix light cookies, I have revisited this, and I think finally gotten it to work the way it should. I admit I’m still daunted by Unity’s inner workings, but for the first time, I feel like I get how I’m supposed to be using the lighting system. I imagine most people who use Sprite Lamp with Unity are mostly using plain ol’ normal mapping at this stage, but for those still using the official Sprite Lamp shaders, they have been updated, I believe substantially for the better.

Hive Jump

So, for obvious reasons, this is very exciting to me: A game made with Sprite Lamp is officially out on Steam! Hive Jump is a multiplayer 2D shooter that feels a lot like days of old, but of course, everything gets illuminated all nice. I’ve probably mentioned Hive Jump at some point, as I’ve been in touch with the developers since way back in the day. If you want to get an idea of what Sprite Lamp can do in the right hands, check it out!

Things not done

So this is an important section for me, and I think anyone who’s ever done a Kickstarter campaign will be able to relate. There are a few features from the original Kickstarter that remain undone, and will likely remain so. This is for a couple of reasons, and I didn’t want to let them just disappear silently. It’s my belief that these features mostly aren’t really going to be missed, but more on that at the bottom of this section.

  • There was never a Steam release for Linux. I tried to make this happen, I really did. Because of how Steam’s version of Sprite Lamp works, it’s necessary for Sprite Lamp to communicate successfully with Steam, so that it can check if the user owns the Pro update or not. I just… couldn’t get this to work. Obviously it’s good to go on the other two operating systems, but some combination of my inexperience with Linux, the Steam API being different in that situation somehow, and not getting much in the way of responses when I was looking for help, just bogged this one down. The Linux build is available from the Humble widget, so Linux users aren’t completely out in the cold (and the vast majority of people who own Sprite Lamp got it from the Humble Bundle at this point).
  • Mesh exporting never happened. Once upon a time, I intended to have Sprite Lamp export a mesh based on a generated depth map. The further I got into the development process, the sillier this feature seemed. There isn’t one universally accepted mesh format, so I would probably have needed to integrate several libraries just to export to things like fbx, obj, etc. More importantly, it doesn’t seem like anyone was even close to wanting to use this feature (this is true of a lot of the depth stuff in general).
  • Custom shaders never happened. I originally had a plan of allowing users to write their own shaders and have them display in the Sprite Lamp preview window. A minimal box-ticking style implementation of this wouldn’t be so difficult, but the interface between Sprite Lamp and a custom shader is so convoluted that it seems extremely unlikely that it would see any use. Furthermore, it seems that most Sprite Lamp users are content with the existing shaders, and are generally not shader programmers themselves. Finally, if someone really wants to do this for a particular pipeline reason, they can edit the built in shaders to achieve a similar effect.
  • Generally not great engine integration. This is the one that I regret most. I underestimated how much pain engine integration would cause me in several ways, and it was foolish of me to think that keeping up with multiple engines was feasible (especially since I’m not especially adept at any existing game engines).  I also communicated badly about the situation with what an engine integration actually means (that is, that it’s only for the fancy Sprite Lamp-specific effects – you don’t need an engine integration just for basic normal mapping). As of now, there’s a fairly good Unity integration, and a useful but not as complete Game Maker integration. I also didn’t foresee the extent to which Unity and Unreal 4 would take over everything, and the fact that PBR (physically-based rendering) would make it infeasible to actually do Sprite Lamp shaders at all.

I think that’s the end of my list of confessions. As I say, for the most part, this is stuff that I wasn’t expecting to get much use (and in most cases, literally none). However, if you are reading this thinking “God dammit Finn, I backed your kickstarter because I wanted to export depth maps as meshes, how dare you”, please contact me! I genuinely don’t mean to leave people out in the cold – I just don’t want to put myself through a bunch of programming work for features that literally nobody cares about.

Speaking of which, another thing that could have gone better was… in general, I think a lot of the features (particular stretch goal stuff) were just not that useful. More on this in the ‘lessons learnt’ thing, but yeah. Most of that stuff did get implemented, in the end, but I think doing so was in large part me tilting at windmills.

Lessons learnt

About crowd funding

I’m not exactly champing at the bit to get another crowd funding campaign going. Why? Well, a lot of it is my particular psychology, I suppose. But there’s a really important thing that I want people to know about crowdfunding.

If things crash and burn – and they might – it will feel like there’s no honourable way out.

I consider myself to have gotten off lightly with Sprite Lamp – perhaps I’m flattering myself, but in spite of the rather long tail for certain features (coughOSXcough), I consider it a fairly successful project. However, it kills me when I occasionally get a heartfelt email from some game developer who I backed on kickstarter years ago, on a project I’ve long since forgotten about, who’s thrashing about in development hell on a project that would have been cancelled ages ago if it was a normal publishing deal. Often they’re fighting tooth and nail to finish the project, giving up years of their life to develop on platforms that are no longer relevant because they promised, or whatever. I wish I could tell them “seriously, don’t worry about it, go work on something else”, but unless every one of their backers tells them that, they’re still on the hook, and it sucks. If you’re considering a kickstarter campaign or something similar, please, seriously consider that this might happen to you. I feel like Sprite Lamp has given me just enough of a taste of what that would be like that I’ll probably never touch crowdfunding again.

Furthermore, I say this as someone whose backers have been basically 100% wall to wall lovely the whole time. If your backers are shitty to you, that probably wouldn’t help much either.

About my own habits

I’ll just come out and say it. I suck at, and hate, communicating with large groups of people. I suppose this is what people would call ‘community management’. Maybe it’s just my latent shyness, I don’t know. But god damn, I was not expecting to stress more about tweeting that I’ve launched a new build than I did about actually doing the build. As a game developer, I don’t know what my long term strategy for this is. It seems the conventional wisdom right now is that to have any success as an indie developer, you need to maintain a fairly active social media presence. My current strategy about that is to really really hope the conventional wisdom is wrong. Plan B is probably to become a farmer or something.

Related to that, having some kind of weird broken comment/forum system on this website that basically never saw any use really didn’t help. The forums are gone now, and good riddance. If you asked me something there at some point and I ignored it, I’m sorry. If you email me I’ll get back to you much much faster.

One on one is fine, by the way. Anyone who has emailed me for tech support or whatever over the years: you’re cool, no worries at all.

The Future

So, right up there in the title, this blog is for Snake Hill Games – and while it’s true that Sprite Lamp is game-adjacent, I’ve always wanted to get back into making games rather than game tools.

A while back, I started fooling around with a simple base for a project, to relearn C++ (I was teaching C++ but hadn’t used it for years, so this practice was very much necessary).  It hadn’t really gotten anywhere, but I learnt a bunch, and it was around this time that I rebooted Sprite Lamp in Qt. That was the major project focus for a while, and there has been quite a bit of tying up of loose ends there.

However, as of now, I am officially Working On A Game. I’m not really going to say much about it for now – it doesn’t even really have a name. I’ll mention that it doesn’t make major use of Sprite Lamp (sorry – it doesn’t really fit well with the required rendering system), but it does contain some unconventional lighting systems that I think people will get a kick out of (it did start as a programming exercise, after all). More on that coming soonish.

Final thoughts

If it’s not obvious from the above blog post, people are welcome to keep contacting me about Sprite Lamp (and other things). If you need help with getting something to work, or advice about using Sprite Lamp, or need an explanation of how normal mapping works, or whatever, get in touch. I’m pretty responsive via email and generally happy to help.

The other thing I will say is, a final thank you to all my backers. Not so much for backing my project – although that’s much appreciated, I’ve said that already – but for generally being a pleasant bunch. Keep doing what you’re doing, and making cool stuff.

 

Sprite Lamp sale, and the eating of dogfood

Hi folks!

First thing’s first, Sprite Lamp is on sale on Steam this week, for thirty percent off.  A couple of people asked me when that was going to happen, so here we go. I turned thirty a couple of days ago so I thought that was as good an excuse as any. I’ll note that this sale includes the upgrade from the hobbyist version to the pro version. So yeah, here are the links to the Steam pages if you want to get in on that.


Mac holdup

I’m not enjoying giving bad news for the mac port, but unfortunately there has been a hold up – we’ve recently been having a pretty major show-stopping bug with some not-yet-understood combination of mono, graphics drivers, and OSX versions. Rob has more resources than I do for this, and he’s currently messing about rolling things back to get it to the point it’s usable. Once we get it to some working state, the plan is to release an alpha to kickstarter backers, to get a feel for reliability, and hopefully that will give us the data we need to move on to a proper release.

Linux alpha incoming

Progress is much more forthcoming on the Linux build, fortunately, and I’m hoping to get an alpha to backers soon. I’m still struggling with the Steam libraries on Linux, but other than that things seem to be coming together pretty okay.

Eating our own dogfood

Developers might recognise this rather gross-sounding phrase. ‘Eating your own dogfood‘ refers to the practice of using your own products internally. Technically, I think this would mean Snake Hill Games was making a new game, and it was using Sprite Lamp, but this isn’t the case (yet). Rather, I’ve noticed that too often, I don’t have a great answer to questions people ask about using Sprite Lamp with Unity, because while I have developed the shaders and put them in a toy environment, I haven’t actually used them for real. Unity is big and complex, and try as I might, I frequently overlook application details that are tripping people up. In an attempt to head that off at the pass, Halley and I have decided to make a small tech demo using Sprite Lamp and Unity. Hopefully the following things will result:

  • I’ll encounter problems with using Sprite Lamp and Unity, and fix them.
  • I’ll encounter workflow issues with Sprite Lamp now that we’re using it for real, and fix them.
  • Halley will create a bunch of art, and write some blog posts on workflow and artistic best practices, that will perhaps be of some use to people.
  • We’ll perhaps end up with some generic assets that people might find use of in their games.
  • We’ll be able to give more concrete answers to questions like “How long will it take to make assets for use with Sprite Lamp?”, as well as point people to a live example of what games that use Sprite Lamp can look like.

This won’t take a great deal of my time (it will be more artwork than codework) but it has already borne some fruit. Tomorrow, I’ll be posting an update about using multiple sprite sheets with Unity’s animation system, and adding a script to the official Unity integration package that automates the process of switching out different sprite sheets.

Anyway, I’m not going to say much about this little tech demo just yet – it’s in very early stages, and there’s nothing really worth showing off yet – but I’ll post a bit more about it soon.

Colour Bind – real trophies

I did a fun thing recently. It’s only sort of related to game development. There is, however, information below on how to win fabulous prizes, so read on because you wouldn’t want to miss that.

Back in the day, I made a game called Colour Bind. I thought it was pretty cool – it’s a physics platformer where you drive a car through various levels, but also there are puzzles and a rather nifty gravity-is-based-on-colour mechanic too. Alas, not that many people played it, but so it goes. The game was/is very challenging, and has lots of achievements (proper ones, for achieving things, not for pressing the jump button a hundred times or whatever) and lots of scope for mastery. Accordingly, I made the bold claim that a couple of the things you could achieve were so challenging that the first people to do it would be given a trophy. A real trophy that you can put on a mantelpiece, not a virtual trophy. Furthermore, I would actually make these trophies myself, and they would be awesome.

That coloured triangle is the goal - you play as the car thing. Also you can change colours.
This is what the game looks like…

So the game came out, and a couple of people really got into it. Before long – although with some pride I will say that it did take a couple of weeks after launch – the trophies were won. I was/am impressed with these guys – I’m pretty good at Colour Bind, but I’ve been playing it for years, and these guys are already as good as me or better on lots of the leaderboards. One fellow, an American by the name of Nathan, won the first three trophies (getting all the gold medals, getting fifteen platinum medals, and finishing all the cooperative levels with his brother), and a Spaniard by the name of Asier won the last one, for finishing all the secret levels (also no small feat, believe me).

I’m generally not very good at being active on the internet, but I thought it was worth documenting this adventure into the world of making actual physical things. It took ages, and lots of mistakes were made, but the end result is something I’m pretty proud of.

The fifth one remains. Go on, try out the Colour Bind level editor. I dare you.
And this is what the trophies look like!

Booya! I made a thing.

Don’t you just want to read a long description of how they were made? Well, you would be in luck, because I have written just such a blog entry, in four parts:

Part 1 – 3D printing

Part 2 – Dying the prints and making the supports

Part 3 – Painting and assembling

Part 4 – Tricky painting and bring it all together

The Fifth Trophy

Okay, this is the bit about fabulous prizes. The trophies were originally claimed to be for:

  • Getting all the gold medals
  • Finishing all the cooperative levels
  • Finishing all the secret levels  (real hard)
  • Getting 15 platinum medals (I didn’t even know if this was possible at release)
  • Making the coolest level in the game’s level editor

Now the purists will notice that the photo of trophies above features four trophies, and the list of trophies just there includes five. The disparity is the last one. The first four are very easily defined – when people achieved them, I crossed them off the list – but the last one, about making something in the game’s level editor, had no predefined cut off date. I kind of wanted to leave it open, because the game was only out on Windows. Then the MacOS version took ages due to various bureaucratic annoyances (don’t ask – suffice to say, it wasn’t the fault of the awesome person who did the actual port work), and the whole thing kind of dragged out. However, I haven’t forgotten. I will be posting back here with precise details (want to see if it’s reasonable to include the Linux release in this before I say any dates), but if you want the fifth trophy, you should get the game and start making some cool stuff. There’ll be a Mac version real soon, the Windows version can be had right now either via Steam or DRM-free via Desura. I’ll look through the Steam Workshop for levels, and they will be automatically in the running. If you make stuff in the DRM-free version, you’ll have to email the level to me or something like that for me to notice – I’ll put some details up for that when I do an official post on the subject.

So I hope you’ll give it a shot! There’s some documentation for Colour Bind’s level editor that can help you get started. Feel free to get in touch with me if you want to know how to do something in the editor or want to know if something’s possible. Or of course, if you happen to be attending PAX Australia, come ask me in person at my booth at the indie pavilion!

Colour Bind trophy building – part 4

Okay, let’s tackle the hard bit first. The colour bind goal model is sitting on my desk with a big white triangle where the colours should be. Mocking me. Telling me that I’m not good enough to paint it. Well, we’ll see who’s not good enough.

This is potentially going to be a bit of a challenge. The things against me are that I have never really painted anything before (apart from some Warhammer figures when I was a kid), and the extent of my paint mixing experience begins and ends with mixing up some grey paint for the other bits of the trophies earlier. Furthermore, the Colour Bind goal triangle is basically just the OpenGL triangle, that is, a triangle with its points being pure red, green, and blue, and those three colours smoothly interpolated between the points.

It may sound strange to some, but red, green, and blue are chosen because they are primary colours – specifically, primary light colours, also known as primary additive colours. The primary colours many people are more familiar with are primary subtractive colours, or primary pigment colours, red, yellow, and blue. With paint, you mix yellow and blue to get green. With light, you mix green and red to get yellow. Screens, and thus computer games, use additive mixing, which is why the OpenGL triangle and the Colour Bind goal use the additive primaries.

So, naturally, I have to paint what’s in the game. But since I’m painting, I’m going to be using subtractive mixing – a subject I know considerably less about. Halley assures me that, unlike the wonderful abstract world of computer graphics, paint is made of chemicals that may or may not have identical mixing properties, consistency, intensity, and whatever else. Fortunately, she’s going to provide me with some advice. She also did a pretty awesome job of masking the model for me. I am seen here taking my first feeble steps into mixing colours.

Also, that picture of the guy with the glasses on my desk is freaking me out. I don't know where that came from.
I probably should have shaved my beard a bit before taking this photo.

After a fair bit of remixing, faffing about, and general obsessing over needless details, things have come out reasonably well!

Damn you, creepy glasses man, why can't you leave me alone?
Seems to have come out pretty well! I’m as surprised as you are.

All that’s left for this trophy is to take the masking tape off and retouch some bits (the white dotted line around the edge needs it), and then attach everything to everything. Specifically, the trophy and the nameplate both need sticking to the base. I also varnished the whole thing in some matte polymer varnish because I was concerned that the paint job would get chipped.

Meanwhile, the other trophy’s repainting job was drying in a somewhat unorthodox drying scenario:

I got paint on my glasses and everything.
If you think I didn’t walk into this face first a couple of times during the process, you give me too much credit.

Now we’re practically home and hosed. Just sticking a bunch of stuff together remained at this point, and happily, it went off without a hitch! There isn’t really even an intermediate phase – just the finished trophies in all their dubious glory. Check it.

This trophy is actually pretty robust, too - if any of them break it'll be the dratted coop one
Done and dusted! I am very pleased with this one.

And last but not least:

The front wheel is riding a little lower than the back, because it's driving up a jump ramp. Just like in real life.
This one too. I like the suspension.

That’s it! Four trophies completed.

As a side note, as someone who generally creates things digitally, my heart goes out to people who spend most of their time making physical objects, because you don’t get to keep what you make! I made Colour Bind, and I sell it to people, but I also get to keep the game. Not so with these – I’ve taken my last look, now it’s time to make some overengineered packaging.

As mentioned, these trophies are going to two people, so I need two boxes. My plan is to cut out some of that weird cardboard/chipboard stuff that the trophy bases are made of, get some wooden dowel, and drill holes the size of the dowel – then, I’ll have squares of wood making up the floor and ceiling of the box, and the dowel holding them apart. Hopefully the result will be rigid enough to survive the adventure of international shipping. I didn’t document this process all that much, because it’s not so interesting, but I did get a photo of my standing near a drill press, so that’s something.

I'm wearing gloves and goggles because I was traumatised by a drill press injury earlier in the project.
This might make more sense when you see the finished product

Basically what you see above is two squares of wood taped together, and I’m drilling holes in the corners. The plan is to then thread some wooden dowel through those holes, and put a nail in each connection to hold the whole thing together. The dowel and the drill I’m using are pretty precisely the same size, so it should be reasonably solid. The next challenge will be to hold the trophies in place without damaging them, or having to attach sticky stuff to them that will leave a mark. I decided to drill some smaller holes in the base of the box and tie the trophies to the base with twine. Here’s Asier’s trophy suitably bound and ready to post:

I'm still a bit fearful of posting the thing.
Not a scratch on it.

And here are the ones for Nathan and Scott:

This twining process actually took ages.
I’m still a bit scared about the coop trophy. Fingers crossed.

Now for the packaging process. We got some vaguely appropriate boxes from the post office, loaded them with bubble wrap and other random packaging that we’d saved from all the stuff we’ve been sent throughout our lives, and got ready to go.

Complete with notes on to the recipients, and a sort of hinging door thingy to protect the set of three.
Almost there…

I almost spelled 'fragile' wrong but I saved it at the last moment.
Mission accomplished!

Well, that’s it! The rest of the story involves me going to the post office, and paying absurd prices for shipping (it is going some distance, I suppose). Next post I make will hopefully be about the recipients of the trophies telling me that they’ve arrived safe and sound, and that all is well.

Anyways, I hope you’ve found this interesting and/or entertaining! Remember, there’s still one trophy somewhat like this one, but different (and yet to be created) up for grabs! These four trophies were for gaming skills, but the last one goes to the person who makes the coolest level in Colour Bind’s level editor. If you want to try that out, you can get the game on Steam or you can get it on Desura as well. The MacOS version is coming out really soon (at long last!) too – its fate is currently in Apple’s hands, but will be on Steam and the App Store when the time comes.