Elysiums.Downfall.io

Project maintained by alykkehoy Hosted on GitHub Pages — Theme by mattgraham

Table of Contents

Overview

Elysium’s Downfall is an online cyberpunk 3D dungeon crawler that takes place on a derelict spaceship headed through deep space. The game was a project developed in 3 short months using Unreal Engine 4.

During this time, our small team of 3 was able to implement the following in a multiplayer setting:

This page will document the work we did and the tools we used to achieve it.

Tools Used

Members

Anders Lykkehoy: Lead Programmer, Project Manager
LinkedIn: https://www.linkedin.com/in/anderslykkehoy/

Kevin Corbett: Lead Level Designer, Community Manager, Lead IT
LinkedIn: https://www.linkedin.com/in/kevincorb/

John Corry: Lead Character Design
LinkedIn: https://www.linkedin.com/in/john-corry-58b890160/

Project Management

The group used multiple Trello boards to track progress and bugs during the project. These boards were critical to our success and helped us with controlling scope creep and time management.

Prototype

Trello Board for the Initial Prototype: https://trello.com/b/UmMnPtnu/prototypetimeline alt text

In the Prototype board we initially made cards for features we wanted to have in our prototype. We then broke those cards down into sub-cards and placed them across multiple weeks to create a loose schedule. At the start of each week, we had a meeting to discuss how the previous week went and assign cards for the upcoming week. This allowed us to have a good overview of the work required and project if we were still on track to finish in time.

Bugs

Trello Board for Bugs: https://trello.com/b/o4tQKuno/bugs alt text

The bug board listed a bug on each card. We then categorized them based on impact level and type (ui / gameplay / animation / etc.). We then sorted the cards into columns based on how difficult we thought they would be to fix. This allowed us to easily prioritize bugs. Once we fixed a bug, its corresponding card was moved into a new column to be tested in the next build before being marked as fixed. alt test

Final Thoughts

From a project management perspective we found Trello to be indispensable. It allowed us to constantly have an understanding of where we were in the process and helped us make sure we were on track to finish in time.

Gameplay Systems

Player Health and Shields

Every player has health and a shield. Their shield automatically recharges after a delay of not taking damage while their health does not. To restore health, a player must use health packs or return to the main HUB city. This is displayed via a UI element in the bottom left of the screen. (White for health and blue for shield)

alt text

In multiplayer, all players have a floating nameplate displaying their Steam ID name, current health and current shields. alt text

Inventory and Weapon Stats

alt text From this screenshot, you can see our UI for chests, the player backpack, and weapon tooltips. All weapons have a name, description (if one exists), damage per hit, and fire rate showing on their tooltip. alt text Every available weapon is stored in the gun table. This table defines additional information about the weapon including: item id, projectile count, mesh, animations, etc. This allowed us to add additional weapons much faster and keep them all organized. If a weapon ever needed changed, it’s as simple as editing its corresponding table entry.

Buff / Debuff System

alt text Just like weapons, buffs are stored in a table. We implemented a few basic buff types that could be expanded on such as: Health, Damage, Damage Reduction, Stun, and Slow. You can also decide if the buff is displayed on the players’ UI or if it should be hidden. This ability to hide buffs was used in a few places. One example is when a player is revived by a teammate, they temporarily get a damage reduction buff while they get their barrings back so they don’t immediately become “downed” again. Also, the player that is resurrecting the “downed” team member gets a hidden damage reduction buff to provide a bit of extra wiggle room in getting teammates “up”. (We discussed if this could be abused in anyway and decided even if it could, for the fun of the game it made sense to leave it in) alt text Here you can see the UI element for visible buffs and debuffs. The name is given along with its duration.

Player Revive System

When in a multiplayer game and a player dies, they go into a “downed” state. This drops an object on the ground that another another player may interact with to revive the “downed” player after a short time. The interactable object has a UI element that displays the “downed” player’s name and a countdown timer till they are resurrectable.

(The images below were taken in a development build of the game not connected to Steam so the default name for the interactable object is shown in place of the Steam ID name) alt text Once the countdown timer for the “downed” player has run out, the UI element updates to show them as resurrectable. alt text

Dialog System

We used a dialog tree plugin for Unreal in combination with our interactables system to make NPCs players can talk to. Interacting with NPCs starts their dialog and gives players options for responses. This allowed us to more organically inform the player of the world and direct them toward the next objective.

Here is an example of an NPC teaching players about the HUB city of Sanctuary. alt text alt text

Here is an example of an NPC giving hints about boss mechanics. alt text

Player Classes and Skins

Our original pitch of the game included player classes similar to other RPGs. Our thought was to try and implement the class trinity of Damage Dealer, Healer, and Tank. In our case the role of the Tank would be someone who buffed the group making all players take less damage, and Healer would be someone who provided a boost to players’ shields. Unfortunately this system had to be cut due to time constraints. We would have liked for players to have had a choice of what class they thought would be useful in an encounter, but ultimately decided that it was not key to our gameplay vision.

Since John had already worked on models for some of the classes, we moved to a skin based system where players could change their player skin to express their personality. alt text

Here is our character originally planned to be a “Tank” class. alt text

Player Mask System

When we began designing systems, one of the first ones we thought of was this mask system. Our thought was “well, the player is in space so it would make sense that they would have some kind of respirator or breathing device”. We then wanted to tie the masks into the player classes by having certain masks provide benefits to corresponding classes. This system got scrapped for 2 reasons. First, it felt bad to us that a player would be forced into using a specific cosmetic item to be optimal. Second, we didn’t have classes anymore so the buffs the masks provided would seem out of place. At the same time we didn’t want to throw out the work John had already completed designing and modeling masks, so we kept them in as cosmetic only enhancements.

alt text

Maps

Tutorial Area

Below, you will find a screen shot of our tutorial area. This is where we teach the player about their inventory, weapons, and the mask system. We also force the player to interact with a terminal to leave the tutorial area. This allows us to know the player understands that terminals are important interactable objects. alt text

Main Hub: Sanctuary

Sanctuary worked as our main hub for the game. From this area players could travel to bosses, change cosmetic items, and put items into their long term storage. This is also the location players could interact with NPCs and buy items such as weapons and health kits. Below is its rough block out with main features and the beginning of the placement of key points of interest.

alt text alt text alt text

PvP Arena

One of the largest requests we received from players after our closed beta was for PvP. As it turns out people really like shooting their friends online, so we knew we needed to include a space for players to do that. This feedback resulted in the creation of our PvP Arena. Typically friendly fire was disabled, but when you entered the PvP arena anything was fair game. alt text

Boss Encounters

Since both Anders and Kevin are fans of World of Warcraft, specificity raiding, when it came time to design boss encounters they pulled from their shared background and design language. Right off the bat we knew we wanted to include 2 versions of every Boss. One being the “Normal” mode for 1-4 players and the other being the “Hard” mode which requires a full team of 4 working together.

Boss: The Mech (Normal)

The background of The Mech is that a rogue group of humans has been attempting to repair a large mech to overthrow the current rulers of Sanctuary. It is the players’ job to infiltrate their base and destroy the mech for good. To do this, players must destroy shield generators around the Mech to gain windows to do damage. After a set amount of time, the shield generators self-repair and they must repeat the process while fending off the rogue group of humans. Every 25% of the boss’ health, he releases a large shock wave doing extreme damage. To combat this, players must time the activation of a shielding bubble to provide them with substantial damage reduction.

Unlit view of the boss room. alt text

Example of the boss shielded. (No generators destroyed) alt text

Example of a generator that must be destroyed. alt text

Picture of the activated players’ bubble shield as well as its corresponding buff in the top corner. alt text

Boss: The Mech (Hard)

Designing the Hard mode version of the fight, we kept everything from the Normal version, cranked it up to 11, and added the need for cooperation. To start with, there are 2 generators at a time, and they must be destroyed within 7 seconds of each other. Because of the layout of the room, this requires 1 person by each generator.

The hallways leading to the generators now contain a puzzle / trap that requires communicating with another player. Each hallway has cut electrical cords hanging from the ceiling, requiring the power to be turned off or the player will be electrocuted. To do this, they must communicate with another player the color of the lights in the hallway as they correlate to the color of a terminal in the main boss room. Activating the correct terminal (matching the light color) will disable power to the hallway, allowing the player to pass through unimpeded to destroy their generator.

Lastly the terminal the provides the shield bubble to the players is on the otherwise of the room divider, forcing a player to fight back to the entryway in order to activate it for the team.

Example of the hallway light puzzle and corresponding terminals. alt text alt text

New location of the bubble shield terminal. alt text

Final Update Trailer

Final Thoughts

First and foremost, multiplayer is hard. We underestimated the challenges that arose designing around multiplayer. At the same time, it was incredibly rewarding. By the end, being able to get on discord and kill bosses together and pvp made it all worth it.

For anyone looking at this project, yes, it is rough, but the core systems are all there. When working on this project, one of our goals was to make sure every system was scalable, and we believe we achieved that. Adding weapons is a very straight forward process. Creating loot chests to dispense those weapons is effortless, and creating new buffs and debuffs is intuitive.

This was a fantastic project beyond just the game development aspect. We all learned a ton about project management, team cooperation, and playing to each others strengths. Hopefully this write up provided insight into our vision and execution of this project.