[Twitch] Fortnite Developers Discussion - Apr. 17, 2014

[Bajee]

Billy, thanks a lot for taking the time to write such detailed answers and for answering my questions. The livestream was very informative and enjoyable. You all seem to have a great time at Epic. Working at such a cool place sounds definitely enticing. I still have to finish up my masters though

[Ben Zeigler]

Can you talk about the Save/Load pipeline for UE4?
Do all Actors have unique GUIDs that remain consistent between sessions for the purpose of serialization tagging?
Would users of UE4 write their own save/load mechanisms or are there stubs that users can build on?

Currently there's no built in system to do saving at the level you need for a game like fortnite. Fortnite built a custom solution, on top of some features in the engine that can be used. We're going to work on a comprehensive example of how to build a save/load system, but it isn't ready yet. I'll make sure to let people know when that information is available. There is a Simple Save Game system that works really well for simpler games, there are some questions on AnswerHub that go into detail for that system such as this one.

For fortnite, we assigned each of our objects that we wanted to save a custom GUID, but other UE4 developers have used a similar system using just the object's full path, as that should stay the same. So, you have a system to identify an actor uniquely. Then, we're using a system built on the SaveGame property flag to actually serialize the actors. If you set the ArIsSaveGame archive flag on an archiver, it will only serialize properties that have that flag set on them. Some of the basic properties are set this way in the engine, and you can then tag your game specific properties.

So, you need to set up a savegame archive. For fortnite, we're using a proxy wrapper based on the Objects-as-strings proxy wrapper:

struct FFortniteSaveGameArchive : public FObjectAndNameAsStringProxyArchive
{
    FFortniteSaveGameArchive(FArchive& InInnerArchive)
       : FObjectAndNameAsStringProxyArchive(InInnerArchive)
    { 
       ArIsSaveGame = true;
    }
};

Then, you can use that proxy archive to serialize a record for an actor or object you wish to. Here's our save code, that writes to a simple struct that has the actor's class, transform, and a TArray storing the bytestream:

ActorRecord->ActorClass = Actor->GetClass();
ActorRecord->ActorTransform = Actor->GetTransform();
 
FMemoryWriter MemoryWriter(ActorRecord->ActorData, true);
 
// use a wrapper archive that converts FNames and UObject*'s to strings that can be read back in
FFortniteSaveGameArchive Ar(MemoryWriter);
 
// serialize the object
Actor->Serialize(Ar);

And here's our code that restores that actor:

AFooActor *NewActor = GetWorld()->SpawnActor<AFooActor>(ActorRecord->ActorClass, TempVector, TempRotator, SpawnInfo );
 
FMemoryReader MemoryReader(ActorRecord->ActorData, true);
FFortniteSaveGameArchive Ar(MemoryReader);
NewActor->Serialize(Ar);

This works well for actors that are self contained, if you have references between actors you can fix those up inside the archive handler, and if you maintain the object's full path before and after they should hook up automatically, if you do a two step process where you create every actor, then in a second run serialize the records on top.

[Ben Zeigler]

Hey everyone, glad you enjoyed the stream. I'm Ben, and I'm one of the tech leads on Fortnite. I thought I'd chime in with a bit of extra detail on a few of the questions Billy answered, I think he did he a pretty good job eh?

Question: How many physics objects do you have in a typical game scene? Do you do anything to speed up physics usage (i.e. consolidating objects, tweaking sleep states etc).

Fortnite scenes have a LOT of actors, but we don't really use Physics in the sense of doing proper Physics simulation. In this random scene I just opened up we have around 7000 building piece actors. As Billy mentioned most of our physical effects are done in shaders for optimization, and we use things like Projectiles (Shootergame has some good examples) for other things. We need to keep the state on the client and server tightly in sync, so we avoided using proper physics simulation.

Each of the building pieces (a wall, a floor, etc) is one actor, with one static mesh component so they stay really cheap. We use network dormancy to keep them cheap for replication, if you run the command SetNetDormancy you can put an actor to sleep for the networking system, and if you use SetActorTickEnabled you can put it to sleep for the tick system. Then, whenever the player interacts with a building piece we "wake them up" and spawn various additional components on demand. This keeps things cheap in the default case, but lets us make the entire game world interactive.

[MieszkoZ]

Hi Kain,

Can you go over the workflow for Navigation in terms of...
1) What options you have available for marking paths as walkable/unwalkable/walkable to some but not all

You can mark pieces of navmesh as "areas", either with volumes or by having navigation relevant actors supply appropriate data. Areas have flags and cost associated with them. Regarding cost you can override default navigation query filter to supply alternative area entering and traversal costs.

When supporting multiple agents types you can also consider using multiple navmesh instances.

2) Dynamic links, such as rotating bridges and elevators?

We do have a concept of "navigation link" which describes discrete traversable connections on navmesh (like jump-down location). Special subclass of these links, called "smart navigation links" (wink-wink) can be toggled on and off at runtime...

But that's not what you're asking Rotating bridges or elevators could be supported by simply rebuilding navmesh at runtime. Of course done when the bridge or elevator stops moving. Navigation on platforms at move is not supported at the moment, but I imagine the low hanging fruit solution would be similar to what we did in Bulletstorm where we simply had a separate navmesh instance hard-attached to the platform. No worries, super cheap memory-wise

3) Dynamic obstacles, such as moveable and destructable blockades?

Like Billy mentioned it's one of the things that's happening all the time in Fortnite. At the heart of our navmesh generation lies modified Recast library. Recast, for those that don't know (shame on you! ) is a fast-navmesh-generation open source lib. Our modifications made it even faster to the point where runtime building of big navmesh chunks is not a CPU killer, and Fortnite takes a full advantage of it.

How much of the navmesh workflow and featureset has changed from Unreal3?

Navigation system in UE4 has been created from scratch, to utilize new technologies and gain both speed and flexibility.

Are you still able to insert use own heuristic functions into the pathfinding mechanisms?

You can but not out of the box. You'd need to recompile Recast lib with navigation filter's cost function marked as virtual... But you probably don't really need that!

I found that really useful for "finding a position to shoot projectiles from when the player is off the navmesh".

We have a sophisticated, data driven system for spatial reasoning. Go ahead and look up Environment Tactical Querying in UE4 sources. It has lots of advantages over using goal evaluators and path constraints like UE3 did. Performance, flexibility and readability are the main ones.

I was wondering how much of my old UE3 usage patterns would remain the same in UE4.

None, to my knowledge. Which is not necessarily a bad thing

Cheers,
--mieszko

[gregdumb]

Thanks for all the awesome Q&A-ing guys. It's really nice that you aren't just leaving us to figure the engine out for ourselves, getting these tips straight from the devs is great. Looking forward to the next stream!

[FrankieV]

once again BORING seriously why isnt anyone listning to the fact that a livestream of the unreal engine should show actual ENGINE FOOTAGE!

Personally I found it all rather entertaining and the only thing that could have made it better would be

1) Women.
2) Zak after consuming vast amounts of alcohol

P.S. Women of course just to get the female perspective on gaming in general.

[Demolition Man]

Billy,
Thanks for the fireside chat last week! I just wanted to pass on to you that I have been doing some work with the folks over at Mixamo and they were very happy to hear Matthew's comments on their animation website. Simply put, it made their day! I can tell you that they are very interested in putting together animations or an anim set that works with the Unreal engine. If you or Matthew is interested I can give you a contact at Mixamo to help make this happen. Just send me a private message.

[MattyCakes]

Hey Demolition Man,
Thanks for the info. Yeah, I've already been working with the Mixamo crew. Exciting stuff coming down the pipe!

[hyperdr1ve]

Hey Ben,
Sorry this is a bit of a thread resurrection. I've been using the two step save/load mechanism that you describe and it has been working great the last few month. I noticed after the jump to 4.8 that when I serialize the records over top of my created actors as the final step that my dangling pointers no longer hook up correctly. Were there any changes that you guys had to make based on the thread safe Serialize effort that came with 4.8?