Ok, going to be long, but I’ll try to do my best. I won’t be able to answer all the things partially because some of these are out of my knowledge areas and partially because some we might not have figured out just yet! For context, I’m a part of Fortnite’s “combat/action” team that usually works on the moment-to-moment gameplay for the player, so that’s where my recent experience lies.
Blueprint Usage Questions
I feel like we covered a lot of the blueprint stuff in the stream, but I’ll go over some pieces again. In the grand scheme of things, blueprints are pretty new to us too after years of using UE3, so we’re still figuring out the best usage patterns that work for us. My take on when/how you use blueprints is going to be largely up to your project, team composition, and overall goals. There’s probably no one right answer. I’m pretty hooked on the cool things blueprints allow our team to accomplish and I can’t imagine we’d ever go back to a 100% C++ game in the future.
For Fortnite, we have a multidisciplinary team full of artists, designers, programmers, etc. and so our usage of blueprints tends to skew in such a way that each discipline can contribute to a major feature in different ways. We tend to implement each core system in C++ first, then expose a lot of the system’s functionality to blueprints so either programmers or artists/designers can work on things. Couple examples: our characters are first C++ classes sub-classed off of the base engine character actor, but then the actual character we spawn in the game is a blueprint that is based off of our Fortnite-specific C++ character class. If the programmers need to make a fundamental change to the characters, they can just modify the C++. If the artists want to add some specific blueprint functionality to the character, they can. Second example: Fortnite lets players build and interact with tons of building pieces. The core of the building system is again in C++, but then every single building piece (wall, floor, etc.) and container in our game is actually a separate blueprint based off a C++ BuildingActor class, which allows for super powerful things. The artists/designers can go into a specific building piece and add one-off special functionality if they want to make it more special (making tires bouncy!) without needing to involve a programmer, and without our programmers having to muddy up our code-base with tons of one-off gameplay features. We also use blueprints to rapidly prototype things sometimes to figure out if they’re going to be fun or not before we devote any programming resources to them.
Fortnite has led to a lot of features that either our team or the engine team has developed over the course of the project, and any that are general enough that make sense to be implemented in the base engine, we go ahead and do that so we can make it available to everyone to use. I’m blanking on any specific blueprint framework-y examples, but there have been plenty of features overall. Fortnite is a pretty big consumer of features like the CSV-import stuff we mentioned on the stream, which is available in the engine proper now. Usually the only code we have that’s not in the main engine is stuff that is very specific to our gameplay.
We’ve chosen to do this from time-to-time for various reasons. The most common case is usually something like an artist/designer prototypes something that ends up being widely used and we decide either that a) it would also be useful to use in C++ directly and/or b) we could make it easier for the artist/designer to use if we wrote a blueprint-exposed function that encapsulated what they were doing, so they could do the same thing with less actions, and/or c) what they were doing is going to form a core system that we’d like exposed to code and blueprints for future development. The bouncy tires are actually another good example of this. We started with that bouncy behavior as a series of blueprint nodes an artist strung together, but then we saw wanting to use/improve that interaction in multiple places, so we put some of that functionality into C++ and re-exposed it to blueprints as a simpler node.
Another thing I wanted to touch on specifically was also blueprint performance vs. C++, because that came up in the stream a few times and I don’t think we did a fantastic job answering that particular part (Cameron gets over-excited, what can I say? :p) The answer here ends up a little bit complicated. The simple version of the answer is that native C++ outperforms blueprints. Cameron was correct in that if you see a blueprint-exposed function you can call on an actor, etc., it’s really just calling back to the C++ code written for it, however, there is an overhead cost associated with executing blueprints that isn’t present with purely native code. As engine programmer Golding mentions in this thread: https://forums.unrealengine/showthread.php?1105-Blueprint-Performance-Benchmark , if we consider blueprints as similar to UE3’s old UnrealScript, it would be a rough rule-of-thumb of around a 10x difference, but that could vary considerably depending on the scenario. Ultimately if you’re only using a few nodes that are calling back into C++ functionality that is handling most of the heavy lifting of an operation, that’d likely end up faster than that estimate. The estimate also initially sounds large, but keep in mind that there is a very big difference between “slower than C++” and “too slow to be used.” Hundreds of UE3 games (including all of Epic’s titles) were written with extensive amounts of UnrealScript handling the gameplay logic. The vast majority of cases you’d want to use blueprints in will be fine, even if they aren’t exactly the speed of C++. Fortnite has numerous uses of blueprints all over the place. The parts of the game that are super performance critical tend to already be in C++, so you shouldn’t feel worried about putting gameplay logic in blueprints. The areas where you do want to be careful are the same as if you were writing in C++. Just like you wouldn’t want to run really performance-intensive code inside every C++ actor’s tick functions, you also shouldn’t put tons of performance crazy operations inside the Tick event of a blueprint. We tend to make a lot of our blueprint logic event-based (triggered when some event happens, like taking damage, etc.) instead of trying to do everything every frame in a tick function.
If you’re interested in knowing more, you may want to also check out engine programmer Michael Noland’s posts in these threads: https://forums.unrealengine/showthread.php?1409-How-does-the-Blueprint-system-really-work-mapping-out-the-Blueprint-related-source https://forums.unrealengine/showthread.php?1165-Blueprints-vs-coding
UI Questions
We do use Slate for Fortnite’s UI. We have a full HUD, inventory screen, lobby, menu, etc. all done in Slate. I’ve only personally done a few widgets or prototype UI things, so I’m not the best person to speak about it in depth. The workflow is a bit different than how we would have done it in UE3, as Slate predominantly lives in code at the moment. The engine team has definitely heard the community on wanting a WYSIWYG UI editor, so like mentioned on the stream, there is one being developed, but it’s in the early planning phases right now.
Two other things to mention re: UI. On Fortnite I do know that we actually have most of our UI code moved into its own module in code in order to make iteration times on UI specifically faster. Also, as another option, Coherent UI has recently released a plugin for UI creation.
Art Questions
As mentioned on the stream, I believe our artists want to actually do some kind of follow-up content going into stuff like this in better detail than my programmer-self could ever provide. Not sure on the time-table on that, but I’ll sync up with them again. I expect we’ll probably do lots of Fortnite-related content stuff as we get further along with the game.
I actually hit the maximum character count for a forum post in the process of answering these…will continue in another post. :eek: