Battle of the Bands:
On 09/02, I worked on creating a BPM system for the project.
I changed the BPM tracking from being manually from the game mode itself to instead being from a one-size fits all level blueprint. This would call a function every second that played a metronome.
Additionally, every 0.8th of a second, the BPM would then be modified due to the level blueprint’s speed adjusting to this through a float.
We also made it so that the song’s speed is tied to the standard BPM set in the level blueprint, and speeds up to match any BPM modifications, as seen here.
This was then modified from taking place over two seconds to one second, ensuring a smoother loop.
Every second would also add a new widget animation that’s playback speed is dependant on the widget blueprint itself.
Additionally, I also updated the HUD, most notably to include a stamina bar.
On the 15th of February, I downloaded two plugins for debug reasons. Through the Runtime Audio Importer, which allowed me to import audio of many different formats, as well as the Easy File Dialog plugin, which allows you to open the file explorer in-game, I was able to create a silly feature of being able to import custom BGM into the game through the game itself.
To begin, I first made a debug Menu, which gave you prompts to load BGM and input it's BGM.
This allows you to, upon opening your files, bring in a song that’ll play when opening the level. The custom BGM will be saved to the game instance, and will tell the level to play it upon opening instead of the song meant for it through a boolean ticked.
While I tried to add a function that analysed the song’s BPM, this wasn’t possible and I settled for allowing the player to add the BPM themselves through a textbox, one that would save over the BPM set by the level if the Custom BGM Boolean is set.
You can see it in action below;
On the week of 26/02, I worked on Character Swapping more. While still not at a stage where I’d be able to morph them all to the same skeleton, I instead continued with having their visibility vary dependant on character ID. For example, if character 1 was active, the other characters would have no visibility. This is achieved by all collision being tied to capsule collision due to the simplistic movement that comes with a top-down shooter, meaning the different between characters is only visual and based internally on a character ID.
Additionally, I added different bullets that support different play styles against different types of
enemies. For example, Character 1 can only fire a single bullet, but it’s the most powerful and reliable.
Character 2 can fire bullets around him, but they get weaker as they travel further.
Character 3 can fire waves of bullets in front of her, allowing her to hit multiple waves of enemies, but having low damage output.
This is all aiming to create a game that has character-switching at it’s very core, with the fast-paced rhythm gameplay meant to be mixed with careful strategic thinking as to what character fits what situation.
Brawl Apart
Having met with my client and played their game, I know had a feel for the kind of game I was working with, being a Multiplayer Party Btawler. Before creating concepts around the kind of interface that might come with this, I decided to look at various other games that did similar interfaces, such as Fall Guys or Party Animals. Additionally, the clinet wished for the interface to be between the cartoon-esque feel of a game akin to Fall Guys and a vapourwave neon style, which inspired me to find games that rely on purple-pink palettes to fully represent this.
To begin, I first worked on the most important HUD overlay, the interface for gameplay. Being a 4-player experience, the client wanted the player's avatars to appear as portraits, which first had me experimenting with how these portraits may look. The client had wished for the score, health and stamina to be represented in the portrait itself, with their personal idea being health representing the right ring, stamina the left side, and the score being represented through the bordering ring, which is what I had in mind when creating some of these concepts.
Then, I worked on different layouts. Being for multiple players, we had to be able to display a maximum of four infoboxes, as well as a time. There was some deliberation on however the best way to present them was, though we felt having the infoboxes tied to corner felt the most unobtrusive for a top-down enviornment.
Additionally, I did some early work on the character select screen. The clients game had customisable avatars, as well as plans for multiple player characters, which I had to take into account in creating these screens, as we'd likely need to represent these through render targets. With a baseline number of 8 given as to how many player characters to expect, I then created these concepts.
Finally, being a party-game, the client's game had multiple different game modes that it was possible to play, with there being six planned. From here, we looked at making a vote screen for the players present to choose their preferred game mode. An issue we had was how to handle mode descriptions, as they were nessecary in informing the player what mode they were playing, but you couldn't have the description box display multiple descriptions if different players were hovering over different boxes. The design we were leaning towards was the rightmost design, which would show a video preview and description only if the option was hovered over in the button itself, being the most informative and visually appealing.
Having later gotten feedback from the client, I decided to work their feedback, as well as my own desire for a more stylish character select screen into the following,
This included the space for other characters to be selected, as well as prompts for the character to edit their appearance. This was an early attempt at briging forward the vapourwave style into the game, due to the iconography of the wire-border for character selection, as well as the triangular stages that the characters stand on.
Finally, I did an early-attempt at a high-fidelity wireframe, in order to get a sense of the game's style and colour scheme. I followed the examples previously researched in creating a cartoony-vapourwave style, and feel for a first attempt I succeeded in creating a dynamic colour palette.
Additionally, I did a first-attempt at a victory screen, aiming to highlight the winning player to gratify their achievement maintaining the style shown in the main menu interface.
I also began work on the logo for this project. I first found various vapourwave logos to use as an inspiration for this process.
The first two I created, inspired by the traditional "vapourwave" sunset that you see in much of it's iconography was not one I felt particularly happy with, simply because of how they looked more like simple text over dynamic logos.
I then made this one which, while feeling better, lacked the type of "neon" that our game's style was so inspired by, feeling metallic instead.
Finally, I settled for this one, feeling it fit our game's style perfectly while paying homage to the vapourwave style we're taking inspiration from.
From here, I then made an early title screen featuring this logo.
Finally, I worked on an objective screen. I found it difficult to keep an obtuse, triangular style while still being informative. My first concept here was not to my satisfaction, for example, and felt difficult to read.
I instead straightened out this logo, keeping shapes such as triangles in-line with the style, but being more legible for the player to read.
As I brought this forward to a high-fidelity style, I also looked at fonts in the process.
The first font tested was Rametto One. While visually fine, it felt too wide in comparison to it's height to use consistently as the game's font.
Next was Road Rage. This wasn't chosen due to being far too gritty and realistic, constrasting against our game's dynamic and vibrant style.
In the end, we decided on Luckiest Guy, which felt as if it fit the cartoon-esque party game style we were going for, while being legible to use for the rest of the font.
With this, I then updated the objective screen based on client feedback, eliminating the unused empty space with a redesigned Rules indicator.
Comments