Let Me See Gray
Two different endings and two different play styles.

Project Details
Role: Level Designer
Game: Fallout 4
Engine: Creation Kit
Team Size: Solo Time

Description

Let Me See Gray is a single-player level set inside the small town of Eden Farms. In Eden Farms, a band of super mutants has invaded a laboratory that developed a serum that can reproduce food ten times faster and without radiation. The laboratories head scientist Dr. Willey asks for the player’s help to clear out all the super mutants in his lab so that he can continue his research near the end of the level. Unfortunately, the player learns Dr. Willey has been turning his staff into super mutants. The player must decide to let Wiley continue his research to help the commonwealth or kill him and let the Serums progress die.

The perimeters were 10-15 mins of gameplay if the player followed the critical path. Then, a side quest that has some relation to the main quest but that does not need to be completed to finish the level. There also needed to be one exterior and interior with two characters with multiple dialogue scenes and two combat encounters.

Gameplay Goal

My main goal was to get the player to engage in more stealth opportunities. I achieved this by having a mix of powerful ranged weapons, cryo mines, and grenades, as well as having terminals placed around key gameplay areas that can be used to retarget them to the super mutants.

level design goals

Stealth Opportunities

I wanted to create a level where there were a lot of stealth opportunities. For example, I use terminals connected to turrets where players can hack them to turn against the super mutants. This was effective in playtesting and gave more opportunities for the player to read notes about the story of the level.

I also added powerful ranged weapons like the missile launcher, which the player can use to target multiple enemies simultaneously. Both gameplay opportunities helped the player to engage in more stealth / ranged stealth combat playstyles.

Impacting the Player’s Decisions

After discovering Dr. Willey has been turning his staff and the citizens of Eden farms into super mutants, you must make an important decision. Do you kill the man who can create a serum that can repopulate the Commonwealth with a healthy food source, or let him go on and continue his inhumane practices?

Both decisions have an impact. Throughout the level, the player meets characters talking about the miracle of Eden and evidence of its effectiveness. This makes the decision hard for the player in the end. If the player decides to kill him, the future of the Commonwealth is lost, and everything the player saw up until the end will die. On the other hand, if they chose to let him go, the player leaves the lab and discovers the town has been occupied by the super mutants that Dr. Willey has created and that the characters the player has met along the way have been captured.

PostMortem

WHAT WENT WELL

Developing the Space Effectively and Iteratively

I felt I did a great job on my LDD regarding how the player will interact with the space—considering initial sight lines, conveyance, and gameplay too. I noticed how comfortable I felt while creating the detail and overview map. I have been learning a lot about space, and it was much easier for me to design something early on. I also used Unreal Engine 4 to create some initial walk-throughs. I got to work on my documentation before, looking for suitable icons and colors to communicate clearly to the reader. I feel using Adobe Illustrator and Unreal Engine 4 sped up that process since I could experiment before putting pen to paper. I am comfortable with both tools, which made a big difference in creating an initial draft of my design. I also was able to consider the different playstyles like stealth and melee. I do feel it was not executed well. However, my LDD was designed around this before I entered Creation Kit.

I am very grateful because this felt so much more natural, and I was able to solve a lot of design problems before going into development. In addition, I felt this was successful because I learned that keeping things simple for the player is a must. Finally, this sped up my iteration process after I finally had a fully functional level.

Developing Non-Linearly

Fallout 4 was a massive undertaking. I am still surprised by how much work it took to set up a quest and how much more work was needed at the end of development to get my level to where the gameplay felt complete. A level is never truly finished. Because of this type of work, a different approach and mindset are required. Ultimately, it’s the spiral development process that keeps things on track. It is also what keeps you sane. This process's backbone is ensuring the level is consistently playable. That is an effortless statement to make. But learning how to practice this is another thing entirely. I made many mistakes in developing this project early on that put me far behind schedule. However, near the development's end, I felt I learned from them. The biggest mistake was developing non-linearly. My gameplay was built around hacking terminals and retargeting them toward super mutants. I struggled with this a great deal. So much that I cut it out of my gameplay entirely until I was pushed to try and get it working again without any bugs. This is to be expected, though. There is always something new to learn and new mistakes to be made. But keeping the level playable where I can get feedback is paramount.

Furthermore, building practices that help me to keep a level in a playable shape is a skill that can be developed. One that made a huge difference is working in “passes.” Breaking up an important goal, like adding lighting into the game, into different smaller goals. What helps me is writing out a condition of satisfaction for the whole level, like an Epic in SCRUM, and then creating smaller goals like adding lights and building it out from room to room. Then the next pass is adding light sources, adjusting the lighting after a playtest, etc. This gentler process keeps the level growing rather than stopping development for the whole level to implement one “feature.” If you do it incorrectly, like I was early in development, you’re just using the waterfall development method rather than the spiral development process.

Connecting Spaces – Increasing Flow

I feel the most vital thing in my level and process on this project was visually connecting one space to another. For example, it’s incredible how removing and replacing a wall with a window can do wonders regarding conveyance. Furthermore, teaching the player early on the difference between a locked, unlocked, and inaccessible door was something I enjoyed developing and implementing. Still, it also provided a consistent design language throughout my level. This is also something I can bring with me into my next project. Teaching the player how one room connects to another without opening a door and walking through it makes the level flow stronger and better paced.

WHAT WENT WRONG

Holding the Player’s Hand

My biggest mistake was giving the player a goal and not having the level design communicate how to solve it. I would hand-hold the player a ton by using keys and directing the player from point A to B constantly. This took the fun out for the player. I struggled a lot with this. I was worried about soft locks, but that made everything quite stale and straightforward, so much so that most players thought they were just told what to do.

For example, I have a character named Greg Davis who needs help escaping from a jail cell. Playtesters would walk by him early in development, and they wouldn’t understand their objective. In response to that challenge, I added a greeting where he asks for help and tells the player how to unlock the door to the cell. Unfortunately, this took out all the fun for the player. I should have given them the same challenge but had the level design do the talking for me by using conveyance in the space of the level.

Furthermore, most of my level was about clearing out rooms, and then the player met up with Dr. Wiley after every significant combat encounter. The player has four keys by the end of the level. This is very repetitive and comes off as uninspired stale gameplay.

Gameplay Balance for Types of Players and Skill of Players

Throughout the development of Let Me See Gray, I tried in many ways to balance the level’s gameplay from an inexperienced player to an experienced one. The approach I tried the most was adding different weapons, more stimpaks, and powerups like bufftats. This works but misses the bigger picture, and it can get out of hand quickly if you forget what your original design intent was. That was building a level around stealth opportunities for an inexperienced player. I tried other things like having leveled enemies so if an experienced player plays the level later, they have a challenge. For the amateur player, I removed Molotov cocktails from the super mutant’s inventory so the super mutants couldn’t endlessly bombard them with powerful attacks. This is great. However, I learned that the level should first be developed around the primary target player and then add other elements to ramp up the gameplay for more experienced players.

WHAT I LEARNED

Know Unknowns

There are known knowns like adding a building into a cell. I know that it’s simple and easy. Then there are known unknowns, like “How do I create a patrol path for an enemy to follow.” Earlier in development, I didn’t know how to do that. Knowing what I don’t know can be just as valuable as knowing. Making a list and finding a peer or stakeholder for help earlier in development when things are not hectic will help reduce errors and speed up development. I would wait until I needed to implement something into my level before researching it.

It's okay not to know, but understanding how to respond to something technically challenging strengthens developers. Ultimately this habit is about becoming a proactive developer rather than a reactive one.

Learn to Walk Before I Run

As a Designer, I don’t have a problem facing challenges or adversity. However, I stumble and doubt myself constantly when it comes to development.

I ran into many technical challenges throughout development, just like everyone else. However, this shouldn’t be feared but welcomed. Not knowing the solution to challenges is just a fact of life, and it exists in development too. Not knowing is part of the design and development process, but so is learning to communicate what I don’t know effectively.

There are some good practices in learning to ask for help. For example, saying, “This is what I am seeing,” but “I want this to behave this way.” Then adding that I had already tried to fix the problem somehow.

Another practice is taking a step back. Taking a step back can be a step forward if you have a proper mindset. When technical challenges arise, endlessly searching for a solution to a problem I don’t fully comprehend will take me down a rabbit hole of APIs and endless internet searches.

Pausing and understanding my technical problem thoroughly will speed up the development process. This is an essential communication tool. I have also learned it is something that is born out of habit. It is a skill that can be acquired regardless of what I think sometimes.

Building my knowledge and the terminology of a language or development tool is very helpful. But, like everything, this takes time. Making a list of the most important things I need to create a playable prototype is that foundation. If it’s not playable, I can’t put it into someone’s hands to gain feedback; I need to solve a technical issue.

I need to walk before I run. Take it slow and embrace the process rather than be frustrated by it.

Playtesters Are More Than A Friend

Last semester Half-Life 2’s gameplay was about 15 mins of playtime. It was quicker to playtest and get feedback. The requirements of the space were less as well, and it didn’t involve a real-time lighting system with weather effects or complex friendly and combative AI. Quite simply, Fallout 4 is a different beast. However, it is so much more powerful. I love this engine, even though it drives me crazy at times. Finding all the bugs, Z-forcing, soft locks, and showstoppers is a full-time job if you do it all yourself. Leaning on my peers and stakeholders was not only a wise but essential idea.

It is funny how you can miss some giant bugs when you playtest your level. Mainly because you play your level the way it was “meant” to be played. The problem is “the way it’s meant to be played” is subjective. So asking for help with a playtest from my peers and stakeholders makes all the difference in the world. Simply put, they can find things I can’t and find them faster.

Gallery

NEXT