Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Originally posted by Tim Sweeney View Post
    We plan to moderate pretty lightly here. I don't expect we'll close threads unless they turn into flame wars or 4chan.
    Which is fine, but when a thread keeps going around in circles and we keep repeating ourselves it would seem that a thread has run it's course and is better preserved by just being locked.

    Comment


      Fortnight source - a snowball's chance in hell?

      Originally posted by Ben Zeigler View Post
      MonsOlympus has some good questions from the last page, so I thought I'd describe how Fortnite is mixing C++ and Blueprints. Here's an example class hierarchy for one of our enemies:

      ...

      If anyone has specific questions about to set up a hierarchy, ask away and I'll reply. As an example, Mons I'm not entirely sure what you meant by "I might encounter the need to have C++ Blueprint dependencies like Archetypes and Id prefer not have those hard links between external and internal classes". What specific pattern are you trying to avoid?
      Hey Ben, Tim, fellow UE4 developers & enthusiasts,

      I know this is a stretch, but I have to ask: If Fortnite is to be a free-to-play game (not sure where I heard that, was it twitch.tv?) has Epic considered releasing the game source to the developer community? I'm studying the engine source & samples as time permits (translation: not enough) and it certainly would be great to study a hard-core, real-world example implementation by the guys who wrote the engine. And perhaps in the future open the game up to developer contributions? Naaw, that's going just too far!

      Yeah, I know the chances of this are lower than a cross-map headshot over a 300 baud modem, but I had to ask...

      Comment


        I usually stay out of the religious programming-language wars, but I guess I just cant resist adding my perspective to the pile:

        Back when I was actually paid to develop games (in the Unreal 1 days) one of my primary tasks was to merge our game's codebase with Epic's engine update code-drops and resolve the issues as they arose. Initially it was pretty difficult since 3-way diff & merge tools were pretty primitive (egads, did we actually use MS SourceSafe back then?) and our group of green developers were pretty liberal about breaking all the rules. But pretty quickly we learned thru painful experience to absolutely minimize our C++ side engine mods, basically just insert a few hooks where we needed them, and keep as much as we could in UnrealScript. It was a pretty educational experience watching the engine evolve from release to release, although the process never became what I'd call routine.

        UE1 was the first really large source code base I worked on, and it all was a good exercise in understanding those linkage vs. cohesion issues my CSC professors were always talking about. The code eventually evolved into a nice, clean separation of engine from game code, defined by a formal API. I'd be the last on the list to lament UnrealScript's demise, even though it was pretty good. But what concerns me now about a 100% C++ engine is that developers are going to start to subclass from random classes, make strange coding mistakes, and generally make a mess of things just like we did back in the day. But they will, it will work, and they'll ship their game that way. Until unintentionally breaking changes are released by Epic. But now the separation between game and engine are blurred (for very good reasons, I agree). This will force Epic at some point to either freeze their code-base at some level due to compatibility-breaking changes (the removal of UnrealScript is a good example) or go into backwards-compatibility regression testing hell (aka become Microsoft).

        If that wasn't clear (it wasn't) in other words, this API provided a nice division that's been lost which back in the days was:
        1. Write your code in UnrealScript wherever possible
        2. If you need your own C/C++ functionality, try to implement it in a separate DLL
        3. If you need to mod the engine, be willing to be responsible for maintaining that mod and merging it into code-drops indefinitely.

        These rules sure saved our bacon when I was told to merge the latest (and really big) code drop, a week before we went gold!! I'm sure that Epic will do everything they reasonably can to not dump breaking interface/behavior changes on us, but now that the line is much more fuzzy (complex) I'm not sure what the new rules are.

        All this being said, take the above with a grain of salt - as I think I mentioned I haven't done any serious UE development in over a decade and am now just getting to know the new engine (and it's getting pretty late), so I could very likely be wrong about the current state of affairs. Heck, I'm still trying to get my head around Blueprints!

        Comment


          Originally posted by ->Dave.G View Post
          If Fortnite is to be a free-to-play game (not sure where I heard that, was it twitch.tv?) has Epic considered releasing the game source to the developer community?
          That's a really interesting/crazy idea! We'll think further about whether any future Fortnite mod plans could eventually include source code as a long-term component.

          Originally posted by ->Dave.G View Post
          Back when I was actually paid to develop games (in the Unreal 1 days) one of my primary tasks was to merge our game's codebase with Epic's engine update code-drops and resolve the issues as they arose... I'm not sure what the new rules are.
          Generally, code residing in separate modules will be more resilient to future changes than direct modifications of Unreal Engine code, and gameplay code will be more resilient than other systems.

          Compared to the Unreal Engine 1-3 days, now GitHub provides an efficient mechanism for code changes to be submitted to Epic requesting incorporation in the mainline code base. This may change the dynamics of development. If, in the course of building a mostly-modular game, a programmer makes some well thought-out changes to existing code, we'll be happy to consider integrating them through a GitHub pull request.

          Comment


            Originally posted by smallB View Post
            C# on the other hands has memory leaks and you simply have no control over them. C++ gives you power. With that power comes responsibility.
            And you know it is not that it is easier to write non - leaking programs in C#/Java - simple example, file management:
            In C++ if you use memory management technique called CADRe or RAII - (Constructor Acquires Destructor Releases ) then you put opening file code in constructor, releasing that file to memory in destructor and your done. No more worrying. In C#/Java you have to actually manually close every file you've opened. So how is this for easy / hard.
            And guys, don't fool yourself that working with C#/Java is easier than with C++.
            It is like with toy tools and real tools really. It is much easier to build castle from sand than real castle but after the work mounts up, you realize that only real castle is actually livable. The sand one is unusable.
            C# destroyed Visual Studio. Once my beloved IDE, now I simply cannot look at it.
            No offense buddy but you don't have much of a clue what you're talking about and you shouldn't try to give people false information if you don't have the knowledge or experience to back it up. C# doesn't inherently have memory leaks. Memory leaks can be found definitely within a couple of classes within the .NET Framework but they are pretty rare. If you get memory leaks in your code, it's because you are not disposing of the native unmanaged memory properly and is usually caused from programmers not keeping track of the memory.

            Also, the misconception that in C# you have no control of your memory is complete BS. You can do a lot of self memory management in C# that negates the GC, and not too mention you can go unsafe and use C++ pointer references and even call into low-level kernel calls so it's more than doable for people who want more control of their memory within C#.

            In C++, you still also have to manage file IO the same exact way. Just because you are using mechanisms that allows you to easily open a file in your constructor while it manages the memory and close it out in your destructor doesn't mean the same concepts don't apply for opening the file and self-managing it from a basic standpoint. The only difference here is you having it auto manage the memory for you instead of you doing the manual memory management yourself. Look at any beginner C++ File IO tutorial out there and you'll understand what I am talking about.

            Now in C#, you could even do the following...

            using (var MyFile = File.OpenRead(...))
            {
            // Do some code like read or write to your file here
            }

            By doing it this way, you are managing the memory of the file automatically by using a "using" statement that disposes of the file after it leaves scope. So its even easier to do in C# and less lines of code than C++. And two more things about File IO is that if you chose to negate the "using" statement, all you need to do is call.... MyFile.Close(); That's it, not too hard for anyone at all But also the second thing is not in every case are you going to want to have the file open in the constructor and close it during the dispose call. Unless you absolutely need to keep the file handle open for the lifetime of the class and there is a purpose to keeping it around, then it's bad practice to do that.

            I've been developing for over 25 years and in over 15 different languages and to say C# is a toy language and not easier than C++ is I can only say one helluva pretty ignorant statement and quite laughable. Now don't get me wrong, out of every language I've ever used, C++ to this day is still the best when it comes to achieving performance if you want that raw low-level access. However, C# is completely a much easier and more elegant programming language than C++ ever was and is much easier to pick up quicker as a starting point then throwing someone into C++ initially as a beginner. And C# is used professionally for a lot more than tools these days. Even in the company I left recently, I would do a lot of our software in C# for them and even a lot of HLSL, OpenCV and advanced CV algorithms while in C#. I'd sometimes do these instead in C++ if I needed that extra ability to optimize the performance but it definitely wasn't the case all the time and it sure as hell didn't make our software any less unprofessional.

            Originally posted by smallB View Post
            It is like with toy tools and real tools really. It is much easier to build castle from sand than real castle but after the work mounts up, you realize that only real castle is actually livable. The sand one is unusable.
            C# destroyed Visual Studio. Once my beloved IDE, now I simply cannot look at it.
            (...Blank Stare...) You're kidding me right?! I don't think you even understand what you just said. Now all joking aside, if you are referring to how the dev environment is setup, you can change it so that C# is not your default dev environment in VS and C++ is. If that's not what you meant, then you aren't making any sense as C#'s integration into VS doesn't have any affect on the IDE in a negative way or in any if you are coding in C++. You do realize there is option when you install to "Not install Visual C#"... when you install Visual Studio?

            I would say to anyone out there thinking about becoming a serious programmer and about using UE4 to create your next big game, don't worry if you choose to start with something like C#. It's much easier to pick up than C++ and will help you get the basic fundamentals of programming down. Get a couple example apps running and when you feel ready, transition over and start learning C++. Buy books and use resources like Google and YouTube as much as you can as there is a lot of great tutorials out there on C++. Chances are, if you are dealing with a problem in code, there is a good chance that someone has and not only documented it, but teamed up with a forum community to solve the issue.

            Also, Blueprints get compiled down so they are just as performant as C++ and will probably be even easier for anyone new to get started with. Just beware, that you can still create un-optimized code based on how you wire everything together so continue to learning the basics of programming and how to optimize your code and what that means to your application. Create little example apps so you are understanding basic concepts and practices then move on when you are ready to rock.

            I get that C++ is a much more difficult but once you master it, you'll be able to do practically anything but as a starting point, stick with the Blueprints and good luck
            Last edited by MC Stryker; 04-23-2014, 05:11 PM.

            Comment


              Originally posted by iniside View Post
              Gratz. You pretty much described every possible programming language in existence. Maybe with exception of assembler. (;.
              I am programmer since ZX81 times, I know every programming language is about same, you just use different keywords, every loop is mutation of checking condition and jump (because how assembler works).
              And everything gets to asm level soon or later.

              And blueprints are best invention since sliced bread. Really! Editor slapping my wrists when i try multiply text string by 5 is something that helps to learn faster.

              edit:
              I had not enough of force in me to learn unreal script, but now its totally different story with unreal 4

              also ++! to this:
              Originally posted by MC Stryker View Post
              as a starting point, stick with the Blueprints and good luck
              Last edited by Nawrot; 04-24-2014, 05:00 PM.

              Comment


                I found this thread by coindence. Though I am a game server programmer, I have ideas about this thread.

                Here is a score starting from zero. I will increase value to the score for oppotunity of using C++, or decrease it for drawback of using C++.

                C++ is faster: +10. It is known that C++ is not so faster than script language, because script runtime has optimized JIT/AOT compiler. (However, in average, C++ is 30~70% faster in my experience.) Processing game logic takes <20% of total time so scripting is enough. But in engine core world, C++ is mandatory because of the incomparable speed. For example, P/Invoke for complex parameters of Direct3D render state functions is a hell.
                So far, the score is 10.

                C++ is harder to develop: -100. Although the most language I still use is C++, it is devil's language. It disappears some of programmer's life. C++ has no reflection functionality, cumbersome for accessing metadata of data types, awkard smart pointers. Lambda expression? Get lost. C++11 is just following other languages. C++ programmers does not need Pomodoro Technique. Executing compilation itself is five minute rest. C++ with boost library is lacks compared to C# basic library.
                So far, the score is -90.

                C++ makes no frame rate hiccup: +10. Realtime apps such as games treats frame rate as important, as well as its equality. Script languages is followed by garbage collection aka. GC. For example, Java and C# GC runs in stop-the-world manner, which consequences frame rate hiccup. (A disgression: A game server processes many players, but does not for rendering. So game logic processing takes major time in server. Stop-the-world by GC itself causes latency hiccup, so that is why game server for latency-sensitive games are written most in C++.)
                So far, -80.

                C++ has no clue between different languages: +50. Developing a game program whose goal is high and wide sometimes encounters limit of script language. For example, there is a need to import C++ auxiliary module. Once this situation occurs, a clue code between two different languages is unavoidable, and this is a sh** to performance and maintanance. Those who worked with P/Invoke, C++/CLI or UnrealScript Native Binding will understand what I mean. Due to its bottleneck, it even affects program design. For resolving this problem from the scratch, engine itself should be written in C++, but the train has already left.
                So far, -30.

                Script has thicker layer: +10 for small projects, +100 for larger projects. Thickness of layer is a double-edged sword. We have no way but to wait until people who treat other layers resolve the problem. The more layer thick, the longer to find the cause of the problem. Let me show one example. One of game engines affords C# script environment, and its base is Mono. We found that BeginSend() in iPhone4 affects frame rate seriously. We looked in the source code of Mono and found that its base was implemented in very alternative way to meet up to the requirement of Microsoft .Net framework implementation, but it works not so nicely. Nevertheless, people developing Mono are magician. For the workaround, we chose other way not to use BeginSend() but it throws many System.Exception, but it is even faster. The root resolution is to modify Mono by ourselves and contribute it to Mono community, but it would have taken much more days. Thicker layer gives efficiency to development for earlier stages, but it sometimes conceals problems, but it appears more annoyingly on later stages. Needless to say that thicker layer takes more memory, which sometimes crucial on mobile devices. In short, thinner layer is like a insurance.
                So far, -20 for small projects or +70 for larger projects.

                Conclusion: Anyway, negative score for small projects (What am I speaking?) In overall, C++ has pros than cons for commercial development projects.
                Last edited by nettention; 04-25-2014, 08:39 PM.

                Comment


                  Originally posted by Devlin Kain View Post
                  I was just curious, why did Unreal 4 decide to go with C++? I know Unity is in C#, and a lot of other games utilize C# as well as javascript. I was just curious, new programmer on engines here, only about a year and a half/2 years in, so go easy!

                  Dev
                  C# only runs in the .Net framework (Windows) and C++ runs on all operating systems. C++ runs better and you can do more with it than C#. Overall C++ is better than C#.

                  Comment


                    Originally posted by trdwll View Post
                    C# only runs in the .Net framework (Windows) and C++ runs on all operating systems. C++ runs better and you can do more with it than C#. Overall C++ is better than C#.
                    That's wrong. It doesn't need .Net. You can use for example mono and run it on whatever you like.

                    Comment


                      Originally posted by Cube2222 View Post
                      That's wrong. It doesn't need .Net. You can use for example mono and run it on whatever you like.
                      If i were EPIC, and i would need to implement a scripting program, i would add something like Python or Java instead of C#
                      UDK and UE4 programmer and Unreal engine 4 betatester. Currently working on commercial VR games for PSVR.
                      Deep knowlegde of C++ and blueprints. Open to freelance work.
                      Games released, Deathwave(Steam), VRMultigames(Steam), DWVR(Steam,Oculus,PSVR):
                      http://store.steampowered.com/app/463870
                      http://store.steampowered.com/app/500360
                      http://store.steampowered.com/app/520750

                      Comment


                        Originally posted by vblanco View Post
                        If i were EPIC, and i would need to implement a scripting program, i would add something like Python or Java instead of C#
                        I never said I want c# , actually, in my opinion there isn't really a need for a scripting language as we have blueprints. And as we have c++, if someone really wants/needs it, he can implement it himself. My workflow for example got much faster in comparison to unrealscript with the change to c++ and blueprints.

                        Comment


                          Originally posted by MC Stryker View Post
                          (...Blank Stare...) You're kidding me right?! I don't think you even understand what you just said. Now all joking aside, if you are referring to how the dev environment is setup, you can change it so that C# is not your default dev environment in VS and C++ is. If that's not what you meant, then you aren't making any sense as C#'s integration into VS doesn't have any affect on the IDE in a negative way or in any if you are coding in C++. You do realize there is option when you install to "Not install Visual C#"... when you install Visual Studio?
                          He meant that new versions of VS are .NET applications and now it is much slower (intellisense...) and uses much more CPU and RAM compared to VS 2008 that was a C++ app.

                          ---------------------

                          I hate C#, nice language design but vendor lock-in into MS world (don't come with mono). The last place you want to be as a programmer (with a future). In the (big) business world it is mostly Java except in the USA where MS used their money to promote C# (paying schools and giving "good" deals to companies). And Java wins any benchmarks I know (by a wide margin).

                          But for game scripting there are better alternatives (LUA, AngelScript, Python,...). I did my own engine coding in C++, but still added a scripting layer. It's about productivity, use the right tool for each job.

                          I'm sure many AAA epic customers still add a scripting layer. You don't do all gameplay logic in the scripting layer, but for certain event based (so not per frame) things it is just more productive to have that layer.

                          It is smart of epic to not add a scripting layer, because everyone prefers another scripting language. And with the C++ API many different bindings will be created by the users anyway.
                          Last edited by Tarantula; 04-26-2014, 01:35 PM.

                          Comment


                            Originally posted by nettention View Post
                            Lambda expression? Get lost.
                            That made me laugh

                            Comment


                              I hate C#, nice language design but vendor lock-in into MS world (don't come with mono). The last place you want to be as a programmer (with a future). In the (big) business world it is mostly Java except in the USA where MS used their money to promote C# (paying schools and giving "good" deals to companies). And Java wins any benchmarks I know (by a wide margin).
                              But Unity produced lot of C# game developers.... thats why pople ask for C# and nothing else even thu theres wide selection
                              =========
                              My Tutorials:
                              Basic knowledge about Classes and UObject environment and stuff like that

                              Comment


                                Originally posted by Nawrot View Post
                                I am programmer since ZX81 times
                                Wow! Haha, you got started a good 7 years before I did. Never got to use that device but that is pretty awesome. In some ways, it's fond to think of the old tech and where everything started. I remember some of the old Orange-Black terminals that had the hard drives that were those huge cylinders that you had to rotate and lock into place and remember thinking that 32 Mb of RAM would be overkill. Lol, man how times have changed...

                                Originally posted by Nawrot View Post
                                I am programmer since ZX81 times, I know every programming language is about same, you just use different keywords, every loop is mutation of checking condition and jump (because how assembler works).
                                And everything gets to asm level soon or later.

                                And blueprints are best invention since sliced bread. Really! Editor slapping my wrists when i try multiply text string by 5 is something that helps to learn faster.

                                edit:
                                I had not enough of force in me to learn unreal script, but now its totally different story with unreal 4
                                I couldn't agree with you more. I was really skeptical about them at first thinking there is no way they are going to be as fast as raw C++ but the time that Epic spent getting the compiler in place is quite honestly amazing! It's the first time I've ever been able to experience Visual Node-Based Scripting that isn't a slow scripting extension. It's true visual programming as best as I've ever seen. They may seriously be on to something here because this is a new way of programming that is actually efficient and powerful. It has a very artistic quality about it and it's just the beginning for what they will do with it over the coming years.

                                In some ways, I think using C++ is a lot cluttered but I'm in love with Blueprints and the ease-of-use.

                                Originally posted by Nawrot View Post
                                also ++! to this:
                                Thanks Buddy!

                                Comment

                                Working...
                                X