No announcement yet.

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

  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by fighter5347 View Post
    I have one simple question. As I'm currently developing a open world game, it would be interesting to know how many verts your characters and especially the foliage has.
    Same here,
    All you can say about the problems encountered working with big open scenes in relation to UE4, If so, In what way solve these problems? advice would be welcome.


      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).


        What about split screen? Do you guys plan to provide some support for local coop games?

        Could you also describe whole Worlds mechanism? Why does GetWorld() function not always return game world while play testing in editor?
        Last edited by szyszek; 04-17-2014, 01:22 PM.


          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
          2) Dynamic links, such as rotating bridges and elevators?
          3) Dynamic obstacles, such as moveable and destructable blockades?

          How much of the navmesh workflow and featureset has changed from Unreal3?
          Are you still able to insert use own heuristic functions into the pathfinding mechanisms? I found that really useful for "finding a position to shoot projectiles from when the player is off the navmesh". I was wondering how much of my old UE3 usage patterns would remain the same in UE4.


            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?


              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.
                Last edited by KITATUS; 04-17-2014, 01:48 PM.
                "Information shouldn't be behind a paywall, It should be free for all!"


                  Originally posted by KitatusStudios View Post
                  Ah man, Did I miss it? :/
                  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.
                      Lead Programmer (Gameplay), Fortnite, Epic Games
                      Twitter: @EpicIrascible


                        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

                        Originally posted by gregdumb View Post
                        Did you use mostly C++ or Blueprints on Fortnite, was it 50/50, ...? What makes you decide where to use which?
                        Originally posted by iniside View Post
                        How do you guys plan, how to split gameplay elements between blueprints and C++. In other words how much of game mechnics is done in BP and how much in C++.
                        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.

                        Originally posted by xgalaxy View Post
                        During the development of Fortnite did you find a need to create new specialized blueprint functionality that didn't exist in the base engine? And if so, have any of these changes made it back into the base engine?
                        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.

                        Originally posted by xgalaxy View Post
                        Was there any point, during development, that you had to move functionality out of a blueprint and into C++, and why?
                        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? ) 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 James Golding mentions in this thread: , 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:

                        UI Questions
                        Originally posted by joessu View Post
                        Slate/UI: Do you guys use slate? If yes or no, How has UI Dev been in UE4? Any neat-o UI things you have for fortnite you are excited to talk about?
                        Originally posted by order66 View Post
                        What are you using for the HUD? Slate? Or some 3rd party extension like Scaleform?
                        Originally posted by Kain Shin View Post
                        How's the UI pipeline for UE4 compared to UE3? Are you using Scaleform on Fortnite? Is the workflow similar to UE3's workflow?
                        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
                        Originally posted by order66 View Post
                        - How did you achieve the "comic" look? Doesn't seem like you are using the PBR. Can you give a quick overview of the render pipeline?
                        Originally posted by fighter5347 View Post
                        I have one simple question. As I'm currently developing a open world game, it would be interesting to know how many verts your characters and especially the foliage has.
                        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.
                        Last edited by Irascible-; 04-19-2014, 06:37 PM.
                        Lead Programmer (Gameplay), Fortnite, Epic Games
                        Twitter: @EpicIrascible


                          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++.
                 - Action RPG Starter kit. Work in Progress. You can use it in whatever way you wish.


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


                              Originally posted by Evenios View Post
                              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;

                              Originally posted by Jacky View Post
                              You already have the engine in front of you and you will get the updates when they are released. You can brake and reverse engineer the stuff in demo's yourself but you cant get the information they talked about anywhere else. We have seen enough tech demos and developer walkthroughs, now it's time for the boring stuff.
                              Last edited by Jacky; 04-18-2014, 02:40 PM.
                              FREE Lightshow
                              FREE VR Drum Kit Project

                              FREE Color LUT Collection
                              FREE Physics Driven Spacecraft Project
                              FREE GTA Style Vehicle Interaction
                              Dynamic DoF(Depth of Field)
                              Camera Crossfade


                                Originally posted by Billy Bramer View Post
                                We had a ton of fun...maybe too much fun?
                                It was funny and informative at the same time. Good job