Just to get this out of the way: I put my StarCraft-related projects on hold for a bit. SCHNAIL will keep going in its current form for a while, then I’ll decide what do with it. In the meantime, my creative energies need an outlet.

Background

I was always fond of turn-based strategy and tactics games, especially ones where you manage a small team of operatives. The XCOM series, Battle Brothers, Chaos Gate (both the original and the new Daemonhunters) are some examples I sank endless amounts of time into. But I am a developer, and sort of a game dev as well, and in the back of my head there was always a process spinning about how to make these games better, or how to make a better one – or at least according to me.

I began to deconstruct this idea, and analyzed what made these games tick, and how to iterate on these. In this article, I will share my thoughts about movement systems.

First, these games tend to play on a grid. This is understandable, as they ultimately stem from board games/wargames which very often use grids to simulate movement, and simplify calculations about distance. It is very probably something that was also a technical limitation at one point, like 25 years ago.

The grid just represents discrete units of movement, but we have games with free movement for a long time now – even though technically it is always a discrete amount that you can move in an FPS for example, the granularity of this is so small that you perceive it as a continuous, smooth movement experience. Why can’t we have the same in turn-based games, where you can just position your guys like you would in an FPS?

The answer is of course, we absolutely could, and there are examples of this. Mordheim: City of the Damned, and Necromunda: Underhive Wars both have movement where you move your chars in a third-person view. I liked the idea, but I felt like it wasn’t

This ties into the second point I miss from most turn-based games, which is proper use of verticality. XCOM is technically 3d, but it is actually 2d grids stacked on top of each other. Here is a random screenshot from Google:

You can see how the height levels are well-defined, and also the boxyness of the whole level. I don’t consider these negative traits – I love XCOM a lot (I even finished Long War…). The boxyness makes it easier to assess the level at a glance.

But I’d like something different. Let’s consider Mordheim for a second.

Movement works in a way that you have movement points (blue orbs), and each one lets you move a certain distance (indicated by the circle). This distance seems to be “as the crow flies”, and not actual distance walked (something I’d like to change). You can also see the swirly blue thing that indicates a point where you can jump down/climb up. I’d like to have that extended, and let the player jump/climb anywhere feasible. These areas would be limited by the character’s abilities of course, but let’s not get into that just yet.

While Mordheim has ranged combat, it is secondary to melee, so ranged weapons don’t have that much depth (Sadly, it is my impression of the whole game – I wanted to like it so much, but it is just death by a thousand cuts for me with all the small flaws. But that is irrelevant here). Cover is WYSYWYG for the most part, which is good. You can’t duck down, hug the wall, go prone or any of that stuff, though.

TPS movement solves one crucial issue though, which is pathfinding. In XCOM, if you select a tile, and click on it, a line will be drawn to that indicating the path that your char will take. I have no doubt this is a complex topic, but pathfinding is one of the problems I’m familiar with, at least 30-something articles deep at least.

Instead of brainstorming any further, I chose to prototype this a bit. I started to build an obstacle course, or in other words, edge cases for my pathfinding.

Behold George, our prototype character.

I chose to use Unity as my game development tool, which I’m learning as I go along. Currently, I can click on a point, and get the character to move there. If there is a wall between, it gets stuck. Let’s consider the scenarios, and build the obstacle course! I’ll focus on the pathfinding behavior first and foremost, but I want to build an actual game, so anything that comes into mind while thinking about this I will write down. There are probably well-established methods of game design, which I’ll be ignoring for now. (I do plan on reading up on game design though)

Starting out, setting the target point should be only valid on certain structures – the green-colored plane in this instance.

First scenario is when there is an obstacle in a way, and the endpoint is not reachable.

The expected behavior (EB from now on) is that you can’t place the movement marker. I’d also add player feedback (PFB, why not) in the form of an error message and maybe a red movement marker flashing up for a sec, or a red line indicating that you ain’t gonna go there buddy.

In this case above, you can get to your destination – but there are multiple ways to do that, and the player will expect the most optimal route – so some 2D pathfinding is in order.

EB: A line showing the most efficient route.

When considering the previous example, it wasn’t obvious, but here it is much more clear: when pathfinding, we need to consider the width of the character. Now, currently it is a static cylinder, but if I want to iterate on existing movement systems, I might want to consider a “shimmying” mechanic as well. Let’s say that in this case, the character cannot fit in any way between the two blocks, and must go around.

EB: A line showing the most efficient path around the two blocks.

Next is embracing verticality. I present two ramps here, one is to steep, the other is walkable. The expected behavior seems straightforward, but what actually determines if a ramp is too steep? A cop-out answer would be that too steep angles are just not gonna be defined as parts of the playing field, but I’d like to play around with this – maybe there is a piece of equipment that lets you climb these types of surfaces? Or since this will be a sci-fi game, lower gravity can allow it? For the first iteration though…

EB: Drawing a line showing the most efficient path to the climbable surface, not being able to place the movement marker on the other.

So the next issue is when there is a gap between two walkable surfaces. I also added an X and a nope icon to indicate what should happen.

EB: There should be a jump/step-over distance in these cases, and if the gap is small enough, the character should be able to jump over it.

There should be some PFB indicating that a jump is going to happen, and maybe there should be a roll for this for risky jumps? This also brings up the question: What if the second platform is lower/higher? The direction (and maybe force) of gravity should be taken into account here. For the first iteration a can/cannot make the jump is good enough.

We had walls too high to climb, and now we have a very climbable one. If we have jump mechanics, we should have climb/step over mechanics as well. If the obstacle can fit the character on top (and that doesn’t necessarily mean it can fit the whole footprint of the char – let’s call this property supportability for now)

EB: You know it by now, just by looking at the picture.

The logical counterpart is an obstacle that you can’t stand on, but you can step/jump over, and the vertical version of it. The vertical gap between the two cylinders on the left is a bit smaller than the character’s height, but if it is a human, logically it could fit through. Let’s call these mechanics horizontal/vertical squezes, where you can’t stand on/between them, but you can move across them.

EB: If you have enough movement to clear the obstacle, you can finish across, but not on them.

And the final thing to think of is the platform where you can reasonably fit (and stay) under, but it is too high to climb on top, and the other way around. The EB is pretty clear here. This implies there should be a “crouch” mechanic, or even crawl, where you can stay inside cramped spaces.

This is all I can think of in terms of 3D movement. It is quite a lot to consider, and I assume it will be quite an ordeal to implement all of these, but it is a problem that is exciting to think about. And it is exactly that, a problem at this stage. I plan to detail my journey through solving all of this – it is worth subscribing to the mailing list (on the right) to get notified when that happens. Thanks for reading, and don’t hesitate to share resources/solutions in the comments below!