About The Game
Conjury Revell is a single player FPS action game in which the player fights through a steampunk city full of enemies, slinging spells and utilizing their environment to carve a path. The game features 3 action packed levels, 6 spells, and 3 unique and challenging enemy types. The game was developed by a team of 25 people for PC and Steam Deck.
Contributions
​
-
Level Design
-
World Building
-
Scripting (Unreal Blueprints)
-
Set Dressing
​
In this project, I acted primarily as a Level Designer and World Builder, though I was also responsible for scripting tasks such as creating blueprints, cutscenes, and bug fixing. I contributed to all 3 levels, with level one being primarily my design and responsibility.
Level 2
Level 1
Level 3
Level 1 (Docks)
Level 1 was my primary responsibility from the original white board map to the final product. Level 1 is the tutorial level and so it needed to be carefully designed with a focus on conveyance and gradual combat progression. The player is meant to start level 1 knowing nothing, and finish level 1 knowing how to use all the mechanics within the game.
Learning Space
To teach the player the basics of the game, I implemented a pop-up tutorial system where the player can learn as they play. The player moves through the level, reaching designated learning moments where they unlock and learn how to use new abilities. As they progress, they are gradually introduced to enemies and more difficult challenges. Here the player encounters a broken staircase and learns to jump.
Conveyance
I was responsible for conveyance passes on all levels of the game, but conveyance was most critical on level 1. As players begin playing, they must be able to focus on learning the game and not on how to figure out where to go. I established a clear design language for conveyance early on by utilizing lights and framing to guide the player. The critical path is always illuminated and level objectives are accompanied by flashing blue lights.
Level 2 (City)
The city level underwent many iterations, and was ultimately broken up into 3 sections. In this level, I was responsible for the initial design of sections 1 and 3. This level is all about combat, and letting the player go crazy with casting spells and using gravity to launch objects at enemies. To facilitate this, we designed it to be open for plenty of rapid movement and circular combat flow.
Combat Flow
To achieve our goal of having fun combat flow, we designed the level so that the player could have limitless paths to weave in, out of, and around cover. Section 1 and 2 utilize open architecture and platforms to facilitate this, while Section 3 uses a large flat playground filled with shipping containers and crates. The design allows players to stay constantly moving and sling spells on the run.
Conveyance
As this level is significantly more open than the previous, conveyance became a tricky task. The level is comprised of 2 arenas and a corridor, so it was easy for the player to get turned around. To mitigate this, we adopted the design language I established in level 1 by adding flashing blue lights to major objectives. I also implemented cinematics for each section, so that when the player kills all of the enemies in a section their camera pans to a gate being opened. This allows them to easily move to the next section.
Level 3 (Airships)
Level 3 involves riding a commandeered airship through a fleet, destroying enemy airships as you move through the level. This presented many unique challenges, as each airship would be a mini-arena in itself. In this level, I was responsible for designing and implementing 2 of the 4 airships. The airships were designed for close quarters combat with a focus on movement and cover.
Movement
As the airships were fairly small compared to other arenas, we needed the player to be able to move quickly and freely to avoid getting overwhelmed by enemies. To facilitate this, we designed the airships so the player could jump on cargo crates, move around them, and move through them. We placed the crates and boilers so that the player could always see at least 2 potential routes and would not run the risk of getting stuck in corners.
Cover
As this game is more about running and gunning rather than a cover shooter, cover was a bit nebulas for us at first. Ultimately the 3rd level was too compact to not have a way to shield yourself, so we came up with the idea of using cover to separate enemies from the player via pathing rather than just blocking incoming damage. We designed our cover so that the player could move around and through it, forcing enemies to take a different path and breaking their line of sight. By doing this, the player is able to utilize the entirety of the play space without slowing down combat or dying.
Postmortem
Went Well
Went Wrong
-
Leadership. This was a massive undertaking for 25 people in such a short timeline. Our leads were solid and made sure to delegate tasks effectively. They broke down the team into strike teams and assigned individuals to be responsible for directing the strike teams and communicating with leads.
​
-
Flexibility. Development for this project was rocky, and we hit a lot of roadblocks. It took individuals stepping up and tackling tasks they were unfamiliar with to make things work. It was our willingness to work outside of our comfort zone to get things done that pulled us through.
​
-
Collaboration. We found that creating strike teams made of members of all disciplines worked best for this project. Each strike team had at least 1 designer, 1 artist, and 1 programmer to cover all the bases we needed to make decisions and work efficiently.
-
Unclear Vision. This project spawned from an unclear idea, and suffered for it. From the beginning no one was 100% sure what the game was supposed to look like, and so progress was very slow. Eventually, our GD managed to establish and communicate a clear direction and we were able to pick up steam.
​
-
Dedication. While the majority of the team were committed to the project, a few were more focused on other tasks and the game's progress suffered for it. With an already limited number of teammates, losing more to other work damages our production schedule. Ultimately, enough people were still committed to the project to pick up the slack and get the project to a point that we could be proud of.​
What I Learned
-
Planning. When it comes to a game like this, it is absolutely critical that the leads and the team have a clear idea of what the game will look like. Though initially we were not there, once we had a clear vision progress picked up. It is important to make a clear plan and establish with everyone what the project is about and what it will look like at the end.
​
-
Adaptability. I learned a lot about how critical it is to be able to switch tasks and prioritize critical tasks. We had many setbacks throughout development and so myself and another designer were assigned to put out fires. We were moved between all 3 levels for weeks fixing breaks, improving designs, and making critical decisions. Through this I learned how to be able to read a new situation and work efficiently to put out fires and get things back on track.