Global Game Jam 2019

This weekend I took part in the Global Games Jam at the Bristol VR Lab. The event was organised and funded by the Bristol Games Hub. For this game jam I was working with Sam Ibbitson and Jason Raval from Meteor Pixel and Josephine Lewis. The theme for the game jam was “What home means to you”. They decided having pride in your home was what they thought home meant to them. My role in the group was to assist Jason in programming (using blueprints) the game using the Unreal Engine.

'ROOM' is a retro FPS inspired by early 90's shooters such as DOOM. The player assumes the role of a Space Marine recently returned from a tour of Mars, who has invited their friends over for a wine and cheese night. OH NO! The house is a mess - you've got to quickly tidy up before your friends arrive... Use Keyboard/Gamepad to clean up the mess and dirt... If you're feeling a bit weary, why not have a nibble on some of that cheese and wine you've set out?

Fig 1 - ROOM main menu

Fig 2 - Team photo

As I had not used Perforce before Jason had to teach me the basics of the source control package.

My first task was to check if it was possible to use a SNES controller as a form of input for the player. Jason gave me 30 minutes to work out if it was possible and if I had not worked out how to solve the problem within the set amount of time we would scrap the idea and move on to another idea. After a few minutes of testing, I discovered that the controller was not sending any recognisable signal to the Unreal Engine so we decided to scrap the idea.

Fig 3 - Initial blockout of the first room with gaps to show where the doors will be placed

I setup a basic blockout for the first level so we could get a sense of scale for the game. Creating this blockout allowed me and Jason to iterate on creating the perfect wall height to replicate the DOOM style. The blockout allowed me to create door widths that allowed the player to move successfully through the door frames.

Fig 4 - Door with a box collision component

I was given the task of creating the door system for the game so I added a box collision volume to a 200 by 200 wall piece. The box collision triggers the door opening when it is overlapped and when the player leaves this volume the door closes.

Fig 5 - Door opening timeline

Fig 6 - Door blueprint

Fig 7 - Door opening function using the door direction enumeration

The door opening function has an input for the Door Direction enumeration so that the door direction can be easily switched using a drop down menu as seen below. I made use of enumerations in this function because it allowed the Sam (the artist) to control the direction of the door blueprint without editing the actual blueprint. If we wanted to change the door direction later in production the changes could be made easily and the amount of movement could be adapted easily if the door was a different size using the door size float value.

Fig 8 - Default public door variables

Fig 9 - Default public door variables (in use)

Fig 10 - Doom heads up display shows the players arms from a first person perspective

Fig 11 - Hand sprite component setup

Fig 12 - Hand sprites attached to the camera in the viewport

As our game aimed to replicate the style of DOOM, we wanted to make the players camera view show the players hands as they walked around the level. My solution of this first person view was to attach the hand sprites (the hands below were placeholders) to the camera so that as the player moved around they would stay in the same place on the players view. The hand sprites had a scene component as their parent which was a child of the camera so that adjustments to both the sprites could be made easily in the future.

Fig 13 - Camera shake component

Using the camera shake component, I managed to create a “view bob“ motion by adding a slow camera shake along Z axis at a low frequency and amplitude. Setting this component to a single instance allowed the shake to play once which made the effect look like the characters arms were moving up and down.

Fig 14 - Activate the camera shake/view bobbing effect when the players velocity is above 1

The blueprint above applies the world camera shake when the player starts moving as I did not want the camera shake to apply when the player was not moving. This combined with the camera shake and the hand sprites gave the player a real sense of walking through the level.

Fig 15 - Finished view bobbing effect

Fig 16 - Hand animation using an array of sprites

The hand animation function created a system that would cycle through an array of sprites. We decided to use this method instead of using a flipbook because this method allowed us to have more control over the individual frames on the animation. The function was activated using a looping timer and the timer speed could be changed to increase or decrease the speed of the animation.

Fig 17 - Initial Room main menu

Fig 18 - Main menu blueprint setup with keyboard/gamepad support

Due to one of the diversifiers (modifiers that you apply to you game that gain you extra points) called “Keep it simple“ we were restricted to only using a D-Pad and two buttons. This diversifier forced me to create a menu that included keyboard/D-pad navigation. To move up and down through the menu you used the up and down keys and to select button you pressed either space, enter or the bottom face button on a controller.

Fig 19 - Basic difficulty selection widget

To save time the difficulty selection screen used the exact same system as the main menu. Each difficulty button opened the same level but they all have different player icons, the four difficulties represent the four members of our team.

Fig 20 - Initial attempt at the heads up display

Fig 21 - Player icon array

Fig 22 - Widget blueprint that controls the which player is chose based on the level of difficulty

Based on the selected difficulty during the difficulty selection menu the selected player integer will be set between 0-3 which will determine the player icon in the players heads up display.

Fig 23 - Changing the player icon system to set a single array and a single brush texture node

Eventually I decided to refine the blueprint so that there is a selected icon array which is populated with the selected player icons and then the brush is set. This system is that different than the original solution but I felt it was more organised and easier to understand.

Fig 24 - Game over and updated heads up display

Fig 25 - Setting the health text on the heads up display based on the players health and changing the player icon

For the health value I set the text so that it updates whenever the health gets updated. When the health reaches below 66 the player icon will change to a sad face and when the health value is below 33 the player icon will switch to a crying icon.

Fig 26 - 4:3 camera settings

To keep to the DOOM aesthetic, we made the decision to limit the players camera to a 4:3 screen ratio. Within the camera options there was the option to change the aspect ratio of the camera to 640 by 480 which is a 4:3 screen ratio. Changing to this ratio adds black bars to the players view if they are playing the game on a wider aspect ratio monitor. Due to this change in screen aspect ratio I had to change the heads up display so that it fit the new aspect ratio.

Fig 27 - Time left event that controls the time HUD element

To add a sense of urgency to the players experience we added a timer to the players head up display so that they had to clean the house within a set amount of time. If the time ran out the game over event would be called and the game would end.

Fig 28 - Game over event

The game over event plays the game over animation and then the credits will appear.

 

Figures List

  1. Rees, O (2019). ROOM main menu. [Offline]. [Accessed 29/01/2019].

  2. Ibbitson, S. (2019) Room Global Game Jam group photo [online]. Available from: https://ggj.s3.amazonaws.com/styles/game_sidebar__wide/team_picture/2019/01/157242/20190127_152720.jpg?itok=3iBPj41t&timestamp=1548603109 [Accessed 28/01/2019].

  3. Rees, O (2019). Initial blockout of the first room with gaps to show where the doors will be placed. [Offline]. [Accessed 29/01/2019].

  4. Rees, O (2019). Door with a box collision component. [Offline]. [Accessed 29/01/2019].

  5. Rees, O (2019). Door opening timeline. [Offline]. [Accessed 29/01/2019].

  6. Rees, O (2019). Door blueprint. [Offline]. [Accessed 29/01/2019].

  7. Rees, O (2019). Door opening function using the door direction enumeration. [Offline]. [Accessed 29/01/2019].

  8. Rees, O (2019). Default public door variables. [Offline]. [Accessed 29/01/2019].

  9. Rees, O (2019). Default public door variables (in use). [Offline]. [Accessed 29/01/2019].

  10. Unknown. (2017) Doom heads up display shows the players arms from a first person perspective [online]. Available from: https://i.redd.it/n04te0oa72vx.png [Accessed 29/01/2019].

  11. Rees, O (2019). Hand sprite component setup. [Offline]. [Accessed 29/01/2019].

  12. Rees, O (2019). Hand sprites attached to the camera in the viewport. [Offline]. [Accessed 29/01/2019].

  13. Rees, O (2019). Camera shake component. [Offline]. [Accessed 29/01/2019].

  14. Rees, O (2019). Activate the camera shake/view bobbing effect when the players velocity is above 1. [Offline]. [Accessed 29/01/2019].

  15. Rees, O (2019). Finished view bobbing effect. [Offline]. [Accessed 29/01/2019].

  16. Rees, O (2019). Hand animation using an array of sprites. [Offline]. [Accessed 29/01/2019].

  17. Rees, O (2019). Initial Room main menu. [Offline]. [Accessed 29/01/2019].

  18. Rees, O (2019). Main menu blueprint setup with keyboard/gamepad support. [Offline]. [Accessed 29/01/2019].

  19. Rees, O (2019). Basic difficulty selection widget. [Offline]. [Accessed 29/01/2019].

  20. Rees, O (2019). Initial attempt at the heads up display. [Offline]. [Accessed 29/01/2019].

  21. Rees, O (2019). Player icon array. [Offline]. [Accessed 29/01/2019].

  22. Rees, O (2019). Widget blueprint that controls the which player is chose based on the level of difficulty. [Offline]. [Accessed 29/01/2019].

  23. Rees, O (2019). Changing the player icon system to set a single array and a single brush texture node. [Offline]. [Accessed 29/01/2019].

  24. Rees, O (2019). Game over and updated heads up display. [Offline]. [Accessed 29/01/2019].

  25. Rees, O (2019). Setting the health text on the heads up display based on the players health and changing the player icon. [Offline]. [Accessed 29/01/2019].

  26. Rees, O (2019). 4:3 camera settings. [Offline]. [Accessed 29/01/2019].

  27. Rees, O (2019). Time left event that controls the time HUD element. [Offline]. [Accessed 29/01/2019].

  28. Rees, O (2019). Game over event. [Offline]. [Accessed 29/01/2019].