DESI1212 2017-18 Games Incubator - Evaluation

 DESI1212 2017-18 Games Incubator - Evaluation

As the team's character designer, character modeler and character animator, almost all character related development was to be handled by me, including the implementation of any assets created and their integration with gameplay systems.

Roles:

Character Designer:

Designing the characters for this game provided its own unique challenges and quirks. I decided very quickly that despite our low-poly aesthetic I wanted characters to have exaggerated and interesting designers and animations.

The original idea for our sole character in the final release, Big Boy, was always a top-heavy character with very little features. The focus of this character was on having a strong silhouette via body proportions alone, especially when compared to characters that may follow. I designed this character without knowledge of whether we would have a class-based system where characters had different stats or if we would force players to be a character depending on their team, so I designed Big Boy to have a silhouette unique enough that his appearance alone would distinguish him from future characters.

As mentioned previously, focus was placed on the silhouette and posing of the character. I wanted our characters to always display interesting poses and a strong silhouette that differentiated them from each other. The 12 principles of animation would play a large role in achieving these exaggerated animations.

Originally we intended to have multiple player characters to keep in theme with our game's concept of being multiple factions forced to fight. However, due to time management issues and issues ensuring Big Boy worked correctly first, many of the characters never made it beyond initial concept art.

While Big Boy was the only character to make it into the final submission of the game, out of the characters I drew concept art for he was the closest character to achieving the goals I set for our character designs.

Character Modeler:

Our team agreed on a low-poly aesthetic relatively quickly and this immediately presented the challenge of how my goals for interesting silhouettes and dynamic poses could be achieved on character models that, by design, have far less polygons than most video game characters, especially those designed for exaggerated posing and articulation. One solution to this problem was to model the characters in such a way that their topology created interesting silhouettes. While this isn't as visible on Big Boy, the female human character exhibits this approach to design.

The first model of Big Boy, as seen above, was merely a test skeletal mesh for the coders to work on character related systems with and test attaching weapons. This model was very close to the final and it's main use at this stage was to test whether it would be possible to achieve my goals for the character.While the rigging wasn't as thorough as it would be later, it showed that even a featureless and low-poly character like this can convey character and provide a powerful silhouette through posing and animation alone.

The final version of Big Boy has finger joints and a joint for attaching weapons to his hands.

The second and only other character to make it beyond concept art, the human character, posed their own challenge towards my goals. I designed the character with realistic human proportions, but also considered exaggerating their lower body and giving them a slimmer appearance as a direct opposite to Big Boy's design, which exaggerates the upper body.

The first pass of the character model, with an early attempt at a visible head.

The same model with UV mapping applied for team colours.

A further refined version of the model.

The final version of the model, with updates boots and a head.

A view of the topology of the model from the front orthographic camera.

As mentioned previously, techniques were used to achieve a defined silhouette and shape the model in interesting, more organic ways:


By rotating the edge ring of the character's clothing it is possible to achieve more interesting looking clothing folds without using any additional polygons. With slight exaggeration it becomes easier to tell the difference in material between certain items of clothing the character is wearing and give the characters a stylised appearance despite the low polygon count.







For comparison, the image on the left shows the same sleeve with the edges rotated to how they would have been when first creating the arm. Manipulation of topology in such ways is crucial for more organic and natural character modelling at such low polygon counts.






For this project I knew I wanted our characters to have colour customisation from the very beginning, as such they were designed in such a way to not have colours clashing too many times, instead opting for colour options effecting entire layers or sections of clothing. This meant character colours would be far more readable at any distance as the surface area a single colour would effect would be large enough to be seen.

For character customisation for work, I had to write a shader that would use a mask to apply a colour defined by the user on certain areas of the model according to the UV map.

The Albedo texture. This won't be seen in game and is simply used as a default.

The mask texture.

The material. Using the generic ColorMask parameters the 3 different sections of the texture can be coloured freely.

The strength of this shader is that thanks to simply requiring 3 generic colour inputs we can allow players to freely colour their characters, or assign presets if need be. When implementing this shader we were not certain if we would include any team game modes but if we did it would simply be a matter of assigning players colours based on their team, or providing them certain shades of a team colour to still allow them to have a choice while helping differentiate teams.

A model for one of the Overlord characters that would be featured in our game. This model, unlike the characters, features blend shapes for facial animation. Thanks to blend shapes we can easily animate the models using preset vertex movements, inside Maya and even within Unity itself. Only one was completed in time for the submission.

Animator:

As the team's animator I was responsible for all character animation and the implementation of those animations. Due to being a third-person perspective multiplayer shooter, there was a lot of work required to ensure that characters fun to play as and against. For a multiplayer environment it was important that characters provided all the information players would need simply from their silhouette and posing.

For instance, it should be easy to tell what weapon the player character currently has equipped from all angles. To achieve this I made sure that the different planned weapon-specific animations showed what kind of weapon a character was using by their silhouette alone.

Heavy weapons would be held over the shoulder, providing a much more top-heavy silhouette to the character.

Medium weapons, such as assault rifles, would be held at hip-height, around the middle of the character, reinforcing their status as medium-threat weapons.

Ultimately due to time-constraint and animation controller issues we only managed to implement the medium weapon animations.

Animating and implementing character movement animations was a very complex task, specifically when it came to combining multiple animations together. The character was first animated with a set of basic unarmed movement animations for 4 directions, forward, backward, left and right.

Crouch Walk Forward

Crouch Idle

Jump Start

Jump Idle

Jump Land

Assault Rifle Idle

Assault Rifle Run Forward

Assault Rifle Fire

Using an animation controller in Unity, I designate what animations should play in different situations and how. For example, all directional movement is handled by a 'blend tree'. A blend tree allows us to define an array of animations that will play depending on the values of parameters they are assigned to. The blend tree will then smoothly blend between them based on those values.

The node graph for the base layer.

 As seen above, the base layer contains nodes for standing movement, crouching movement and jump animation states. The animation controller can transition to these different states when specific criteria are met.

The parameters tab shows all of the parameters I have set up for this animation controller.

The parameters 'Horizontal' and 'Vertical' are used for player movement and refer to the movement direction the player is inputting on their control device, whether it's a keyboard or controller. This value is set via code in the player movement script and updated when needed.

Visualised on the right is the blend tree motion field. The blend tree blends animations based on what the current horizontal and vertical values are, with the maximum being 1 and the minimum being -1. For example: If the vertical parameter is 0.5 and the horizontal 0 then the blend tree will blend the idle animation and the forward run animation equally. Likewise, if both vertical and horizontal were to be 1 then that would be the upper-right of the field, meaning forward and right, and it would produce a blend of the forward run and right run animations giving us a diagonal run cycle.

'isCrouching' is self explanatory and will cause the movement blend tree node to transition to the crouched animation blend tree and that node will transition back when the player is no longer crouching. 'HoldType' is used to determine what weapon the player is currently using. Using code to set this variable we can switch between animation sets via transitions, allowing for multiple weapon animations.

Using the layer system we can override animations easily. By defining a mask we can set what joints are affected by this layer meaning we can make the player character use the upper body animations of the medium weapon animations while the lower body continues to use the default unarmed animations. By using the 'sync' tickbox the layer will copy the node structure of the specified layer, meaning we only need to set up one set of nodes and then use the syncing option to change the animations to the weapon specific ones when needed.

With multiplayer video games it is not only important that we communicate what weapon a player is holding at any time but also where they are aiming, especially in the case of a third person shooter. To do so we can use the blend tree system and update a aim angle parameter that will allow the blend tree to blend between the two poses.

Blending between the two poses.

Evaluation:

Overall, I believe this project could have gone so much further and my work in the final game is not what I wish it were. A lot of these issues stem from lack of familiarity with Unity and some issues with Unity that were too time-consuming to realistically overcome near the end of the project. One such issue was the default movement animations and the weapon movement animations not synchronising as desired. This is caused by a difference in animation duration between the default running animations and the medium weapon animations.

Both of these animations are the exact same length in Maya, yet in Unity they are different lengths. Had I managed my time more efficiently I would have been able to spend more time trying to solve this issue but unfortunately despite all my attempts I could not. This, among with other issues caused with my lack of knowledge with Unity, made even the most basic of tasks for me in Unreal Engine 4 a larger task than I anticipated. While I ultimately learned a lot due to this and I am now far more knowledgeable of Unity than I was before, I wish I allocated my time more efficiently to properly implement all of the features and content I sought to include.

If I were to continue working on this project my first priority would be fixing the animation controller sync issues that currently cause the player to animate incorrectly. As a lot of issues and unfinished aspirations are due to time management issues, being given more time or the ability to work on the project again would give me the time I need to properly realise all of the work I aimed to finish.