Engine Questions
My experience with networking has been really positive. UE4 and Fortnite both have driven optimizations and quality-of-life improvements in the networking space that have been great to work with. In UE3, if you had a struct you were networking and any part of it changed at all, the entire struct had to be replicated. In UE4, only the differences have to come across. UE4 also adds fast TArray replication, better support for multicast RPCs, etc. I think the engine does a really good job of letting gameplay developers setup their code and content in a way that works properly in a networked environment without having to worry about the low, low level of network/socket programming.
Specifically re: blueprints, I’ve been blown away by how the engine team was able to expose networking functionality directly to blueprints in a way that is fast and usable once you know the concepts. I actually just did a 6-part tutorial on doing networking in blueprints that you can check out here: https://forums.unrealengine/showthread.php?2956-New-Blueprint-Networking-Tutorial-Videos-Posted As mentioned in the stream, definitely want feedback on these, ways to improve, etc.
For Fortnite in particular, because we have so many actors at once that are potentially relevant from a networked standpoint (enemies, players, tons and tons of building pieces), we actually are also using a new network optimization called network dormancy, that effectively lets us manually put various actors to “sleep” and wake them up for updates in our game. That one is definitely more of an advanced feature and something that I would expect the vast majority of games to never need to even worry about, but it is another new thing in the networking space.
The documentation and engine team are hard at work at putting together the C++ documentation for all of these networking topics, so they should be coming soon. Once they’re out, if there are still questions or concerns re: C++ networking, hopefully we can follow-up and get some specific tutorials in that space too.
We effectively use a “vanilla” version. The relationship the engine and our game teams have is very symbiotic and one of my favorite parts of working at Epic. Ultimately having a game in active development in the engine is probably the best way to test out the engine and identify which areas are working really well, which need improvement, features that we need, etc. When the engine team adds a new feature or update, they immediately get it battle-tested by a full game team in-house. They can observe how our developers use (or mis-use :p) things, areas the workflow isn’t as fast as it should be, and so on. Fortnite’s development has yielded numerous feature requests/improvements that wouldn’t be obviously needed until a game team was using the tools directly.
From the game side, we benefit tremendously from being able to work directly with the engine team. They can help us optimize things, figure out the best ways we should be doing things, answer questions, add new engine features that would help our (and others’!) game development, etc. It’s very neat to be able to be like, “Hmm, I have a question about how engine feature X works…I’ll just go ask the person who wrote it!”
On Fortnite, any time we add a new large gameplay feature, we always try to view it through the lens of “is all of this feature specific to our game?” If not, we try to intentionally split stuff out that would be useful for other developers and work to get that put right back into the main engine. Fortnite has been pushing RPG-style mechanics more than past Epic titles, so as our systems develop and mature for that, we’ve been moving or requesting pieces to the engine (example: the CSV/spreadsheet importing stuff mentioned in the stream). We tend to integrate the main branch and Fortnite branch at least once a week, so anytime any Fortnite developer modifies something in the engine, it comes back to the main branch within a week or two.
We do not use archetypes and I’m pretty sure that system is gone (I admittedly haven’t gone looking for it, so I don’t want to say that with 100% confidence right this second). Blueprints have basically entirely replaced that workflow for us in an amazing way. Virtually every spawned actor in Fortnite is a blueprint based off of some native C++ classes we wrote. All of our building pieces, characters, containers, etc. are all blueprints. We basically try to not directly hard-reference content in C++ and instead set all of those properties up in the blueprints. If we need scripting associated with an actor, we can just add it in the blueprint event graph. If we change a property in the blueprint content, it propagates to instances out in the level. Because blueprints are effectively generating classes under the hood, we also benefit tremendously from blueprint inheritance, where we can base one blueprint off of another, just like you could with C++ classes.
This one is probably better answered by the engine team, but the basic gist behind it is better support for multiple worlds existing at once, which allows for a lot of flexibility and neat tools in the editor (like each asset sub-editor in the editor could have its own world). In UE3, there was a global GWorld pointer in code that tried to juggle the currently executing world, but that becomes error-prone and messy as more and more worlds exist. The engine team has actively been working to eliminate usages of that for its removal and GetWorld() is a way to access an actor’s associated world without using it. For any actor that is part of your game session, GetWorld() should be returning your game world, but there are multiple worlds active in the editor, so not every call to that function you see will explicitly be the game world. I’ll see if I can get someone else to come in and explain this better if I massacred it :).
I’m definitely not the best person to answer this one. I’ll see if I can summon the AI team to get you a reply, but I do know Fortnite is making heavy use of dynamic updates to the navmesh as players place building pieces and destroy tons of actors across the world.
This is another one out of my wheelhouse. Again will attempt to summon a more knowledgeable source instead of ruining this question answering it myself. Sorry!
Hmm, this one is a little tricky to answer, partially because I’m not quite sure what kind of details you’re asking for. Do you mean starting from scratch, how do you go about making a game? Or do you mean what is our workflow in regards to like importing art assets, setting them up, etc.?
The generic answer here is we tend to brainstorm/design up some ideas we want to try and then go about prototyping them. When it’s early and we don’t know if something is going to be successful or not, we just piece things together with the bare-minimum prototype assets necessary to convey the idea and get people testing it, so we can iterate on feedback. It doesn’t need to look good, it just needs to work enough that we can tell if we think it’s fun or not. If you’re starting at the very, very beginning, it’s really important that you test and iterate on whatever the core mechanic of your game is going to be and make sure it is solid/fun, because that’s the foundation everything else is built off of. There’s definitely a temptation to start adding tons of features, mechanics, shiny art, etc., but if the core mechanic can’t hold up, you’re going to run into problems down the road.
The really important part of making a game that people tend to ignore or don’t want to face is that you need to be willing to work really hard on a feature and throw it away when it’s not working. This is why we try to do prototypes without committing full art, effects, etc. when we can avoid it. The more resources devoted to something that gets thrown away, the more expensive it was to make. Sometimes you iterate on something a lot, try everything you can think of, but when you sit back and look at it, the feature just doesn’t work in the game for whatever reason. Maybe it’s just not fun, it’s too confusing, it doesn’t fit in with the rest of the game, etc. You need to be willing to toss it in the dumpster for the good of the game, which is something that takes getting used to, especially when you’re really invested in a particular feature.
When we have something we’re pretty sure is fun and want to move forward on, that’s usually when we start involving the art team. Depending on what it is, a concept artist might draw up what things should look like, send it off to a modeler to actually make in 3d, etc. We’ll hook the art up, make the code or script more solid and shippable, etc., and move on to the next thing.
If you’re meaning specifically how to start the framework of a game in UE4, that’s probably dependent on your team composition and size. For Fortnite, we have a good mix of artists, designers, programmers, etc., so we tend to split things up where it makes the most sense for us. Our engineers start making custom C++ classes based off of the engine framework ones (game mode, etc.), designers/artists might prototype out some things we might want to try in blueprints, etc. A smaller team w/o programmers might just opt to start things in blueprints. It really depends.
If you can clarify your question a bit, maybe I can give you a better answer instead of this rambling mess of answer :).
Cameron has also been fulfilling his promise of providing no updates on his newly formed twitter, so I admire his dedication to his cause.
) 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.