When the player interacts with the UI, I want it to be really clear what’s going on. When you click on a creature’s portrait it snaps onto your mouse cursor before sliding back to where it started; the player needs to know that they can click-and-drag that portrait. When you hold down the mouse button on the portrait, any “ability” icons next to the portrait curl up and hide behind it to let the player know they’re dragging the creature and all their abilities along too.
If you release the mouse button in a useless place, everything smoothly returns to where it started to let the player know clearly that their action had no effect. If they drag the portrait near an appropriate resting-place, all the other portraits near that place will move aside to make room for it, even if the player hasn’t released the mouse button yet. If the player moves the mouse away from that resting place, the portraits will all move back to where they were, showing that you’re no longer considering dropping your portrait in that place.
Everything on the UI needs to move smoothly, deliberately, and intuitively to make sure the player understands exactly what they’re doing with the elements they’re interacting with. I hope I’m slowly getting close to this goal.
I spent all of New Year’s Day making the drag and drop mechanics feature-complete for one of the in-game menus.
It’s been amazingly more complicated than expected to implement something that I use in my OS and other games every day without even thinking about it. When you pick up a sprite to drag it somewhere, you have to record such a huge amount of information about what you’re doing and what you might possibly plan to do with that sprite.
I use the mouse cursor as an entity which records what it’s carrying, where it started carrying it, where it’s considering throwing it to, what it’s doing with it at the moment, and about fifteen other things. When you release the mouse button, the game has to check so many things regarding “Is this a good place to drop this?” that it’s amazingly easy to leave loop-holes that can be exploited and result in duped items or creatures.
Another important thing is to only check certain “drag and drop” conditions if you actually need to – because you’re looking at doing a huge number of checks on a per-pixel basis, you can’t do that every frame all the time; you need to turn certain features on or off depending on whether they might possibly apply at any given time.
In the end, everything turns out very satisfyingly tactile and you can kinda “throw” objects around between windows in a smoothly rendered way. I like the result so I made a little video about it.
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.
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.
I’ve been working on lots of little mathematical bits of graphics for UI stuff and also simple in-game animations. You’ve probably seen the “Spawn In” animation where people seem to drop out of the sky, which is all animated procedurally, but I’ve now added a nice little line-graph UI element for a new game system and I’ve just finished the particle emitter system.
I uploaded a video showing the particle emitter system being built from scratch if you’re the sort of person who likes to watch that kind of thing. Also, an irrelevant animated gif.
While making the “Popup” boxes work in a fully implemented way, I recorded ten minutes of my desktop footage just to show a little bit of my workflow. Most will find this kind of thing extremely boring, but some people might like to see how a game actually gets made.
The video basically shows the “Warm Up” bars being displayed when a creature doesn’t have the big popup box open over an object they’re working on. I wanted it to be clear that a creature keeps working on an object even after you close the popup box and go do other things. Once the creature finishes working on the device, a “Cool Down” bar appears over the device (This part was already working prior to recording).
Still concentrating all my work on the popup boxes, I’ve got them linked into the AI decision-making process now so they are actually opened by creatures instead of the player directly. Creatures decide to “Go Open Popup” and walk over to a trigger to open its popup box. Only player creatures can make this decision, which is caused by clicking on a trigger while a playable creature is selected. Other, non-player creatures can interact with triggers without using the popup boxes.
The popup boxes are now handled inside the AI loop as well, meaning they can actually cause things in the game world to happen. At the moment, opening a trigger’s popup box and clicking anywhere inside the popup window will cause that trigger to fire off all its linked objects.
Eventually there’ll be multiple buttons on the popup windows, each with a progress bar for how long it takes to use that button, and a cool-down for how long you need to wait before using that trigger again. I’ve implemented the graphics for the progress bars upon the popup boxes, but they don’t actually do anything yet.
I’m progressively building a small GUI engine to place inside the popup dialogues that appear in-game. They will eventually be the main way that the player interacts with objects within the campaign, so they need to display text, icons, buttons, and basic animations. They also need to be able to detect clicks with perfect precision.
These things would usually be easy if it weren’t for them being placed on a not-square surface. I spent today getting the click detection working for them, and making the little red “Close” button at the top-right work. I’ve also implemented the text rendering on the face of the popups.
The font looks incredibly ugly. But when it appears in game, it looks quite effective. I’m pretty happy with the result so far.