Tex Mechs

This project is an archived student project, the content here is considered obsolete.

Trailer

Details Breakdown

• Engine: Unreal Engine 4.22
• Development Time: 2019/7 - 2019/12 (5 Months)
• Approx. Working Hours: ~240 hrs per person
• Developers: 17

Combat System

Feature Showcase

Architecture

Architecture

Audio System

Architecture

Audio System

Sound Parenting Class Hierarchy

Sound Parenting Class Hierarchy

Brief Technical Breakdown Notes:

There’s not really a very efficient way to restrict where the audios being played since they are so not in common with each other

• E.g: Ambient sound can either being played by class, script, or drag & drop directly to the world.
• Animation Sound Cue in Animation Assets won’t be able to benefit from full blueprint support, and mostly need to follow specific keyframe in anim asset as an anim notify
• Most sound effects can be played anywhere, and are mostly one-shot (play once and GC self.) and can have overlapped
• However, BGM usually shouldn’t overlap with another BGM

With, instead of control the source, we control the actual playing sound

• Because we only care about which sound is currently playing, not so much about where it came from. (We still care where it came from, but not as much as the sound itself, and this info. is easy to gather)

So, we restrict the class type to be used first, that only a sound cue can be used to play, instead of a raw audio asset

• Audio assets are the raw wav file data, but the sound cue is an abstract layer ahead of that, we can do a lot of logics to control how the actual sound will be played
• A Sound Cue also contains a sound class, which we can assign one for each sound cue. It’s like an “identity” of each sound, e.g, pickup SFX? interactive SFX? combat SFX? ambient? etc
• Once any sound cue is being played, no matter where they came from, there’s always a sound class that can determine the “identity” of the sound

Finally, all sound classes are part of a Master sound class, which can inspect all classes that are currently being played. And dynamically control and balance them

• This is done by using a passive duck down specific sound class while other certain sound classes was activated.

Menu Flow

I was responsible for the Menu Flow, which includes the Main Menu, Pause Menu, and Game Over Menu. The Main Menu is the first screen the player sees when they start the game. The Pause Menu is accessed by pressing the Escape key during gameplay. The Game Over Menu is displayed when the player dies. The Main Menu has buttons to start the game, view the controls, and exit the game. The Pause Menu has buttons to resume the game, restart the game, view the controls, and exit the game. The Game Over Menu has buttons to restart the game and exit the game.

Tag System

Architecture

Tag System

System Breakdown:

What Is Tag System

In general, the tag system provides an efficient, elegant and robust way to communicate between different classes.

What can Tag System Do

It performs as a barebone framework to unlock the ability to implement a large number of other systems, such as ability system, buff/debuff system, even shooting/reloading or RPG elements.

This is a customized tag system specifically for Tex-Mechs, meaning it does not focus on Network Replicates/Predictions, and is a more lightweight framework. However, it should be a good start for expanding in the future.

What is in a Tag

A “Tag” refers to a child class of BPO_Tag class, which contains TagName, Duration, Payload, Stack (Detailed explanation is in below)

BPO_Tag

BPO_Tag class was inherited from a C++ class: UTagObject, which was basically a UObject, except for it overrides GetWorld() just like any other AActor (To be able to communicate through Function Library, because UObject does not guarantee to exist in current world)