Robot'em Up! - Graduation Project - 2019/2020

Lead Game Designer | Vision Owner

A 2-player beat'em up in which you fight using Basket-ball moves with an energy ball. Pass, dodge and dunk on your enemies and progress through a mysterious city.

8

9 Months

Graduation

Unity

What Went Well

Main tasks

We were able to prototype the different features very quickly, allowing us to make a lot of iterations to improve our core gameplay. I've been able to integrate a lot of Signs & Feedback which ensure a clear understanding of our game.

What Went Wrong

Lead Game Designer : 3C Design, AI Design, Combat Design, Documentation, Technical Design, Fast Prototyping

During the pre-production we had a lack of communication between Game Designers and Game Artists, so the Art Direction didn’t serve our gameplay, not readable and simple enough for the fast-paced action of our game.

Vision Owner : Communication, Brainstorms, Presentation, Documentation, Feedback giver

What I learned

I learned a lot as a vision owner, how to communicate the way I saw the game to very different people with different trades. I also learned a lot as a Game Designer, using personal processes and embracing the iteration for every part of the game.

Miscellaneous : UX Design, Accessibility, Animator, VFX/Shaders

3C DESIGN

 

As a designer I wanted to experiment on 3Cs this year in a holistic way : Design, Programming, Animation

This video is the result of the 3Cs after the 3 months of pre-production which answers two of our intentions :

"Punchy Action, Flashy Reaction" and "Basket'em Up!" which refers to having a combat system and feel which include basket-ball moves.

Technical Specifications

So the first step was the documentation.

As an example, here is a technical document made for the arena camera. The goal of this camera behavior is to make fights highly readable while keeping some dynamism.

So as you can see on the document, it can rotate along an axis and move forward/backward to follow the player's middle point.

The arena camera was also designed to be easy to set up in order to iterate quickly on the LD part.

Scroll Down to view PDF

Available parameters

Then I worked in a close duo with a gameplay programmer to include all the parameters I wanted to tweak.

This allowed me to find the right balance between the animations feel and the snappiness of the controller.

By tweaking this variables from 0 and through multiple iterations, I've been able to get the wanted feel and to not miss any opportunities, I created different presets with different inertias, max speed, drag, etc...

Testing this different presets against the enemies created different dynamics. E.G : player's max speed < enemies' max speed + high inertias --> Make players feel like a prey, have to kill the enemy before he gets too close

Here are some of the scripts with available parameters that I had access to.

Movement Set challenge

Our players are fighting with a twin-stick controller without any hitlag while our enemies are often constrained by their short reach and movement speed.

Giving too much movement options to players could have ruined the experience by making it too easy to dodge everything. I tested the game a lot with different moveset which varied with the player's speed, the ability to jump, climb, grab, dash, etc...

In the end we canceled the jump because it gave too much movement possibilities while not being very readable nor pleasant with our 3/4 Top-down view, and limited the dash with 3 stacks that slowly reload overtime. The climb and grab mechanics were designed to offer pacing and verticality during non-fight scenes, the climb is automatic whenever a player comes towards a climbable wall which results in a low brainload mechanic, while the grab requires specific positioning and inputs which results in a higher brainload. By alternating the two of them, we've been able to offer a more controlled pacing during non-fight sequences.

The result asked time and a lot of A/B Tests with playtesters but was too critical to overlook. I ended very happy with the result

WIP to real Animations

Along the way I made WIP animations for every movement/action, using basic shapes in order to get the feel right as soon as possible. This allowed us to have a convincing prototype during the early stages of production. (fig1)

Later in the production I worked on real animations and their integrations through blend trees and additive/override layers. Here's the blend tree that allow our player to face any directions while moving wherever he wants. (fig2)

Note : I did the side runs animations and reworked the forward run. the others were made by an artist.

fig1

fig2

Collision, Crowd Control & Action Cancel

In order to bring a more organic feel to in-game's actions and collisions, we added crowd control elements which helped a lot.

Light Push

apply a impulse force directly to the physics component of the character without canceling its actions.

Heavy Push

push the character away and cancel its current action.

Bump

push the character away, cancel its current action and take a second to be able to move again.

Wall Splat

if the character touches a wall during a Heavy Push or a Bump, he receives extra damage and take a bit more time to be able to control its character again.

Adding these controls to some existing hitboxes or to exotic level elements allowed us to have very organic reactions and fight intensity.

For example for the boss, its punch' attack had a clear damage hitbox (the red square) but on top of that we added an invisible hitbox (represented by the blue rectangle) which caused a Heavy Push crowd control on players, not damaging them but which gave a clear sensation of power from the boss.

Accessibility Guidelines - Option Menu

I wanted to integrate accessibility options which would let more people to play our game flawlessly.

In order to do that I regrouped all official accessibility guidelines from "Easy" to "Medium" difficulty and sorted them by difficulty to integrate and how much it brings to the game.

Then I chose the different parameters that could go in the option menu and a gameplay programmer integrated it.

Every options with a red square is what affected the 3Cs, directly or not.

By thinking about it early in the production, we were able to integrate it easily.

AI DESIGN

Creating enemies - Ideation & Selection

The first step I went into was to simply come up with dozens of enemies rough ideas and behaviors, may it be projectile patterns, movement or attacks, trying to take inspiration from various games and movies. Trying to come up with as much ideas as possible instead of focusing on the first idea which seems appealing allowed me to broaden my vision and to have a pool of ideas and behaviors to pick from.

After that I had to select which one should be prototyped. I did this selection by choosing the enemies which directly answer to the player's abilities, are easy to understand, to prototype and which would have good synergies when put together in a battle.

At this moment, I thought that having a basic melee enemy and a turret would enable us to have a simple but entertaining combat so I went on prototyping these 2 before going on more interesting designs.

My intention on the AI Design is the same as the 3Cs : design them in a holistic way : including Design, Programming, Animation.

This video displays an arena of our Vertical Slice, featuring our 5 enemies.

fig1

Fast Prototyping - Mistakes and iterations

After 9 hours of work, I had my first melee enemy working, I worked on WIP animations, used the built-in NavMesh from Unity and went for a simple state machine with Enter/Exit conditions and events. With that, a few attack and bump coroutines, the melee enemy was ready and allowed us to have our first punching bags.

After that I prototyped the turrets (fig1) and quickly came to the realization that they actually played the very same role as the melee enemies : invite players to flee in a single direction. To change that, I decided that the turret would anticipate player's movement which ended being the perfect result : as a player you flee the melee enemies while having to take some backsteps to not get hurt by the turrets' projectiles. The synergy of these two put players in a constant positioning dilemma, which directly answers the main challenge of our game : positioning, needed to shoot the ball at the wanted location and dodge enemies attacks.

After a few adjustements on their readability and firerate, it turned out as on the fig2.

The different turret's iterations took me approximately 6 hours to make it right (animation, code and feedback included).

fig2

Smooth & Adaptable Blends

By choosing when to trigger animations at certain percentages of actions, I've been able to make the animations match the wanted feel.

Here the variable "When To Trigger Falling Anim" (fig1) enable the falling animation (fig2) at 90% of the bump duration.

Here it's a combo of 2 animations : the "bumpBegin" which stays at the last frame until the animation "bumpFall" is triggered. This way we can change all the distance and duration variable while keeping the animation's feel.

fig1

fig2

Frame Datas

Another advantage from making WIP animations is that I've been able to test quickly and come up with frame datas that we already iterated on

This way, the support animators and myself were able to create the animations faster.

Providing the key poses moments and the animation layers also helped a lot to know what your animations must look like.

And since every WIP animations were integrated, replacing them with the new ones were quick and easy.

The Shield Enemy - Case Study

The shield enemy is certainly our most interesting enemy. If the player's ball hit the shield, it instantly rebounds on it and deals no damage to the shield enemy.

The way it directly interacts with the player's main mechanic seemed like a really cool idea but it came with many interesting design problems that I had to solve during the development.

On the right is a One-Pager with a template from GDKeys.com which I modified a bit to suit my needs. 

SHMAR stands for Strength, Health, Movement, AttackSpeed, Reach.

The Shield Enemy - Iteration 1

The first iteration included the shield in front of the enemy which made the ball rebound as on a wall (according to the ball trajectory and shield's normal direction), and a charge attack in a straight line.

The first thing I saw was that losing the ball when you hit its shield was very punitive and that its attack was either easy to dodge if we set a long anticipation time or too frustrating with a short one, no tweaking felt right.

Our next step would be to make its attack more interesting to dodge and to make the rebound more forgiving.

The Shield Enemy - Iteration 2

For the second iteration, we modified the attack so that he can turn during its charge, which made it more dangerous and increased the need of a dash to be safe. We also made the recovery time longer so that a good player gets the time to hit him once in the back after its charge.

And for the rebound we made it so that if the angle difference between the "classic trajectory" and the Vector "enemy to player" is less than X, then the ball directly comes back to the player. That way players immediately had a second chance to pass around him.

After this iteration the attack felt a lot better and the rebounds were more forgiving. But it still felt like a mini-boss to most players, which spend sometimes one minute to take him down due to its shield. So I had to find new solutions to make him easier to fight while keeping the shield mechanic as it is.

The Shield Enemy - Iteration 3

On the 3rd iteration I decided that the enemy would lose its shield for a few seconds once he gets hit in the back. This way, once players get his shield down, they can chain him with normal passes and finish him. 

This way it rewards players for understanding the enemy behavior and to take him down but took less time to take him down.

The final problem that I had was that the shield enemy would unexpectedly change focus from one player to another, which often happened when one player tries to get in its back.

I took some time to spot this problem but once I found it I just tweaked the variable (which handle how much distance difference there must be between both players to change focus) to an absurd number which made sure that the shield enemy would always keep the same focus, making him more predictable.

 

It took multiple iterations to get its behavior right but it allowed us to have an interesting enemy which interacts directly with the player's core mechanic and is readable.

I also had the chance to do all the shield enemy final animations, including the GIF on the left.