THANK YOU FOR YOUR SERVICE
PRODUCTION DIARY
Thank you for your Service - Creation of the game and it's game design document
The original idea that I was going to go with for my Final Year Project was way too complex. It would have been impossible for my to do on my own, which lead to me wanting to think of an idea that is much simpler to develop. Main reason is that, I creating it on my own and I have under a year to develop it in.
The initial idea for Thank you for your Service came from when I was reading articles
on the internet, about the poor working conditions of amazon employees in the
sorting centres around the UK. In these articles it talked about how workers were
forced to work for long hours, with little to no break (some people said that they
were not even allowed to go for toilet breaks); and work to impossible quotas.
When I read about this, I thought it would be an interesting issue to turn into a game
because it allowed me to create different gameplay scenarios and build an interesting
narrative around. Furthermore, it could bring this issue to light more with members
of the public, which could lead to change in those workplaces.
Originally, Thank you for your Service was going to be set on Earth in present day,
but when I was designing the logo for the main company in the game, Arch. It looked
liked Mars. After seeing this, I change the setting to Mars and set in the near future. Reason for this is because it allows for more interesting storytelling and sci-fi is a great way to tackle social issues.
To make sure that this project is successful, I will have to create two versions of this game. The first version will be the gameplay version, which will entirely focus on the gameplay. The second version will be the narrative version, which is the version that will explore the story of the game.
Before any development of the game can start, it's very important that a game design document must be created. Reason why is that it helps me to plan out the mechanics of the game properly, aspects of the story, characters, levels, etc. Also, if I forgot how I designed a mechanic or how an aspect of the game should work, I will always have a design document I can refer to. The creation of this design document took several days because I wanted to make sure that I got everything correct, and did not miss anything as well.
Thank you for your Service - Creation of a Development Plan
Hello again, this is the second update to Thank you for your Service. So after finishing off my game design document. I had to create a development plan, to help map out when things need to be completed. This is very important step in the development process because if I don't have, I won't be able to track what has been completed, what's not been completed, what the next thing to do, etc.
Firstly, I created a Gnatt Chart. This chart is very important, as it layouts all aspects of the game that need to be completed, how long I have got to do, and when I have to do it by. To make it easier to see, I also coloured coded it so it was much clearer.
After creating this, to help even further with project planning. I used a website called Trello, to create a board where I could place different cards on it, with different parts of the game. Under these cards, I'm able to add task which break them down into smaller jobs that I can do. For example, when designing a mechanic, I have four stages in the check list. The first stage is breaking down how it will work, second stage is pseudocode, third stage is creating it in blueprints and the final stage is converting it into C++.
Thank you for your Service - Planning out the mechanics of the game
Hello, welcome to the third update for Thank you for your Service. In this update, I shall talk about how designed the mechanics and planned out their creation. This is a very important stage in the development of the game because by doing this, I won't be going in blind once I create them in the Unreal Engine. To make the development of the mechanics easier, I have broken it down into four development stages. The first stage will be writing out the mechanic in plain English. The second stage will be taking what was done in the first stage, and turning it into pseudo-code. The third stage will be turning the mechanic into blueprints (this is the visual scripting language used by Unreal Engine 4). Then once I am happy with all the previous stage, the final stage will be turning the blueprints into C++ code.
Stage 1 - Writing out the mechanic
The first stage of mechanic development is to write out in plain English how the mechanic functions, the main variable of the mechanic, what other mechanics it will interact with, data that it will receive and data that it will send out. Below is an example of what I did for the package mechanic.
As you can see above, I first broke down what the main variables that will be attached to this mechanic. After this, I explain how this mechanic will work, how it will interact with the environment and what happens to it once all the criteria has been met. The next two sections I broke down was what mechanics it will receive information from and what mechanics it will send information to.
Stage 2 - Pseudo-code
After I am happy with what I completed in the first stage, the second stage is to take this plain English and turn it into pseudo-code. I wanted to do this because I wanted to make sure that this mechanic will work, once it's eventually turned into C++ code. Furthermore, by turning it into pseudo-code it will help iron out any problems, if there are any. Also, it gives me insight to how it will look once it is in C++. Below is an except for the pseudo-code that I wrote for the package mechanic.
Stage 3 - Blueprints
Once I am happy with all of the pseudo-code, the next stage will be major, as I will be turning the pseudo-code into Blueprints. I am doing this first before building as C++ code because blueprints is a visual scripting language, which allows me to create the mechanic very quickly, and if any changes need to be made, then I can make them very quickly. Also, Blueprints complies much faster than C++ code which means that if I do want to make changes, I won't have to wait for a long time time for the code to compile. Below is an example of some of the Blueprints code I created for the package mechanic.
Stage 4 - Converting it into C++
This will be the final stage of mechanic development. So once I am happy with the Blueprints I created, the next stage will be converting everything I did in Blueprints into C++. This is the most important stage, as this stage will show off my coding skills which hopefully lead to high mark in Final Year Project and will help me in future employment as well. Also, C++ is much more powerful than Blueprints as I can customise it to what I want.
Thank you for your Service - Writing out the script of the game
Hello again, this is the fourth update for my game Thank you for your Service. In this update I shall talk about the script that I have been writing for the narrative version of the game.
Overall, I have spent several months on the script for this game because I wanted to make sure that I got it right and that it is engaging for the player. This is especially important because a story that is not engaging for the player, then it will affect the results when the player play tests the narrative version of the game. At the moment, the script is nearly finished but I have taken a break from it because I want to get the mechanics down first before I finish off the story.
Game Development Update 1 - Starting the Project and Source Control
Hello again, this is the next major milestone in the development of Thank you for your Service.
In this update I shall talk about starting the project in Unreal Engine 4, how I set it up and how
I implemented the source control.
When deciding to set up the project, I had to ask myself several questions. The first questions
was: which version of the engine shall I go with? When I asked myself this question,
I looked at the versions I had experience with and the version that the university computers had.
After researching, I ended up going with 4.22.3 because I had experience using it
and it was the version of Unreal that the uni computers had. To be honest, the main reason
behind choosing this version was because it's the version that the uni computers use
and since my main testing centre will be at the university,
it was logical to go with the version that they had.
Also, when I was starting the project. I choose to go with Virtual Reality Blueprint template.
The main reason for going with this is because it already set up many things for me,
such as setting up the VR controls, basic VR functions and setting up the camera properly.
Also, by doing this it saved time because I did not have to any of it myself.
Setting up Source Control
Before doing anything, I wanted to make sure that my work was safe from being lost or destroyed, so I needed to set up source control. This is very important because if I did lose it, not only would it be demoralising for me but it would mean I would fail my final year project. Also, for example if I broke a mechanic and did not know how to fix but I knew that in a previous version it worked fine, then I could revert back to that version. Another reason for using source control because it allows me to access my project from wherever I want. For example, if I didn't have my external drive, all I would have to do is clone my files from GitHub and then I would be able to continue with my work.
One great thing about Unreal Engine 4 is that source control is already built into it, and it can be easily set up with the few clicks of a button. In UE4, I can choose from three different source control programs and these are: Git, Subversion and Preforce. In the end, I ended up choosing Git because I already have experience using it in previous projects. Also, it didn't take too long to set up. To help with source control, I download GitHub Desktop which allowed me to connect with my GitHub account online, and it allows me to quickly push and pull different versions of the game to my branch.
After setting all of this up, I was ready to start developing the game fully because I knew that my project would be safe.
Game Development Update 2 - Creating the Basic Mechanics in Blueprints
After setting up the project and source control, the next stage of development was creating the basic mechanics in blueprints. The basic mechanics that I had to set up was: the character, picking up objects and dropping them properly (without glitches) and the package mechanic.
Setting up the character:
Luckily, as I was using the Virtual Reality Blueprint template many things such as the headset, VR controls and camera was already set up for me. The only thing I wanted to do though was make my custom character because the character that came along with the template was not suitable, since it allowed for movement (which was something that I didn't want in my game). Also, by creating a custom character, it allowed me to make many changes such as putting in my own variables, functions and so on.
In the player character, the first things I set was attaching the VR control blueprints and implementing in it's functions. For example, I added in a function that tell what type of object had been picked and what hand it was picked up in. This is very important for objects such as the destination stamp, which allows the player to print out destinations by pressing the trigger button. For example, if the player picked it up with the right hand, then they should not be able to use the trigger on the left hand to shoot. Also, it allows me to hold several different objects at once, such as package in one hand and the destination stamp in the other.
Setting up picking and dropping objects:
Even though the VR template comes along with an already built in pick up and drop function, I wanted to make some changes to it because it was fairly glitchy and clunky. For example, one major problems with is that if you held an object in a certain way, then it would cause the player to move around the level. I did not want this because the game is supposed to be played in one stop, and the player is not supposed to move around. Also, it could lead to player getting motion sick. So, to fix this problem, I had to make a function that would disable collisions on the object currently being held by the player. By doing this, it stopped the problems that I was having.
Creating the package mechanic
Out of all of the main mechanics, I decided that this should be the first one to go in, as the other mechanics in the game will not work without this mechanic being implemented. When I created this mechanic, I firstly created it as a C++ file and then made a blueprint of it. I did this with all of my mechanics because later on when I want to recreate the blueprints in C++ code, I will not have to make another file. So after doing this, I started to implement everything I wrote down in the mechanic design document and pseudo-code. Along the way, I did bug testing such as making sure that it can picked up by the player, that it's finding other blueprints, it destroys itself properly and so on. Once I finished this all off and was happy with it, I moved on to the next step which was creating the basic level.
Game Development Update 3 - Creation of the Basic Level
So before, I could implement the basic mechanics into the game, I needed a basic/rough level of the main area that the player will be working with. Doing this is important because I wanted to get a feel of what it will be like when the player experiences it. Also, it gives me a chance to see if the game will flow well.
Designing the level:
Above is a rough drawing of the level I want to create. I quickly made this in my note book because it was much quicker than making it on a program like Photoshop. Also, it's something that always have on hand.
Implementing the Level:
Some of the buttons that I created for the console. These designs will highly change in the near future.
After finishing off the design of the level, I started to create some basic placeholder models for the level that I could put into, to see how they it in with the game. Also, at this time I was playing around with shaders to see if they would work with this game or not. At the moment, I'm not too sure because I feel that a toon shader will not fit in with the tone of the narrative which is quite dark. Once I finished this off, I started to implement the more complex mechanics into the game.
Game Development Update 4 - Adding in the more Complex Mechanics via Blueprints
So after finishing off the basic level, I thought it was time to start implementing the more complex mechanics into the game. These mechanics included: Box Creator (3D Printer), Chute, Button, Box Type & Size, Clock, Destination Stamp, Final Report System, Package Spawner, Quota Board, Requirements Board and Strike System.
Package Spawner
I decided that this is the second mechanic because this is the mechanic that will be used to spawn in the packages, into the level. This is a very important mechanic to get correct because I needed to make sure that packages spawn correctly. For example, when any package spawns I need to make sure that it's requirements are set. Also, with this mechanic I need to make sure that the packages spawn in the correct place.
Requirements Board
This is another very important mechanic to implement because it's the board that display all the information that the player needs to complete an order. For this to work, I had create a function in the package which would find the requirements board in the level, and when ever it's picked up by the player, then it should send data to the board. This was a very easy mechanic to implement.
Destination Stamp
For the player to print destinations on to the packages, they need to use a destination stamp. The destination stamp looks like a gun, but instead of shooting bullets it prints out destinations. The player can choose the destination they want by cycling through them with the use of the joystick. The player then can print the destination by pulling the trigger. To make sure that this mechanic works, raycasting was used which meant that when the ray hit the package, it would find the package in that level and set it's destination
Box Creator (3D Printer)
One of the requirements for the package is that it needs to be placed into a box, which must be a specific type and size. So to do this, I create two arrays that held a types and sizes, and after this create functions that would create the box by sending the type and size data with the use of parameters. Another function I create was the increase and decrease index functions, which allowed the player to change the type and size of the box they wanted with the use of the buttons (this is discussed later). Also, I added in text which would display to the player the type and size of box they currently have selected.
Button
For the player to interact with other functions in the environment, they needed physical items in the environment such as for the Box Creator, which needed buttons to change the type and size of the box. The creation of this took a very long time because I had to get the collisions right, make sure that the button can work from any angle, the button static mesh moves down when it's pressed by the player's hand. Also, had to make sure that it didn't interact with objects built into the environment such as the table. This was important because when I attached the button to a table, the button would activate without me touching it. This was fixed by changing the collision properties in the blueprint class. Later on I will have to do this through C++ code.
Box Type & Size
As I said before, another requirement is that each package needs to be packed into a box of a certain type and size. This is the main mechanic that will facilitate that. With this mechanic it can receive parameters which will set the type and size of the box (from the Box Creator mechanic). In this mechanic, to allow the player to place the package inside them, colliders are used to detect if the package is inside the box or not. If it is in the box, then it will lock the package inside that box and close it up.
Clock
This was a very simple mechanic to implement because it would count down from a set time (e.g. 2 minutes), and once it hits zero, then it will mean that the player has run out of time. Once this happens, the final score room level will be loaded.
Quota Board
At the start of level, a random quota is set between 20-30. This is stored along side number of packages that have been sorted. This means when a package is sorted, the number of packages variables will go up. There is also a boolean in this mechanic that checks if number of packages sorted and quota number has been met.
Strike System
This strike system is used to tell how many times the player has incorrectly sorted the package because they did not meet all the requirements. Requirements are checked when the player puts the package into the chute. With this strike system, the player will have three chances to get something wrong and if they get more than three wrong, then they will lose the game and will have to start again.
Chute
So another requirement for the package is throwing it down the correct chute. Each chute has a will have a different colour (Red, Green & Blue), as each package needs to be thrown down a different type of chute. So to get this working properly, I had to add in colliders which would do an overlap check, to find the package and set it's chute requirement. Also, this is where the requirement check is done.
Final Report System
This is the main system that is used to calculate the final score. It does this by taking data from all of the other mechanics in the game such as: number of packages sorted, number of strikes, number of packages sorted correctly, was quota met, etc. All of these data points are then taken, and a score is calculated.
Game Instance
This is used to save data between levels, such as the score and story choices.
Game Development Update 5 - Creating and adding some of the final models into the game
So after implementing the rest of the mechanics, I decided that it was time to start making the final models for my game, specifically the main area.
Game Development Update 6 - Playtesting the game and feedback
Before the lockdown, I did a small playtesting session at my university with a small group of 10 people. Each playtester would play both versions of the game, and they would provide me with verbal feedback.
This testing was conducted for many reasons, with the the main being that I wanted to get feedback on the gameplay mechanics and narrative. I wanted to know if all of the playtesters understood how to play to the game and understood the game's narrative. The second reason for doing this is that I was testing my data collection methods that would have been used later in a much larger testing environment, but sadly this never happened because of the ongoing pandemic.
The feedback I received from all of the playtesters was great because it showed me that they all understood what was going on and how to play, without me having to help. Also, it helped provide feedback to refine the mechanics. For example, the box creation mechanic had two parameters that the player had to interact with; this was the size and type of box. Everyone who played the game would always get the type correct, but never the size. I saw this happening and decided that it would be best to simplify the mechanic down to just getting the type correct instead. This overall made the mechanic much easier for the player to understand, and made the gameplay flow much better than it was before.
Also got narrative feedback as well, originally in the game I had an opening sequence that would have introduced the main story to the player. While playtesting lots of people did not like this portion of the game and I didn't like it as well as control was taken away from the player. In the end, I decided that this part of the game should be removed as it caused motion sickness for player. I replaced this section with a tutorial which actually made the game flow much better than it was before because people were playing the game straight instead of standing around waiting for the game to start.
Game Development Update 7 - Improving the game environment
Once I was happy with the gameplay mechanics and overall narrative, it was time to update and improve the game environment. Before the game environment was updated, it was very basic and bland. In the game environment update I decided that the level should have a very industrial and worked in feel, as that fits in with the narrative I am going for. I didn't have time to create my own models for the environment, so I decided to use these asset packs from the Unreal Marketplace:
Modular SciFi Season 1 Starter Bundle by Jonathon Frederick - https://www.unrealengine.com/marketplace/en-US/product/modular-scifi-season-1-starter-bundle
Modular SciFi Season 2 Starter Bundle by Jonathon Frederick - https://www.unrealengine.com/marketplace/en-US/product/modular-scifi-season-2-starter-bundle
These asset packs were chosen as they fitted into the game world that I wanted to create and went well alongside the custom models that I already made. Quixel was also used to get environmental objects such rocks and cliff faces which could be used to double up as the surface for mars.
GAME ENVIRONMENT ONE - MAIN PACKING ROOM
The first game environment that I started to work on was the the main packing room, as it's the main area that the player will spend most of the their time in. This is why I spent the longest time working on this area to make it look good. Below is a before and after.
GAME ENVIRONMENT TWO - PLAYER QUARTERS
After finishing off the 'Main Packing Area', the next game environment to work on was the player quarters. The Player Quarters is the second environment that the player will interact with most, especially the narrative as this is where characters will call up the player and talk them. This is also one of the levels where the player will be able to look outside and see the surface of Mars, which meant using models from Quixel to create the outside environment.
GAME ENVIRONMENT THREE - STARTING AREA
When the player starts the game, they will be in a starting area. From this starting area, the player will be able to choose what gamemode that they want to play, which includes: story, gameplay and tutorial. They can also choose what difficulty the game will be and if they want to quit or not. The starting area is designed to have a punch card system as though they are about to start their job. This is also another area where the surface of Mars is shown.
Game Development Update 8 - Updating Blueprints to C++
Once I was happy with all of the blueprints that I created for the game mechanics, the next stage would be converting all of these into C++. Reason for converting it over into C++ because it's much more efficient than Blueprints and allows for much more customisation. The only problem is that it takes sometime to do convert them over and this is a single person project on a tight deadline, I decided to only covert the main mechanics over into C++. In the end, the final version of the game will be 60% C++ and 40% Blueprints.
Game Development Update 9 - Making the menus for the game
Making the main menu for a VR game is much different than making a main menu for a non-VR game because you can't follow the same rules. For example, the controls for interacting with the menus are much different because you're not using a mouse and keyboard, or controller; but using virtual hands or pointing with your head to interact with objects. The main menu system for this game went through a couple iterations until it became what it is in the final game.
The first iteration of the main menu system was very basic. It was using Unreal's built in widget system and you would use rays to interact with them. These rays would come from the controllers, and the player would highlight the widget button that they want to interact with. The button is activated by the player pressing the trigger. The overall design and look of the menu was very basic as well.
This iteration of the menu system had many problems and drawbacks, with the main problem being that it wasn't very responsive. For example, sometimes it wouldn't detect if one of the menu button widgets were selected or not. This meant that the player would find it frustrating to interact with the menu.
The overall design and look of the menu was not good, and was not up to the same standard as the rest of the game. It overall was very boring as there was just a basic skybox and there wasn't really anything for the player to look at, or be amazed by. If the player loaded up the game and saw this type of menu, it would not make a good first impression.
This lead to me re-designing the menu; making it's functionality much better and making it's overall look and design fit in with the rest of the game.
The second iteration of the main menu was much more complex than the first, and it's overall look and design was much more complex as well. In this iteration of the menu, Unreal's widget system was replaced with custom system menu system designed by me.
In this brand new menu system, instead of using rays to interact with aspects of the menu, the player will pick up cards which display the different game modes and difficulties. After this , the player would insert these cards into the orange boxes on the wall. Once inserted, the gamemode that they chose will load. The reason for designing the menu system in this way was because it's much more interesting for the player to interact with, and it also teaches basic mechanics like picking up and dropping items. Moreover, it fits in more with the rest of the game as it's like a punch card system in a workplace, which fits in more the main theme of the game.
Furthermore, the overall look and design of the main menu and it's level were given a complete redressing and upgrade. The main menu is now somewhere within the facility instead of taking place in space. I decided to change this because the original location did not look visually interesting and was not to a high standard. By setting the main menu on Mars, it fitted in with the rest of the style for the game and allowed me to create a detailed level. This would impress players when they first played the game.
Game Development Update 10 - Finishing Off The Game
Two weeks before the deadline, I managed to completely finish off the game. This meant that all gamemodes, mechanics were in the game; the game could be played from start to finish without any issue and that there were no major bugs that could cause the game to break. This is what I planned to do at the start of this project because I wanted to make sure that I finished the game early, so I could have the time to finish off the report (which is very important), film videos and most importantly; having not to rush because I have enough time to hand into the Final Year Project to the uni.
Throughout these two weeks I play-tested the game every day to find bugs and fix them. Also, throughout these two weeks I added in music into the levels such as the main menu and main packing area, just to make the game sound more interesting and not be quiet. Another aspect that I added some finishing touches to was optimising the code to make sure that it ran better than before. This was done by using Unreal Engine's built-in profiler which could check the frame-rate, amount of memory being used (both RAM and VRAM), how much of the processor is being used, etc. Also with the code, I went through the C++ scripts and removed redundant code that wasn't being used. I did the same for the blueprints as well.
Finally, I was also making many different builds as I went along and tested them to make sure that once the game was built that there were no problems. This was very important because if the build didn't work, I could lose a massive amount of marks. Luckily, every build that I created worked and the lecturers marking my work were able to play it.