Breaking Bank
Breaking Bank was my Final Major Project (FMP) or my MSc in Video Games Enterprise, Production and Design. This was a self defined brief that was pitched, designed and developed in 10 weeks. Breaking Bank was developed in Unreal Engine 4 by a team of five people. Three Programmers, one Producer and one Designer (myself). The goal of the Project was to create a light Payday 2 like game that had a simple gameplay loop and some replay ability. We also wanted to explore Networked multiplayer with Asynchronous PVP (Think Payday 2 meets Left for Dead PVP). But, I will go into how that plan unfolded later on.
The Level in Breaking Bank is biased on the Bank level From Payday 2. I chose to create a level I knew well from Primary research (Playing the game, my favourite type of research) leading up to the start of the pre-production. I chose to do an already proven level design so that I could focus on other aspects of the games design. I made this decision due to the fact that I was the only designer on this project. Not needing to go through the full iterative process for the level design gave me more time to spend on system design and milestone presentations for our acting stakeholders (my lecturers).
Although I was using a proven level design I still had to go through the process of White-boxing and into Grey-boxing to find the scale and correct floor space. I began by making the basic layout of the Bank building. I made sure to frequently reference the source material but not to adhere strictly to the total layout. After finding the dimensions I was happy with, taking into consideration player and AI movement, I began to devise some of the systems that would make up the core mechanics of the game and how they would fit into the level.
I looked at Payday 2 as a reference for the obstacles that the player has to circumvent in order to obtain the goal. You can classify these obstacles as passive and active. For example, an active obstacle is a guard as they move around the environment limiting the areas that the player can access without detection or when the heist goes loud will seek out the player to attempt to eliminate them. A passive obstacle could be a door that requires a key but doesn't cause the player to lose the incognito status or try and kill the player.
From the research I created a list of some of the most common uses of Active and Passive countermeasures that were the most commonly used throughout Payday 2 and other games with stealth elements. My research showed me that balancing these different types of countermeasures would be key to finding the correct difficulty for the level. Passive countermeasures are like obstacles to dodge. Active countermeasures are obstacles that the player has to interact with to surpass and in some cases inaction will cause failure.
After creating the basic layout of the level and finding some of the potential obstacles that we can use, I began to create some layouts of the level including: guard patrol locations, camera placement, doors and keys.
.jpg)
When figuring out where to put the elements in the level I used the planning map from Payday 2 to plot the positions. Some of the locations are the same as in payday as the level geometry has natural choke points for the obstacles to be most effective. For the most part this map remained accurate to the final game although some guard nodes and some key card spawn locations moved.
Once I figured out how the level looked and functioned it was time to fully define the player: how the player would interact with the world, stealth mechanics and combat.
Using FPS games such as Payday, Destiny, Halo and CoD I was able to approximate these starting values for the 4 weapon architypes. Each weapon is designed to have a range that they are most effective at. The Rifle is for medium to short range, the shotgun for close range, the Sniper is for extreme long range and the pistol for medium range uses and for a backup if primary needs a reload.
Along side this I researched how different shooter gamers handled health systems and found that the system found in Payday 2 is largely similar to systems found in other first person shooter games like Halo: Reach. Looking at how these systems worked in a vacuum and then how they interact with the combat system to create an ebb and flow. The system works on two resources, Armour and Health. Health is a finite resource that when depleted causes the player to die. Armour is a potentially infinite resource that acts as a buffer to Health that, if no damage is taken for a short period, will regenerate to a predetermined maximum.
For this example lets assume that the player has 100 Health and 100 Armour. If the player takes 50 damage they will be at 100 Health and 50 Armour. After a predetermined amount of time the Armour will start to linearly regenerate until it has reached the max Armour or the player takes more damage. If the player takes damage over the remaining Armour the player will take Health damage. This damage will not regenerate. Then the Armour regeneration takes place as normal regardless of the Health value.
This system, although simple, can greatly impact how players fight. With all of the systems together there is a few things the player needs to consider when deciding to hide or to fight: number of enemies in area, position of enemies, ammo count, health and armour status, amount of usable cover, potential escape routes if the player needs to retreat and objectives in the area of the fight. This level of complexity allows for players to make decisions and allows for potential player skill growth.
It was at this point in the project that after receiving some feedback and looking at the time remaining at hand that we did not have the development resources to create the asynchronous PVP aspect of Breaking Bank so we decided to cut it from the scope of the game so we could focus on the core gameplay and also keep looking at the networked cooperative elements as we had already created a basic joining game system utilizing the Steam networking solution.
Now that we had our player systems designed and in development I needed to start creating some of the ground work for the front end of Breaking Bank. To show the flow of how these menu screens would work and what each would contain I created this menu flow chart wireframe.
The flowchart above shows all of the interactions a user may make within the menu and where that interaction will take them. This chart helped the programmers with building the architecture for the menus and helped when bug testing to see if the in game layout was correct. It was also useful for trying to figure out how many button presses the player has to input before they can play the game. This instance of the menu requires 2-3 button presses depending on if the player is the host of the lobby.