How 'Fortnite' Designers Made Their Own Tools

[Music] thank you two years ago the fortnite quest team was in crisis we knew quests in Bal Royale had a very direct impact on player engagement when you're when you've finished your quests there's a feeling that you're done with the season check the boxes wrapped it up what games next even if players were still enjoying the game finishing their Quest was a natural jumping off point but despite being oh let me show you my slides too but despite being one of the larger design Quest design teams on fortnite we couldn't create enough quests to keep all our players busy for the whole season we were relying too much on cheap to

produce quests like get five shotgun kills we didn't have time to reframe the system or to make better quests within the system and we certainly didn't have time to make more quests than we were currently making my boss asked me to solve this crisis my name is Eric Carter and I'm a principal technical designer at Epic though I have a background in computer science I spend all of my time structuring content and using unreal's designer facing tools to help fortnite's design team work faster and better prior to working at Epic I was a tools and Source control product owner at Bungie so I have experience designing and leading tools teams but I'm not a tools engineer I'm a game designer and I use that context and expertise to help game design teams succeed as a game designer the first thing I did

when I joined the quest team was to start building quests if you remember the nerdo quests from chapter 2 Season 7 that was me I made those and I'm infinitely proud of being able to contribute to the legend of one of the coolest ninjas ever I watched a lot of Naruto to capture the right themes and tone I read brand documents and poured over partner guidance and IP rules visit this media is very particular about how Naruto characters are depicted I also absorbed a lot of wisdom and nomenclature from other designers about how quests work how quests work in fortnite and I worked within the design processes that epic uses to keep our designs consistent with the rest of the game but I didn't write a single line of C plus plus I tell you all of that just to make it clear that I'm not a programmer in Disguise I live and work as a designer a

rather technical one but a designer nonetheless and my design content creation experience is the Crux of how we solved our crisis as someone who is working in the middle of it the crisis had a few very obvious causes but one large cause stood out making quests was hard very few people had the knowledge to do it at all there were hundreds of ways to break a quest and only one way to do it right the iteration loop from a completed idea to a quest asset to testing was literally days long and our workflow led to overlapping work loss changes and tons of unnecessary production and testing overhead shame to admit it but despite being the

company that makes the most sophisticated game engine in the world we were making our quests in a very impressive set of Visual Basic skill scripts running in Microsoft Excel this is it actually this is actually the version of the spreadsheet that outputted the Naruto quests this GIF won't Loop while I'm talking this is just me tabbing through all of the required sub sheets there wasn't any error checking here you just had to know what to put into each field and not make any typos our Quest team grew out of our systems design team and system designers really like Excel and so at some point the spreadsheets they were using just evolved into this whole Quest editor thing and the result still hurts me to think about a little bit the sheet is pretty complicated because quests are by their nature pretty

complicated after five years of dailies weeklies seasonal narrative quests event quests webquests MTX Quest bundles and twitch quests there's just a whole lot of configurations that are available this spreadsheet exported all of these configuration options to an asset that Unreal Engine could use and the length and complexity of that asset can give you a sense of why this is irreducible complexity this is the configuration for just one quest in Chapter 2 season 7. only one person on the team the marvelously knowledgeable embedded tester Hunter Kent knew what all of these did I'm deeply in his debt for his help explaining all of this nonsense it's important to point out four dangers in all of these Quest features first in some configurations there are many

features that are irrelevant for example daily quests are granted by the lobby so the field that specifies what NPC grants the quest has no effect regardless of its value second some values like the server back-end name are auto-generated and had to match a specific schema and should never be tweaked by designers but they still needed to be stored in the same asset file the designers were working in third some of these options were incompatible a daily Quest can't be in a quest bundle a quest can't have both a reward array and a post-match reward box and finally in some configurations there may only be one correct answer among several choices weekly quests must have a gameplay tag specifying their week number a transient Quest that gets

handed out must also be marked as repeatable now I've just given you a pretty conventional argument for a situation where a design or art team needs a bespoke tool for editing a specific type of content I'm sure many of you are familiar with this kind of proposal being placed on a tools team's roadmap and the very long weight to that tools teams availability believe it or not tools team availability at Epic is just as rare as at your studio this is an aspect of the crisis that I needed to solve with the help of only two already overbooked Quest engineers so how is a single Tech designer going to solve a tooling problem like this

remember how I told you earlier that my design content creation experience was the Crux of the solution to this crisis the first important takeaway I want you to get from my talk is that doing Hands-On game design work actually gives a game designer a few advantages over a conventional tools team when it comes to optimizing workflows in my case I knew the ins and outs of our Quest tooling problem first hand because I lived it for four months I didn't need to do any user studies I didn't need to collect feature wish lists or Shadow content creators these problems were just my daily life and the daily lives of my neighbors the usual techniques the tools teams would use to collect requirements for a new Quest editor were unnecessary

if you're a member of a tools team at a game Studio I'm sure you've had the experience of listening to a designer rattle through a long list of pain points in a familiar tool or been emailed pages of modification requests communication over these points is very difficult it takes a lot of thought to prioritize and flesh out each desire from a designer's brain into a programmer's brain and figure out how and when to make that a reality being able to skip this usually important step in tool development is the First Advantage I had over a tools team even after that requirements communication was finished design teams are constantly evolving their vision of the game and iterating on the intent the intent behind the content they're creating there will always be a lag communicating this evolving intent to a tools team

and deciding how to match tools maintenance work to this evolution is one of the hardest problems in software development as a game designer being completely tapped into the evolving context of where our game is headed is my second advantage over a tools team um there's also an inescapable difference in how content creators are tasked and how a tools team is tasked tools teams by their nature move slowly because they require approval scheduling and strong Direction Strong justification for their Direction in every Studio there are many competing desires for tools work coming from every discipline I've even seen tools requests coming from other tools engineers the production process for this represents a very significant overhead

and no matter how many agile trainings I do I've not found a way to make that overhead go away but the expectation for Content creators is that by the time the game ships they will produce a certain amount of content whether it's a hundred quests a season five new skins each Milestone two levels a month there's no oversight approval or objection when a content creator spends one hour working on something that will save them two hours creating content VFX libraries shared textures reusable blueprint libraries and kit bash sets are all examples of workflow optimizations that did not require approval or scheduling being able to avoid the overhead of Team scheduling is the third Advantage I had over a tools team the unfortunate reality is that content creators are always in a state of being

held back by tools development the more advantages we can use to decouple content creator workflows from needing tools engineering support the more fun engaging beautiful lovable game they'll be able to create it's for that reason that we as tools leaders need to find ways to utilize the advantages that game designers have in creating their own tools that's why a desire to capitalize on those advantages is the first important belief I want you to take from my talk if we find ways to capitalize on those advantages our jobs will be much easier and our games will be much better you might be thinking okay that's great Eric but we've seen that spreadsheet Quest editor that some systems designers built and that's just part of the problem but I think we should understand

insufficient tools like the quest editor spreadsheet as a product of designers that are not empowered to create their own tools a few clever designers scratch together the best thing they could given the limited resources they had they had Excel and so they made an editor in Excel today let's contrast that with some of the results that highly empowered designers can make in unreal foreign on the fortnite quest design team after I made Quests for four months I switched gears to focusing primarily on creating a quest editor that addressed the most important aspects of the quest design workflow we knew that we knew the tools team wouldn't be able to create a quest editor from scratch fast enough to resolve our crisis in that moment but a friend of a friend in the tech

design Department Bryce Lumpkin told us we should take a look at editor utility widgets which turned out to be the most effective designer tools empowerment I have ever encountered unreal has a pretty robust UI tool called umg or unreal Motion Graphics pretty much every game in unreal uses umg to create their in-game UI so it's a very robust system that many people know how to use it's a wysiwyg editor so UI designers are often building the UI themselves and fairly non-technical people can make really valuable contributions without support from engineers behind every umg widget there's a fully functional blueprint graph which allows designers to write UI Behavior using the same blueprints they use to make the rest of the game editor utility widgets actually built on top of umg with the key difference that

they aren't UI that runs in the game they're actually UI that runs in the editor when I heard this I was blown away I've made UI in umg so adoption of editor utility widgets was almost instant for me I needed to learn a few lessons about asset manipulation and some of the editor paradigms around cdos and asset metadata but that was basically API memorization I did along the way with umg epic has leveraged a well-developed excellently documented robust tool which many people are already trained on to create rapid easy to use Frameworks that designers and other non-technical people can immediately begin to use creative tools anyone who can create UI in unreal

has the skills to create powerful asset editing and management tools that means UI designers technical designers Indie devs and honestly anybody who can use gamedev YouTube can begin making tools without hiring a single tools engineer these people can solve tools and efficiencies in their own workflows in three months of less than full-time work two people went from this to this our new Quest editor took a Quest from six pages of tightly packed properties to about two pages Not only was it shorter but it's also organized in a much more user-friendly way moreover most of this space is used by convenience features that allow designers to make quests with less effort than before

things that previously the the previous layout didn't do at all let's dig in to how we made the quick jump into a tool the exceeded Quest designers imaginations earlier we talked about four dangers that I could clearly see from my work as a content creator we addressed each one of those four with a solve that was fairly simple in editor utility widgets in our new workflow a quest designer first selects what kind of quest they're making a daily weekly store narrative or bespoke Quest with that information we instantiated a different UI with a different set of properties filtered out store quests never expire so all the calendar and removal properties are always blank the store Quest editor just doesn't show

those properties at all just getting rid of irrelevant properties like this honestly might have hidden half of all prep properties for every Quest similarly it was easy to solve similarly it was easy to use a few blueprint string operations to generate the values of properties that must follow a specific schema to be correct like the server backend name which was just a combination of the release number the quest name and objective index and on the rare occasion that that schema changes like when design creates a whole new category of quests design completely capable of updating the blueprints that generate new values across all quests so we can hide those properties from day-to-day work in the editor as well this didn't save as much work as the other areas but boy did it prevent a lot

of bugs it might have been a bigger gift to our server Engineers than it was to our designers to solve the last two dangers we needed something slightly more complex let's look at a specific example we knew that daily quests will only ever reward a seasonal daily Quest token and XP so we didn't want to expose any of the reward properties in the daily Quest editor that's like five properties right there that we don't need to show but XP values that are rewarded are constantly being tuned and seasonal tokens cycle out every three months so we couldn't just build that straight into the auto generation that the tool does we needed a template system the designers could very easily modify for each release in our workflow after picking the type of quest in the quest editor you picked a quest template

Quest designers could edit that template themselves and the values in that template were copied over to each Quest when the editor was open instead of maintaining some kind of template asset we actually use a quest itself for the templates a quest designer can edit the quest template directly using the exact same methods they used to edit any Quest this also allowed for very fine-grained control my Naruto quests were weekly quests but they also rewarded a special ninja event token the tracked event participation I just created a Naruto template by copying the weekly template and added a ninja event token to the rewards then that bit of extra work was done automatically for me in every Quest I created Quest templates also solve the incompatible configurations problem as long as the templates have the right set

of options picked all are resulting quests had them selected as well and Quest designers didn't need to worry about which needed to be set when the quest editors had more or less settled into their final form another Quest designer Greg Metzler took a took a visual design pass on them the fruit of his work is obvious in readability and general ease of use Greg has a lot of experience as a UI designer in unreal so he was able to make all of his changes directly in the tool and check them in the same day because of his his familiarity with umg it didn't require mock-ups or translation to xaml he just put his existing skills to use between Branch locks and this amazing Improvement came about with no impact on our Dev schedule

the second important belief I want you to take away from my talk is that tooling Frameworks that rapidly create tools using familiar content systems which are already maintained by the gameplay and engine teams can solve big problems for small costs this was not the end of our work either the quest editors were our Flagship tools but we created a bunch of messy hacky smaller tools really quickly to solve lower value problems bulk importers seasonal update tools specialized string replacement and migration tools came from start to finish in a single day and saved a few days of work these small ugly tools bred Moore designer created tools one of our Quest designers RAF coonan made an entirely new daily Quest bulk updater on his own

by copy pasting an existing bulk updater tool that I had authored and today other people are using his Quick Fix and thinking of making their own tools for other problems these tools are cheap require almost no maintenance because of their Reliance on game systems and pay for themselves almost every time they're used at this point in my talk I was going to say there are probably low-cost editor utility widgets solving small problems at Epic that no tools engine even knows about but after my talk was written somebody heard about a problem I was working on and they forwarded forwarded me an editor utility widget and they said I could quickly copy and modify this into a tool that addressed my problem when I saw it it turned out to be a modification of a tool that I had built months prior it was like tools karma coming back

around to help me all right I've been talking for about 20 minutes so it's time to go on a quest I want you to think about a problem at your Studios that wastes content creator time but is probably small enough that it will never get on a tools engineer's plate to solve if you're an engineer find someone who has one of these tiny problems and have them describe it to you you have about five minutes to do this you can talk to yourself talk to each other yeah okay all right Quest complete the point of my talk is not about Quest designers or any kind of designer going off and building tools on their own the point of my talk is about engineers empowering designers to build great tools with lightweight support throughout the quest editor process

I had a lot of empowerment from folks in other disciplines in order to make these improvements happen they are great examples of how a studio can Empower content creators to build their own tools Chief among them was the support that I got from Jay Nakai a generalist programmer on the quest team as I came to understand the the complexity of quest setup Jay cleaned it up at the source and made sure that the editor utility widgets had access to the native types that quests used in their definitions I also had endless questions defining the space of what was possible what was valid and what half of these things even did Beyond Quest systems Jay empowered me with improved editor utility widget filtering and drove many of the improvements to

the underlying editor utility Tech that's been available to the public since UE 5.1 because these tools are at their core umg widgets they naturally have access to the robust asset ecosystem that underlies all unreal games we easily used Quest assets as templates for other Quest assets and those templates never got out of date or required their own upkeep but we also leveraged other data types the designers were familiar with to help them maintain their own tools features you might have noticed these buttons that allow Quest designers to easily fill in complex Tag sets these Tag sets evolve as fast as fortnite does and it's the designers themselves who are making the decisions about how they should change and when these buttons are actually populated by

a standard unreal data table designers are already familiar with working with these data tables and each row of the table becomes its own button Quest designers can add their own buttons or update existing buttons just by editing that table documentation exists directly within the tool on how to do this and designers can never leave the editor they're working in to make these instantaneous tool updates their changes can be checked in Via their normal perforce workflow and they become the new canonical functionality instantly Quest designers like Errol hanhan and Kyle Phillips make valuable contributions without ever changing an editor utility widget by updating and maintaining these data assets earlier I mentioned Greg's awesome contribution to visual design as well artists and visual designers will surprise you with the ways they can

support these efforts when they're excited about them and realize how easily they can contribute two of our UI Engineers also made very significant improvements once the editors were stood up Marshall beachy used his deep familiarity with umg design patterns to optimize the sustainability and performance of our editor this was a larger engineering investment that was easy to justify once the quest editor had become a core part of designer workflows and proved that it was going to be an enduring part of our process Vlad golivan made many of his own improvements and extended the underlying Quest Technologies with the editor in mind one example of that is the quest map marker custom widget that he created adding map markers to tests and specific objectives on those quests has a lot of

irreducible complexity in the data Vlad used slate and C plus plus to create a custom widget that essentially functions as a wizard to guide designers through the available choices the custom widget can't be edited by designers but it makes up for that by being highly specialized and efficient at this particular task our native map marker code has evolved over time and the native widget has been able to hide those changes from designers keeping their process the same Vlad also added better support for Native data type usability so those data types function better everywhere they exist including an editor utility widgets one great example of that is how we expanded copy paste for tag containers so you can copy just a single tag out of a container instead of copying the

entire contents of that container he also did a much more complex copy and paste Improvement which allows designers to copy an entire Quest event from out of our native Quest debugger and paste directly into the quest editor what this meant is designers are essentially copy pasting an event out of fortnite into our authoring tools to create complex quests all of these contributions empowered a small efficient and focused team to nail a fantastic tool and immediately pay dividends to content creators our Quest quality went up and the number of quests we could produce with the same team increased we also subjectively improve the quality of life for our designers improving these tools and offloading some of the maintenance to Quest designers also freed our Quest Engineers

to focus more on technology and gameplay features now we're using similar a similar approach for Tooling in areas adjacent to Quest design like battle pass creation and blueprint reviews I think I copy pasted my notes some weird way so I'm trying to get caught up it's the slides that are wrong and the results loudly announce the value of these methods we dramatically increased our Quest output numerically drove quests to be one of the most praised aspects of fortnite and we're able to refocus our Design Energy on creating new Deluxe native content Deluxe narrative content because we had time to invent stronger and more unique approaches to motivating and rewarding

players our ability to produce quests has gone up so much that we've actually been able to create so many quests that we experimented with expiring quests on a weekly instead of seasonal basis strategically this space to evolve and experiment has helped us recognize the value of quests and the right way to deploy them in service to epic's goal of building the metaverse today I'm more excited than ever about the futurists in fortnite the third important belief I want you to take away from my talk is that by empowering designers with effective tool building Frameworks we can free our game teams to focus on new gameplay better outcomes and core technologies that includes more complex tool initiatives that can't be built in those Frameworks

the bright future of quests in fortnite that I just described is a strong contrast to the crisis we were in two years ago from my perspective that contrast is in large part because of the principles and takeaways that I've been talking to you about today so let's recap because hopefully some of these principles can cause a similar degree of change on your teams the first important takeaway is that doing Hands-On game design work actually gives content creators a few advantages over a conventional tools team when it comes to optimizing workflows Hands-On content creators and game designers in particular intuitively understand their own requirements they have much deeper insight into the future and intent behind their designs and they have open scheduling

tools teams should Empower game designers to use those advantages to create maintain and adapt their own tools to empower them we should invest in robust designer focused Frameworks like editor utility widgets and think about those aspects of the game editor as first class citizens in our games tooling ecosystem the second important belief I want you to take away from my talk is that tooling Frameworks that are powered by game content types and use familiar game set game systems have small costs but are still capable of solving big or small problems foreign hopefully by going into some of the expedient choices the fortnite team made to leverage existing Assets in the creation of asset editing tools helps you to see some of the ways that these close to the content tooling Frameworks can help your team make the same efficiency gains

the third important takeaway is that by empowering designers with effective tool building Frameworks we can free our engineering teams from overhead and maintenance to end up with Superior Tech Solutions instead so here are a few practical action items if you use unreal invest in training your Tech designers Tech artists and tools teams on how to build and support editor utility widgets create tools that rely on familiar game asset types to dynamically and maintenance free populate tools features so content creators can expand the tool with their growing needs and finally whether or not you're using in using Unreal prioritize developing and supporting Frameworks that encourage content creators to make their own tools and help them adopt maintenance problems on

their own thank you so much for attending my talk this is my first time speaking at GDC so please leave a review in the survey that they send out to you that's how they decide whether to invite me back and next we have some time for Q a so feel free to come up to either one of the microphones when you're ready someone asked me a question earlier how are these checked like do they have Source control where do these things go editor utility widgets are actually an asset in unreal so just like a umg widget that is open in the uh edit in the editor you can edit them and run them in real time and check them into perforce let's go here on the left hi Eric uh thank you for your talk it's really great to hear how you know the teams at fortnite and at Epic are really

they seem very interdisciplinary and there's a lot of you talked a lot about mentioning uh your co-workers and how you've worked together with them uh so that's just really good to hear just comment um I would kind of like to to pass your quest to us back on you and kind of hear a little bit about what's perhaps a process or another tool or something on your team that seems Out Of Reach that you know you would love to change if it were possible um one thing that the question was uh what is Out Of Reach for our team a lot of it for me is just sort of scheduling stuff like I mean I talked about how tools teams are limited in their scheduling but that's reality for everybody so there's a NPC creation uh problem right now where it just takes a lot of work to make NPCs and I would love to build a tool that just spits out all the right data assets and like you check a few boxes but it's just something I haven't gotten around to yet cool thank you over here hey so I really love the workflow and the process I really love the process and the

workflow that you've described in this talk and I wondered if um there's been any interest from any other game teams within epic and have you thought much about can you transfer this between projects yeah so almost all of Epic is working in the fortnite project if you're not working on like an engine or metahumans you're in fortnite so the the tools we create just seem to kind of seep around to different people uh I mentioned that tool that came back around to me that was on the AI team so like I didn't even know that they were working on that it's just one of my customers had taken that tool and said can you make something like this and then they just started like pulling widgets out and building their own thing so it definitely kind of flows naturally to other disciplines but one of the strange things about editor utility widgets is they've been around since I think 2018 but almost nobody knows what they exist or why and so they haven't been adopted even at Epic very widely and that was one of the reasons I wanted to do this talk was just to say

like hey there's an amazing thing that you can do all you have to do is just start using it let's go on the left thank you uh yeah I gotta I got a real important question uh is uh Jay Nakai here where's Jay Jay Jay is in North Carolina sorry uh he was going to be really embarrassed when I called him out to answer questions so he just didn't come to the conference all right real question uh how often did you guys run into problems where uh the editor functionality that you had wasn't enough to do what you wanted often Jay was actually a big what's that oh yeah the question was uh how many times did we end up uh with something editor utility witches couldn't do and my answer is often uh there were a lot of things where like so so native data assets were a big thing for us where like blueprints just didn't have access to like a struct that I needed to be able to set and the cool thing was uh I

would ask Jay like hey I just need this struct and he like adds some metadata to it and make it read only and and it was done so there were there was a lot of times when Jay and I were on a zoom call for like four hours in a row and I'm building stuff in in the editor utility widget and just like sending requests to him immediately and then he's checking in and I'm syncing and we're ready to go and the one of the great things is like you can edit the editor utility widget like instantly it's like playing a blueprint it's like play an editor um and so I would just move to something else and keep working and he checks in these native changes which for him you know he's got to get through our our like check-in Gauntlet and make sure it compiles and I don't have to wait for any of that every time I edit but those native changes do go through that slower process so that's why it's really important to have people supporting this effort right now and I think this is true of like any Tech stack at any point in time it's not possible to just go do

this on your own for a lot of stuff you do need these like quick five-minute changes add a meta tag make it read only something like that uh yeah question um for some of your bigger tools like Quest designer are you all putting those in their own plugins or is that all just sort of live in folder structure your project man I wish I had better advice about plugins um the question was uh do they live in plugins where do these things go uh editor utility widgets as assets can kind of go anywhere and we're figuring that out on fortnite as part of a larger project what is our strategy for plugins in unreal and I think the answer is just like use the architectural experience and wisdom you have to decide where these things go I'm starting to think a lot about like how can I organize these in a way that like they don't cook or ship um and and we can make smart choices around that but it's still very much a thing that I'm figuring out plugins in unreal are evolving like every day

hi um since you're using data assets to drive your quest system did you ever consider taking any sort of approach where you would at runtime like reload your data assets instead of having to come out of Pi and going back in sort of to speed your workflow up yeah so the question was um have we considered using these data assets at runtime to kind of update our Quest and that's actually one of the things that I'm most excited about to be working on now is essentially authoring quests we have a quest debugger which essentially just says every single gameplay message that could be a quest objective just spews there constantly and then you can filter that and the model of quest authoring that I want to move towards is actually Quest designers playing fortnite and doing the thing they want players to do and then just grabbing that event and pasting in the editor and being done and so we're actually like authoring those quests essentially at

runtime and I think the next step after that is putting those kind of runtime capabilities in players hands in creative mode so they can author quests like running fortnite without any of the editor tools hi there uh I'm a programmer who loves the idea of designers making their own tools uh but how do you prevent them from you know making the architectural mistakes you know before risk early on a lot of Engineers ask me like well I want better architectural skills in the tools from the beginning and I think that a really smart person talked to me about how designers making essentially Leaf tools is what he called it is fine they can make messes they'll it doesn't really matter but trunk tools things that are really core to how uh Tools in in our game are built are much more uh much better in the hands of people who are great programmers people who are

great at architecture and uh some of the contributions so so we actually went through that transition where I had made a lot of the editor utility widgets and I'm you know I'm kind of a special case because like I studied software architecture in in college but you can build a messy ugly tool in editor utility widgets and when it becomes an important tool like the quest editor did you go to somebody like Marshall BG and you say we have a mess that works really well can you just make this not a mess some of our tools actually the the blueprint review tool was I we and in editor utility widgets and then pretty much like the day I released it the engine team was like that's really cool we like that we're gonna start building it in slate and I was like I feel bad because sort of wasted all my work but the other the other end of the spectrum that was like the fastest accepted prototype that I've ever done so that actually ships in uh Unreal Engine 5.2 which is in preview

right now so you can see that tool it allows you to look at a swarm change list like a swarm review or a prefers Channel just paste that into the asset tool and then you get a list of all of the changes in that CL and you can diff them right there which was a huge speed up for us um and I don't know you know maybe maybe made a mess of the editor utility widget but then a brilliant tools engineer made it into a slate widget so I think the short answer is like uh uh some editor utility widgets are better authored by Engineers people who are great at architecture and programming but you shouldn't let that stop you because one of the strengths of doing it in this little Walled Garden of editor utility widgets is you're never gonna spill that mess out somewhere else hi I I work with Bryce Lumpkin so yeah I'm glad you mentioned him um and I'm also talking tomorrow about editor utility widgets just across the hall so um I'd like to ask what do you think

are the biggest stumbling blocks for people coming new to editor utility widgets oh uh what are the biggest stumbling box to people coming new to editor utility widgets um I think so one of the things that took me a really long time to learn was like how to go from a class uh to the asset metadata and then two so there's a there's a concept in unreal which is a CDO a class default object and so you have like an asset living on disk and that doesn't that's like a definition of a thing but then if you actually want to do stuff on that you have to like load the CDO and getting from like a class reference to that is a really confusing thing and I just had to memorize all of the ways that you like follow reference and look up metadata that's a really hard one I think that one thing that is sort of a hassle is like understanding how the asset system

operates on assets because you've never done any of that in blueprints that you're familiar with or UI that you're familiar with and so for me like one of the tricks is the python documentation is like auto-generated and so you can go to unreals python documentation and see every single function that the asset system has with really good descriptions and then you take that knowledge to the blueprint search thing and you just blah blah blah and you don't really know like it's ugly and hard to lay out there but if you start in Python moved there then you can have a much easier easier time understanding how asset manipulation Works in unreal which like I said if you're a designer you've never even looked at before so I wanted to go back to the um the tools Karma and the the widget from the AI team that seems like a potential problem space of like with individual teams making their own tools that duplication and Reinventing the wheel

are you doing anything to solve around that um is it a problem that tools are duplicated across other teams I think mostly no so uh epic has like a huge there's a huge team on fortnite I don't know like more than a thousand people and so we do have people like me and Bryce who are constantly building like underlying widget tools so Bryce built a really great file selector so when you need a path you can say like I want a Content relative path or an absolute path or a relative path and it's very important to maintain those as like that when I when I said it's important to see these tools as first class citizens of your asset ecosystem that's sort of what it means like you need a good file selector that meets those needs in your project and if you're not doing that kind of stuff yeah you do end up with 500

different file selectors and they all suck but replicating an individual tool across multiple teams I think is fine like it's sort of messy but develop like I don't know you made a month later so matter that much this solves that problem having good staff uh like Tech designers and Tech artists resolves that quickly because they recognize the areas that are being used a lot we have a editor utility widget scripting channel in slack and that's sort of a Nexus of where a lot of those decisions are being made hi I'm wondering how much the workload is for the designer to maintain the tool after it's created so for example when you add new title request maybe you need to update and whether that would take too much of the designer's time as

opposed to putting among the content creation which they're probably more accustomed to yeah that's a great question um they're asking like what is the the maintenance of one of these tools and I think that uh it it's hard to describe that in a talk but it is unbelievably low because so much of what powers these tools are gameplay systems that are already being maintained by like the gameplay engineers and so the additional burden of like how did I keep this tool working uh is like oh we needed a new button or we needed to move this stuff around and it's much more about just like it's sort of the the initial cost of authoring it well we have a new Need for that tool so we authored that again there's very little upkeep on these tools because they are so close to systems that are already working in the engine um quite quite a few of the things you mentioned at the downside Sarah is something you could also solve with

asset validation um and I think you can do that in Blueprints and it stops you from saving the assets if there's a conflict like mutually exclusive properties and stuff did you think about using asset validation instead or start with that and then move on to edit your utility widgets afterwards or what's your thoughts about using that yeah so about asset validation in like pre-save asset validation we have a really robust uh content validation system on fortnite that does a whole lot of error checking Beyond just like is this asset in a valid State we make sure that we can export it to our online servers we make sure that uh you know it's not going to break the bill later and we did a lot of that hand in hand as we were figuring out you know what are the complexities of the the quest system and what are the invalid States we were also adding those to our content check scripts we have two steps of that one is

like at save time where it's like hey this is really broken you shouldn't even save it and then also a check-in time where it's like hey you know maybe this was valid alone but when we start looking at all the rest of the content it doesn't work like you're missing references or something and so um I think that was a really important step the problem with that comes in with like you know technically it is valid for content to be transient but not repeatable like we can imagine a time where that could happen so we don't want to like prevent you from saving it but like you you dig in put your fingers in the mud and set it that way if that's what you actually want so we don't offer that in the editor one important part of this whole process was like you can still go in and edit that huge list of quest assets and sometimes in our like prototyping phase people will just go do that and and it's fine and we'll update the editors later but we didn't we didn't want to like rule out those

valid but but very uncommon cases with with content validation but that was a big important part of our strategy in general um all right so that's the last questions I'm going to go over there if you want to talk and have more of a personal conversation you just turn right go to the end of the hall I'm gonna hang out there again thank you very much for coming to my talk please fill out the surveys [Music]