Neurasthenia Weekly Dev-blog

Neurasthenia is the newest project Blappy Productions have worked. The specification of the game is that it is a Zombie survival game akin to the likes of Call Of Duty Zombies. The following will show an outline of the production, detailing the work I was responsible for, issues we came into both as a group and me individually and how we went about fixing those issues by the end of the production.

---

Project Overview

There were two major specification we had to work too for this project which are listed below:

• We had to ensure that the game worked for a VR platform which in our case we chose the Oculus Quest 2

• We only had about 14 weeks to develop and test the game meaning we had to limit our scope

Neurasthenia is inspired by classes wave-based survival games with our main source of inspiration being Call Of Duty's Zombies gamemode. This meant we could play with more supernatural concepts to give context to our mechanics in our given time frame. We also decided to go with an endless wave format for the horror survival aspect as that was far easier to program overall and meant we could focus on the character controls and weapon functionality.

In total our team was 6 including me. The team consisted of the following people with their respective roles:

• Brandon McRae/Me (Producer and Programmer)

• Nathan Warren (Level and Game Designer)

• Clare Mc

• Conor Currie (UI/UX Artist)

• Ethan Huston (Level Designer)

• Daniel f\efesfg (Programmer)

---

Week 1 - Idea Generation

Week one was a simple week to start out with everyone getting fitted into their roles and preparing things for pre-production which was planned to begin on week two. Being both the producer and one of two programmers, I began by setting up the necessary pipelines to all us to work seamlessly.

I began first by developing a GANTT chart on a website called Monday.com which will be used by every member of the team to keep on top of our schedule. Monday.com also offers the options to upload our files to the website to keep backed up in case of future issues that we may come into. Below shows a screenshot of the chart along with some of the contents we backed up to the site:

Monday provides us a number of ways to visually express data that is set in a table which is shown in the image above with options to add more to the table to automatically update the GANTT chart. Additionally there is a status option which ranges from "not started" to "Working on it" and "Done" which the team is able to use to make me aware of their progress without the need to directly tell me if I'm not available for any reason.

There were no issues setting the chart up and adding everyone to it with editing permissions.

Along side the GANTT chart I also set up the work pipelines to allow the team an easier work experience given the pipeline was used effectively. First of all I created a VR template project in Unreal to give us a base line to work off as none of the team had any prior experience with VR projects in the past. After setting the project up I created a Github repository to allow us to use a Source Control pipeline to back up and save changes we make in the project in real-time instead of working off a local file. This meant we would have an easier time staying up to date on all of our machines and had no need to send each their files etc we worked on.

To start I had to get the team to download Github (Desktop) along with Git and Git LFS (Large File Storage) as we would at some point be uploading larger files which we would have difficulty doing without GLFS. Once everyone had the required software I then added then set up the repository link as seen in the screenshot above, uploading the project files to the repository and linking Git to it so we could update the files as we worked.

With the repository set up and linked the only issue was getting the team used to how to work with the pipeline appropriately as to avoid upload conflictions. As this was the first time even I had used it, it was confusing although we worked out the based of how to use it. The process would go as follows:

1. First we'd fetch the origin files first to ensure our files were up-to-date, Usually this would automatically inform us of files to pull but to be on the safe side we could press the button marked as 1 to check for updates

2. If we made any changes to the project, those changes would be presented in the section above the change information. For us to be able push our changes we had to ensure there was at least a title given to them although we could also add descriptions to make it easier to read the changes in the history log.

3. Once the changes were labelled we then had to commit the changes to the master files and then push them to the origin branch to update the main repository.

4. This last section is the "History" tab. If we were to come into any issues or lost changes we had the option to restore them based on the history although this wasn't a full-proof way to ensure changes weren't lost if something were to go wrong.

---

Week 2 - Primary Research Expedition

In week one we decided on the setting of our game in order to begin preparations for primary research and pre-production. We landed on setting our game in an abandoned insane asylum and as such we had to find a local spot in Belfast to gather reference images to make it easier on the level designers and 3D artist to understand our setting better. We picked an abandoned ward in Forster Green Hospital which has had a history of scandles and has sense been abandoned. Sense there was no other asylum like structures we could get access too this was our best choice and fitting the setting we were going for perfectly.

After getting permission to take pictures of the outside of the facility we made our way down to it and took a number of reference images and gathered images of the inside online as the windows were sealed with steel barricades and we weren't allowed access to the inside due to health and safety concerns. All that being said we gathered a number of decent images which gave us a better idea of how to construct our level. Some of the images we gathered are shown below:

The research trip went off without any hitches and the staff worked well with us to ensure we were able to get what we needed within legal means.

---

Week 3 - Preproduction and Shader Development

From this point on I will be dividing my work into two sections, the work I did as producer and the work I did as a programmer.

Producer Work

As the project was out of the Idea Generation Phase and production had now begun I began to hold weekly meetings with the team to discuss the work they did that week and any issues they came into or any additional help they needed as I had to make sure I needed to ensure the production was running smoothly at all times. Later in this blog I will provide notes and recording from these meetings that we were able to salvage which in itself is an issue discussed later in the blog.

Programmer Work

During the making of the Games Design Document we decided to make unique custom shaders to give the game its own visual style to set it apart from the crowd. That meant I had to develop two different shaders. The first was a fog shader to give a light fog with heavy falloff at close distance to the play to allow them to see ahead of themself.

<Fog Shader Code>

Getting a simple fog shader was simple enough as all I needed to do was get the colour of the Post-Process 0 scene texture and lerping it with a white constant 4 for the colour. To make the effect look more like fog I fed in a Depth Fade node into the alpha of the lerp and set the opacity and fade distance using constants until I got the intended effect. Finally I had to make sure the material properties were set as a Post-processing material otherwise it wouldn't work properly.

<Pixelization and Colour Pass Shader>

Originally we had planned to make the graphics pixelated with a low colour pass to make the shading more broken up or cell shaded in a way. We decided to drop the pixelization after realizing it would be too hard to play with in VR and would encourage motion sickness. To achieve the colour pass effect we wanted all we had to do was take the Post Process 0 scene texture and desaturate it before multiplying it by the number of colours per channel we wanted to pass through. Usually RGB channels have 256 per channel but by reducing it to 20 per channel we could create this "cut" between colours creating that cell shading like effect we wanted. then all we had to do was divide and multiply it a few times so it would translate properly to the material.

With both shaders made it was time to test the together. After discussing with the Game Designers we agreed that we would go for a classic green Gameboy colour palette. With everything ready I added the two shader materials to a post-processing component on the player and set the colour graident to the right shade of green. The results can be seen in the images below:

After developing the shaders and testing them we ended up with the final result which can be seen below. I then decided to begin work on a blueprint that would spawn some upgrade stations we planned to add at one of 4 random locations we could determine using arrows. The purpose of this script was to make sure the machines always changed positions each time the level is restarted to make strategy a bit more difficult for the player as one station may not be in the same place every game.

<Perk Machine Spawner>

Achieving this was pretty simple and required little planning. All we needed was 4 arrows to represent the positions each machine would spawn at, an array for the classes/ blueprints we wanted to spawn at each arrow and an array for the arrows which would be used to pick an arrow at random to spawn the machine onto. With these variables made, all I then had to do was get a reference to the random arrow picked from the array to remove it once the machine was spawned and get a random class from our machine list and feed it into a "Spawn actor" node. Using the arrow reference I got the world location and rotation, made them into a transform and fed that into the spawn location. Finally to avoid duplicates I removed the class and arrow from their respective arrays. This was all done in a "For loop" so the spawner would go through each element of both arrays and once they were empty the code would not execute again.

The above video shows the code in action with the only issues being the last machine wasn't spawning on the last arrow however this was fixed behind the scenes.

Overall this week was fairly productive however next week we have to focus on the core mechanics as they are the vital part of the project.

Week 4 -

Week 5 -

Week 6 -

Week 7 -

Week 8 -

Week 9 -

Week 10 -

Week 11 -

Week 12 -

Week 13 -

Week 14 -