Role: Combat Designer
Engine: Unreal Engine 4
Tools Used: UE4(Blueprints)
Team Size: Solo
Responsibilities
❖ Design and implement combat system.
❖ Prototyped and adjusted attack animations in relation to startup, active, and recovery windows with Unreal Engine blueprints.
❖ Prototype, iterate, tune, balance character abilities
❖ Design, create, and implement combat related feedback
❖ Implement block and parry system
❖ Design and program AI behavior
DevLog/ Update #3
I have been fleshing out the game more, and that comes with a major art overhaul. It is important to think about the 3 C's in game development which is something I was thinking about a lot as I continued to work. Where as the previous updates were largely prototyping mechanics that I thought were cool and getting a feel of a 3rd person action game in Unreal, having a better grasp of what the 3 C's means in relation to this project can help solidify the player experience into something that is tangible.
Basic level Layout / First Look at art
Character: Maya to Unreal
First and foremost was getting a character that would be the player in engine. I have been using rigs from Truong CG Artist to get a better understanding of rigging and animation in Maya so I thought it would be insightful to go through the Maya to Unreal pipeline first hand. There were some minor issues with the export from Maya and import to Unreal such as textures not being imported properly but a consistent issue was the model having this unsettling stretched neck during animations. To combat this I played around with the skeleton in Maya and the joints in the neck area in specific to reach a result that still has some issues but is less unsettling in my opinion.
Model missing Necklace & Braces on ankles & Right Arm
Stretched Neck
No/Less Stretched Neck
Stretched Neck
No/Less Stretched Neck
Camera, Control, And Player Feel
For a 3rd person action game, camera and control are very tightly connected. Where as in first person games where everything is in front of you, in a 3rd person game the player character usually has a myriad of animations for all of their actions. A player wants to be able to see all the dazzling string of attacks their character can inflict on their enemies, but the camera also has to be able to show off important things in the world to progress while also not get in the way of the player from performing actions. This all ties into if enemies are stratifying to hit and if the game feels good to play. With the overhaul in art, the camera and control are things that are going to be playtested constantly to ensure the game does not feel bad to play.
DevLog/ Update #2
While the first update was more about functionality I was aiming to make hitting the enemy satisfying. To achieve a better combat feel I added particle systems, camera shake, as well as fixed some of the timing for attacks.
Testing new hit impact particles, added camera shake
Impact Particles
Added Strong/Heavy attacks
Dodging
Dodging Enemy
Added Blocking
Blocking Enemy's Attacks
Parry/ Perfect Block
Compelling Player Options
While making hitting enemies feel satisfying it is equally important to get the player interesting defensive and movement options. If a player can get by the entire game with only one button what is stopping them from doing so? One mechanic I sought to create for this reason is perfect blocking which is shown on the left. If you block right before you get hit, time slows down and can unleash an onslaught of attacks on enemies.
A basic tactical spell cast was also prototyped. Within the spell casting it slows down time for a break from all of the fast paced action for a more calculated attack.
Casting Magic
Devlog/ Update #1
Basic Movement Functionality along with 8 Way directional movement when locked onto an enemy
4 Hit basic combo from attack 1 to 4 as well as testing impact particles
Attacking an enemy
Air Combat
Transition from ground combat to air combat
Prototyping, Iterating, and Tuning Combat
The initial inspiration of the combat was the stylish combat found in games such as Devil May Cry and Bayonetta. With this in mind the first steps in the process was to get basic player functionality on the screen and to make hitting an enemy feel satisfying.
The main framework for the combat was to have an assortment of animation montages that would play with each button press. Each animation would have a series of animation notifies that would fire off events to start and end hit detection as well as the first frame the player is able to continue the chain of attacks. A weapon trail and basic particles were added to signify the active hitboxes and successfully hitting an enemy successfully.
The moment something was functional it was then tested for game feel. Was the combo window too strict, did hitting the enemy not have an impact, was the combo not flashy enough? These were some of the things I was trying to observe as I tuned the combat experience.
Hit Detection
When attempting to solve whether an enemy was hit there are various solutions. We could just align a simple box collision on the weapon mesh and call it a day, but I wanted to see if there was a better way to do hit detection. After doing some research I ended up using a spheretrace to trace along the path of the weapon. Socket points were put on the weapon mesh and when an attack animation starts we start to trace along the previous location of the socket to its current location. This creates a net like structure that should detect if an enemy is hit between the individual traces. While it seems to work fine this is an ongoing concept that I am researching as there is always another way that may be more accurate or require less computation, which is important in fast pace action games.
Hit Detection Concept (Trace from S1L1 to S1L2 to S1L3 etc.)
Hit Detection Traces
