When people first play games – perhaps the first thing they notice (after the appearance) is the interactivity. If the input is imprecise or unresponsive, or the means by which they interface with the game is not quite right, it immediately sends a bad signal and they’re unlikely to continue.
Think of most of your favourite games – with a few exceptions where innovate gameplay might make up for it, they almost certainly all control exceptionally well.
This game was originally a 2D dungeon crawler and it went through various iterations. I’ve also dabbled in other small games for gamejams or out of interest, and without fail I always end up flitting between various systems to program them and move on before completing because something new and shiny catches my eye. I’d do a bit on UI, on procedural generation, maybe something on niche gameplay features… but never finish them. Which is why this time I’ve resolved to work almost exclusively on movement, input, and combat before moving on. After all, it’s basically the core of the game. As a result, the other systems are mostly in their nascency, but there’s still plenty to talk about there.
Movement
Olusia is a top-down game. I’m taking a lot of inspiration from classic CRPGs, but not in the realm of player input. Most classic CRPGs implement click-to-move. There’s nothing necessarily wrong with it, but it’s suited to certain types of game – specifically those where you’re in control of > 1 unit, or turn/round based games. There are a few reasons I didn’t opt for it:
- Less personal. You click where you want to go, and the unit will path there as it wants.
- Less responsive. There’s less opportunity to respond to stimuli quickly and precisely
- Inappropriate – it doesn’t really make sense when taking into account the rest of the mechanics
Instead, I have opted for full directional movement and rotation. Move with WSAD keys, and the unit will face wherever you are pointing the mouse, as shown in this GIF:
It allows for more “actiony” mechanics and makes aiming bows or spells that much more interesting. It also has a tactical aspect missing from most point-and-click games – for example, you can face one way whilst walking backwards, perhaps so you can block projectiles with a shield at the same time as retreating. Walking backwards does result in decreased speed – and so does holding up a shield. For example, in the following GIF:
This guy is in very light clothing and so has a high run speed, but slows down when raising his shield.
Movement effects are cumulative. If you are in heavy armour, walking backwards, and for some reason have two shields with which you want to block, well…
You move quite slowly. But that is all the players choice.
Using Items
Item usage is something that is largely decoupled from movement. That is to say: you can move and use items at the same time (with rare exceptions).
Each arm is bound to a mouse button. Left click to use the left arm, right click to use the right. Simple!
All items will largely follow these same rules, and most will also have the ability to what I’ve termed “Prime”. I’m not sure when or why I labelled it that, but I have stuck with it.
If a mouse button is held down, the item will be “primed” until released. Here is a quick example with a sword:
The sword is raised upon holding down of the button, and swung upon release. This sort of thing allows a little more control over the mechanics of various items, especially ranged weaponry or shields.
There’s also some other stuff that ‘feels good’ to help with finer control. This includes rolling and jumping. Not only do they look cool, but they also make combat higher-stakes and faster by providing the ability to dodge attacks.