Jeffrey Grow

My most recent project, Entropy 2.5, is a fast-paced 2.5D top-down action game where up to 4 players compete to collect points. To collect points, players must fly through goals by launching hazards out the back of their ship, propelling themselves forwards. These hazards bounce around the enclosed level until they come into contact with a player, destroying them and forcing them to respawn. Players throughout the game must monitor their regenerating fuel, as having no fuel leaves you unable to move and dodge hazards effectively. Players may also make use of periodically gained charges of power to activate offensive or defensive abilities to assist them. Here is a screenshot of what the game looks like at time of writing:

My primary job on this project was to provide an intuitive and useful user interface for the project, as well as an enjoyable user experience for players. The process took a lot of time and playtesting, but the results are one that my team and I are happy to ship the game with. As such, I thought I would spend some time to share a more in-depth view of that process, the choices I made, and why I made them. I will start off by talking about the games HUD, which is critical for displaying some key aspects of gameplay.

No HUD

From the very start my team knew exactly what we wanted from the gameplay. As such, our first wish for the HUD was to have no HUD at all. We figured it was a long shot and wouldn’t work out, but we decided to try and playtest without any HUD anyways. The results came back as we thought: people were confused because they weren’t sure why someone won, when they could use abilities, or why they sometimes couldn’t move.

HUD Version 1

This led to the first real version of the HUD. I wanted to keep using minimal screen real estate and displaying only critical information. The teams decision was that we needed to display the player’s fuel, their score, and if they had power to use a special ability. For fuel, I wanted a bar that looked slick but was still easy to read so players could tell at a glance if they could move. For score, I wanted players to have ridiculously high scores, because big numbers are fun. For power, I wanted it the same as fuel: easy to read at a glance. The other main decision was that the HUD for each player would need to be colored the same as their ship for clarity reasons. With this information I came up with the following HUD which appears in the four corners of the screen:

After playtesting this HUD with new players, my team found some major problems that led to a new design. The first problem was that the fuel bar was too hard to read. This became compounded with the fact that our gameplay was quick, giving players very little time to look at the corners of the screen. The second problem was with the scoring system. We couldn’t come to a conclusion on how we wanted to do scoring exactly, meaning that the space was empty. The third problem was that players didn’t usually notice they were charged with power, and those who did weren’t sure what that meant or how to use it.

HUD Version 2

This led me to the second version of the HUD. I decided to change the fuel bar from a linear bar that dropped in size to instead using large segmented pips because we felt it would be easier to read at a glance. For power, I included sprites of controller buttons in the HUD next to the power section, showing what buttons corresponded with it. For score, I opted to leave the section in because my team felt we still might use that style of scoring system. The HUD that came from this was as follows:

After playtesting this interface with new and veteran players, we gathered data that would inform my next iteration on the HUD. First we found that fuel graphic worked, and it was easier to read at a glance. However, testers generally agreed that it was an eyesore. Second, we decided as a team that the score section just needed to be completely redone. While we felt that having large number scores would be fun, it would still have the problem of players not being able to read them at a glance. As such we decided that the new scoring system would be small numbers, specifically displaying the amount of goals a player collected in a single life and how many they collected that game. Third, while we saw players starting to use their power more than before, the number was still far too low. When we asked players, we found that in general none of them noticed that they even had power to use.

HUD Version 3

At this point, our game had changed visually by miles; our play area and background weren’t static anymore. Because of this, the visual style choices I had made for the HUD became stale and needed to be completely redone. The old style looked almost like a paper cutout against the new visuals, and so I felt I needed to update the HUD to look less solid against the constantly changing background. This led to the general visual style becoming more transparent.

Then I focused on the information the HUD had to convey. As a team, we felt that the way the fuel bar was conveyed was fine, but the visuals just needed to be polished. With that, I updated the bars outline and the pips themselves so they matched up and looked cleaner together. Next, score was replaced with two separate sections of “Streak” and “Total”, to represent the changes in the scoring system.

Then I made the most drastic change to the HUD. So far, through testing, we couldn’t find a good way to convey to the players when they were charged with power through the HUD. Because we couldn’t find a way to convey it in HUD, I decided to make a particle system that made the player’s ship glow in their color when charged. This fit with the original design goal of making the HUD take up less screen real estate, and would also help solve our consistent problem with conveying when players had power to use. With all of these decisions in mind, I made the following HUD:

The team and I were happy with the results. The HUD was more visually consistent with the game, took up less space, and was still legible. The fuel bar looked nice and still conveyed the information it needed to at a glance. The new scoring system was in and displaying what was needed to the players. I was able to take a piece of HUD and turn it into a piece of UX, giving feedback on the player themselves instead of off to the side where they didn’t look very often. Power was clearer to players as a piece of UX, and was being used more often than before.

Particles, Particles, and More Particles

There were multiple other parts of the game that needed proper feedback to really create a good user experience. For player deaths, we realized that just having a cool explosion particle system wasn’t enough. My teammates ended up implementing XInput for better control of rumble, screen shake for more impact, and shaders that allowed us to create ripples on the screen. All of these together helped make player deaths feel like they had impact; it made them feel important.

During the 3rd HUD section, I mentioned that the backgrounds weren’t static anymore. This was another major change to the game to improve the user experience. We felt that with how movement heavy our gameplay was, having a static black background didn’t fit very well. So, between the 2nd and 3rd iterations of the HUD, I went to work making multiple particle backdrops. These ranged anywhere from calm floating space clouds to two clouds of energy launching particles at each other. After that, I scripted a system that would automatically shuffle through these backgrounds on a timer, creating a flowing and dynamic backdrop for our game. This fit better with the gameplay and helped improve the visuals of the game, creating a better overall user experience.

Colors and Boxes

But that’s not where the additional bits of feedback ended. As a team we agreed that players should be able to tell who was in first place at any given point. We noticed that the background particle systems I had made and the outline of our levels were white. With that, one of my teammates decided to script a system that tracked who was in first place, or if there was a tie, and then would transition the colors of the particle systems and the outlines of the playfields to the currently winning players. It again helped push the visuals further, and also provided more feedback to improve the experience of players engaged with the game.

Another bit of feedback we decided to give players in the play area instead of on the HUD was when players grabbed goals or became charged with power for abilities. We made two separate text boxes that would fade into existence near a player before fading out again. We decided on text boxes because it was different than the other feedback we had provided up until that point, making it more noticeable. The first text box which appears upon goal collection is in the players color and informs them how many goals they have gotten in that life. We decided on showing the goals from the current life instead of total because upon testing we found that players in general were more excited to win from collecting the goals in a single life versus their overall total. As such, displaying that number would help add to that excitement in the moment.

The other text box appears whenever a player gets charged with power. This helped us circumvent the problem we had been encountering for the entire project with conveying whether a player was charged or not. Whenever a player obtains a charge of power, a text box in their color would appear above their ship saying “Charged”. That combined with the particle system I mentioned earlier, helped players always know when they had abilities ready to use which could turn the tide of the game.

Final Notes

One of the largest challenges for this project was that the gameplay was not conducive to having any kind of complicated HUD. Because of this, I had to design different ways for important information to be conveyed. Once that was taken care of, my team and I had to implement those ideas, test them with new and veteran players, and then iterate on them. By following this process of designing, implementing, playtesting, and iterating, we were able to craft the user experience we wanted out of the game.