Rush Devour
Embedded Files
My contribution to Rush Devour
DEVELOPMENT
During my third year of studying Games Design, I collaborated with fellow students to develop Rush Devour. Our task was to create an innovative and accessible game prototype along with a unique hardware input device that would enhance the gaming experience. We opted for a one-button RPG to infuse a spooky element into the game, and we decided to build the physical controller as well. Our primary goal was to cater to individuals with motor issues, and we believed that the simplicity of the one-button approach would be perfect for them.
Before starting to code I decided to first of all come up with some of the coding risks that might happen with this project and how I would deal with them/stop them from happening in the first place.
Accessibility - While making the game for once specific disability can allow for a lot of polishing on those features it can often leave those without disabilities or with other disabilities struggling to play the game with the same efficiency. Whilst creating options to control some of the values affecting gameplay it will also be important to check the gaming accessibility guidelines for recommendations and for making sure it's on track.
Inexperience - Many of the systems required for the game I have not implemented in other games before meaning the time to complete tasks may increase, because of this I need to scour the internet for similar videos/forum posts to get a better understanding of what is required to achieve a certain mechanic.
Equipment - Due to every monitor having a different image quality the brightness on one monitor to another may drastically change which could heavily harm gameplay if it's too bright or dark, in order to accommodate for most people I will have to configure settings at the university as well as having options to change certain graphical values.
To start, I began by creating a preliminary layout for the level just by using cubes. Our level designer provided a bird's eye view of the layout and numerous key details to guide my decisions. My primary objective at this stage was to develop the movement system, as the graphic design would occur later on.
Initially, the game had a design where the player would continuously move forward and pressing the turn button would rotate them by 90 degrees. However, we received feedback from a lecturer who had arm motor issues, prompting us to modify the game's controls. Thus, we made it possible for the user to select the direction they wanted to turn, reducing the number of button clicks required. This change made the game more accessible to those with disabilities. Additionally, I researched the appropriate time intervals for the flickering lights to avoid triggering epilepsy. After careful consideration, I set the minimum time between flickers at 3 seconds to ensure the safety of all players.
rushdevour1.mp4In order to tell the player that they were approaching a Zombie we used a rat that would spawn within a certain distance and using a nav mesh agent go towards the player's position before eventually despawning. We decided to use this visual cue along with a rat noise so that players aren't relying on one sense.
The zombies in the game are assigned fixed points that they loop around, once the player gets close enough they deviate from this path and follow the player, if the player gets a certain distance away from the Zombie the Zombie will return to its patrol path, however if the Zombie gets too close you will get into battle with it.
In order to interact with the environment we created a bar that the user had to fill up by clicking the button. For inanimate objects the user could take all the time in the world as they cannot fight back but against Zombies if you don't press it quick enough the Zombie would start fighting back. It's important to note that nothing will happen until the user presses the button first meaning they will never be caught off guard.
I created a Main Menu to test how users can navigate and interact with menus. However, I encountered some difficulties that I did not anticipate. Initially, I used the left-click of the mouse to move from one button to another and then hold down the button to confirm or perform the on-click method. Since we did not have a controller initially, I decided to utilize Unity's new input system, which allowed me to assign multiple keys to a function. This made the game compatible with various controller types. The only issue was that when using the back button to return to the previous menu, the first button in that menu did not automatically highlight, which was my intention. To fix this, I had to create a new action map for each menu and enable/disable them accordingly. Although this solution was tedious, it was successful.
As I worked on the Main Menu, I decided to create a custom underground scene using ProBuilder to enhance the player's immersion. It was even more exciting when a train passed by the user's screen at intervals.
In the Options menu, I aimed to make the game more accessible than my previous projects. I added the Brightness option to tackle the issue of varying monitor brightness, ensuring that the game is neither too bright nor too dark for players. I also included a Contrast and FOV slider. My decision to add these options was influenced by https://gameaccessibilityguidelines.com/. To make the game friendly to colourblind players, I added a colourblind slider. Since the game used red and green colours to indicate negative and positive things, I couldn't avoid using them altogether. Instead, I allowed players to switch to orange and blue colours, which work with the three main types of colourblindness.
To showcase the game's accessibility, I created a small accessibility menu that highlighted all the features we used from the game accessibility guidelines website.
Implementing the unlocking/picking up/selecting of weapons was a new challenge for me. Using Player Prefs, I made it possible for the keycard and keys to be automatically unlocked, while the other weapons could be unlocked by picking them up in-game. I also added a visual indicator that shows green for unlockable items and red for unlocked items, making it easy to see which weapons a player can equip at any given moment.
To add more of an environment to the game I added a foggy smoke particle effect that laced the floor of the level to give you a feeling that there could always be something behind it. I also used colour adjustments to make the scene colder to fit the underground, a vignette to focus the player's attention on them also darkening the scene and some bloom which was mainly for the lights in the scene.
I also originally had a trash can with some flies with 3D audio but I later decided to remove them as they were a bit pointless and audioly distracting.
rushdevour2.mp4
I took it upon myself to create the first level using ProBuilder due to time constraints and issues with our level creator. ProBuilder was the tool of choice because it allowed me to keep everything within Unity and my 3D modelling skills are not extensive. With ProBuilder, I was able to adjust the texture scales to ensure a seamless look and the end result was a much-improved scene.
To design the weapon UI, I opted to reflect the main menu settings. The selected weapon was highlighted in purple, while locked weapons had a '?' sprite and the rest displayed their proper sprite without selection.
For the dialogue, we had various types, some requiring one or multiple lines, while others auto-scrolled or required player input to move to the next line. We maintained consistency by typing at the same speed, using a typewriter effect to display one character at a time, and utilizing bold/italic/colour to emphasize specific text. We also recorded voice lines to bring our female character to life.
Page updated
Google Sites
Report abuse