How’s the UI pipeline for UE4 compared to UE3? Are you using Scaleform on Fortnite? Is the workflow similar to UE3’s workflow?
Ah man, Did I miss it? 
Edit: Totally forgot the clocks went forward, haha. I suck.
I dont think so from what I see it’s starts at 2PM EST which is about 20 minutes from now for me 
Do you guys make much use of Archetypes on Fortnite?
Does the archetypes system still exist?
If so, do they cause problems when properties within Archetypes change for instanced Actors placed in a level?
Thank you very much for everyone who joined us for the stream, asked questions, etc. We had a ton of fun…maybe too much fun? I’ll try to stop by this thread after work and see if I can’t answer some of the questions we couldn’t get to during the stream. Fortnite is definitely very much in active development though, so we might not have answers for everything just yet! We’re really looking forward to community involvement to help guide the game over time though, so we were super excited to be able to share a bit of our dev. process.
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:
Hey thanks for answer, though I thought that you answered it pretty clear on stream 
I especially liked to lego blocks analogy, as Honestly it was something I was telling other people when they asked what to do with blueprints, and how to split responsibility between bp and c++.
once again **BORING ** seriously why isnt anyone listning to the fact that a livestream of the unreal engine should show actual ENGINE FOOTAGE!
…
I don’t know what to say if you think this stream was boring too. It was so much fun and informative at the same time. And again, i’ll quote myself from your previous thread;
It was funny and informative at the same time. Good job 
**Thanks **for answering our questions , keep it up! It’s awesome to hear how you guys are using Unreal.
Also, please ignore Evenios. His opinion is not shared by the vast majority of us.
Because you’re opinion is your opinion. The livestream doesn’t need to show engine footage. We have the engine in front of us.
I have a feeling that you’re trying to troll.
Why would they waste the time showing engine footage? We already are customers. They release a new content example every week or so, that you can actually play with and look behind the curtain. Much more worth than a video.
Do you know how much information was inside this one, just like the previous streams? Wait a second, did you even watch more than a minute of this?
Evenios - Didn’t we have this conversation in another thread? Myself and a few others gave a pretty detailed response as to what the streams are about, might be worth refreshing yourself chap!
EDIT: Yeah looks like it was you buddy, see here: https://forums.unrealengine/showthread.php?2672-actualy-show-Engine-footage-during-livestreams&p=16085#post16085
Also, thanks Epic. This was probably the funniest live stream ever. Matt should definitely voice a Fortnite character though… be it a unicorn or gingecorn
I enjoyed the live stream, you guys are a blast! Thanks for replying to the questions in more depth here, look forward to the rest being answered.
So sad I missed it 
Was actually at home to watch but forgot to tune in… Will it be available at youtube in the near future?
Edit: Too early for me here in germany… -.- Just saw that you can watch the stream on twitch ^^
It is already: ?v=M5k3hhlaNZI
Thanks guys, it was an awesome stream! Way more fun than I was expecting too
+1!
Awesome stream guys! I found it Hilariously entertaining! Was playing it side by side while working with UE4 