Hippo Heros

Hippo Heros is a multiplayer hero shooter developed primarily as an experiment in combat design with multiple diverse characters.

Game Engine - Unreal Engine 5

Target Platform - PC

Team Size - 3

Timeline - 3 Months

Hippo Heros Character Demo.mp4

My Contributions

Designed and Implemented Herobot Character
- Design logs and week to week process detailed below

Team Character Integration
- I implemented the blueprints necessary for each of the team's characters to interact with each other properly. I created common functions for hp, damage, UI calls, spawning in levels, and switching characters. Since each of our team members developed their character on their own We needed to guarantee that our abilities could interact with each other when we came together.
- This team ran into issues with the order of our implementations as we were highly focused in the initial weeks of the project on the combat and gameplay elements of our game without properly setting up the architecture to build it on. I personally learned a lot about creating a project that expects to accommodate multiple well-polished characters and the engineering needs of each polish element as I worked to try and integrate each part of our characters.

Herobot Design

Most Recent Dev Video

Anecdotes

Developing the Aim Reticle:

Developing the aim reticle taught me a lot about designing a simple but intuitive UI for aiming.

Situation: Players were having a difficult time telling where they were aiming both the peashooter but also the Missile/Sticky ability when firing.

Task: Develop a aiming reticle that can demonstrate both the aim location and the minimum/maximum ranges of the missile and sticky bomb.

Action: The actual development of my aiming UI took a couple of weeks. To start I created a red dot in the middle of the screen for basic aiming as that is fairly standard across games and easy to implement. My first iteration of an aim target for the missiles/stickys was to have a red target show up on the ground in the world where the ability would land but when testing that visual with players I found that they had trouble understanding how their aim affected the target location especially when aiming outside of the minimum and maximum ranges. Harry suggested that I look at how splatoon does their aim UI and as a result I ended up changing it to the current version where a outer ring will show up when the fire button is held and the player is aiming at a valid target within range. The circle will disappear when aiming too close or too far to indicate that the aim location will not actually be the target location of the ability.

Result: While this takes some getting used to in game, it is much simpler and makes it more clear when the player is aiming at a target within their range. I think my biggest takeaway is the importance of simpler UI elements especially when the player is expected to make quick decisions and may be looking at other things on screen. The advice of which games had already done this well with a similar use case was very helpful as well.

Improving Dash Feel:

One of the biggest changes to the feel of an ability came from adding some polish to the dash.

Situation: Rocket Dash felt unimpactful and slower than it should have given the intention of being a highly impactful ability in maneuvering the character.

Task: Add polish to the dash to give a better sense of immediate acceleration and speed. The actual numbers for acceleration and speed worked well so the change in feel needed to come from polish and not number changes.

Action: I added fairly simple FOV change over the duration of the dash. On dashing the FOV quickly increases to give a feeling of an immediate burst of acceleration and then gradually returns to normal as the ability ends. This does most of the heavy lifting in terms of the feel, although adding VFX and SFX to the ability is what really gives it the feeling of a rocket as opposed to any other type of dash.

Result: This was one of the first elements of polish I added to the character and really drove home how important adding basic polish can be to the feel of an ability. The dash quickly transformed from a somewhat difficult to feel increase in speed to an impactful rocket accelerating the player in any direction.

Merging and Unifying Our Game:

Situation: In the ideation and creation of our game and characters, we have taken the approach of individually creating our characters with the intention of merging them into a single game after we had already spent time working on the implementations of said characters. This has created some issues in that we lack some definitions for damage, keybinds, and UI elements that should be common across all of the characters.

Task: Create common ways to deal and take damage as players, make sure keybinds for character abilities and movement are unified across characters, and make sure that UIs are not drastically different for each character.

Action: Frankly we are still working on this part, but I've created a common third person character in Unreal that should unify at the very least the way our characters deal and take damage. Keybinds are fairly easy to unify as they just require defining common keys and then changing the existing hooks for each character. Since none of us have created particularly crazy or unique abilities this is the easiest part to integrate. UIs is where we may have issues. I have thought about and planned out our plan of attack for creating a common UI (currently in development) by allowing each character to set the cooldown time and time remaining for each of their abilities. This will require each character to assign an ability to each UI element but as long as the hooks are well designed it shouldn't be too much of an issue hopefully.

Result: In merging our characters I've realized that we've gone about this project somewhat haphazardly. Part of that is due to the order in which this class has required specific deliverables, with movement and abilities coming first before damage responses and UIs, but also we could have done a much better job about being on top of merging our characters into a single game earlier. I've learned a lot from this experience about the proper order of operations when working on a project that requires independent development of various content and although its somewhat difficult to go back and correct what we've done at this point, I have faith that if we were to start this project over we would do a much better job the second time around. Similarly if I end up working on another project that requires individuals to develop their own content separately, I will definitely make sure that at the very least key elements that are common to all parts are well laid out and developed before each person gets too far in developing their part.

Design Log

Week 1:

We mostly just talked about the type of game we wanted to make. We settled on a 3rd person hero based combat game with a focus on heroes with different play styles based on classes.

Since we are starting with a 3rd person game and movement may evolve for each character we decided to just start with the default Unreal 3rd person template for movement. I expect that as we design heroes with specific movement abilities and gameplay feel, we will probably leave the default movement for some of the heroes and alter others.

Image re-imagining of our process

Week 2:

Since our team has been handling implementations somewhat independently in terms of character design so far, this week we discussed the general type of movement we expect the game to have and what kind of verticality we should include in our designs. Our conclusion was that our verticality should mostly come from the level design and not from flight abilities.

Im loosely basing my design off of the above character "Prison Break" from the manga Shangri la Frontier, who's main mechanic is the ability to equip and remove items and incorporate them into his kit as well as use them as shields and projectiles.

As a result I built a movement mechanic that involves changing movement styles on dropping and picking up "skates". Ideally I want to encourage players to use Skate Mode more often than Walk Mode as I want this character's playstyle to be based around picking tactical times to discard parts while controlling the fight and then not spending too much time before retrieving them to regain access to their more powerful abilities. By choosing to discard the skates the player should be giving up their speed for the ability to do some precise platforming but the trade off is leaving them without any other easy movement options making them fairly predictable to chase down.

I don't think I've quite nailed the balance of movement, particularly the skate movement is difficult for me to judge how controllable and useful the dash is in terms of what our actual gameplay is, but in terms of functionality I'm quite happy with how far I got this week. I mostly just need to add a few bits of polish to the movement and then tune the numbers better when we have more defined combat to test with.

Week 3:

This week I was super busy and didn't get nearly as much as I wanted to done. In context of the ADSR envelopes I spend some time working on the different implementations of my dash so that the version with skates would have a different ADSR feel than the one without.

A large part of what I did was experimenting with how long the sustain lasts when dashing and what the release feels like as the dash ends. Since I want the skates to feel much looser and faster I added a longer sustain to the skating dash and to compensate I also added a small speed decrease at the end since it felt like the player was getting too much lingering speed to control effectively. For the walking dash I made it a much shorter sustain than the skate dash and after playing with it decided to let the base movement drag handle the release effect. Both dashes have very rapid attacks since they are meant to feel like responsive ways to dodge hazards but the goal (which I think I got close to) was to make the skates feel like an effective way to build speed or rapidly change direction and keep that new velocity where the walking dash feels more like a lunge or dodge roll. I may actually add a roll to walking dash eventually if I think the dodge roll visually feels better but thats a task for future me.

I also updated the dash so that the player can change direction while dashing which I think felt much better for control, especially when using the skate dash.

If I had more time this week I would have also worked on adding some more combat abilities with different ASDR envelopes. I think I will be leaning heavily on playing with the feedback of each ability to get the feeling of heavy impactful attacks vs dinky little chip damage attacks as I keep going. Next ability I want to add is a heavy missile launcher vs a lighter less destructive projectile.

Week 4:

This week I was focused on designing and implementing the different attacks including missiles, sticky bombs and the peashooter.

The peashooter is the character's basic way of doing damage and doesn't do much damage on its own but should allow the player to chip down the health of the opponents or finish them off if they are very low. I made it a burst fire ability to make it easy to hit at least a few of the bullets each spray.

The missiles are long range, slow, high damage explosives that let the player do lots of damage and control areas assuming they plan where they are firing correctly. Firing at moving targets will require outside setup or very good predictions. Its more on the opponent to dodge than it is on the player to hit a specific target. On the flip side once rid of the missile pack the player gets sticky bombs that attach to the first object they hit and detonate on something else hitting them afterwards. These are meant to encourage the player to spend their time without the missile pack setting up the area for combos. The sticky bombs aren't as long range but fly quicker than the missiles. Laying down sticky bombs and then using the skates to detonate them or picking up the missile pack and firing missiles at the existing stickys is a great way to trigger extra damage if executed properly.

I'm generally trying to provide the player with ways to do small amounts of damage independent of other abilities but also reward them for controlling areas of the fight to herd opponents and setting up weapon combos for massive bursts of damage.

I did also make a very rudimentary aiming capability but I need to make it more clear where the player is aiming ahead of firing and tie it to some kind of visual indicator that helps with min and max ranges as well as aim location.

Week 5:

This week I added sounds to explosions and made sure all the explosion animations were working correctly.

I also added a targeting reticle for normal shooting and firing abilities. Its very rough but helps alot with accuracy.

I also created a generic character that all of our team's characters can inherit from to have standard behavior for getting hit and taking damage but I didn't actually get to implementing damage or stagger animations or anything.

I wanted to add some animations for skating and for firing a missile but mixamo didn't have any.

If I have time to go back and add more polish I'll probably focus on some basic camera effects and animations for using abilities. A proper UI with cooldowns would also be nice.

Build Week 5.mp4

Week 6:

I conducted 2 playtests (Thank you Harry and Bill) and most of the information I gathered was related to the clarity of my aiming reticle and the polish of aspects like my dash ability.

Changes I made as a result

Changed aiming reticle to function more similarly to Splatoon, instead of placing the aim target where each ability will land, I've changed it so that the reticle always aims at the center of the screen but changes visual when the player is aiming inside the min and max fire range vs outside it. I'm hoping this makes it more intuitive for players to know where they are aiming without having to look around the screen.
Changed dash to be on Left Shift
Changed missiles to be on Right Click
Added camera fov change and pullback on dashing to improve the feel of the speed.
Added a rough model to the top half of my character so it is obvious that they can aim separate from their movement direction.

Build Week 6.mp4

Week 7:

I didn't really get to work on this this week. I created an enemy that can take damage and get hit by weapons but I didn't actually get to integrating any of the AI behaviors or polish that come with taking damage.

I did add a couple more indicators to my throwing parts but thats all I really had time for.

I want to add some basic movement and avoidance behaviors to the AI so that it can act as an aim trainer for our game. I don't think theres much other use for AIs in our game but it would be good to have a moving enemy players can practice shooting.

w7.mp4

Week 9:

This week was half catchup for stuff I missed in previous weeks and fleshing out some of the ideas I had earlier in the semester for mastery moments.

Additions:

Works for all characters (or should, currently only implemented on mine)
Cooldown indicators for 4 abilities
Parts status indicator (very rough) for my character

Gameplay

Explosives knock back all players, includes projectiles and missile pack
- Bomb Jumps
- Knockback combos

Overall most of the thought that went into the mastery moments using explosive knockback was done in earlier stages of designing this character. Bomb jumps and comboing explosives into each other or other abilities were ideas I've been waiting to implement and finally got to it this week. The UI elements are super rough but the functionality is there and I'll upgrade them next time I get a chance to make actual icons and stuff for abilities and parts.

Page updated

Google Sites

Report abuse