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.

Animation Practice: Character Concept Art

When designing the character I had various wildly different ideas originally but eventually narrowed down a character I thought would be interesting. Ultimately I took elements from each design and integrated them into the final character design.

Space Smuggler concept:

Originally I played around with the concept of a sci-fi smuggler character wearing a futuristic hard-surface outfit. I tried different ideas for his head after as I was happy with his outfit but ultimately I felt like I could do something a little more interesting.

After deciding to try other concepts, I sketched some various, wildly different ideas for a character to see if anything seemed interesting. With another sci-fi character at the top right, I decided to go in the opposite direction and try a film noir approach with a detective character. While I was considering going with this idea and putting an interesting spin on the design, such as a film noir cop in the future, I decided to keep trying other ideas. This eventually left to the bottom left concept which I didn't fully flesh out, but later served as the basis for the design of my final character.

Continuing from the design previous, I tried drawing what I thought an interesting post apocalyptic protagonist would look like, in the same vein as Mad Max and other silent protagonists. This quickly led to the initial concept of a leather jacket-clad, red scarf-wearing female post-apocalyptic character. While I eventually decided to not give the character a jacket or coat, I went through different ideas for the clothing. 

As mentioned previously multiple elements from experimenting with the previous character designs made their way into this character's design. The overall lower body appearance of combat boots and trousers from the last page's last design served as the inspiration for her current design, albeit with vintage motorcycle boots replacing them. The two belts in the sci-fi concept also made their way into this design, with the 2nd belt becoming a shotgun shell belt and the scarf from the original sci-fi smuggler being used and made more important to the overall design.

With the character's design almost finalised, I began thinking of the prop and pose for the character. I quickly decided on her having a Ithica 37 shotgun. The weapon is commonly used in post apocalyptic video games and movies and has essentially become what we think of when we hear 'shotgun'. For the pose I drew two ideas, one a confident yet cold firing stance, as if about to execute someone, and the other a more relaxed pose of her smoking while sitting. I eventually decided to use the first pose as I felt like it would show more of the character, without boxes obscuring her, and also because it shows more of the character's anti-hero personality.

The final pose

Animation Practice: Development and Experimentation

For this project I decided to model parts in Maya and then flesh them out in ZBrush to ensure everything would be proportional and, considering the amount of hard-surface elements, would look how they should. A majority of the project was done in ZBrush still, but Maya was invaluable for quickly and efficiently creating the low-poly, detail-lacking base meshes for various parts, especially the more complicated parts like the belt buckle.

I first began with the base mesh. This would be the underlying body mesh of the character that I would use to rough out the proportions, shapes and topology. While I originally planned on using ZSpheres, I decided to go with this approach as it would be more useful further on when I needed to make clothing and accessories.

Thanks to the GoZ tools included in ZBrush, moving the models between Maya and ZBrush is fast and efficient.

The first iteration of the mesh, while the image planes aren't visible, I made sure to follow reference images to ensure realistic proportions were achieved.

A majority of the time spent modeling was done with smooth mode on, to make sure the mesh would look fine in ZBrush and be an appropriate base for the rest of the clothing.

Once the base mesh was finished I began using it to create the mesh for clothing by duplicating the polygons from the base mesh. This ensures the topology is inherited from the base mesh and makes create of clothing far easier.

Basic mesh for the trousers, belt and top.

A screenshot of the first model sculpted in ZBrush, the top.

Initial model of the boot and it's various parts.

Thanks to using Maya in the pipeline, creating multiple elements suchs as the belts and zips on the boots was quick and easy and allowed ideas and concepts to be tested quickly with a rough representation of what it may look like in the final sculpt.

Boots and trousers imported into ZBrush.

The boots after having details sculpted on.

Folds sculpted onto trousers with leg bandage and belts added

For this project I decided to include a shotgun as the prop of the character, I chose to model the Ithica 37 and tried two different versions, one with a longer barrel and one with a shortened one. I eventually ended up using the shorter barrel one.

After modelling the head mesh and importing it, I used ZBrush to sculpt a thick scarf and Maya to model the goggles

For the hair, I hadn't made a final decision on whether to have her hair tied back like in the original concept or to have it down to her shoulders as seen in one of the concept drawings I did. To experiment I tried creating the long hair and seeing how it would look.

While I think the result was good, I also made another version of the hair but tied back, and compared.

I prefer the tied-back look and decided to use that in the final sculpt instead, but the original hair was helpful for experimenting with the tools I'd use for the final hair.

The final model, featuring the finished scarf and the additions of gloves and shotgun shells to the 2nd belt.

POSING

With the model finished, it was time to pose the model. Using the ZBrush Transpose Master plugin included with the software, I was able to pose the model without merging everything into one model.

The plug in temporarily merges the subtools to their lowest divisions and merges them, from there I seperated the different parts of the model I'd pose into their own polygroups and from there rotated them into position.

Once done with posing I had let the plug in automatically reflect the pose onto the original tool, all that was left was to clean up the stretched geometry and pose the fingers and the prop.

Before adjustments - Low Divisions

After adjustments - High Divisions

With the character posed and a few adjustments made, all that was left to do was render.

RENDERING

ZBrush features a robust renderer that gives the user an incredible amount of control over various rendering elements such as ambient occlusion, ZDepth and many more variables.

From the Render Properties menu elements can be turned on and off, allowing for more or less detailed and calculated renders.

The BPR RenderPass menu lists the various maps generated when the model is rendered. These maps are incredibly powerful for fine tuning things such as depth of field and shadow strength to the user's preference later on.

These maps can then be individually exported from this menu and used in programs such as Photoshop.

Importing these channels into Photoshop allows the user to alter elements such as Shadow strength and Depth of Field in real time, without having to re-render after every change, like if they were to make these changes in ZBrush itself. This workflow is an invaluable way to fine-tune renders and achieve the results with real-time feedback and not down-time between changes.