MOBILE PROJECT

Post Apocalypse and XHale.





















INTRODUCTION 1.0



Our second group project at Winchester University was the mobile game project. My last project didn’t go very well, so I was a bit sceptical going into this new one. Despite this, it became obvious to me during our first group discussion that this group was going to be a lot more compatible. The first thing we discussed as a group was finding some common ground in our interests; many members of the group were very dedicated to making sure this project could be something we could all excel in, as well as enjoy throughout. Upon discussing potential ideas for video game and console genres that interested us, we concluded on vr horror games. Many of us were also interested in particularly the zombie-horror genre, so we used this for our starting point.


PLANNING DEVICE 1.1



We were challenged with creating a unique mobile device, so we began to brainstorm ideas to make a vr headset more unique. I thought of an idea to have the vr headset use more than the two regular senses, visual and auditory, and to have the game actively react to the presence and pressure of breathing. This would work well with a horror vr game, as games like this already cause the user to often hold their breath in anticipation. In our game, the player would have to stealth around a post-apocalyptic environment, holding their breath in certain sections to avoid detection. This was my first sketch to convey the idea of a chamber to detect the breathing:


Figure 1.1.1, Initial Sketch


Upon further development and later discussions, we decided to have our headset be completely portable to better fit the ‘mobile’ aspect of the game project brief. The idea was to have small cartridges, similar to the DS or Nintendo Switch, that would insert into a section in the back of helmet.


Figure 1.1.2, Sketch


After discussing this sketch with my group, we decided it looked slightly too claustrophobic, and we didn’t want to cause any discomfort or stress from our users, so we tried to rework the design. Upon looking at pictures of other mobile vr headsets, like the oculus, and decided to opt for a mixture of straps, Velcro, and plastic sections, similar to the PlayStation vr. Here are the sketches I created during our brainstorm:


Figure 1.1.2, Discussion Sketch- headset


Figure 1.1.2, Discussion Sketch- handheld


Figure 1.1.2, Refinded Sketch


PLANNING GAMEPLAY 1.2



Once we all had a basic idea of the functionality of the device, I began to focus on the game. In our brief, we were encouraged to include hints of the Sustainability Goals 2 – End hunger, achieve food security and improved nutrition and promote sustainable agriculture- and 11 – Make cities and human settlements inclusive, safe, resilient and sustainable. We thought that these aspects could be very effectively woven into the story and narrative of a zombie apocalypse game, and to this capacity, they would not dominate our project, but would still be at the core.

For this project, we also decided to appeal to a target audience of teens, as they are a main consumer of indie horror games, such as Five Nights at Freddy’s, and Poppy’s Playground.

We began to brainstorm a story with these elements, and a gameplay style for our game. Upon much collaboration, we ended up with this pitch:

“ The player embodies a farmer in a post-apocalyptic world, who cultivates crops. This character also takes some of their crops to trade with other settlements, in exchange for building supplies to help fortify their farm and make it safer. Taking the same perilous path each time, the game will show the same journey at multiple different points in time, showcasing the changing world of the apocalypse, with enemies mutating and evolving with each level. ”

In our idea for the game play, it would be similar to another game favoured by our target audience, Five Nights at Freddy’s. Each level would take place in the same location, with the main change being the date at the beginning – e.g ‘night 1’ – and the difficulty of the level. Our game, however, aimed to push this formula with the inclusion of enemies varying from level to level. With this concept in mind, I created this timeline:


Figure 1.2.1, timeline


Each Day is a different level, with our game having five levels in total. With the delivery aspect to our game, a key inspiration was Death Stranding, although tonally we tried to avoid the wacky and unpredictable feel of the game. For tonal inspiration, we leaned more in towards the likes of Resident evil: specifically Resident Evil 2 Remake, and Resident Evil Biohazard. We were aware that these games were 18 rated though, so we knew that we would have to tone down the horror aspect from these inspirations. To combat this, we opted for a semi-realistic style, similar to the likes of TellTale games, specifically ‘TellTale’s The Walking Dead, A New Frontier’. With all of this in mind, I began to create concept art of the enemies to be shown in our group pitch presentation.


CONCEPT ART 1.3



Figure 1.3.1, Day 1 Enemies


Here I designed the first group of enemies: the bikers. I tried to make them look varied, but also menacing- leaning into many villainous biker stereotypes found in the media. I feel that each one looks intimidating in their own way: especially the middle one, Biker 2, who is the only one I drew without a weapon drawn and ready. I like how I was able to capture an odd arrogance to him, by his unbothered and slightly unhinged demeanour, with his head held high and a hands-on-hips pose: he looks to be the leader of the gang. The others look more like the ‘muscle’, which I feel makes him the most frightening in a unique way.

For this project I would be using Unreal Engine, a program I had absolutely no experience in, making this project a huge learning curve for me. I decided to push myself further and learn the basics of another new program, Blender. Following a YouTube tutorial, I tried to recreate the face of Biker 1:


Figure 1.3.2, Biker 1 Model


Overall, for my first Blender model, I don’t think its half bad. I don’t like his cheekbones, I think they’re too exaggerated, and his lips look quite strangely, and unnaturally pouty, as though his has lip-filler, but overall, it’s decent for a first try.

Next, I created concept art for the second wave of enemies:


Figure 1.3.3, Day 13 Enemies


My favourite part of video game design or development is definitely concept art, specifically character design. I really enjoyed coming up with these designs, and especially trying to capture the more desperate, untrusting, and nihilistic look of a group of Day 13 survivors. One of the survivors is clearly ‘bitten’ and appears very zombie-like already with his slumped posture, greyed skin, and yellowed eyes, while the others look angry, desperate, and detached. With these being the last bunch of humans to design before the first wave of zombies, I tried to make them look quite near the end of their journey: clearly an infected in the group will greatly decrease their likelihood of survival. Out of all the designs I did, my favourite is Survivor 2, simply because of how similar he looks to a zombie: it was very fun and interesting to draw.

Another member of the group oversaw creating the designs for the infected, which he did as headshot 3D models. The infected started out as regular zombies on Day 34, and gradually mutated until Day 165 where they had large mouths taking up most of their head, a lack of eyes, and their teeth had grown mush sharper.


We had also decided on a name for the game by this point. We struggled a lot to find a name that seemed to fit the delivery aspect, as well as the zombie-horror, and brainstormed a few ideas, until it hit me that the perfect, and slightly humorous, name would be ‘Post-Apocalypse’, due to the nature of delivery in an apocalyptic world. We also decided on a name for the headset: due to its breathing related sensors, we called it ‘X-Hale’, which we thought sounded pretty cool, and very fitting of a game device.

Finally, before the pitch I began to train an AI as a proof of concept for our breathing technique. I sampled five different sounds for the AI to recognise: Background Noise, Breathing, Heavy Breathing, Holding Breath, and Direct Speech. I got samples from members of my group for each to get a range of samples, and you can find it yourself by clicking here.


With everything ready, it was time for the pitch, where we showed our current progress to our lecturers and peers in a presentation.


PITCH 2.0



For our pitch, we all showed our current progress, and the lecturers liked our idea and work. Their only issue was how ambitious it was, but congratulated us for pitching something so big, and claimed that if all our portfolio work was as good as what we had shown, then it would be perfectly fine. I definitely took this as a win, as it was much more successful than any of the presentations in my last project, and I felt that mostly everyone was contributing their best work. There were a few members who did not, one had a broken laptop, which was completely out of her control, but unfortunately, one member contributed nothing, and not once messaged or interacted with our group chat for project discussions, choosing to ghost us instead. Considering it was only one member this time, I did not let it effect my outlook on the project.


For this pitch, I also created illustrations which I compiled into a video, showing a mock-up of the breathing system:


Figure 2.0.1 Mock-Up Video

With the presentation under my belt, I began to work on the game itself, and try to learn Unreal Engine.


GAME DEVELOPMENT 3.0



As I was a completely new user of unreal engine, I decided to consult a YouTube tutorial to help with the game’s progress. This game had many complicated elements, so I knew I’d have to use multiple different tutorials.


The first tutorial I used was this one, which was teaching the viewer to create a 1st person survival horror game. This was slightly different from what we had originally planned, but I figured that I could convert it into vr later in the project, and that it would be a good idea to start with 1st person.


The tutorial had many elements that I did not need, like a hunger system, but the tip I found most useful was about the perspective. When you load up Unreal, you can create a game that already has a 1st person view; however, this tutorial recommended starting a 3rd person level, and attaching the camera to the model’s head. This way, it achieves a ‘true first person’ camera, with a body and hands that are visible when you jump or crouch.


Figure 3.0.1, Camera Position


Figure 3.0.2 Early Video

Around this time, I also created a plane for the game to take place on, using Quixel to get texture for the floor, and had begun to map out the level.


Figure 3.0.3, Early Photo 1


Figure 3.0.4, Early Photo 2


To further plan out the map, I took some screenshots of different angles, like aerial view, and drew over them to show what was going to be in each location. This marked my original ides of minimal cover, and the idea of going through a building.


Figure 3.0.5, Plan- Aerial View


Figure 3.0.6, Plan- Forward View


Figure 3.0.7, Plan- Backwards View


One of the main things I was trying to implement was an AI patrol feature. I consulted many tutorials, but mainly this one. I wanted to create an enemy that would patrol a location, and if they spot the player, give chase, or end the level.


I have never used the blueprint system before, but I was very excited to try it as I find coding language very difficult to understand and write. With the aid of the tutorial, I was able to create these lines of commands:


Figure 3.0.8, Blueprint 1


Figure 3.0.8, Blueprint 2


This is pretty much the same as in the video, but for some reason it did not work. My AI would not patrol, or even work with the animations, not idling and just staying in a default ‘T’ position. I ended up spending far too long trying to fix this issue and decided to move onto building the level.


Figure 3.0.9, AI


LEVEL BUILDING 3.1



The first thing I decided to create was the cover for the player. Originally, I was going to build up cover out of numerous items, stacks of different and interesting things to hide behind that looked as though they belonged in a farm. Unfortunately, my Unreal Engine had an issue where some of my assets became corrupt, and after a few days of work, all the cover was deleted. Although this was disheartening, I actually think it was for the best: upon revaluating the idea of cover, I decided to go with a simple, reliable piece of cover. This seems far more common in video games, where assets are reused to give the player a sense of reassurance and consistency, which seemed especially important in a horror game. I did, however, get a short video of the early production of my previous work. It is in a much earlier stage than it ended up, but it shows the original idea of building up cover out of multiple items:


Figure 3.1.1 Early Cover

Later into production, I also added lights above the new crate covers, to aid the player even more. At this point in the project, I also had sourced many more models from Quixel, like the corn I had drawn in the concept video. I had also changed the time of day to evening, and added more atmospheric elements like clouds and fog.


Figure 3.1.2, Level Building 1


Figure 3.1.3, Level Building 2


Once I had made this full stretch, I began to keep trying with the AI, placing him off to the side, and making his patrol coordinates correspond with his location: this way he would emerge from the corn to check nearby pieces of cover, giving the player minimal time to hide and navigate. However, I still could not get this to work, so he is still hidden to the side with all his scripts and programming, just unable to use them.


Figure 3.1.4, AI Placement


Here is a gameplay test of the current elements in play:


Figure 3.1.5 Gameplay Test

I tried a few more elements, like a menu, but I’m not sure if it was due to something on my end, due to my inexperience in Unreal, or due to the fact I was using Unreal 5 which is currently unstable, but I had a series of strange glitches when trying to do this. Every time I would make a blank scene and try to make a menu, the camera would not be static, instead, a new 1st person character would spawn, and start falling through the floor. Neither of my lecturers knew why, so I continued to focus on making the level playable and pleasing to look at.


PLAYER CHARACTER DESIGN 3.2



With the final presentation coming up, our group were talking about the idea of designing a player character. Obviously with the time constraints, it would be highly unlikely to have a human character modelled, rigged, textured, and in the game, but it would be a nice element to be able to present. We ended up deciding to have a choice of two player characters: similar to Leon and Claire in Resident Evil 2.


I wanted to make the characters as relatable as possible: this is frequently the trope with vr or 1st person characters: the player is really meant to relate to and see themself in the character. At the same time, video game characters, particularly in the horror genre, seem to be a projection of one’s best self. Fictional characters are often role models, or the kind of people that players can admire and strive to be like. Especially in the afore mentioned Resident Evil franchise, the male and female characters are seemingly exaggerated versions of these aspirations: a lot of people point this out as a negative and claim that horror games present women in a sexualised and unrealistic way, but I do not think that any horror protagonist, male or female, is ‘realistic’. In fact, I would argue that it would be easier for an average female gamer to achieve a similar body, through working out and such, to Claire Redfield, than it would be for a male gamer to achieve a body similar to Chris Redfield. So, I began to experiment with the middle ground of being almost a blank slate, and relatable, and being something more, like a role model.


Another thing to consider, is that I wanted the choice to have no effect on the gameplay. Choosing to play as a male or female character is mostly just for a personal preference, and I wanted them to each be as capable as each other.


Design wise, I went with a medium skin tone. I wanted the race of the characters to be slightly ambiguous, and as relatable to as many players as possible. I also decided to make the two characters appear visually similar, leading to the choice to have them as brother and sister. In their design, I stuck to similar colour pallets, and wrote a short description out for each one.


Figure 3.2.1, Character Design 1


Figure 3.2.2, Character Design 2


FINAL PRESENTATION 4.0



For the final presentation, I showed all the above work, along side a gameplay mock-up I had made specifically for the presentation. This showed elements that I was unable to achieve in the engine, like a menu and title screen, and merged it with what I had created. For some reason, my laptop was very buggy at the time of recording the footage, but other than that, I am happy with the outcome:


Figure 3.1.5 Gameplay Test

Overall, the pitch went pretty well: unfortunately, due to illness, or unknown reasons, only two members of my group showed up for the presentation. After such successful teamwork up until this point, it was a little disappointing to have it fall at the last moment, but it wasn’t the end of the world. The lecturers recommended that I keep working on the game after the project to take it even further, so I continued making some changes.


FURTHER PROGRESS 4.1



I worked a bit more on the game, mostly, making it have a linear progression, and fleshing out the whole level. I attempted to add a barn, but could not find adequate models on Quixel, so I had to build the walls and texture it. I also added more cover, and more lights, and a well- which I had drawn in my initial plan- until the end of the level.


I would have enjoyed working on it more, but by this point the next group project was set, so I set my priorities on my new assigned work.

Here is the final video and photos that I took of game:


Figure 4.1.1, Aerial Map- Lit


Figure 4.1.2, Aerial Map- Unlit


Figure 3.1.5 Gameplay Test

CONCLUSION 5.0



Overall, I really enjoyed this project. If I were to describe it simply, it has been a huge learning curve for me. Beginning to tackle Unreal Engine was a huge challenge, which I’m not sure I was totally ready for, but I hope to put in more of my personal time to improve for the future.


Another positive, was the group work. Much different from my last project, everyone was supporting each other, and seemed to work well together, which was really refreshing. It also became obvious towards the beginning of the project, that I was working with a lot of introverted people, so they often looked to me for leadership during presentations and such, which I found helped me to broaden my skills as a team leader.


This project was very helpful, and I look forward to using Unreal again in the future.