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.

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.