CINE1102 2017-18 Animation Studio: Assignment 2

CINE1102 2017-18 Animation Studio: Assignment 2 - Virtual Reality Project

Intro:

For this project we were tasked with creating and delivering

We decided to work as a group for this project to attempt to produce a piece of work that would allow us to focus on our own strengths and build our team skills. Due to this project stemming from my original alternate reality/virtual reality concept I decided to work as the team's gameplay designer as I have experience with Unreal Engine 4 and I wanted to challenge myself by developing a virtual reality game.

2.1 Role -  Gameplay Designer:

A majority of my focus on this project was designing and coding the player character and the interaction mechanics in the project. With no experience with virtual reality development but a lot of experience developing for Unreal Engine 4, this project was the perfect opportunity for me to develop new skills and increasing my familiarity with Unreal Engine 4's blueprint system.

From the beginning I wanted anything interactive in the environment to be as modular as possible, allowing the level designers to easily customise the base interact-able blueprint into new objects with unique actions when interacted with. The benefits of this system meant that not only is it extremely easy to quickly populate the environment with interactive objects, but all of the code for picking them up and interacting with them is already handled by the base. This means no code is actually required in the child blueprint itself for the object to be picked up, and coding what happens when the player pulls the trigger is as simple as coding from the event that is fired in the base blueprint when the player pulls the trigger.

2.2 Interactable Objects:

Interactable objects featured in the project, the first four being various base blueprints and the others being children of those bases, excluding 'Interactable Interface', which is used to allow the player pawn and the bases to interact.

Simply put, by creating the initial, basic 'base' blueprint, we can create 'child' blueprints from it that inherit the code from the parent.

The blueprint for the Base Interactable blueprint.

The base interactable blueprint contains all of the code for what happens when the blueprint actor is grabbed via the controller grip buttons. Since this outcome will be the same for all interactive objects that can be picked up, we put this code in this blueprint and leave object-specific actions to the child blueprints.

The graph for a child blueprint, this specific one being a flashlight prop.

By triggering the 'Action' event that is fired when the player pulls the trigger, specific code can be run. As shown above, code specific to an object can be added into the child blueprint, meaning each child blueprint can have unique code.

By default, interactables are coded to be attached to the hand at the rotation and position they were at relative to the player's hand, this allows for a slightly more realistic approach to holding objects. But for instances where objects should be held in a certain way, I added the ability to force objects to snap to a specific rotation relative to the hand. This would work well with weapons and other objects that should aim ahead of the player's hands at all time and ensure the player doesn't have to spend extra time rotating the object to be in a suitable position.

Using these comprehensive settings in the 'class defaults' section members of the team can easily change how each actor behaves:

• Snap: Whether the object snaps to the player's hands at a default rotation.
• Hold Location: Unused.
• Use Alternate Hold: Determines if the actor uses its default position when snapped or the values specified in the next two variables.
• Hold Transform: The position the object snaps to, relative to the hand.
• Hold Angle: The angle the object snaps to, relative to the hand.

2.3 Player Blueprint:

Coding the player character was a very demanding task as it went through many iterations with the final one being almost completely original code. Originally we intended to allow players to choose between teleportation and traditional locomotion however we decided that we would stick with one locomotion method, which was the traditional system.

The movement code for the player.

Due to the default virtual reality pawn using teleportation locomotion, I had to code a traditional movement system using the thumb-sticks of the left controller.

The turning code.

Due to difficulties with testing and playing whilst sat down, I decided to implement the ability to rotate the player using the right hand controller, allowing the player to stand still and play, without the issue of worrying about the headset cord.

Using a 'blueprint interface' we can make blueprint actors communicate. As seen in the above image the player actor detects any children of the blueprint interactable base and triggers the 'Interact event' that is sent to the detected actor. If the player is already holding the object it will instead drop the actor.



2.4 Level Interactables:

Code for detecting the player's hand and setting 'hint' text to visible.

Unlike the interactive objects that can be picked up, level interactables remain stationary and can not be manipulated besides being activated. This is used for lights and other level objects that can be activated.

A fan blueprint that is a child of the base level interactive blueprint. The wireframe collision box is used to detect the player's hands and allow for the activation of the object.

Upon receiving the activation input, the fan model will begin playing a timeline animation.

Code for grabbing.

Due to being set up in this way, it is incredibly simple for team members to quickly create child blueprints that can inherit the parent code and all that is required of the team member is to code using already established coding.

Level interactable blueprints feature one class variable: 'Touch to Interact'. By enabling this the blueprint will instead activate when the player's hand touches the detection collision box in the blueprint. This can be used the simulate the feeling of the player physically pressing a button, instead of having them pressing the trigger button to activate a button.

3.1 Character Rigging and Animation

During this project I was also the sole animator and character rigger of the team, responsible for rigging and then animating characters for animated hologram sequences featured in the game. This project was my first time rigging and animating characters sculpted in ZBrush, as such it was quite challenging adjusting my rigging techniques to the topology found in sculpted character meshes.

A routine I ensured I followed was the structuring of character skeletons and naming conventions used for their joints. This allows us to theoretically reuse animations across the cast of characters using animation re-targeting if need be.

The mother.

The father.

The rat.

The mother character has blend shapes for talking, allowing easy animation of dialogue without having to use alternative animation methods such as face joints. Blend shapes can be easily controlled in Unreal Engine 4 and this was a large deciding factor in using them instead of face joints.

In addition to the facial blend shapes for emotion and lip-syncing, I included blend shapes for hologram distortion effects, to make the holograms in the game more visually interesting. Thanks to Unreal Engine 4's animation editor the motions for characters can be animated in Maya and the blend shapes can be controlled and added to the animation in Unreal Engine itself.

The original 'talking' animation for the mother, viewed in Autodesk Maya.

The final version viewed in Unreal Engine after using the software's animation editing tools to animate the distortion flexes.

Thanks to this method of animation distortion effects, it allows the animator to have more control over the effect than if we were to use shader effects to achieve a similar result. It also allows us to purposefully distort the first and last frames of the animation to create a seamless loop transition.

I was also responsible for the rigging and animation of the hands that would represent the controllers of the player, instead of the default Oculus Touch model that is used in the final version of the game. We intended for the hand to play context-sensitive animations, such as forming a pointing gesture when their hand is in the vicinity of a interactive object or closing when holding an object.

4 Evaluation:

Our initial ideas for the game did not pan out how we had hoped do to many issues involving time management and problems with our production pipeline. Pinpointing specific reasons for the state of the game can be simplified to poor time management as a majority of our work was left till near the end of development for multiple reasons. With uncertainty with what we could realistically achieve in the time we could work on the project, and uncertainty with next to no limitations for what we could create, a lot of time was spent figuring out what we would actually create. Due to none of us having experience developing for virtual reality and having limited access to a virtual reality headset testing or prototyping ideas for ourselves was extremely difficult.

Another issue with our project was a lack of communication and a lack of experience developing for video games among some team members. As the gameplay designer I should have ensured that our team members were producing assets as efficiently as possible, however I was so focused on the virtual reality side of development that I failed to provide the team with guidelines for how our assets would be produced and implemented. Due to this, many assets have inconsistent quality and certain models are imported as separate scenes, meaning objects like books on bookshelves were exported far away from the scene origin. This inconsistency is due to differing approaches to the video game modeling pipeline due to inexperience with video game development that could have been corrected by enforcing a strict approach to how we handled assets.

This project was a valuable learning experience as I now know what I can do to improve my ability to work with teams and help my team members by establishing guidelines for our development pipeline. It has also taught me that I can should always experiment with ideas, even if there's a chance it may not make it into the final game, as I made discover or develop something that could make a huge improvement.

If I were given another chance to develop this project I would have prioritised ensuring our team understood the virtual reality development pipeline and I would have focused on ensuring all of my gameplay related coding is finished sooner to ensure the team have as much time as possible to become familiar with it. While the modular interactable blueprint system I coded was useful, we didn't manage our time properly and as such we did not make many objects using it and all it was used for in the end was to replace level blueprint code with actor blueprints. We did not realise the project we set out to create but I definitely learned a lot about Unreal Engine 4 and virtual reality. 

CINE1102 2017-18 Animation Studio: Research

CINE1102 2017-18 Animation Studio: Research

Introduction:

For this project, I would like to create an interactive animated experience. Instead of simply being an animated video that viewers view from a controlled perspective, viewers have control of how the animation is viewed and could potentially interact with it. There are three fields I have been researching and testing; augmented reality for mobile devices, Virtual reality using devices like the HTC Vive or the Oculus Rift and finally gyroscope technology in mobile devices. The aim of this project is to produce an animated experience that is immersive and provides an experience just watching an animation could not.

Ideas:

What are my interests?

When thinking of ideas I'd like to pursue and develop, I considered what my interests are and how they could translate into this project. My main interests are video games and their development, animation and technology; conceptualising ideas that involve these interests was relatively simple as I have experience with both AR and VR and a project developed for those platforms

Is it interesting?

Secondly, I need to consider whether the ideas are interesting and if it's something I feel would challenge me and develop me skill-set. While I could have decided just to create a 3D animation using Autodesk Maya, I decided to challenge myself and learn by developing for VR or AR.

Is it achievable?

Finally, when pursuing ideas that are outside my area of experience, I must contemplate whether I can realistically and successfully see the idea to completion. If I decide to work in a group, any idea becomes significantly more achievable due to working with people with various skill-sets.

Initial Ideas:

Augmented/Virtual Reality

My first idea was a project that involves augmented reality or virtual reality. For augmented reality a lot of concepts were considered, such as what platform and augmented reality system I would use, and the complications involved with them. As mentioned above, Google's augmented reality platform, ARCore, has not been released for my mobile device, meaning developing for it will not be possible at the time of writing. Developing for Apple's ARKit would be possible if working in a group due to possible members owning an iPhone.

Originally, I sought to use augmented reality to develop a simple application that could be used to view an animated scene from any perspective the user desires. As my only experience with animation was with scenes where I am in control of the camera, I wanted to explore animation ideas that could make immersive use of the user being in control of their perspective, viewing it from any angle, while still involving my focus, animation. This scene could have involved anything, from just a simple fight scene, to anything I'd find interesting.

For virtual reality the concept of the user being in control of their perspective is the same, except the virtual reality user would have a more immersive experience if they were inside the scene, instead of viewing it from the outside. Making use of video game engines, interactive elements could be possible using controllers, conventional console controllers or VR motion controllers like the Oculus Touch or the HTC Vive controllers. Interactive elements could include moving objects or throwing them at characters who would react to them in an immersive way. This would be a challenging concept that tests my animation skillset and as such I would ideally prefer to use virtual reality.


Complex Character modelling, rigging and animation project

As an animator, working with character rigs is an essential part of the animation process. To further develop my skill-set, I considered going through the entire character creation process to challenge myself. While I do have experience modelling characters with a low polygon count and limited texture work, I've never tried to model, rig, and animate a photorealistic character who could be used in a video game. While modelling isn't my focus as an animator, rigging and creating a control rig for the character is the main focus of this project.

Character animation project

Finally, a more conventional animation project that involves animating a voiced scene with characters. Most of my animation experience revolves around animating for video games or animating dialogue of single characters; as such I would use this idea as a change to focus entirely on animating a full scene involving interaction between characters.

Initial background research:

Augmented reality:

- Google hasn't released ARKit for every device yet - end of next year release planned.

- Allows viewer to view from the outside.

Augmented reality is a field that has grown increasingly popular in a short amount of time, seeing use in hugely successful apps like Pokemon GO and Snapchat. These apps use augmented reality to display characters on surfaces that the user can interact with. Pokemon GO, developed by Niantic and released on the 6th of July 2016 smashed expectations by reaching the top of the iOS and Android app stores and earning $1.6 million dollars a day on iTunes within it's first week. Not only did Pokemon GO's success expose the world to augmented reality, it demonstrated how powerful even a basic implementation of augmented reality can be in improving the user's experience and immersion. The app's integration of augmented reality is little more than positioning characters in the real world via the camera, but this paired with the player's position being tracked at all times provided a  experience that had never been seen before.

Google have been publicly interested in augmented reality for many years now with their 2014 augmented reality computing platform, Tango, that saw a small release on select devices for researchers and software developers and have begun focusing on a consumer implementation of the technology in the form of ARCore to complete with Apple's ARKit. Google's ARCore has seen a small scale release on select Android devices, those being the Google Pixel and Samsung Galaxy S8, with expectations that 100 million Android devices will be AR ready by the end of 2017, and hundreds of mllions by the end of 2018.

Virtual reality:

- Allows viewer to watch from within the scene.

- HTC Vive and Oculus Rift are expensive and would be difficult to develop for.

- The most immersive option.

Virtual reality is a concept that has existed for many years in many different forms, with the most recent and most popular being the consumer releases of the Oculus Rift and the HTC Vive, the two biggest kits on the virtual reality market. 2014 was a landmark year for virtual reality and saw the purchase of Oculus VR by Facebook, the announcement of Google Cardboard and even the announcement of Sony's virtual reality project that would eventually become PlayStation VR.

Gyroscope/360-degree video:

360-degree videos have become increasingly popular recently with Facebook and Youtube integration on mobile devices and any hardware that has gyroscope technology. It allows viewer to watch from within the scene with limited immersion but with the same appeal of being able to view a video how you want. 360-degree videos are not just limited to mobile devices but also VR headsets and mobile VR kits, making this option the most available and cheapest option. With the release of Google Cardboard immersion can still be achieved without needing an expensive VR headset, however this option lacks any interactivity, at least if it is just a video and, if Google Cardboard is used, means that interaction will be awkward due to the mobile device always being mounted on the user's face.

- Safest option with least risk, options include simple playing a 360 degree video or setting up an unreal engine animation that allows for gyroscopic camera control

Documentation Research:

In order to efficiently learn how to work on these projects, I will have to rely on documentation on the software I will be using; as such, it is very important that I see how extensive documentation is as this will be a significant influence on what project I pursue. Epic Games have an extensive library of VR documentation available on their site, making pursuing a project in VR far more realistic.

Further consideration:

Can the software run on my device?

As with all experimental technologies, there comes issues of incompatibilities with certain devices. Mentioned earlier, Google's ARCore is at a stage in development where it is only designed to work on the latest Android mobile devices, which excludes my mobile device. Apple's ARKit currently works on a far larger range of Apple devices and would be the preferable option to ARCore at the time of writing.

Virtual reality on PC is usually a very demanding task, as the computer will need to render two screens in the headset, and the computer's monitor, at a frame rate of at least 90 consistently. This means less powerful computers will have an even harder time of providing an immersive VR experience than if they were just used for conventional games on a single screen at 60 frames per second. This means that if I pursue the VR game project I will need to use a powerful PC for development and be mindful of the performance of the game if I want it to work on less powerful PCs.

Do I have alternatives?

Apple's ARKit currently works on a far larger range of Apple devices and would be the preferable option to ARCore at the time of writing, however, as mentioned before I do not own any Apple devices that run ARKit. After forming a group with multiple other students we now have an iPhone we can develop an AR app for using ARKit.

Currently, I do not own my own HTC Vive anymore and as such I will have to rely on the Oculus Rift at the University for developing the VR game project, however there are no motion controllers, limiting our interactivity to the keyboard and mouse or controllers. Unfortunately this means that the room-scale VR I was hoping to develop for on the HTC Vive will not be used, and the player's immersion in the VR game will be limited to looking around and moving with their control scheme.

Is it realistic?

With no experience developing for augmented reality, and relatively little for developing a virtual reality game, achieving my AR/VR idea seemed very unrealistic; However, I have now joined a group with several other classmates of various skills whose strengths will be an immense help in seeing the idea of a augmented reality or virtual reality project come to fruition. As others can focus on their respective fields, I will have more time to focus on developing using Unreal Engine 4 and animating, while improving my ability to work with a team.

Conclusion:

At the time of writing, I have decided to pursue a project relating to virtual reality, with augmented reality being an alternative if virtual reality does not seem realistic. While my concepts for the projects were relatively simple, due to my limited experience with augmented reality and virtual reality, our team can concentrate on developing more interesting ideas that hopefully challenge all of us equally and develop out skill-sets.

References:

Kharpal, A. (2017). Google says augmented reality will be on 'hundreds of millions' of Android devices next year. [online] CNBC. Available at: https://www.cnbc.com/2017/11/07/google-augmented-reality-will-be-on-hundreds-of-millions-of-android-devices.html [Accessed 6 Nov. 2017].

Robertson, A. (2017). Google ARCore gives Android users augmented reality without Tango. [online] The Verge. Available at: https://www.theverge.com/2017/8/29/16219696/google-arcore-augmented-reality-platform-announce-release-pixel-samsung [Accessed 7 Nov. 2017].

Szymczyk, M. (2017). Pokemon Go Is Driving Augmented Reality And Geolocation Adoption. [online] Zugara. Available at: http://zugara.com/pokemon-go-is-driving-augmented-reality-and-geolocation-adoption [Accessed 7 Nov. 2017].

Docs.unrealengine.com. (2017). Virtual Reality Development. [online] Available at: https://docs.unrealengine.com/latest/INT/Platforms/VR/ [Accessed 18 Nov. 2017].

Design Research Project: Sketchbook

Game Design Documentation

Early Development

This coursework tasked us with choosing a game genre or type and designing and developing a video game prototype. While my game was originally based off the traditional multiplayer shooter genre, it eventually evolved into a game that mixes the timed goals of racing with elements from shooting games, such as a third/first-person perspective and a weapon that can be used to attack other players.

The original concept for my game prototype was a multiplayer 1 vs 1 first person shooter that took heavy inspiration from arena shooters like Unreal Tournament and Quake. After a few concepts around this idea, I decided to try something that isn’t just a shooting game, something I thought would be fun. Taking from my time playing Team Fortress 2, a game notorious for the player’s ability to launch themselves high into the air using the game’s rocket launcher being fired at their feet, I decided to explore ideas of a game prototype based around that gameplay.

For a while in development, this game was about reaching the top of the level, with falling platforms too, hence the height counter on the FPS UI, eventually this idea was dropped and I opted to go for a more traditional approach to rocket-jumping level design.

Taking from its inspirations, my project, simply titled ‘Missile Arena’ was played from a First-Person perspective for quite some time during its initial development. Once I began work on the third person animations I make the default perspective third person for testing, with the intention of letting the player swap between the two perspectives via a key press. This was never fully implemented and the first person and third person methods of playing the game exist in the game as two separate character blueprints, with only the third person player character being accessible normally.

Online networking was always planned since the first concepts of the game, and a large amount of coding was required to get it working. Online services for the game are provided by the Steamworks SDK Unreal Engine 4 plugin, and work flawlessly in the game provided you have a Steam account logged in on the computer you are using. Another stipulation with this being an unpublished Steam game is that only people in the same continent as you can play with you, meaning I was unable to test the connection with players from other continents.

Initial Concepts

Originally, I wanted to put a lot more emphasis on player movement with air-dashing, wall jump and ledge climbing mechanics. When I implemented the first version of air-dashing I had not learned how to properly code for multiplayer, as such the way I coded the mechanic wasn’t functional in a multiplayer environment. I decided to cut this mechanic and to fully focus on ensuring multiplayer was coded properly. With the shift from a simple 1 vs 1 arena game to a rocket-jumping multiplayer game, I decided not to use development time on implementing wall-jumping and ledge climbing as the player’s missiles can be used for the exact same purpose.

The page also features the only concept art of a character model that didn’t make it into the prototype as I decided to focus on gameplay and networking systems instead of visual assets. The UI on the launcher was implemented before the game switched to a third person perspective. Also visible are two ideas for power ups which, again, are remnants of the original concept of the game.

Concept art for a test map when the focus of the game was still a 1 on 1 arena FPS.

Blueprints

This prototype is the product of hundreds of nodes of coding, as such I will show the most important blueprints.

GameInfoInstance – Contains the logic behind managing the multiple menus of the game, checking for save data and starting servers and joining them.

PlayerInfo – Contains all the variables for the player which is used for various parts of the game.

GameplayGM – Handles respawning and connecting and disconnecting players.

GameplayPC – Handles the players lap and time data and also loads player info to Serverside Player Controller.

Animation

Despite the game originally starting off as a first-person game, it was always intended to be a multiplayer game, so representing players over a network correctly was important. My initial work on animation started with the basic player movement animations such as the idle, running and jumping animations. Animated .gifs of most of these animations can be found in the Animation folder.

As you can see in videos at the bottom of this page, this process took quite some time as I tried multiple methods of simulating and replicating each player’s aim across a network. Originally the aim offset was handled in the character blueprint, but this didn’t replicate to other clients properly. After countless google searches I managed to find the solution I needed and instead handled aim offsets via the animation blueprint, an aimoffset asset and aimoffset poses.

In total 15 aim offset poses were created, making sure to closely match them to where the player’s missile should be shooting towards at that angle

The animations used by the player character and the character blueprint

The animation blueprint Event Graph, with nodes that are used to get the player’s aim direction and use it in the animation blueprint to apply an aimoffset to the animation. You can see unused nodes commented with ‘AimOffset180’, nodes which were used when I only had the first set aim offset poses finished that provided a total of 180 degrees of aim offset. Now there are poses for looking back, the player’s aim is represented at all angles.

The third person character’s animation blueprint, with aimoffset blending added to the basic movement to produce the end result.

Research

A lot of research was done during the course of this project, from countless Youtube videos, to Epic’s multi-hour video tutorials and crash courses on networking and animation systems. Many times, I would have to visit the Unreal forums, Unreal Documentation or Unreal Answers for small things such as properly implementing aimoffsets, and especially for high-importance problems like networking the various elements of the game. A lot of the things present in this game prototype are thanks to countless hours in total spent studying different ways people implement similar mechanics, and following Epic’s comprehensive documentation.

I spent a lot of time studying what made arena shooter games fun, from their movement mechanics to how weapons handled. While this comes mostly from the initial ideas of this project when it was a competitive shooter, things like enjoyable movement mechanics still apply. Numerous tweaks were made to things like the player character's max speed, acceleration and jump height to test out different ideas and see what felt good to play with. In the prototype the player moves a lot faster than they did at first, this is to make up for the removal of the dash mechanic and allow the player to traverse further horizontal distances.

As mentioned earlier, the biggest influences for these tweaks were Team Fortress 2, Unreal Tournament and Quake, games notorious for their use of rocket jumping. Rocket jumping is a great example of emergent gameplay, being that it was never an intentional aspect of Quake and Unreal Tournament, but it became so popular and useful that it changed the way Quake was played forever. Team Fortress originated as a Quake mod and rocket jumping was just as prevalent there as it is now. It's hard to recreate something like this for a prototype so the my implementation of rocket jumping is comparatively simple and streamlined, but it still allows for the vast range of movement it gives in the games that inspire it, such as launching yourself from wall to wall and climbing walls with explosions.

For this project I spent a lot of time playing ‘jump maps’ in Team Fortress 2 to see how level designers handled these mechanics, and common level design elements used in those maps. The maps varied greatly in difficulty, complexity and size, and showed how something as simple as firing an explosive at your feet to propel you can open up thousands of different challenges to overcome. While rocket jumping has always been a large part of games like Quake and Unreal Tournament, the sheer quantity of maps creating for such a simple yet fun mechanic shows that there is enjoyment to be had in the mechanical challenge maps such as these present. Numerous parts of the prototype map are based off various elements of these maps. An example of this is this area:

The 2nd wall requires multiple chained rocket jumps up the wall to advance. These are very common in Team Fortress 2 jump maps and test the player's timing and knowledge of where to aim to launch themselves up effectively. It's far more lenient in this game due to no ammunition restrictions and the wall being rather small, just serving as a tutorial to the concept of chaining jumps.

This tight-rope area is based off of 'obstacle course' maps that were very common in older games with publicly available level editors. Obstacle course maps were very common in the original Red Faction video game on PC, and I used my knowledge from spending a lot of time on them when I played it to bring elements from them into this map.

Media

Videos of the project at various stages of development.

Evaluation

This project had a focus on networking, gameplay systems and animation. Networking each players character properly and bringing their save data into matches was a very important and a lot of time was spent working on these networking features. Thankfully after a lot of time studying tutorials and Unreal Engine 4 Wiki pages, the networking features work without a problem as far as I know, and all the systems relating to networking and gameplay function and have room for expansion if I wanted to continue working on this prototype. An example of this are the player customisation options, which was created in a way that means I can easily flesh out the feature after this prototype.

As this project was about creating a prototype, I made sure to implement everything that is crucial to the game, with most non-essential assets taking less priority. An example of this is how in the final prototype the level lacks polish and unique assets as these are less of a priority for my focus than ensuring the networking works flawlessly and the objective of the game functions. Despite this, some mechanics are implemented rather poorly to get them in the final prototype in time. An example of this is the timer and respawn systems. Instead of respawning being handled automatically, it is only done once the player is dead and they press the R key, and restarting the level/time can only be done once the final checkpoint is reached and the player kills their character. Situations like this are because of my poor time management and are featured in the prototype in the bare minimum way they needed to work. Had I more time I would have properly integrated these mechanics in a way that is a lot more user-friendly and makes sense.

Animation was the strongest focus of this project, I learned a lot about animating for Unreal Engine 4 and aim-offsets, and after becoming familiar with the workflow, creating animations for the game became immensely simple, effective and quick, especially when compared to older game engines like the Source Engine. The animations for both the first person and third person characters turned out how I hoped, with the exception of the new jump animation which, while more dynamic than the original, looks very awkward. I would like to come back to these animations and further improve them and ensure they show a consistent quality.

Had I more time or a second chance, I would have managed my time properly and ensured I met my original goals for the game, such as the use of more refined assets for the levels and an original character model. I would have also had more time to try and fix the bug that caused an issue with mouse problems when using the menus and starting the game. This problem came about too late into development and with little time left I was forced to package two executables of the game, one that starts the game from the main menu, and one that starts the game from the main level. With more time, I could create more levels with more interesting challenges of various difficulties instead of the one short level currently in the prototype.

Ultimately, I stand by my decision to fundamentally change the objective of the game and I feel that it was a good decision for making a more unique and interesting experience, instead of just another first-person arena shooter. I also feel like this really challenged me to think of how to design levels for such a different kind of gameplay style, and I learned a lot while trying to implement the many things that comprise this prototype, from networking, UI design, save data and player character mechanics, and using all these to communicate data that will be shared across them. I developed invaluable knowledge of Unreal Engine 4, and the methods of creating systems, networking and integrating animation from the various methods of research I conducted over the course of this project and I feel as though that despite the problems that appeared in the final moments of development, I produced a solid, but definitely open to improvement, prototype.

Animation Practice: Evaluation

For this project we were tasked with sculpting a character of our own design in ZBrush, from the concept stages up till rendering, documenting each step. The character we design should have a story and design that suggest they’re an anti-hero, a character who, while not a villain, exhibits negative or immoral traits or actions that makes them less heroic than a standard hero. We were also tasked for creating a prop for our characters that is relevant to their story or character.

I began by researching what an anti-hero is and using what I learned to factor into my designs for the character designs I created. Taking inspiration from numerous notable anti-hero characters in film and video games, I came up with a number of official concepts. Initially I spent more time than I would have liked trying to design a character that actually embodies the qualities of an anti-hero, so a lot of time was spent thinking of concepts that eventually would go unused.

 After designing a futuristic Sci-Fi smuggler, I decided to try other designs and eventually ended up with a character I believe to be far more interesting, a post-apocalyptic survivor. While I did like the concept of my original character, he was an anti-hero in his job only and in no other aspects, so I thought I should focus on creating a character who more closely exhibits those traits.

I made the choice to involve Autodesk Maya in the workflow, using it to create the base meshes for several parts of the sculpt. Using Maya for this purpose is considered industry-standard for hard surface modelling and game character creation and as such I saw this project as a chance to experiment and learn how to use both programs in the character sculpting workflow to increase efficiency and allow for the easier creation of hard-surface geometry.

This method would prove invaluable for modelling the character’s prop, a shotgun, and her numerous accessories such as belt buckle, boots, gloves and other items of clothing. Using this method was a learning experience and being able to use it and traditional ZBrush sculpting methods not only taught me how to use the program itself, but also gave me more experience modelling organic and hard-surface geometry and taught how the pipeline between Maya and ZBrush worked. I believe that ultimately this was a good decision as I learned a lot more through this process and learned how to overcome challenges that came about.

In conclusion, I am mostly happy with how this coursework turned out. I believe I managed to create a model of high quality and learned an immense amount about ZBrush and sculpting in the process while also practicing Maya modelling techniques. Had I managed my time more effectively I believe I could have made a more impressive model and character that further embodies the qualities of an anti-hero, as I feel like my final model doesn’t represent the concept of an anti-hero as much as I had wished it would. I would have also spent more time learning some of the many useful features of ZBrush, such as polygroups, that ultimately made the process so much easier, but could have saved a significantly saved time if I was aware of them when I was initially modelling the character. I believe the model itself could still be improved significantly and I made numerous mistakes, such as modelling the character with arms at the side and legs straight down, instead of in an A-Pose or a T-Pose, that ultimately made the process harder and more time consuming than it needed to be.

If I could try this project again I would use my time more efficiently, document my work more often, and ensure I don’t make the same mistakes I made this time that hindered me. I would have also made sure to spend more time in ZBrush and experimenting with the many tools available, as I often relied on Maya for creating geometry I couldn’t create as effectively in ZBrush at my current level of knowledge of the software. I would ensure I spend as much time as suitable to learn the program and it’s many systems to ensure I don’t need to rely on Maya as much and consequently allow me to spend as much time as possible in ZBrush, sculpting, learning and gaining more experience with the software.

Animation Practice: Final Character Renders and Turntable

1. General Renders

2. A3 Renders

3. Turntable Animation

1. General Renders

2. A3 Renders - Featuring both the character and the prop

A3 - 300 DPI

A3 - 300 DPI

A3 - 72 DPI

A3 - 72 DPI

Prop - A3 - 300 DPI

Prop - A3 - 72 DPI

3. Turntable Animation

Animation Practice: Character Background

Character name: Red (Real name: Erica)
Age: 26
Birthplace: England

A wandering, silent and vengeful killer that roams the lands of post-apocalyptic England. Known only by the name 'Red' given to her for her iconic red scarf that she is never seen without. In a post-apocalyptic world where civilisation is only barely forming, the only people who knew her real name were her friends and family who were killed or tortured when raiders attacked her village. During the attack she and other were taken hostage and tortured at the raiders camp. The last 2 people to be tortured, she managed to attack her torturer and escape with her sister, taking his gun and any ammunition she could find. Before she could get away, the raiders caught up with her, attacked her, left her for dead, captured her sister and drove away. While she survived, her tongue was cut out and her lower-face scarred, as such she refuses to ever take off the scarf that conceals her face.

Scarred by the events that took place, she aimlessly wanders across the country, killing any bandit she comes across without hesitation, even willing to shoot through a hostage if it means killing the person on the other side. The experience has left her cold-hearted and almost emotionless as she moves place-to-place, searching for any information as to where her sister could be, or if she's even still alive.