Recently I made the sword-wielding characters of my game unable to attack while moving. Previously, attacks felt somehow meaningless — floaty, weightless, they just sort-of happened. Now that they stop you from moving, they feel somehow more important, more visceral.
It seems like a tiny thing. One little flag inside the attack system setup, plugged into the movement code and… Bang. It feels like a real game.
The Little Things
I had been neglecting my game for a while, but getting ShaderForge has kicked me out of that stupour and back into action — cleaning up a whole heap of annoying little niggles and previous bad decisions.
Attack and Move
When I first implemented the ability to attack, it was with guns and it makes sense that guns can be fired while moving — this is a staple of Unreal Tournament after all. My mechs’ turrets are almost completely independent components that can aim and rotate on their own; although the hero’s turret is tied to the direction of the cursor along with its legs, this was never a hard limit by any means.
I suppose it was only natural that when I shifted over to implementing melee attacks that modified turrets would still allow attacking during movement. I mean, why not? It’s a large robot with two sword arms, it probably has the shock-absorbers to handle it.
I started off adding movement lock to make enemies a bit more interesting — a sword-wielding enemy that raises its weapon slowly enough can be evaded if it must stay in position, but if it is constantly shimmying up against you there is no escape. In doing so the lock ended up being applied to the hero too, and it suddenly felt better on both sides of the equation. More, well, like Nox.
Icon’t Believe It
Then I moved onto the UI — again. I’ve been grappling with icons for basically ever. My last attempt involved auto-generating them, but they still ended up as static images on disk — which would blunt my ambitions for vast arrays of items made of different materials and potentially tweaked on the fly.
So I ripped out that screenshot code, that had to be run manually in the editor, and jammed it into my heads-up display code. Now screenshot icons do not exist until you equip an item — at which point a copy of the item is made and pictured for use. It works because the copy goes on the UI layer, is lit by a sun that only lights objects on the UI layer, and is pictured by a camera that can only see the UI layer. This means I don’t have to worry about other shit getting in the way, and items will be consistently shot no matter what level you’re playing.
Glyph Action
The other half of my icon shenanigans involved making glyphs for abilities. One of the biggest pain points in Project Y4 was arranging item models just so to make square ability icons out of mainly very cuboidal objects. While I still prefer screenshots so that the things on the UI exactly match the things in the world, it’s hard to make them work in parts of the UI that have a different shape. Inventory Tetris mimics the actual shape of the object so that’s great for screenshots, but the skill bar at the bottom really doesn’t.
I’m also an abysmal artist so I can’t have anything too visually complex going on or I won’t be able to keep it up. As such, I’ve started to aim for a very simple thick-white-outline style. This should be easy for me to make and will tint nicely in-game for different statuses (disabled, out of ammo, etc), but still be vibrant and recognisable in the heat of battle. Plus, even if I rework item models and variations the glyphs should be abstract enough to be stable.
Heads Up
The thick white outline has now spread out to the rest of the UI too, though here I’ve allow the colour scheme to be changeable (I’ll eventually let the user tweak it, once I have menus and shit). Even here, more glyphs are helping to make the health, armour and kill counts feel somehow more grounded, more real.
Suddenly, it’s not just a collection of systems you can interact with. Suddenly it looks somehow… complete.
Of course I’d still love to do grungy metal panels like Earth: 2150, but I just don’t have the technology. Maybe I’ll commission a freelancer once things are less liable to change and need rebuilt every five minutes?
Ah well, whatever it is — it’s really starting to come together now.
There are still some major things to cover: those spinning bots are a symptom of how completely broken the AI code is right now, and that’s in dire need of work. Depending on how I feel, though, I think I’d rather ignore that and tackle procedural level generation again — I think I’ve worked out a way to solve all the issues I was having with actually modelling and arranging the tiles.
The main reason I really want to get into level construction is that it’ll lead naturally into win conditions — making some kind of actual proper meaningful experience that, maybe, other people can start to have a go at?
In the mean time, here’s a video!
Rao Dao Zao 
Having weapons impact your movement works for ranged weapons as well. Slowing your mech down if you fire heavy weapons or even adding a bit of knockback can really add some weight to your weapons. If you want to go really fancy, you can have the slowdown/knockback depend on your mech’s other systems (ie: a heavier mech would be less effected than a jumpy lightweight one). On the flipside, the game will be a slightly less arcady, run&gun&jump game.
LikeLike
At the moment weapon firing sort-of requires you to be standing still, as melee attacking and walking cause the turret to sway around during the animations and the shoulder guns fire exactly where they are pointing — i.e. frequently not exactly forwards. So yes, it might be wise to enshrine this in a movement lock to avoid people getting pissed at their shots going wide and not really knowing why. (On the other hand, for enemies it means an agitated enemy in pursuit will fire more wildly which is… kind of cool.)
The mortar is totally scripted because it’s the only way I could get that projectile arc to work, so it is unfortunately immune to unit animations at this point. Hrmmm.
LikeLike