It’s been two weeks? Oh dear, I’m so sorry. Tyler and I have been rather busy with all sorts of things, it must have slipped our minds. Fear not, work has not ceased on HitBox, it’s been going smoothly and we’re making great strides to get the game ready for the Synapse event next month, as well as the multiplayer demo soon after. Let’s get into exactly what’s been going on.
As much as I understand controllers are not required for a PC shooter, it’s awkward for us to go to events and have people sit with a mouse and keyboard. Ideally we want HitBox to be playable on a big TV with 4 player split screen, each player holding a controller at the event. And so it was deemed necessary to get controller support up and running soonish.
The first major issue we encountered was navigating menu’s. Unreal’s system for doing this is incomplete and it proved difficult to get it to work the way we wanted to. It was unreliable, it didn’t work particularly well with the menu’s we’d designed for a mouse and keyboard and it was generally buggy and irritating.
An important decision had to be made here, one that was not taken lightly. How do we enable players to use the menus with a controller, and have it work reasonably well?
Inspiration came from a controversial game called Destiny:
We wondered how well a cursor would work with controllers in HitBox’s menu systems. After some quick tests it was discovered it worked quite well actually. It frees us from the limits of linear, grid based UIs, and allowed us to control a variety of different menu screens with nothing but a controller.
Then came another issue, how do we make it work in split screen? The cursor is the windows system cursor being controller by a gamepad, but windows doesn’t support multiple cursors. We ended up modifying Unreal Engine itself to implement software based cursors for each controller plugged into the game. The result looks something like this:
Sure it’s unconventional, and some people will likely dislike it, but hey, it works great.
Controller aim assist
Another important part of controller support is the often controversial topic of aim assist. Players tend to be insulted by it’s use, but the fact remains that it makes shooters on console feel a lot nicer to play. And it almost always makes players using a controller far more effective.
For HitBox we wanted a very subtle aim assist that wouldn’t get in the way of your playing. If the player is irritated that the aim assist isn’t letting him do what he wants, it’s too strong. So it needs to be weak but effective.
One of the most basic aim assist techniques is to slow down your rotational speed when you’re aiming at an enemy. We decided against this as it causes problems when aiming at moving targets. Imagine a player is moving perpendicular to you, and whenever you aim at him, your aiming sensitivity decreases, and so you aren’t able to catch up to him and shoot him. It’s this situation we want to avoid. If the aim assist ever stops the player from shooting his target, it’s wrong.
The solution we went with was two fold. First we ever so slightly nudge your aim toward an enemy we think you want to shoot at, always being careful to give priority to player input. Then secondly we give a wide birth to bullet shots. Essentially bending the path of the bullet toward an enemy if you’re reasonably close to a hit.
It works really well and feels nice. We have yet to test it with non developers, but it isn’t obtrusive and helps greatly with accuracy.
Here’s a gif of it slightly tracking an enemy. Note, in this gif I am not touching the right (aiming) stick at all, all aiming is being done by the assist. And I could easily cancel it out if I wanted.
We’ve also implemented a feature which completely disables aim assist if you aim using a mouse. Which should balance things out.
Game voting and server traveling
The next task on the list in the past two weeks was sorting out what happens when the game ends. We previously had this screen when a match ends:
And it’s fine for an offline, single player demo. But it’s no good for online, since clients cannot request for the level to be reloaded to play again. Furthermore, the final game has multiple maps and game modes, so there needs to be some way for players to choose, or vote, on what they want to do next.
A voting system.
We put a lot of thought into this, because ideally we don’t want to have a lobby screen that you sit and wait on for 5 minutes, like a Call of Duty game. Each match must flow into the next with as little interruption as possible. So we decided we’d have everyone vote as soon as the game ended, on the post game screen, so when a timer hit’s zero, you can immediately be travelled by the server to the next match.
This is what we came up with.
It works really well. It gives live updates as to the current winning vote, and immediately travels everyone to the next game as soon as the time is up.
This is an important milestone, since it’s the first time since we broke the game following the demo release that you can now play through the game without hacking it or breaking anything. It’s once again a complete game. Which means we’re suprisingly close to our internal goal of “minimum viable product”, or the most basic version of the game that could potentially be sold as a complete product.
That’s it for this week, we got a lot done, and we hope to get a lot done in the next week with regards to cleaning up some bugs and preparing ourselves for the upcoming event. We also need to do a bit more work on the networking systems and the game will soon be ready for multiplayer testing.
Anyway, thanks for following us, it means a great deal.