Summary

Game Description

Bardo is an action-adventure game taking place in the realm between life and death. Explore the fantastical, shattered world of your own mind by gliding through the sky to reach floating islands and faraway vistas. Overcome your inner demons as they threaten to prevent your ascent back to the world of the living.

The Deliverable

For this school project, our team was assigned a visual arts concept from the previous school block. The concept included concepts for the environment, characters, visual effects, and more.

Our goal was to use this concept and create a game demo. So, we were tasked with conceptualizing, producing, and releasing the game within 8 weeks.

Project Information

  • Engine:
    Unreal Engine 5

  • Platform:
    Windows (PC)

  • Genre:
    Action-Adventure

  • Release Date:
    June 2024

  • Context:
    University Project

  • Project Duration:
    8 Weeks

  • Team Size:
    22 people

Responsibilities

Project Role

This project I worked as a Technical Designer, focused on designing the Combat of the game.


I also helped as a general Game Designer, concepting the game, brainstorming ideas and playtesting.

Contributions

  • Designing and implementing the player combat system which includes:

    • Melee and Ranged Attacks

    • Aim Assist mechanic

    • Bullet Time mechanic

  • Creating the combat animation system which includes:

    • Input Buffering mechanic

    • Smooth Animation Transitioning

    • Aim Offset

    • Animation Flagging

  • Implementing the combat animations

  • Playtesting the combat and iterating.

  • Interfacing with Animators on the requirements for the combat animations.

  • Interfacing with Enemy Designers about the interactions with the player.

Process

The Concept

With the visual style and environment we chose, the scope for the game seemed to be quite big. So, our biggest challenge was trying to keep a reasonable scope as we only had 8 weeks to develop the game.

We decided that our game would focus on gliding through the world while fighting enemies to reach the top and defeat the boss enemy.

I was in charge of the combat, but because we only had 2 animators, the amount of animations we were able to have for the player was not much, so we decided to keep the combat very simple.

Player Combat System

What:
The player combat mainly consists of shooting ranged beam attacks used to take down enemies and activate crystals. The player can choose to shoot the beams freely or while aiming.

The aimed shot zooms in on the screen, allowing for more accurate aiming. When used in mid-air, the player enters bullet time.

The ranged attacks also have aim assist, so when the player aims towards a crystal or enemy but is slightly off target, the beam will lock onto the target to ensure it hits where the player intended.

How:
When I started building the system, I focused on actual melee combat, so I created hitboxes for the slashes and communicated damage and knockback to enemies. Then, I quickly transitioned to focusing on the ranged attacks as our gameplay concept shifted and we focused more on the gliding mechanic.

Why:
We chose a more ranged combat focus to easily combine it with the gliding mechanic. This way the player can shoot enemies from a distance while platforming and flying. Due to the limited time of the project, this also seemed the most feasible option.

Combat animation System

What:
The combat animation system I made allowed us to make easy attack combos and tweak the animations that would play. Which allowed us to easily replace the placeholder animations with the final animations.

The system also includes input buffering, so even if players quickly mash the inputs, the combo will play smoothly. It allowed for easy animation flagging, which we used for the hitbox detections, the timing of the ranged beam attacks and more. The system has a data table in which values like damage, knockback and stun can be tweaked.

Lastly, I also worked on the aim offset of the player. This made it so the player would always look towards what the player was aiming at. I also ensured that the animations would blend correctly while running and flying.

How:
I used my Melee Combat Animation System as a base for this project and improved and built upon it to create an animation system that fit this project. I was able to do this by properly communicating with our animators and understanding what they were capable of doing in this short timeframe. In the end, we downscoped a lot for the combat due to the limited time, so we ended up with one simple 1-2-3 combo.

I created the aim offset by editing the idle poses that the animators made, getting the camera angle and tying those together.

Why:
The combat animation system was made to ensure that players would notice no inconsistencies or visual bugs in animation while playing the game and that the attacks would feel natural and easy to use.

But it also acted as a great tool for quick iterations and prototyping. Because the system is so modular, I could easily test and prototype using placeholder animations and could replace them with the new animations as they were being worked on without having to rework much.

Takeaways

Huge Scope = Less polish

One major takeaway is that the bigger the scope, the less time you will have to polish aspects of the game. With the 8 weeks we had, we managed to make a content-complete demo but lacked some overall polish that could’ve enhanced the overall gameplay experience. If he had 2 more weeks of development time, I think the result could’ve been much better.

Alignment is key

Another thing I noticed was how once the team was somewhat aligned on the concept, we were able to work much more efficiently. If you need to keep explaining the concept to team members, a lot of time will be lost and they might deliver work that is not aligned with the rest. We were able to align rather quickly and come to mutual agreements, which sped up the development process a ton.

Next

Galactic Goo