Modular Game Features | Inside Unreal

[VIDEO PLAYBACK] - See ya. - It's going to sting a little bit. - I'll have a bit. - Right, who is this for? Robert, for you next? There you go. - Hey, look out. - They're not. I'm not a vessel waiting to be filled, am I? - That's what she said. - Ma. - It's industrialization that makes possessions. - Mom. - Hi, baby girl. Have you come to help us? - The pool's frozen. It's like a fridge out there. It's freezing. - George, I'm talking. Den, go now. She's such a tomboy. - Whoa. Steady on. - Come on. - In or out, love. It's getting a bit nippy out there. - We had touchdown. Can anyone hear me? Please copy. Mom, mom. Do we have any methylated spirits? - What? - What are you wearing, George? - The spaceman needs it. - Well, the spaceman can make do with water. - Yeah, we saw the Omegaman the other night. Pretty bloody ending. - Hello, little girl, where you going? You're growing up fast. - I mean he's supposed to be a scientist, right? I mean he's walking around with all his children in this pandemic. - Exactly. Exactly, back to your bloody microscope, you know what I mean? - Dad, you smell like beer. - I know that's my special perfume. But the missus liked it, you liked it, didn't you? - What's not to like about Charlton Heston. - Dad, can I go on an adventure, please. - Yes, love, of course you can. Off you go. [MARKER SQUEAKING] - Still likes me. He still likes me. - Still your husband. [ICE RIPPING] [CLUNK] - I tell you, any time there's a blackout, I just, I feel so powerless. [LAUGHTER] Just someone try and remind me where the fuse box is. Do we even have a fuse-- what is a fuse box again? It is this thing. - Hey! [DOG BARKS] - Gentlemen, I give you the videos. - Whoa. - What's that? - Here? - Warren, Warren, can you go and see what that mutt is barking at? - Yeah, just a minute. But why is it a bloody-- - Warren, the dog, please. - Would you just let me finish. - George? George. Georgie. - You're upside down. - Georgie! Warren, she's gone. - Right. [BEEPING] [SHOCK] [END PLAYBACK] AMANDA: Hey, everyone! If you can't wait to try out the latest tools coming to Unreal Engine, download 4.27 Preview 3, which is now available on the Epic Games launcher and GitHub. The release of 4.27 will bring new virtual production workflows, updated architectural and manufacturing pipelines, optimized data compression and video encoding with Oodle and Bink built in, and more. Didn't make it to GDC 2021? Then we've got you covered--all of the virtual talks from our Developer Day presentations are now available on-demand on our YouTube channel. Watch them to see The Coalition's debut of the UE5 technical demo, "Alpha Point" and learn more about MetaHuman rigs, animating in Unreal Engine, and the value of cross play. Ferrari introduced its new 296 GTB hybrid sports car in Fortnite, making history as the game's first highly realistic, drivable vehicle and bringing the dream of Italian racing excellence to players using Unreal Engine. Steer over to the Unreal Engine feed to go behind the scenes on the virtual production road trip. More and more businesses are offering customers the opportunity to personalize products before they buy. That dynamic now extends to property with Zaha Hadid Architects' real-time configurator for holiday homes on a Caribbean island near Honduras. Venture over to the feed to learn more about the future of real estate development. Earlier this year, we launched the Women Creators Program with ASIFA India. Over four weeks, 20 artists met with former Unreal Fellowship graduates and UE evangelists for one-on-one mentoring and virtual workshops, as they learned the latest techniques in real-time world building, lighting, sequencing, and virtual production using cloud-driven virtual machines. Now, we're thrilled to debut some of their wonderful projects--pop over to the feed to watch them. And now over to our top weekly karma earners. Many, many thanks to: ClockworkOcean, Everynone, T_Sumisaki, LunaNelis, uponHaveFun, darrymanillow, JoSilver, liam.vd, chrudimer, and Mr_Happy_Sloth. We're launching this week's spotlights with Space Xiaowantou, which translates to little round head. Maria Yue used the adorable space-based piece to explore lighting and cinematic features in UE5. Head over to her ArtStation page to watch the whole thing! And if you needed more robots in your life, Hwang Seongjoon's ready to deliver with TOB & VITA, a playful short film featuring silly antics from a couple of quirky factory robots. Watch the full film on their ArtStation page and let them know what you think. And lastly, face your fears in Hideout, a third-person stealth game set in a post-apocalyptic world dominated by an artificial intelligence. Take on the role of May in her quest to save her brother. Avoid the robots, explore the town and find its secrets! Download Hideout on Steam. Thanks for watching this week's News and Community Spotlight. VICTOR: Hi, everyone, and welcome to another episode of Inside Unreal, a weekly show where we learn, explore, and celebrate everything unreal. I'm your host Victor Brodin, and today I'd like to introduce, welcome back to the show, lead engine programmer Michael Noland, as well as senior engineer programmer Mike Beach. MIKE: Hi, everybody. VICTOR: Today, we are going to talk about modular Game Features, and, explicitly, some of the new plugins that we shipped with Unreal Engine 5 early access. And I will hand it over to Michael. MICHAEL: Cool. So today we're going to talk about a couple of different new features in UE5. They shipped kind of in their first form in early access, and we'll be continuing to improve them on the way to 5.0 final. The first is the Modular Gameplay plugin, and it's often used in conjunction with the second, which are Game Feature plugins. And so the Modular Gameplay System is kind of a way to attack complexity in your game code. So we found on various projects we worked on internally, where things like the player controller, the player pawn, the game mode, game state, these kinds of classes end up just being like the central dumping ground, where you get all kinds of different features and functionality poured into one class. And you can end up with a 20,000 line C++ file. And so Modular Gameplay leverages the component system in the engine to allow us to layer in components on top of existing actors. So all you have to do is, in like your base actor, say, hey, I participate in the system. And so there's a registration call you can add. If you've downloaded the Ancient Game sample, there is a plugin within it that kind of has these base classes for you. So it's called Modular Gameplay Actors. And this will be at the engine level in 5.0 final. But right now it's kind of in the sample game. And so you can see here, you know, it's just add a component receiver. So it's basically telling the system, hey, I participate. I want to have components added to me, programmatically, later on. And, you know, at end play, you remove the receiver. So some of the features in Ancient Game were actually built this way. So actually, I'll just go show the plugins here in just a second. So there's a two plugins in Ancient Game that are using this. There's the Hover Drone plugin. And there is the ancient combat, or Ancient Battle, which is sort of the combat portion of the game. And so, in here, we see like she's sitting there by the fireside and you can go into drone mode. And when you activate this drone, all of this is actually built in a plugin, the drone flight, drone controls, that kind of stuff. For the Game Features, they are like a regular gameplay plugin, with a special set of rules and behavior on top of it. So we see Ancient Battle and Hover Drone. If we want to make a new one, we can just go to new plugin. And it's one of the templates that's in here. So we'll pick a Game Feature plugin. And they can contain code as well. The default template it's just a content-only one. And so they'll always be saved in your project under plugins under Game Features. And so let's say this is-- MIKE: And that's important, right, Michael, the putting them under Game Feature, under that specific subfolder, is where like it does the discovery to find the Game Features. MICHAEL: Yeah. That's right, although the new plugin wizard will enforce that. So if you pick this, you can't remove Game Features from it. It'll warn you that it's got to be within that folder. MIKE: Gotcha. MICHAEL: So we made this new plugin. And as part of that, it actually made a new asset for us inside of the plugin, with the same name. And so this is the actual definition of what this Game Feature is. And so you can go back and you can edit the plugin, like the different settings. But you can also activate or deactivate it. And so the plugins have both what's an initial state, and then their current state. So the initial state is, what is it when the editor starts up like, or when the game is running to begin with. And so a lot of times you'll just have your plugins set to registered. And then, based on gameplay conditions, you can choose to enable or disable it. So for example, a lot of systems in Fortnite are built this way. So like the various vehicles on the map are part of a Game Feature plugin. And so if you wanted to have a game mode that didn't have any vehicles, you could disable that Game Feature. MIKE: How would that work? MICHAEL: So that way like the core gameplay doesn't know about the existence of the vehicles. And that controls things like the memory used for loading them, all that kind of stuff, can be controlled just once at this very high level. MIKE: Yeah, I know you just called it out, but it's worth emphasizing, that it's something that kind of caught us a little off guard when we were developing Ancient Game with this stuff is the state of the Game Feature persists through like PIE sessions. Like it persists in the editor. So if you like, we'd have it where we'd hit a state during PIE and it would load up the Ancient Battle Game Feature. And then we'd stop that PIE session and then PIE again. And at the beginning, where the Ancient Battle isn't supposed to be loaded up, it would still be loaded. So we had to kind of marshal, kind of like control that stuff a little bit. MICHAEL: Right. And basically, yeah, when your game is ending, your PIE session's ending, you would tear it back down. But, yeah, it's worth noting also if you're doing multiplayer PIE, the Game Features are this global concept, since they're built on top of plugins. And so if you activate it for one of your sessions in multiplayer, like within the editor, then the other session is also going to have it active as well. And usually that's not a problem. It's just something to be aware of. And so for this plugin that we've made, we can see it's active right now. And the initial state is active. So I'm going to go ahead, and, you can see here, it warns you shouldn't be editing it while it's active, because whatever it's done has already taken effect. And so if you change this, you won't see it until next time. So we'll flip it back to registered. The Game Features have a few built-in things. And so one thing is they play really nicely with the asset manager. And so you can tell, hey, my Game Feature's introducing new assets into the asset manager. So like if you make a Game Feature that contains new weapons, or new items for your game, you can just say, hey, here's another place to scan for weapons, or here's another place to scan for cosmetics or something. And then the asset manager, that's a simple way to do sort of this encapsulated content, that your existing game systems can already take advantage of. So if you've got some piece of code that's like, I'm just going to enumerate all of the weapons in the game and randomly spawn them or whatever, you could inject weapons into that list without having to do anything else. The other key piece is this actions array. And so actions are basically a list of commands that happen whenever a Game Feature is activated or deactivated. So I'll go and add one, and you can see some of the built in ones. So you can do things like add new cheat managers. You can add components, using the Modular Gameplay system we were talking about. MIKE: Some of the ones on the list there are like specific ones that we made, specifically for Ancient Game. MICHAEL: In Ancient Game. Yeah, and so stuff like this, add abilities and attribute defaults, these are Ancient Game specific. In 5.0 EA, there's only a few at the engine level. There will be some more in 5.0 final, that we find useful for various games. And we'll probably have additional sample content that shows off how to use this sort of together with the asset registry, with the asset manager, like all these pieces playing well together, in a sort of cohesive sample. So let's focus on the add components first. And so add components, this is a built-in one. And so we can say, basically, hey, I want to add a component of a given class to actors of a given type. So you pick the actor class. And so, for example, you can just pick pawn. And so now, we can throw a component on every single pawn in the game. Sometimes you might want to be more specific, like only the player pawn or only specifically Lira or only, what's her name? The character in Ancient Game? VICTOR: Echo? MIKE: Echo. MICHAEL: Yes, you know, throw something on specifically Echo or specifically on the Hover Drone or whatever, but for right now we'll just go ahead and do this on the pawn itself. MIKE: And another thing-- MICHAEL: Sorry, go ahead. MIKE: Sorry, I wanted to call it here just another point that you made is like this won't add it to all pawns, like in the-- it will if they are pawns that have opted into this system. MICHAEL: Yes, that's a very good point. It will only add it to pawns that actually have a line like this, or sorry, like this. And this can actually be in Blueprints as well, like you can call this same function from a Blueprint based class. But usually you'd use like the C++ based class even for all of your Blueprints. MIKE: Yeah, so here we have modular pawn if you look on the left. And that is the base class for our pawns in Ancient Game that we want to receive these additional components. MICHAEL: Yeah, exactly. VICTOR: So that would be the pawn for the Hover Drone. MIKE: And Echo. MICHAEL: So, Yeah. MIKE: OK. MICHAEL: Echo's using it as well. MIKE: Yeah. MICHAEL: So now, let's go ahead and make a new component. So like the plugin that we created, the Game Feature plugin, just shows up in your plugins list in the content browser. And so that root asset is the definition of the Game Feature. But then you can add other assets to it as well. And so we'll just create a Blueprint based off a pawn component. And this could be based off of just like actor component as well. But pawn component like has a few extra, it's ensuring that it's only added to pawns, basically. And so what we're going to do is we're basically just going to play a particle system, every few seconds, just to show off like how you could extend this without having to go in and edit Echo's Blueprint. So first we'll go ahead and hook up with the Blueprint we just made. So pawn and the periodic explosions, and so basically any pawns that registered into the Modular Gameplay System, will now get one of these added. And order doesn't matter. Like if the Game Feature is activated after the pawn's already spawned, it will still get that component once the Game Feature's activated. If the Game Feature's activated before the pawn is spawned, then at the point where we did the registration, it will look for any pending calls, and take care of them then. And so we did it in pre-initialize components. So the component would be created fairly early on, if the Game Feature's active before this happened. So now we've got this Blueprint. And let's make this a little bit bigger. So what we can do is we can spawn another component. So-- MIKE: I liked how the first thing you did was like, get out of here, tick. We don't need you. MICHAEL: [CHUCKLES] Yeah, and so, we'll create this particle system. So what was the one we wanted to use? MIKE: Looks like impact explosion or something like that. MICHAEL: Yeah, let's go with that. MIKE: It's like destructible impact. It's not explosion, yeah. Yeah, that guy right there. MICHAEL: Yeah. And so, basically, we're going to get this, we're going to attach it to the component. So let's go ahead and roll this new variable because we'll want to replay it later. So now we spawn a particle system. It's just going to play once right now. So let's go ahead and create a custom event to replay it. So there I held down D and clicked, which is a shortcut for doing a delay. You can also get to it from the menu. And so this is going to, after four seconds, do this again. And so we'll grab my particles and reset them. Then we'll just do that one more time. So basically it's just going to play over and over and over again. But we also need to call it from when we began play. We create the particle system, we set it, we actually need to attach it as well, and then we need to replay it. But we also need to go ahead and attach it to ourself. So since we're a component, we're probably going to attach it to our owner, which is the pawn. MIKE: Drag it off the particle component. MICHAEL: Yeah, grab that. There we go. So there we go. VICTOR: And we did get the question if it's possible to do this in Blueprints as well. And we can clearly tell that Michael is doing this in Blueprints right now as a Game Feature. MICHAEL: Yep. So, at the moment, like we probably don't have all the helper functions to make everything feel really nice and easy, doing this in Blueprints. Like we have the static function for C++ to make it real easy. But this under the hood is a subsystem, and so you can get that subsystem, and then register in Blueprints as well. So, yeah, it's possible to do. But usually games using this would probably have a mix of C++ and Blueprints. MIKE: Yeah, the thing I'll note about that is that, because we set up some Blueprints originally for Ancient Game, and then we moved them to native. And one of the reasons is because in native, you have a lot more granularity of like the startup functions that you have available to you, like pre-initialized components. You don't really have access to that in Blueprints. And that's where we wanted to register with this system. So in Blueprints, you could register with the system like on begin play or something like that. But if there's a very specific phase you want to register it at. MICHAEL: Yeah, and like I mentioned at the moment, this is a plugin within Ancient Game. But these will, something like these will be at the engine level for 5.0 as well. And so then, you could just inherit your Blueprint from these and not have to add the calls manually. All right, so we've got our periodic explosion component now. And so we've got it set up so that it should automatically add it. And so we see that the plugin's not active. So when we run, we're not going to see the explosions. But then when we activate it, we will. And I'll explain this in just a minute, this validation thing. MIKE: One thing of-- oh, yeah, OK, here we go. And we're not seeing the explosion because it's not active right now. MICHAEL: Yep. And so you can also programmatically, or via the command console, activate them. But in the editor you can use this, and so we'll go ahead and activate it. And so now we've added this explosion, this just pulsing on Echo every so often, or, sorry, yeah, Echo. MIKE: The huge element here is that we didn't have to add the component directly to the Echo character Blueprint. We didn't have to add any logic that knows about this kind of explosion effect, or things like that there in the base game. It's all self-contained within this modular feature. MICHAEL: And, obviously, this is like a really simple example, with just a single particle system that could have easily been added to the base Blueprint. But when you start getting more complicated, and like you layer in, imagine that you have new abilities that you want to layer onto a character, like the ability to double jump, or things like that, you could have that in a Game Feature. And then the base character doesn't know anything about double jumping. And so it's something that could be basically injected in on top of it. And so this gives you several different benefits. It allows you to sort of build your content in sort of more isolated silos. So, for example, say you're working on some new feature. And you're coming up on a milestone. And the new feature is not really ready for prime time yet. You can just deactivate it, and because it was all isolated to this one place, we know that there's not going to be dependencies on it. And so other things are not going to break as a result of it being disabled. That's really valuable for live games as well, like, you know, we ship Fortnite content updates very, very frequently, and entire new seasons every few months. And so we can be working on a feature, and if that feature slips its release date, we can just change the release version on the Game Feature plugin. And then it will be activating the cook to build. MIKE: Yeah, to help illustrate the power of this stuff, like the example that was given to me on Fortnite, because we were taking this Game Feature stuff and using it on Ancient Game, but the way it was described to me and Michael, you can confirm this, is that, like for example, like one of the seasons we did Star Wars stuff. And we want to give characters light sabers. We want to augment the map where there's like a crashed TIE fighter, and there are stormtroopers walking around. Like we can bundle all of that into a single game feature that's kind of like our Star Wars kind of event, like Game Feature, that is able to be like activated and then deactivated, once the event is done, right? MICHAEL: Exactly. MIKE: Yeah. MICHAEL: And so Fortnite has things within the game feature to do stuff like overlay at this point in the map, this other map. And so like they can have entire buildings that come in from one of these features, or things like, when we did the helicopter, which was one of the first things we built out with a Game Feature. The helipads placed in the map were actually tied to the Game Feature plugin itself. And so, if it was disabled, the helipad would spawn with nothing on it. And if it was enabled, it'd spawn and it would have the vehicle spawner on top of that. And then those were placed in this overlay map, instead of in the base game map, so that there were no references to the helicopters in the base game. MIKE: And for Ancient Game here, one of the actions that we created specifically for Ancient Game is a rudimentary version of that, where it might not be done in the best way, because now we're playing with the open world system and things like that. But we did it to get the job done here as an action. So like if you do the dropdown on the actions window, you'll see like add level instances, or something like that. And we're able to spawn kind of sublevels over overlaid onto them onto the map, as well. MICHAEL: Yeah, exactly. And you can create your own custom actions, specific to your game. So like if you have, this is kind of a way to when this feature activates, poke into some other system. If you want to tell it, hey, I'm here now. And that allows you to avoid writing, like, hey, let me run over all active features. And let me see, do they have this piece of data. Instead, it allows you to be very pinpoint precise, because in Fortnite, I think we're actually into the low hundreds of Game Features now. And so we don't want to do, for every call site, run over 100 Game Features, asking, hey, are you one of the two or three that actually does this particular thing? MIKE: Granularity was a question for us when we were starting Ancient Game, is we didn't know how granular to go, because, when we were originally hearing about the idea, and hearing how useful it was on Fortnite, like I, me personally, as someone who gets caught up in the promise of modularity, right? Like you get really excited by it. You're like, I want to break down everything. I want like the character in its own like pocket, and I want like all this stuff. And we started going down that route, and we found that it's just hard to kind of maintain that. And so we started breaking them down in logical kind of back to the Fortnite example of events, like logical subsections in the game, it was like, hey, what's all stuff that comes in together. So like the Ancient Battle plugin is an example of that. Like it includes the light dart, and it includes the Abas battle and the destructibles and stuff like that. And originally we were like, let's have a light dart game feature. Let's have a boss battle, like a boss Game Feature. And we are finding that like, why? Why are we-- MICHAEL: Yeah, exactly. I mean, so we kind of, to some extent, we leave it up to the user, the end user, of how granular do you want to go? But definitely I think there's a balance to be struck. Like it probably doesn't make sense to have every individual weapon, every individual vehicle, all as their own unique Game Features. So like that low 100's number from Fortnite, that is actually inflated by creative devices that are all done individually as separate features, to enable, to allow them to be shipped enabled, disabled, that kind of stuff. But for most stuff in Fortnite, it's a little less granular than that. Like we have several vehicles and a single plugin called Valet. We have, like most of the new stuff in a given season, just all goes into one big season plugin. It's only stuff that's like, OK, this is going to happen halfway through the season, or it might slip, or special events or concerts or things like that, where those are getting their own unique feature plugins. And so there's that balance in between them where it's almost more about the development schedule and who all is going to be collaborating, working on a thing, as opposed to these are perfect, pristine like plugins that nothing knows nothing about anybody else. And actually that's a good segue. Plug-ins have sort of an opinionated asset referencing restriction, or Game Feature plugins specifically. And that's to give us those properties we were talking about earlier, where you can actually enable or disable them. And so, by default, plugins actually aren't allowed to reference content outside of themselves, without creating a warning. And so you saw that warning when I saved the Blueprint earlier. So if I save it here, you see it actually pops up validation failed. So we can actually go look at what that is, and it's because I'm using this particle system from another game feature plugin. So I'm using it from the Ancient Battle. And so that's allowable, as long as we tell the system that it's OK. And so the way we can do that is we can say, hey, my new plugin depends on the Ancient Battle plugin. So if you didn't have Ancient Battle enabled, my plugin wasn't going to work either, because the particle system it's using is gone. And so we can go back over here, we can hit edit plugin. And then down here at the bottom, there's plugin dependencies. And so we can actually say, hey, I actually depend on Ancient Battle. VICTOR: We did receive that question from Last Devil earlier if Game Feature-- can Game Feature 1 add a component to an actor of Game Feature 2? MICHAEL: It can. So there's two ways you can do it. One way is Game Feature 1 can depend on Game Feature 2, and then it knows about that particular class. And so like you could pick Game Feature 2 pawn here, as long as you declare the dependency. The other way is you could have some other method of determining that that needs to happen. So one of the things we have in here is what are called, there's actually an example, here we go, this game framework component extension event. And so here you can kind of send signals about what is the state of this thing. So then you could say, I'm going to add this to all pawns, or all pawns or a particular type. But then only if I get a special event, like sort of this loose binding between them. So just to finish the thought process I was on, so I've added that dependency in the plugin now. And so if I go back over here and save it again, I didn't get the pop up in the corner of the screen saying that it was invalid. And so, by default, every Game Feature plugin creates what we call sort of an asset referencing domain. But you can go in into project settings and actually define additional ones. And so we'll just open this up real quick. So asset referencing policy here. And so this kind of has rules for like, hey, if I have a plugin in the engine, what can it access. Hey, if I have a default plugin in the project, that's not a Game Feature, what can it access? And then you can define additional rules to like say, hey, plugins that match this path, are of this rule. And so like these Game Features, basically, Game Features are allowed to access content in the game project. But they're not allowed to access each other unless they have that dependency declared. But even within game content, you could do something like declare a test maps folder. So like under test maps, you could then say, all of the content in test maps is allowed to access content in any Game Feature plugin, anywhere else, because it's something that's not shipping, and we don't care if like because one of these things was disabled, that test map is going to break. And so some people might also do that with like their cinematics content, where they want to be able to just drop in stuff from in progress things while they're recording a video or something like that. And so this is all kind of, it's a rules-driven generalization of what we'd originally come up with for Fortnite. And so, on a per project basis, you can define like your tech art or whoever, or a lead programmer could basically define, here are the rules for our project, what's allowed to reference what. But we default to Game Features can only reference content in the game, or in other plugins that they declare as dependencies. MIKE: And the exciting thing about this is like, I mean, obviously some of this is like superficial if you can just like add in dependencies and whatnot, but it's kind of to draw up those boundaries, to help people create content that is less messy or less, like I'm sure anybody who's built a project on this scale-- MICHAEL: Less fragile as well, just in general. MIKE: Yeah. That scales, like you just end up with these like brass like referencing Blueprints right and left and stuff like that. And you end up with the player controller problem, where this monolithic player controller is the one nexus of like all these references. And this helps people who-- helps you distribute that kind of mentality to the rest of the team by enforcing it pseudo-- like in some way. I think this is a great way to kind of get into, so as we were adopting gameplay features, modular features, in Ancient Game, one of the problems that we had like understanding this, is these things are implemented as plugins. And when you talk about a plugin, you think about dependencies in a certain way. You think about the plugin, the game depends on the plugin, that the plugin shouldn't know anything about the game. And the game should know everything about the plugin. And so we started building things with that way. And we started hitting up against the wall. And it took some kind of like, oh, like if we start thinking about these as more like mods, it kind of inverses that kind of dependency picture that we had in our heads, where Game Features depend on game content. And the fact that they're plugins is kind of almost like there's a lot of baggage with that term, right? MICHAEL: Right, and it's actually almost unfortunate that like the engine concept of plugin is called plugin. Like there are some things in the engine that are absolutely plugins in that sense. So anything that uses like the modular features API, is like this true abstract plugin, where you have this abstract interface, and then several different plugins could all implement the same interface. And then you can call functions against it, without having to know which is which. But honestly, most plugins in the engine, and definitely these Game Feature plugins, are really more like, I am an assembly of related things. So like in the engine level I'm an assembly of these different modules that have particular startup phases. Or in Game Feature, I am an assembly of content that is kind of bundled together. But it's not, it's not capital P plugin. It's not something where there has to be this complete abstract interface between it and the rest of the stuff. And so like we're saying, Game Features, by default, can access anything in your base game, in terms of content, in terms of code. All that kind of stuff. They can just depend on that, and use it however they want to. MIKE: Yeah, code, even like, we like, when we were developing it, we were like, Oh, OK, this makes sense for assets. And then even when we got to code you're like, wait, because usually the way you're developing games in UE, like your game modules are like the end, like the leaf of the tree. And we were like, wait. So my C++ module in my plugin references my game module, to get at like classes and code and stuff like that, from that. And that was where we kind of started, like, Oh, OK, now we're starting to get it. This is a mod. Like we're modifying that game. MICHAEL: And I think thinking of it as mods, I think that's a great term for it. It's like it better describes the kinds of things it's going to both do to your game, and the kinds of access it has to the game. So-- MIKE: Yeah, do we want to dig into like more of the nitty gritty on Ancient Game, or is there anything else that you wanted to go over like, Michael? MICHAEL: I think that some of the high level stuff. So, yeah, if we want to switch over to your view, and we can dig into kind of how Ancient Game actually used this in practice, I think that'd be great. MIKE: Yeah, give me a second. I will switch to screen sharing. VICTOR: Thanks for that, Michael. Definitely knocked off some of the questions we received so far. MIKE: OK, I'm sharing my screen. Can we see it now? Hi, everybody good? VICTOR: Say yes, yes. You're good to go. MIKE: Cool. OK, so the first thing about like Ancient Game in the way that it was set up is like, we have auto, like the initial setup when you open the editor without tweaking it is, we have auto added some favorites for you. And these are ancient content which is like the base content of the game, and then the two other things are our two Game Feature plugins, which is Hover Drone content and Ancient Battle content. Let me break these out into their own content browsers, so I don't have to keep opening and closing the content drawer. OK, and so the simplest one is our Hover Drone. But like once we started kind of like, Michael showed the most powerful piece of this, which like comes default with the engine action, which is adding components, which actually we don't use at all in our Hover Drone one. Wonder if we use it in our Ancient Battle one? Oh, let's see, Ancient Battle, these are the definition files for our Game Feature plugins. MICHAEL: I think the light mode throwing might be using that. But it might also just being using the ability. I don't remember. MIKE: Yeah, so, the component one is really powerful, because you can write, you can author, like Michael showed, you can author a component like on the fly, and just have that component do something. But we were finding some of the stuff that we were having our components do early on, such as like add abilities, you would have this component that gets attached to the pawn. Its sole job is just to add an ability to the pawn. And then that component kind of sits around, just doing nothing for the rest of the time. So it's kind of something like startup code, and things like that. MICHAEL: And that's a place where we end up creating custom actions to do that instead. So you don't have this kind of just lump of a component sitting there. MIKE: So like, yeah, that's why we created the add abilities action for our project. But let's look at some of the link anim layers. So like, yeah, as we started working with this stuff, we started questioning like, OK, how are we going to divide this content in some of the more complex things. So for example, one of the first hurdles we ran into is like Echo needs to do some action, like for throwing the light dart. She needs to wheel back and throw. And we don't want that action necessarily, like that animation, to be in the base content. We want it to be part of our Game Feature. So how do we additively like introduce animations into Echo's like anim graph basically? We had this component, let me see, that if I go here, that we created, that's basically link anim layers. And so we started talking to the animation team about how to accomplish this. And they said that they have this concept of anim layers. Well, I'm not the authority on it, like basically, as I understand it, we set up an interface in the base anim graph, that basically is an injection point for essentially sub-grafts or like other animation Blueprints. MICHAEL: You basically declare like a slot in your anim Blueprint graph, that is like, here's where other things can come, you know, I can define a layer here. And then you can inject stuff into that. MIKE: Yeah. Let's see if we can find it really quick, like if I go into ancient content, Blueprints, character. Oh, it's going to be in on our animation. So if I go to characters, Echo, here's our anim Blueprint for Echo. MICHAEL: And these kinds of techniques, like this ties into that question that we had earlier, about could I have one Game Feature extending another game feature, is, if you think in terms of things like this, where you can declare, here's an extension point, or here's an event, or here's a place where other stuff can hang off of, then that gives you that opportunity to break things up in logical boundaries. So-- MIKE: Here we have like this is the animation, our Echo's base animation, like that's in game content. We have this layer that we've added, this full body layer that's going to do a full body. And you can see it, just basically the default implementation of this layer is that it inputs and it doesn't do anything. And then it outputs the pose. So we have like this way to inject now into the anim graph different actions. And so like if we go into, if I go into Ancient Battle, and look at characters, Echo, you see we have like an Echo light dart anim BP layer. And this is, here's the input here now where it does something different. These are kind of like interfaces, as it was explained to me, that come in and kind of you implement this interface, and then you're kind of able to do all this stuff, that you would in our plugin. And so that's kind of how we started separating animations. So like this component that we have here, this link, link anim layers component, basically, will take our skeletal mesh from our owner, and it will link in the anim layers that we specify. And this is like a component that we created. And then for our light dart specifically, if we look at the class defaults, I believe, let's see, is that the right one? Ancient battle, Ancient Battle, let's look back at this. Link anim layers, specifically for Ancient Battle. VICTOR: Hey, Mike, sorry for interrupting. I just discovered that we're not seeing your mouse cursor. Do you have that option underneath your Discord screen share settings? Can you enable that? MIKE: Yeah, give me a second. Sorry, oh, screen share settings. VICTOR: It's a little arrow. If you hover over the video call window, there's a little arrow, down arrow next to stop. Yep, right there. And then-- MIKE: Should I stop streaming and then look it up? VICTOR: Yeah, let's do that for just a moment. I know it's a little easier to follow along. MIKE: Yeah, sorry guys. I'm also like remoting into a computer for this. So like, let's see, screens, I select this one. screen res, smoother video, I don't see an option specifically for showing my mouse, which is problematic. VICTOR: Interesting. It might be something special then. Let's just, we can still see sort of where you're hovering. MIKE: Yeah, sorry. VICTOR: You can keep it in mind. Oh, you're good. MIKE: Yeah, I'll keep it up, there we go. MICHAEL: Just kind of call-out, what you clicked on, or where you're at I guess. MIKE: Yeah, I gotcha. VICTOR: Thanks Mike. MIKE: Let's see, layer types. Let me stop this. I'm stopping, clicking stopping, there. So here this, just this component Blueprint that we've added is simple. And it has a list of the anim layers that we want to link in and we've specified that in this subclass. This component is kind of still the component that we're talking about that, we didn't 100% love, which is a component that does one thing, and then like that's about all it does. It's not like-- But I guess it does like push and pop essentially, itself. Like it will push the anim layers like linking them, and then it will unlink them, when like this is removed. So if you deactivate the Game Feature, it will remove this component and so on this component's, like, going out, as it's saying goodbye, it's going to also unlink the anim layers that it did, when it was added. So if people, back to kind of which game features we have in here, Hover Drone is probably the simplest, because Hover Drone is basically adding the ability, like we found, as Michael kind of mentioned earlier, that this Game Features System plays well with the Ability System. You can add these abilities, and you can take them away from your heroes, from your characters. And so the Hover Drone, I'm expanding out that abilities here, which I'm sure you can see. But like you can see we're adding, similar to the components, we've set up our action to target the BP Echo character. And we have a list of like the abilities that we want to grant. And we even provided a way to associate it with an input action, from the new input system. And like let's look at this action, really quick, in native, like what it looks like. Oh, man, let's see. Do I have it open here? Like here. Add abilities, click. Am I blinding everybody with my white light Visual Studio theme? VICTOR: With team flash, yes. MIKE: Let's look at the-- MICHAEL: Yeah, I'm sure I also got grief for my lack of dark mode. MIKE: Yeah, see, so here we go. We have our add abilities like feature action, oh, man. Hold on real quick. I'm having a lot of problems with my own mouse right now, because I'm remoted into this computer. I may watch the stream. OK, I don't want to mess with things too much. But, OK, so we have our add abilities action. And this inherits from-- Am I going to, can I kill my-- I'm going to try something here on the fly. Did that mess stuff up? VICTOR: Not sure what it would have messed up. MIKE: I just, I killed my remote thing, and now I'm remoting back in. Are we still screen sharing? VICTOR: I believe we see a still frame. MIKE: Oh, yeah. Give me a second. Sorry. VICTOR: Since you're also doing that, we did get some recommendations from chat how we can enable the mouse, and still see that. And so why don't we, well, while we're-- MIKE: Yeah, OK, what can I do? VICTOR: Apparently if you do Windows R and you type in, let's see here, basically we want to enable mouse trails, and then set it to the shortest trail. And that way we'll get a mouse trail. MIKE: Windows R? VICTOR: Oh, actually, you know what? I think we see your cursor right now. Yes, we do. MIKE: You can see it now? OK, I don't know what I did, but it's back. VICTOR: It's back, all right. There we go. Thanks chat. MICHAEL: Sometimes the turn it off and turn it on again approach, that's all it takes. MIKE: Yeah, I'm remoting it, and so like it was getting really graphically corrupted for me on my end. So anyways, so here's another. So the base class for writing your own action that you want to do is UGame feature action. We found we were reusing some patterns that actually Michael defined in the component action, specifically the Add Component action, that we kind of extrapolated out into this world-based action. And this is basically, it lets you hook up into like world startup. Like basically when any world is created, you have a section to kind of run your code. And so we had-- MICHAEL: This is kind of related to, because the actions are this global thing of they persist with throughout the entire application. But then like in PIE, for example, you start up a world for your dedicated server, you start up a world for each client. And then you also have the editor world. And so we wanted to have a way for each one of those worlds, to do something within them. And this is a place that will probably continue to improve for 5.0, because in using this in more and more places, we're running into issues where, what if you have one client sitting at the front end, another client in a match, where you don't necessarily want to have the components added to the client in the front end, just because the features are active. Things like that. MIKE: Yeah, and so like by default, UGame feature action comes with kind of these, hey, I'm the Game Feature registering, I'm activating. Michael, do you want to comment on like explicit what the difference between registering, activating, loading, kind of all those different steps are? MICHAEL: Oh yeah, sure. So there's actually a fairly big comment in the Game Feature state machine, that describes all of the different ones. But at a high level, there's sort of like this behind the scenes state machine for every individual Game Feature, that handles like, OK, installed means it's on disk and present. So any built-in Game Feature is always going to sort of be at least to installed. Registered is like, OK, I've actually told other systems that I exist. So, for example, that registers with the asset manager and lets any of those assets that are listed, be part of sort of the asset registry, or not the asset registry, but the asset manager list of known primary assets. Loaded is, hey, we're actually planning to use this soon. It may not be active yet, so any of the actions haven't occurred. But sort of everything is warmed up and ready to go. And so, we won't go into depth in this talk. But if you look at some of our previous talks, or the documentation for the asset manager, there's this concept of bundled states, since you can say stuff like, hey, these assets, when my primary asset is loaded, I want these secondary assets to be loaded, too. And so loaded can do stuff like that, where like if an action lists, hey, I want to load this Blueprint, or, you know, to add a component, it will automatically be added into the bundle state for that, so that when the Game Feature is put into the loaded state, it's preloaded those classes, rather than loading them on demand when you actually activate it. And then activated is kind of that final state, where the Game Feature is completely up and ready to go. MIKE: And then those states are also reflected here in the data asset for your Game Feature, which you can, like Michael was showing, you can click between these to like put your game feature into these states. And then there's also console commands that you can run that do it as well. MICHAEL: Yeah. And there's a Game Feature subsystem where you can also programmatically say, I want to activate or deactivate these different features. There's a few more states than those four. Those four are kind of like the destination states. These are the ones you would want to-- it's going to get to eventually. But then there's like between registered and loaded, there's actually loading, which is the process of loading, doing these transitions. But it'll never like stay in one of those states. But if you have one that's taking a long time to do it, the UI in the editor will actually show you. It'll put up a little text block below that, saying what the current state of the plugin is, if it's not one of those four primary ones. MIKE: Got you. Awesome. And so, yeah, the feature actions, you get kind of hook points into some of those states right here, and then we built on top of that our world action base. We just used activating and deactivating, and we basically kind of activating, we more register ourselves for when like world delegates get, when a world is like first popped up. And then in that handle game instant start, for a particular world, we end up calling our added world. And so that's kind of our sub-actions. We ended up doing that for add abilities. And so we basically have this, and then there's the data, which is our ability set. Like this is kind of the properties that are reflective, that we saw in there, that are just like the abilities, the actor that we want to target, similar to the components, the ability, like mapping, like and we have structs on structs on structs here, like that gets down to like, hey, this is the ability that I want to add, and so on and so forth. And then basically, when a world is propped up, we have that add world function that we've overridden. And we kind of say, hey, we've gotten a world. We only care about-- this particular Game Feature only cares about game worlds. We don't want to be adding components or adding abilities in the editor world or anything like that. And so we do all this work to iterate over our abilities list and grant them to them. MICHAEL: And a really brief aside, but like one other thing we're experimenting with, which we think is a good direction to go to, but we haven't shipped it in very much yet, is using these same actions on other kinds of assets. So in addition to like Game Features themselves, imagine that you have like a playlist or a game mode, like this is team death match, or this is domination, or whatever. You could use these same action structure, action subclasses within them. So things like, OK, here's where I actually add the abilities for a team death match. Or here's where I add the component to the game state, that is actually the current state of the dominion game mode. Like, you know, it would go and find all the control points, and register with them, and say, hey, I'm listening to you. I'm going to keep track of score, or whatever. And so you can do stuff like build out these game modes, without having to put it all into like one monolithic class. MIKE: Yeah, that was one of the questions that we had when we were starting here, is, like, how would we architect this if we were doing all these different game modes. And we kind of like, like I said, my modular brain earlier, like let's break it all apart, started going down. And I was like no, no, we only have one game mode in this like demo in this example, like this is, we don't need to complicate it, and things like that. But, yeah, we were starting to think about that as well, when we were developing that. VICTOR: One quick, Mike, are you also seeing the flashing on your end? MIKE: I'm not. I'm seeing it come through on the video, though. VICTOR: Could you maybe just restart the screen share? MIKE: Yeah, we'll lose the mouse this time. MICHAEL: The lawman hard hat technical difficulties. MIKE: Yeah. Yeah. MICHAEL: Geocard. VICTOR: We have one, but hopefully this will be quick enough that we don't need to put that up. MIKE: I see a flash, I see it flashing still. Comes any time, it seems any time I'm hovering over something it's doing that. I'll try not to hover over stuff. And if it's too problematic, we can have someone else drive or something like that. MICHAEL: Yeah. VICTOR: I think right now it's going to be-- MICHAEL: I can pull up the DF file sequence spectrum. Yeah, basically, if you just want to me what files you want me to pull open, I can do it on my screen-share. MIKE: Yeah, that sounds good. Give me a second. Let me stop this. Sorry, guys. I don't know, real devs with real problems. VICTOR: That's the life. MIKE: Yeah, if you want to open up the Hover Drone, Michael, in the editor, that's what I was going to go on next. Did we want to talk about that the input system at all? Like I know that there's-- because like here, so this is the Hover Drone. MICHAEL: Yeah, so yeah, I think that's worth talking about. MIKE: OK, go ahead. MICHAEL: So another new feature, it's actually I think experimental in 4.27. But it's getting a lot of additional development and love in 5.0, is the enhanced input system. And so this makes the input system a little bit more data-driven. And so you can actually use assets to define things, rather than INI settings. And so it makes it, it's very minimal to these kind of modular concepts, where we can do things like, hey, you know, here's an input mapping that is activated when the Hover Drone is activated. And so you can see the Hover Drone here defines one of these actions is add an input mapping. And then this is just another asset. And in this asset, we can see it's adding the left mouse button or the gamepad right trigger to do the action. MIKE: And then that's associated with an action, which is another asset file, that we then in the abilities, add abilities, if you expand the add abilities, we associated with that one particular action. Yeah, that was another question, similar to animations that we had when we were approaching this, is like, man, if this was like a game that scaled, like I don't want to have to, like I mean, I know it's just an INI, but I don't want to have to like add every single input like for as I add more Game Features that arguably I can be like feeding into my live game. And I don't want to have to be augmenting the base game to account for new input actions and things like that. MICHAEL: Yeah, exactly. And so it's literally just built into this add abilities, where it's, here's the ability I'm going to grant. And so this GA is just a Gameplay Ability subclass. And then the input action that's going to trigger it is this input action, to play drone. Which is what, you know, it's triggered by that. So-- MIKE: Yeah, and here's a question for you, Michael, that I don't think we did perfectly on here, is, so we have the drone, and we have the light dart. And they both use the same input action, we'll say the same key bindings. And those are two separate Game Features. And we were basically like, originally we were sharing an input action, and then, at some point, we divided where the input actions like are essentially the same, but kept in their respective game features, which feels like the wrong way to do it, if it's the same button mapping, in my mind. MICHAEL: So it depends on ultimately what you're going to do with the game. So having them as separate binds can be valuable, if it's something like you're doing key-binding customization in your game settings or whatever. And then you can allow users to be like, well, I want this mode to play differently to this mode. Conversely, if it's like, the action is like a well-defined thing, so imagine like you've got, you know, you're doing a MOBA or something and you have kind of your basic attack, your movement ability, your special and your ultimate or something. Then you might do bindings for, here are the five kinds of actions any character can do. And then, within those characters, this is what this ability does. And so I think there, that's where you'd want to have just one set of input binds that are shared across all of them. MIKE: Yeah, so here, so if we were going down that route, we would put the input actions either into the base game or their own plugin that both-- MICHAEL: Both of the other ones would depend on, yeah. MIKE: -- would depend on, and that we can share. MICHAEL: Yeah. Yeah. So I think it really depends on what it is. So like cars might be another example, where you might have like, how do you steer, what is brake, what is honk or something. Probably you want all of your different cars to control the same. But if you have a car and then an airplane, some people want inverted controls only on one, but not on the other kind of thing. And so there you might have like split it out, to being two separate things that you can configure independently. MIKE: Yeah. So, yeah, I wanted to, it seems like we've kind of shown what the-- Michael, I don't know if you can re-maximize that window. MICHAEL: Oh yeah, sure. MIKE: Like the Hover Drone was really our basic one. All it does is add a Hover Drone ability that is contained in the Game Feature. It adds some input control to that, that gets built like-- MICHAEL: Sorry, yep. MIKE: Yeah, sorry. And we created an input binding kind of component specific for our game, like so that we can do the input binding. And that's kind of what that add input mapping action communicates to, so specific to Ancient Game is that. And then the last one down here is so, this was a latecomer to our development of it. Like the Hover Drone functions well by itself, like as an ability with the other two. But we had this issue where we really wanted, like, this default camera framing the character in the campfires in the initial scene of the demo, we wanted that camera to react to the light dart deploying where it kind of follows it up and kind of like zooms into it. MICHAEL: Yeah, kind of this cinematic hero moment, where it's floating up out of her hand. MIKE: Exactly, and so it was taking cues, this camera, we made a Blueprint that kind of is just listening for these events on the character, or these specific pieces. I think we used tags, where it's just looking for tags, because we're using the gameplay ability system, to be added to cue the camera. But the problem is like it was kind of this weird dependency issue again, where we want-- the base game shouldn't know about the Hover Drone at all. So we had to kind of put this into this specialized campfire drone transition camera actor, so aptly named, into the level. And so what we created was an action that would dynamically spawn things into the world as well. So we specified the level that we want to spawn into. And then again, in the code, similar to what we were looking at, when the world is brought up, we do a spawn actor and we spawn this guy in there. And now he's kind of actively like associated, and he's packaged up with the drone camera as well. I don't know if that's the best way of doing it. But it got it done, and was good. MICHAEL: And some of this was a little more complicated, because the Game Features were added while the project was in development, as opposed to sort of everything being designed with that in mind, from day one. MIKE: Yeah, we tried our best. But like we kind of wrote a faux Add Component system. But as you see, we kind of like, we're barely using the Add Component Gameplay Feature part. We kind of develop the actions, were really strong for us because we could write very game-specific actions for what we wanted to do. MICHAEL: And a game using the Ability System can do much of what they need to do with those abilities, because you can also do something like grant a GE to a player or whatever as well. So-- MIKE: Yeah. Yeah, that was another thing we were wondering about. Like we were trying to find the fine line in the sand, like, at the end of the day, tags are just kind of like these F names that are defined in config files and INI files, like is it OK that those configs live in the base game? Like they're really not like adding much to the base game. But, at the same time, if we're trying to go like the purist approach, they should be like compartmentalized with the components, with the Game Features as well. So that was when we were coming to tags, and trying to understand it. MICHAEL: And this is something that we've actually improved, actually, as a result of this, and some problems we ran into in Fortnite as well, where it's now much easier to define native tags. And, you know, tags are kind of expected to be a way to have plugins communicate with each other, without having to have an explicit dependency. And so like the two main ways we recommend to people to do that are either gameplay tags or primary asset IDs. So primary asset IDs are how you refer to an asset that the asset manager is managing. And we explicitly allow those without, you know, it's not a data violation error, to reference a primary asset ID from another plugin. And so you could use that to say, like I want to reference the experience, or I want to reference a map in another plugin, or something like that, and say I'm going to layer this on top of that. MIKE: Gotcha. MICHAEL: The gameplay tags are also, like, every individual plugin can define their own set of gameplay tags. Or you can add gameplay tags up to the base game. But there's a built-in support for like a tag INI per plugin as well. MIKE: That's what we ended up doing on here. So if you look, each of these Game Features also has its own config file, that has its tags that are associated kind of like with that system. Do we have any questions on the Hover Drone, Victor? VICTOR: Not specifically on the drone, but we do have a lot of questions in regards to Game Features. MIKE: OK, I'm wondering if those are worth going into, we can look quickly at the Ancient Battle, and see what all composed its, going into it. And so-- MICHAEL: Yeah, let's go through that I guess real quick. So like Ancient Battle also adds a level instance, and so this is sort of like layering stuff on top. And this is something that in 5.0 final we'll probably have a nice way of doing with data layers, if you're using the open world tool sets as well. Although right now those all have to be in the base game. MIKE: Yeah. MICHAEL: Content directory. MIKE: We came, there was a kind of confluence of kind of features meeting here, which is like we started using the world partition, the open world stuff, and data layers for the dark world. So the Ancient Battle is supposed to represent like everything that's brought in for the dark world or the gameplay associated with the dark world. And the problem is like some of the destruction pieces, we wanted to come in. So like the way we thought about it, was the interesting thing, like if you run around the world, without, like the dark world without this Ancient Battle Game Feature plugin, what does it look like? And we're like, well, you're not going to have the light dart. So you can't destroy things. So conceptually, like puristly, it doesn't make sense that these things are destructible yet. And so we wanted to put our destructibles into a sublevel and have it so that that sublevel gets kind of like put into the main level, so that once you have the light dart you can start blowing stuff up, and whatnot like that. And so like there's a point where Echo has to blow up a pillar to get by it. And the cool thing that we thought about like this as it extends to real games is like I was thinking of like a fall-out game or something like that. There's a vault. And there's a vault that you want to get into and maybe they haven't put what's behind that vault door yet, and it can't open up. But you want to kind of tease that in your base game. And so it's something that you know is coming later, you don't know what's going in behind that vault. So you kind of put a static geometry vault there. And then, later on, when you're layering this in, you replace it with a sublevel of like a vault that now opens, or something like that. And that's kind of what the pillar was to us. Like it's this thing that's blocking your path indefinitely. And then once this Game Feature is enabled, you can now destroy that pillar, and make it past it. And then there's more content that has been added to your world. And so like the robot or the golem or the ancient one, as we call him, is also in that sublevel, and things like that. MICHAEL: Yeah, and you can also imagine doing like seasonal events or something, where like you want to decorate the map with, you know, snowy trees and presents under them, or something like that. And so you could use this to like layer in additional interactable objects in your level, or additional collectibles or pickups or whatever. MIKE: Yeah, going back to the Star Wars example that I used for Fortnite is like the crashed TIE fighter is something that you layer in on your map, and stuff like that. Yeah. MICHAEL: Exactly. MIKE: And abilities-- what, sorry, go ahead. MICHAEL: I was just going to say the exact same thing, add abilities is the same as what we were talking about with Hover Drone. And so adding various different abilities here. MIKE: Ancient battle is a larger plugin that encompasses a lot more of the gameplay than the hover drone does. So you can see there's more abilities here, like Echo's dodge when she's in the final battle, the forced walk, like we have this force walk because we wanted to show off some of her like IK, in the thing. So we added a like you hold Shift and she walks and stuff like that, is kind of why there are more here. MICHAEL: And then we've got the input mappings, which are the controls for the dart and stuff like that. Then we do actually have an add components here in this one, where basically this is what he was talking about earlier, about how the animation layering is occurring. And so this is one of those things where, at the moment, this is a component, that then goes and does something else. You could also create like a custom action that was explicitly, I'm going to do the animation layering via some game specific system. MIKE: Yeah, we could have ported that easily to that. And then the other one, if you expand that, is like the other components, or is this targetable registrar component. Like we wanted all the things that you can destroy or blow up to be, because they communicate with the reticle, to register themselves with this system, rather than kind of doing a spherical like gather of area around you, or a bunch of ray-cast, we can query this system of like, hey, what are all the targetables in the world, because we used a reticle like arrow to direct you when you're aiming to like towards the thing that you want to aim at. And this kind of adds that to all our targetables in the game. And then the last thing is world system. So we found the world targetable manager is similar to what I said, is kind of like a singleton, where we were going gung ho. There might be, there's probably other ways to do this. But I was finding and when I work in C++, I like using world systems. And I wanted the same thing for all our targetables, like a targetable manager singleton. And so I made an action that will do those to you and then you're accessible from Blueprints. MICHAEL: And another way you could do that is you could create a game state component or game instance component, through-- not game instance component, but game state component, and then throw that on using add components. But either way, it's just a global singleton that you can get to easily from various places. MIKE: Yeah, it's easy to get caught up in like you're excited. Like once you're creating these actions you're like, Oh, Yeah, I can see this. I could see this. And you like make all these things of you want to shoehorn everything through it. And so that's kind of what that was. Yep. OK, I think that's the tour of this stuff. Unless like people are wanting us to dig deeper, it kind of gives the high level picture of how we pieced all this stuff together and how we divided content on Ancient Game. VICTOR: We have a few of those questions. I don't think they're specific to Ancient Game, though. I think it would be useful for us to cover that a little bit more general. And then maybe you can use Ancient Game as an example, if it fits the topic. Just spinning off of what you were just talking about, we did have a lot of questions in regards to if Game Feature plugins can be used as DLC or methods of producing DLC for your project. MICHAEL: So there's kind of two different parts there. So one thing the Game Feature plugins make really easily is making sure that your game will work without the content. And so like making sure that if the DLC is not ready, available yet, or hasn't been purchased, that the game will still function without it. There is not a fully built-in thing specific to game functions on how you actually download that content. But what you can do is you can define all of the content within your plugin to be in a different pack file than the rest of your game. And then use either like platform-specific methods like the PlayGo or stuff like that, to control actually downloading it. Or you can have it be on disk, but just inactive, until they've actually earned or purchased or however the unlock method works for that DLC. And so Fortnite uses that latter method for stuff that's going to be active in a future season, or going to be active as part of an event, is the content will be on disk in the game, but inert until the Game Feature is activated. And sometimes we'll actually encrypt it if it's like, you know, a special event or a concert or something, the content in that pack file will actually be encrypted as well. And so we won't release the encryption key on it until, you know, right when the event starts. VICTOR: There were some questions in regards to if it's possible to use-- let's see if I can find exact question. This was in regards to using the chunk downloader, and then releasing a Game Feature plugin via the chunk downloader. MICHAEL: So, yeah, that should be possible. We don't have any examples of that, demonstrating it. But it would work the same as if you were downloading chunks for something else. You would just basically set all of the assets in your game feature to be a particular chunk ID. If your plugin has any C++ code, that would still need to have shipped in advance, if that makes sense. You know, you can't do like downloadable DLLs on most platforms, for example. VICTOR: Thanks. MICHAEL: But all the content could come in and then activate, once they've downloaded the DLC. VICTOR: Still thinking about this, you showed it very early on, but essentially preparing all of the main classes and objects in your game to be used with Game Feature plugins in the future, is sort of required, right, for you later on push a bigger patch to your game to make that. MICHAEL: So, I mean, you do need to be doing that with that in mind. But like some of that prep work is, like you said, just in your base class. So like you don't have to touch every pawn in the game. You could just touch the base pawn that all of your other pawns derive from, or things like that. MIKE: And that's only if you want to use, like that is specific to-- MICHAEL: Add components. MIKE: -- adding components onto the Game Features. Or we used it for some other things, but it's however your action works, and the component's action works, using that system. MICHAEL: So for example, some games may entirely use just the fact that you can inject stuff into the asset manager or the data registries. So, if you're doing something where now you have additional cosmetics in one of these downloads, or you have additional weapons or additional maps or something, there you wouldn't, your game code would have to take, oh, be aware of that, of like, oh, all the tiles I show for selecting what map you're going to play in the front end is asking the asset manager for the list of all available, you know, gameplay maps or something. But then when a Game Feature activates, it can just say, hey, asset manager, I'm a new gameplay map, for example. And so it really depends on what you're using the system for, how you'd have to modify your game to make it work. But it's effectively a tool kit for you to be able to build out modular games. But it's not making hard opinions on exactly how you must use this, if that makes sense. VICTOR: Next question comes from [INAUDIBLE], who's wondering, it is more difficult to debug dynamically added components, because they may not be even visible in the actors' hierarchy. Are there any plans for better debugging dynamically added components or Game Feature actions in general? MICHAEL: So the components you can debug if you start from the component itself. So like in the dropdown in the Blueprint debugger, you can pick, hey, I want to debug an instance of this component. And it'll give you a list of all of the spawned instances in the PIE world. We are separately, like not specific to Game Features in general, but we are improving sort of like the Blueprint debugger workflow in general, and trying to make sort of like a better watch window, better tooling within the editor for debugging Blueprints, watching lots of values, that kind of thing. And so no timetable on that. But that's an ongoing effort. VICTOR: The next question comes from Rodolfo Pisotti, who's wondering, could this tool be used to create features to be used in Editor and not necessarily during gameplay runtime? MICHAEL: Mechanically, I don't see why not. Like the Game Features themselves, like they are active, like we're talking about, when the editor has booted up. In practice, I think that there is a little bit less value there. Like I think you'd probably just be doing like a regular Editor plugin, usually, when you're layering in stuff, because you don't have kind of the same problems that you're trying to tackle. But mechanically it would work fine. There are certain things that aren't going to work. So like trying to add components using this, like the modular component manager very explicitly does not work in Editor worlds, because we don't want you to accidentally like add a component to a thing and then save the map. And now it's stuck on that thing. It's not being data-driven anymore. So definitely some of the actions are not going to, you know, they'll be inert in the Editor world. But if you're making your own custom actions, I don't see what would break if you were doing that. VICTOR: Next question comes from Ishan Bugami, who's wondering, does these features come into 4.27 as well? MICHAEL: Bits and pieces of it are in 4.27. But it's not a supported feature as part of 4,27, so basically, a lot of this is a prioritization of code that we'd originally developed for Fortnite. And so some of that work was done in the Fortnite branch, and then kind of came along for the ride into 4.27. But it's kind of just like a snapshot in time of a work in progress, as opposed to, this is actually a thing that we think is ready for licensees to use, which was 5.0 EA, is the first point for that. MIKE: Because actions, or actions, I believe, were worked on basically-- MICHAEL: So actions are actually in 4.27 as well, MIKE: Oh, OK. MICHAEL: But none of the UI work, so like where we showed how to switch between the active state of the plugin, the new plugin wizard. All of that work was done as part of 5.0. MIKE: Gotcha. MICHAEL: And so basically we didn't do any testing on Game Features in 4.27, so that's why I would say, we don't view it as a supported thing in 4.27. But it's actually worth calling out that even all of the stuff that we showed off now in 5.0 is still considered experimental. And so it may change in a few minor ways between now and 5.0. But probably by 5.0 we'll kind of consider it beta and ready to use for general production. VICTOR: Next question comes from Robin Hassenbach, who's wondering, can you create session inherit from Game Feature plugin templates? Like Michael said, you've got a template weapon feature plugin and inherit from it. MICHAEL: Not exactly. So like you could create some base assets that are like, you know, this is what my weapon Blueprint is, and then have variants of that in different Game Features. But the Game Feature itself, the asset that's at the root of that plugin, is a data asset. It's not something that you're subclassing from. So there's no inheritance on that. VICTOR: Carlstyle was wondering, can you please talk about data registries and give us some examples on what they could be used for. MICHAEL: Sure. So data registries are kind of a generalization of what we'd kind of done in the past with composite data tables and composite curve tables, where you basically want to be able to say, I have a key, and I want to get a value. I don't care what data sources provided that value. And so, like at a high level, like if you're not familiar with like data tables and curve tables, they're just something, they're like a spreadsheet, where you can say, I've got a row name, which is my key. And then in a data table, then I have a struct that is my value, and in a curve table I, in addition to my key, I also have like a float index, like the level. And then I get a value along a curve back from it. So the basic versions are just single assets, which aren't extensible at all. Then composite data tables and composite curve tables are like, I'm going to make a meta-asset that is actually composed of these other three tables, or this list of other assets, which is a little bit better, but it's still kind of this rigid, I have to define the hierarchy of data once up front. And so data registers are that next logical step, where you define, I am a conceptual table, but then things can come along at runtime and say, hey, I'm going to provide data into this table as well. So you can imagine a data registry of something like, what is my loot table for treasure chests in my map. And so the base game provides some set of loot, and then a Game Feature could come and say, I'm going to add a data source to the data registry that is called loot table. And now the additional items in my Game Feature plugin are now in the loop pool for treasure chest to spawn in my game. VICTOR: I think you were mentioning earlier that we could spend an entire Livestream talking about some of those features. And I think we will, probably later this year, if not earlier next year. We'll try to get Michael back on the stream to do that. I just signed you up for it. I don't know if you want to, but it seems like you would be the right person to do that. MICHAEL: Yeah, I think that's one of those things where like when we have a sample game that's using some of that stuff together, it'll be a lot easier to demonstrate, because it's the kind of thing where, the system is doing a lot for you. But there's still a decent amount of setup within your game to actually make use of it. Like you need to actually have a data-driven game to demonstrate it. So I think that'll make that kind of conversation a lot easier. VICTOR: And for those of you out there, we're aware that there's requirement for documentation on our online learning courses on a lot of these new topics and features that we're shipping with Unreal Engine 5. Know that this is all still early access. We are doing these Livestreams to be able to give you a little bit of information, at least so that you have something to go with. But know that in the future, when U5 gets released, we will have full documentation, including courses on Unreal Online Learning, and probably more Livestreams on these topics, if you prefer some of the other formats of learning. But it's always great. We want to get as much information out as possible, to the extent that we can. And this is one of the ways that we can do that, before all of the features are done and production-ready. MICHAEL: Yeah, A lot of these systems are kind of hot off the presses. So there's not a lot of examples at the engine level yet, but we're going to improve that with time. VICTOR: Did hear that Michael's alarm went off, that we're getting short on time here. Let me grab a couple more questions, and then we're going to wrap up so that you can make your next meeting. His busy days here at Epic. Let's see here, Robin Hassenbach was wondering, is there any platform limitation to modular Game Features. Will that work across PC consoles mobile, Viera, et cetera. MICHAEL: Yeah, there's no platform-specific code in that at all. So it'll work anywhere. VICTOR: And that goes with almost all of the features that we ship natively with Unreal Engine. MICHAEL: Yeah, I mean, it's pretty much only sort of like graphical features, or things that use platform-specific APIs, where there might be limitations there. For the most part, we try and write code that's portable across all of our supported platforms. VICTOR: See Last Devel was wondering, can dedicated servers load and unload Game Features for connected clients? MICHAEL: Yes, but you'll need some game code to do so. So like it won't, in PIE, because everything is happening all in the same process, it kind of just happens for you. But in a standalone game, what you would probably do is, in your game state or in some managers, actor, or system, you would be like, for this game, these are the Game Features I need to have active. So like in Fortnite that's the playlist data. So we load the playlist data, and it merges in with some hotfix data and says, OK, now I know the list of all the game features I want to have active for this game. I know all the data tables I need to load for like the loot system and everything else. So it does all that work, and it also replicates the client, hey, here's the list of things you need to load too. And then the game is not like the actual game, the true begin play is not ready until playlist data ready, effectively. And so you'll have to do a little bit of extra work there to like basically, the server is going to tell the client, hey, load these playlists. And then don't drop your loading screen until you've loaded these Game Features as well. But, yeah, you can absolutely do it. VICTOR: The next question come from Inside who's wondering, will there be some global event buzz so plugin can publish events and other plugins can subscribe to them without knowing about each other? MICHAEL: Maybe. Like so we've experimented with that in the past. It's one of those things where it can definitely be kind of a foot gun, where you can end up with really hard to debug gameplay code, that's like nothing knows nothing about nobody. And you need to do a lot of printf debugging or whatever to trace and figure out where things are happening. But having said that, I think that there are definitely subsets of problems where that's a really elegant solve. And so we may provide an engine level system for that, but don't have formal plans to do so right now. VICTOR: Next question comes from One Learner who is wondering, are the game features once triggered auto instantiated, memory managed, and garbage collected, all automatically? MICHAEL: Sorry, could you repeat that? VICTOR: Are the Game Features, once triggered, auto instantiated, memory managed, and garbage collected automatically? MICHAEL: So the Game Features, like the features themselves and how they're loaded, are kind of very explicitly managed. And so when a feature's activated, we're allocating like a backing object for the state that the state manager for that. Then the assets that are loaded by the Game Feature, once it's loaded and activated, are managed through the asset manager. And so like we basically changed the bundle state on the primary asset that is the Game Feature itself, or deactivate it. So I think the answer is effectively yes, but I'm not sure if I answered all four of the subparts there. VICTOR: I think so, and I believe-- MICHAEL: But basically, there is a system that manages this. Like you don't need to call at the root on an action, for example. And an action is UObject, and so we can have object references within it in like a transient array or something, and those will be exposed to the GC system. VICTOR: Let's see, I have to preface this question with that chat decided on a new term for the Game Feature plugins, which is plug outs. I hope we don't officially grab that. But the question reads, you mentioned adding things to the map from Game Feature plug-outs. How does that, can it interact with baked lighting? MICHAEL: The answer is, it can't, not realistically, so-- MIKE: Yeah, it doesn't. We're basically doing, what we did in Ancient Game was just dynamically spawning, just the equivalent of if you were running a Blueprint that dynamically spawned something into the level. So you can't bake that stuff. VICTOR: Robin Hassenbach is wondering, do you need to use the enhanced input for Game Feature injected inputs, or can that be done in the traditional way as well? MICHAEL: Enhanced input is the recommended way. Technically you can have INIs in Game Feature plugin. We don't recommend it for a variety of reasons. But you could use that to modify like the base input, INI, from a plugin, but probably what you'd end up doing if you're using the old input system, is just define all of your input actions in the base game. And it would just be slightly less modular in that case. But definitely enhanced input is sort of our recommendation for new projects starting now, for sure. VICTOR: Quickly going through some of the last questions we got here, I know I have three minutes. So there's probably only one more. Oh, there were some questions in regards to how Game Feature plugins and the gameplay ability system work together. Do you have any comments on that? So at the base engine level, we don't have any examples at the moment of programmatically adding abilities. Ancient Game demonstrates that. It shows off, like here is a way in Ancient Game to add abilities into the ability system at the right point in time, when the ability system code is being initialized and stuff like that. And Fortnite has the same thing as well, in Fortnite specific code. So we'll plan to have more samples in the future. But we think they play very well together, in general. MIKE: They play well together, but for Ancient Game we had to write some glue code, which people can look at for now. But I think we'll have better examples in the future. VICTOR: Thank you both. With that I'm going to try to give Michael two minutes, probably one, in which you can sync up for your next meeting. Thank you so much for coming on stream to talk about this with us today. If you all out there have any more questions, feel free to post them on the forum announcement post on our forums. That's where our Livestream announcements happen, as well as we continue the conversation post Livestream, but also occasionally before the stream. If you ever have any questions that we'd like to prepare for our guests, please make sure to fill out them there. Mike, Michael, thank you both. I hope to see you again sometime in the future. Yeah, with that, I will wave goodbye to you both and I'll continue my spiel once you've left. Thank you both. MICHAEL: It's a pleasure to talk about this stuff. I'm really excited to see what people get up to, and definitely interested in any real world problems you guys run into with the stuff, because, like I said, it's still early days, still experimental. So any feedback is much appreciated, so that we can make this a better system for everybody. Right. Have a great day. MIKE: Bye, everybody. VICTOR: Bye. And with that said, it is just me now. And the reason why is because today is my 111th Livestream that I produced, organized, and hosted on the channel. And I am sad to let you all know that this was actually the last Inside Unreal stream that I will be hosting. I've moved on to the product management team as a product specialist. And I will actually be more hands on, making Unreal Engine better for everyone out there. First thing I did was the VR template that you can see in 4.27 and UE5, and there will be more of that, specifically towards XR, because that's sort of where I have most of my experience in the industry. But I'll be tackling some other things as well. And so I want to thank you all. It's been kind of an interesting ride here during the pandemic. For those of you who watched the stream from before that, you know we have a whole studio and a whole team behind the scenes and stuff. And sort of took that, just did it here from my living room for the last year and a half, until the tech team behind the scenes, I do want to do some thank you shout outs here, have actually been helping me with that for the last couple of months. So that's been really nice, because before it was just me and my stream deck. That said, I am going to go to the Unreal Slackers Discord right after the Livestream here. I might just grab a cup of water or something and hang out with you all. So if y'all want to go to UnrealSlackers.org, I'll be hopping in one of the voice channels right there. You can come hang out for me. I'll probably be there for the rest of the evening, just chilling with you all. If you want to talk to me, have questions, talk to each other, please come and join. It's a good place, especially now that we're sort of still a little bit difficult to see each other in real life. So with that said, no traditional spiel today. If you want to see that, I've done that for the last two years on the channel. So thank you all for watching. I hope you've enjoyed all the content we've been able to produce here on the channel. And know that this is not the end of Inside Unreal. We are taking a break for next week while we're making some transitions on the channel, but from there on out, we will be continuing all the topics. I've booked stuff until basically the end of the year. So there's lots of stuff coming. And that said, I do want to let you all know what we've got. So the week after next, we're going to go over highlights from 4.27. And so make sure you join that to catch everything that's new in 4.27. Yeah, there's no spiel today, Loresh. Anyway, thank you all so much. This will not be the last time I'm on the channel, but this is the last time that I'm hosting the show. So thank you all so much. And I will catch you all next time I'm here. Take care everyone. Stay safe.

Channel: Unreal Engine

Views: 40,618

Keywords: Unreal Engine, Epic Games, UE4, Unreal, Game Engine, Game Dev, Game Development, ue5, valley of the ancient, early access, modular game features, game feature, game features, plugin

Id: 7F28p564kuY

Length: 96min 41sec (5801 seconds)

Published: Thu Jul 29 2021