Most of the work lately has involved changing the way the player is shown how they’re interacting with the game. Use of abilities now has a totally different flow where that player can see how much ‘Juice’ their ability has left and the ability fails when they run out; an ability ‘Upgrade’ system ties into this concept.
I’m also trying to massively improve the menu system so it’s not so much about clicking on tiny little buttons, instead being a mostly drag & drop interface. I want to keep the menu system easy and also make it extremely clear to the player exactly what they’re interacting with.
Drag & Drop design is an absolute nightmare to work with, but it looks tactile and sensible when it actually works.
So I talked about particles the other day when I pushed the prototype into the game engine and got them working, but I had to do some work to make them really “exist” in the game world. The first thing to do was make sure you couldn’t see them through walls, and I’ve now given them the ability to “collide” with the floor.
As an example, I’ve made “Bullet Casings” eject from guns fired and bounce on the floor before coming to a resting stop and fading away. To do this, I had to make the X axis inertia inherit the direction the creature was facing when he fired the gun to make sure the bullet fires out of the “back” of the gun. On top of this, the particles are told, when they spawn, how high above the floor are they. The floor is defined as the bottom-most pixel of the sprite that emits them.
Using this information, the particle can tell when it has hit the floor, however, because the game camera is skewed isometrically, the floor is angled. If the creature is facing North or East, the floor behind the creature is tilted “downwards”, otherwise it tilts “upwards”. The further the particle has traveled horizontally, the further the floor has skewed.
With much fiddling, bullet casings now bounce along the floor as per the rules of the isometric camera, and any particle can follow the same rules with a simple “CollidesWithFloor” flag.
That was certainly a whole lot of words that probably make no sense out of context, but I’m still pretty happy with the result; I’m wondering if I should make particles bounce off walls now.
While play-testing your own game, it’s sometimes hard to imagine what a lot of your game’s features are going to feel like from the perspective of someone other than yourself. After a lot of play, I’ve decided to throw out a chunk of code regarding “Ability Cooldowns” simply because it’s no fun and doesn’t make immediate sense.
It can be kind of hard to accept that a ream of code you wrote might actually have no place in the game you’ve written it for, but it’s just part of “Making a game”, you put some code in, see if it works, and then change it if it doesn’t. The code I’m removing has been a core part of the gameplay for months now, but as the game’s changed slightly over time, I’ve created a much more relevant set of rules for how “Abilities” are used in a fairer and much more sensible way.
It’s become quite a challenge to communicate to the player exactly how “Abilities” work, especially when you have a full team of five creatures running about potentially all using different abilities at the same time in different locations. The player needs to be able to always see at a glance who is doing what and whether it’s working or not. I’m changing the way the “Solution” box at the top-right of the screen works so that it will show what abilities are currently being “Cast” and how long they’ve got left until they’re finished. Hopefully you’ll start to see this change in future videos. In the meantime, here’s some play-testing I recorded.
In other news, Man Fight Dragon has been accepted into the Indie Pavilion at PAXAus 2013 where I’ll have a little booth for people to come look at a game and maybe play it if they’d like to hunch over a monitor and keyboard.