Wastelander's Inferno
Project Overview
Engine: Fallout 4 Creation Kit
Platform: PC
Synopsis: "Wastelander's Inferno" is a single player mod for Fallout 4. Within the mod players will enter an arena wherein they will be confronted with a series of obstacle courses each different from the last to earn sweet sweet cash money.
​
Key Takeaway: It's easier to adjust your design than it is to force your design to work in the tools. Learning to be flexible with your designs is monumental to success.
Design Goals
Dynamic Combat
Polished World Building
Constantly Varied Gameplay
Dynamic Combat
I wanted each combat encounter I had throughout the mod to be different from each other forcing the player to think on their feet about how best to take down their enemies.
To achieve this I took reference from sequences in the base Fallout 4 game where players would be thrown against traps in a unique way. I wondered if I could integrate those traps into a normal combat encounter with enemies to layer on the components that the player could use to their advantage. This also assisted with varied gameplay outside combat, but what I was able to achieve with specific boss fights with these traps was one of the most exciting results I achieved with this project.
The focal point of this pillar being the boss fights in the 3rd course and how they each have the player fighting a foe much stronger than them, but there are traps in the room that can be used cleverly to even the odds.
Polished World Building
When it comes to the stage that a level sets I wanted to really lean into being able to create a space that felt polished in a concise space and also helps to set the tone of the characters who live in that space.
This meant that each space in the world would need a consideration of what the room was before and after. What was a room before the war that changed the Fallout universe? How has this room changed now that it's been utilized for a totally different purpose in a new world?
​
Additionally, while building this world I took extra care into consideration of how I was conveying information to the player as multiple gameplay sequences would be revolving around challenging the player. I figure if I'm going to push the player to be challenged I, as a designer, also need to balance that by doing whatever I can to subtly help them as well.
Constantly Varied Gameplay
Within the world of Fallout 4 players have a lot of interesting gameplay abilities. What I worked to achieve was to test each of these different types of gameplay in small contained scenarios. I wanted to give each type of player one course they might excel at, and one they might struggle with. So that required me to design around players who love stealth, players who love combat, players who love exploring.
The pieces that I feel best exemplify this are the room where players need to dash across a floor of trap triggers while Raiders shoot at grenades, or the maze where players can fall into 1 of 3 rooms each with different mechanics involved with escaping danger. In both of these sequences there's a multitude of solutions to the problems like as if it were a DnD puzzle. This allows players to feel clever at outwitting me and can result in some really fun moments to play through.
What Went Well
-
Frequent communication.
Stakeholder was consulted to verify feedback between sprints resulting in clear communication of milestone results.
-
Test early, test often.
Later milestone sprints had many tests conducted across multiple machines to find and squash all bugs possible allowing for more precise design passes to be conducted.
-
Balance achieved quickly.
Thanks to the numerous tests that were conducted I was able to iterate on the difficulty quickly and find a medium that allowed me to focus more time on the stability of the product.
-
Worked in tight iterative spirals
During construction I stuck to a strict schedule of working for 15 minutes then stopping to evaluate the work done. This allowed me to keep an objective view of the actual progress happening and catch when I was getting caught on an issue too long without losing excess time.
What Went Wrong
-
Working against the tools
Early on in development I encountered some construction problems with the level structure that resulted in a lot of seams throughout. Instead of changing the design to better work with the tools I filled seams with props. Iterating on the design to solve the problem more efficiently saved me time later in development, and was a lesson to learn.
-
Time management
I had issues with time management early on in production, learning to create better development habits and not overly drilling into minute details helped to get a lot more work done quickly.
-
Test early, test often
The earlier milestones as compared to the later milestones were a night and day difference because I did not seek as many tests. Putting aside ego to get feedback on what works and what doesn't would have lead to a stronger start to production.
