Hi, my name is Joshua Rainbolt, and I’m a Lead Senior User Experience Designer for AWS Game Tech. I am one of several stakeholders who have been lucky enough to be involved with the evolution of Amazon Lumberyard’s prefab system over the past several years. We called them “slices” at the time, because our team noticed an overuse in the term “prefab ”in the game community (so naturally we had to be rebels), plus, we wanted to really own our implementation. Since then, Lumberyard’s slice system has grown and evolved. We’ve taken all of the customer feedback and key learnings along the way to build Lumberyard’s next prefab system; a system which has simple and implicit rules baked into the workflows and usability patterns that requires no explanation to understand, a system where someone can finally say, “Oh I get it,” a system that helps game builders accelerate game production, and becomes something you never have to think about.

What are Prefabs?

(“Prefabs”, if you’re unfamiliar with the concept, are basically an abstraction for collections of game objects that you instance and work with within a game. Sounds simple? Read on!)

Over these past four years the amount of learning, changes, and growth in this area of prefabs has been amazing to watch! I’ve been fortunate enough to ride this particular train and learn how something so seemingly simple is really the backbone of all the video game engines we know of today.

“What?” You say, “How can this mere concept be so pivotal in the gaming world?” Let me tell you, if you’ve ever fired a video game weapon, spawned a character, seen an outdoor environment rich in trees and vegetation, picked up an object, or pushed a block, you’ve probably interacted with a prefab. All of these actions are enabled by prefab systems in game engines. This notion of a “prefab”, once converted to code, is the very backbone of a game engine.

Now I can feel some of you nodding your head in agreement already. “Yes, Josh. Prefabs are universal and versatile. They are the dynamic visualization of any gameplay elements (and their relationships to other elements) that are drawn on your screen. They are one of the foundational tools to make a game engine work efficiently and smoothly.” Indeed, they are everywhere and yet as a consumer you wouldn’t even know they exist.

So with something as invisible as a prefab, you would think, “Why do game engines care about improving these frameworks? Isn’t a container just a container?” Great questions! With a powerful prefab system you can cut out thousands of hours from game production work, you can produce your game on more platforms (because it cuts down on memory usage),  you can reduce the content creation overhead with dynamic content, you can reduce your game’s final package size, and so much more. With a powerful prefab system, a game designer can focus on the most important parts of the game: the gameplay mechanics and the fit-and-finish.

Where did this all start?

One of the first tasks I had when joining this team back in 2017 was writing a usability guide for our then-slice system. I was quickly dropped into the deep end where understanding our customers’ mental model and how these simple abstractions were so critical to game teams. Ultimately, we uncovered some very specific problems about how users thought these items should work based on similar systems they had used in the past, and at the same time, how our system was so powerful yet opaque. The question then became: how do we build new functionality atop the existing system in a way that would better enable our customers to understand it and use it effectively?

I learned during those early days of user testing that even users who share similar roles on different game teams can experience prefabs very differently. How can something that should be the same across the board be a different experience for different people? The answer is this: there are variations in all of our users’ mental models. Just like coding, there are a variety of ways to solve the same problem, which leads game teams to different outcomes and different situations. Things such as how deep creators nest content, how frequently or infrequently users save their work, and how prefabs talk to one another in gameplay scenarios are all examples of ways game teams who were in the same situation during game production could be stuck at different places.

Our Assumptions

Now, our initial belief was simple. Specifically: Give the user as much freedom as possible to create and build whatever they want and get out of their way. However, we quickly began to see flaws in this assumption. Yes, users can make all kinds of stuff. But they were also telling us about how things were breaking in unusual ways that we had not anticipated, such as accidentally overriding content that made part of their game disappear, creating infinite loops that started crashing their games, and creating prefabs without the proper duplication from the original source asset. The use cases just came pouring in.

Okay, so our initial assumption was clearly incorrect, so what exactly was at the core of the customer issue? After some further research we began to see that users were not understanding the rules in the same way. Maybe language and a better visualization could help people’s understanding of such a powerful tool.

Experimentation

So we started experimenting with visualizations and more distinct language around what each action did. At this point, we felt that our customers were speaking the same language about the problems and more holistic issues were being defined in common terms. So we put a small win in our column, but we still had more investigation to do before we could design a better model.

Early Findings

At this point we were learning some vital information. When a user creates a prefab, references a prefab, or saves a prefab, these interactions are causing confusion about what was actually happening behind the scenes. If I save A, what happens to B? If C is linked to A, will something break in B? If you’re confused, you’re not alone. We started asking: How we could change this foundation enough to enable meaningful, predictable results to our end users? 

We noticed that a major choke point was the Save Slice Overrides system. So we spent time investigating how to better improve reliability and communicate what is going on to the user, and how to make sure the user feels confident about what was just saved.

During these user interviews, a PM and I were meeting with a particular game team and asking them about the recent update, and how this update would change their perspective. The answer I received was not what I expected, yet it became a pivotal point in our story: “I don’t understand this at all. This entire thing is backwards. Why do I need all this?” And you know what? They were absolutely right.

Why on Earth are we building atop a system that doesn’t solve the foundational issues users are reporting? We needed to think differently about this. How can our prefab model be a system that is easy to use and yet be mostly invisible to the user?

Climbing the Summit

So the team put together a slice summit where we got all the experts working on this system together in one room and spent a couple days reviewing the problems from different angles. We began iterating through user scenarios as we all brought a wealth of knowledge from different user perspectives.  If I was a game artist, what were my expectations? If  I was a game programmer,  what were my wants and needs? How might I spend my time interacting with the system?

Do you know what we learned from those few days? That user who was angry was right. We had done a few things backwards. We assumed users needed no guard rails when in reality users want us to create some simple rules they could follow. The rules needed to be simple enough to visualize that it wasn’t too hard to understand what had just changed. This problem could be solved; all that remained to answer was “how”?

Identify and solving problems

Fast-forward to a few months later. Lumberyard had now formed a strike team to address these customer pain points. Each customer’s journey through our slice system resulted in a greater understanding of how differently each game team was interacting with our system and the need for rules that covered a number of game types. At this time, several games were in the final stages of development. The need for comprehensive rules was at its peak. We were now fixing dozens of slice issues, improving performance, rendering speed and hearing from our customers about a greater satisfaction with our overall slice experience.

At this point we were getting better at predicting how issues were going to arise and affect other systems, thanks to all the customer interactions we had. We were starting to build better guard rails, including the introduction of a Quick Save menu that gave users a better understanding of how to help manage their data. As a result, we noticed a drop in customer-reported issues when working with slices. But this wasn’t good enough. We knew there was still more we could do.

With the completion of the slice strike team, we now needed to turn to a long-term, more global effort. We needed to do more than refactor the UX; rather, we needed to refactor how we were processing data, assets, and the customers’ understanding of this process.

Testing our assumptions

So a senior project manager and I sat down with our data and started white-boarding out simple rules that factored in all of the feedback from these game teams we interviewed over the years. We went through our compiled notes and came up with a list of simple rules we thought could be something. We started getting Scott Nelson involved, one of the lead developers today on our prefab system. He helped flesh out our ideas and validated that our rules held water. Eureka! We were on to something. Now we just needed to put together a demo to validate the process we had made.

I made an interactive demo and defined 12 steps to test drive this workflow for our customers. Beyond being able to test the usability of the features, I was also able to program some simple logic that helped us understand which steps were the hardest and which paths they took. For example, did the user right-click on an entity in the outliner or use the menu system? How long did it take a user to read the instructions and then execute on those instructions? Which steps were skipped and which ones never got completed? On the very last page I had a form submission so the data came directly back to me from the user who just drove the interface.

How our customers feel

Some of the results we saw right away were that customers loved this new system and were very excited to get it in their hands. In our early research of moving from Slice to prefab we’ve interviewed 13 customers. We had reduced this 6 step convoluted workflow down to 1 simple step.  The research has shown a significant jump in user comprehension (from 54% to 93%). User overall satisfaction (slices 6 out of 10) to (prefab 9 out of 10). This coupled with some of the customer quotes we feel we are heading in a good direction.

“The new prefab system is SOOO much better. The existing slice system felt unfinished. Like it got to a point and stop. However this is really nice to see. Everything makes a lot more sense. It feels like it will be a lot easier to work with.” —Peter Walters: Carbonated

“I appreciated the workflow restrictions that helped make it more obvious where data was getting saved. I loved that the workflow requires intention from the user.“ ⁠—Martin Timothy: New World

With this information in hand we began presenting and formulating what is now known as the Keystone team (“keystone” meaning the most pivotal stone that holds up a rounded archway in older architectural design). We too were a centralized and important element that held up our game engine.

After spending time vetting our ideas, we put together a major project. We were finally making progress on a universal system that we could all be proud of. And the more people learned about it, the more people became excited to get involved in the project. The project began to grow in attention and in popularity. We added more developers and an awesome Software Development Manager (Gavin Monroe) who would help us lead the team to success. Now, fast-forward to today.

Ready, Set, Go!

Finally! Our team is on course to release our new prefab system to the world this year. I would love to go into all the new features and details about what it will look like and how it will work; however, you’re going to have to wait just a bit longer. We are still in the process of polishing this implementation and making sure we are ready for the future in game production. I can tell you though, it’s going to be awesome. I look forward to hearing about your personal experiences and listening to your feedback. Just know we will continue to learn, grow, and strive to become the best engine out there.

I would like to take a moment and recognizes several individuals for their hard work and leadership on this project. This includes lead product experts Terry Michaels (SDM), Editor expert Tom Hulton-Harrop (Senior SDE), Bradley Rebh (PM), Joe Stankowicz (Senior SDE), Yuyi Hsu (UX Manager), Scott Nelson: Tech lead (SDE), Danilo Aimini: Front end (SDE) and Amar Mehta (GM). Thank you!

Editor’s note: The photos of people not wearing masks were taken prior to the pandemic.