Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

  • #31
    ^^ Blizzard used Unity for Heartstone. Is that game considered AAA or not? I dunno. Regardless, it would be rather strange to claim C# will not be used in AAA games when it is already being heavily utilized in several titles
    Godz for UT '99 / UT 2003

    Comment


    • #32
      It won't be used for writing the actual engine. The game is another thing.

      Comment


      • #33
        Yep true. When I speak of managed languages (or rather any high level language) becoming more widely used I am thinking far into the future (basically, pure thoerycrafting). Defintely not within this decade. On Consoles, there are still a lot of assembly optimizations etc that folks were doing. At least- on 'current' gen for sure. I cannot speak on next gen at this time. We are still getting up to speed on those [edit- We meaning my studio I am employed at]
        Last edited by sandboxgod; 04-11-2014, 10:37 AM.
        Godz for UT '99 / UT 2003

        Comment


        • #34
          Originally posted by Jarhead View Post
          C# and C++ can perform equally well...
          No they can't.
          Please stop believing in fairy tales.

          Comment


          • #35
            Originally posted by Jarhead View Post
            C# and C++ can perform equally well
            People who belive in this are the once that can't grassp why so simple games like Minecraft or Fez have so high requirments and yell "opimize" at developers

            C++ compiles to direcly to CPU machine code it does not have manage code which makes you code easier in cost of prefermence. You cant go faster then that or else you create more optimal assebler code. I ammused that developer now days are so lazy and addicted to assist code that they start to discredit C++, where i belive C/C++ is first thing they should learn as this way you understand software a hell lot of better. When i first used c++ i felt free like a bird.

            Also small reminder.... Unreal Engine always had C++ coding since very begining, with *.u file you could also see associated *.dll file, but it was not avable to nonlicence users... until this point (or rether licence become cheaper). If you wonder why licenced developers could do more with UE thats a reason, they could do call to even deepest point of engine, could implement external code liberies and so on. Epic states that Blueprint is what replace UnrealScript, and give access to C++ so things fit perfecly
            Last edited by Shadowriver; 04-11-2014, 01:39 PM.
            =========
            My Tutorials:
            Basic knowledge about Classes and UObject environment and stuff like that

            Comment


            • #36
              I really think that if this thread is going to continue in this direction it needs to be locked. It's all downhill from here. OP got way more than he bargained for.

              Why C++ for Unreal Engine 4? In short, performance and portability concerns mean the core of the engine is going to be written in C++. The original question could alternatively be interpreted as "why was UnrealScript removed, and not replaced with something like C# for quickly iterating on game logic?" That would be a better discussion to have, but that's not the discussion that's occurring here.

              What we have arrived at instead is a C++ vs C# argument that is indistinguishable from billions of others that echo throughout the internet, and is not constructive. Ultimately, for most people, that choice comes down to personal preference, and no one here is likely to change anyone else's mind.
              Last edited by Neverender; 04-11-2014, 02:08 PM. Reason: Made language more neutral

              Comment


              • #37
                The first three generations of the Unreal Engine included a sandboxed scripting language, UnrealScript, which provided a simple interface for gameplay programming that was shielded from the complexity of the C++ engine.

                The scripting approach is very welcoming to new programmers, but eventually it breaks down and becomes an obstacle to innovation and shipping. We experienced this over time as the Unreal Engine grew until finally, in 2011, we moved to a pure C++ architecture. The causative factors were both pervasive and general:

                - As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.

                - As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or "interop" layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.

                - Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.

                - Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can't trace the C++ that code led to it, and vice-versa.

                It is these reasons, ultimately, that led to Epic's move to pure C++. And the benefits are numerous: UE4 is a unified and fully-debuggable code base, freed from Interop Hell and totally open to programmers to study, modify, and extend. There are side-benefits, too, such as increased performance in gameplay code, and ease of integrating other middleware written in C++.

                Building Unreal Engine 4 as a unified C++ codebase has been very freeing, giving engine and gameplay programmers enormous flexibility to write code without unnecessary interop barriers.

                This isn't to say that C++ is the ideal language for simple gameplay code. It is more complex and more dangerous than UnrealScript, C#, and JavaScript. But that is another way of saying that it's more powerful.

                By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish, whether it involves debugging your entire codebase in-context, interfacing to low-level engine systems, modifying them, or talking to the operating system or advanced third-party libraries.

                Comment


                • #38
                  Originally posted by Tim Sweeney View Post
                  The first three generations of the Unreal Engine included a sandboxed scripting language, UnrealScript, which provided a simple interface for gameplay programming that was shielded from the complexity of the C++ engine.

                  The scripting approach is very welcoming to new programmers, but eventually it breaks down and becomes an obstacle to innovation and shipping. We experienced this over time as the Unreal Engine grew until finally, in 2011, we moved to a pure C++ architecture. The causative factors were both pervasive and general:

                  - As an engine and its community grows, there is increasing pressure to expose more of the its native C++ features to the scripting environment. What starts out as a sandbox full of toys eventually grows into a desert of complexity and duplication.

                  - As the script interface expands, there is a seemingly exponential increase in the cost and complexity of its interoperability or "interop" layer where C++ and script code communicate through a multi-language interface for calling functions and marshaling data. Interop becomes very tricky for advanced data types such as containers where standard scripting-language idioms differ greatly in representation and semantics from their templated C++ counterparts.

                  - Developers seeking to take advantage of the engine's native C++ features end up dividing their code unnaturally between the script world and the C++ world, with significant development time lost in this Interop Hell.

                  - Developers need to look at program behavior holistically, but quickly find that script debugging tools and C++ debugging tools are separate and incompatible. Seeing where script code had gone wrong is of little value if you can't trace the C++ that code led to it, and vice-versa.

                  It is these reasons, ultimately, that led to Epic's move to pure C++. And the benefits are numerous: UE4 is a unified and fully-debuggable code base, freed from Interop Hell and totally open to programmers to study, modify, and extend. There are side-benefits, too, such as increased performance in gameplay code, and ease of integrating other middleware written in C++.

                  Building Unreal Engine 4 as a unified C++ codebase has been very freeing, giving engine and gameplay programmers enormous flexibility to write code without unnecessary interop barriers.

                  This isn't to say that C++ is the ideal language for simple gameplay code. It is more complex and more dangerous than UnrealScript, C#, and JavaScript. But that is another way of saying that it's more powerful.

                  By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish, whether it involves debugging your entire codebase in-context, interfacing to low-level engine systems, modifying them, or talking to the operating system or advanced third-party libraries.
                  Thanks for taking the time to post Tim, it is appreciated. A long time C++ coder myself, I can only agree with maintainability.

                  The seas are a bit rough right now with the engine, and Slate being somewhat of a major weakness. However, by opening up the engine, and seeing that Epic is being very attentive to the developer community, things will improve, and I can only see success going forward.
                  Dejan Macesic, ing., MBA | Founder | Base64 Inc.

                  It is by will alone I set my code in motion.
                  It is by coding that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning.
                  It is by will alone I set my code in motion.

                  Comment


                  • #39
                    The Words of Wisdom from Tim Sweeney himself ! Still am thankful for you and the hundreds of developers for this powerful and beautiful engine!
                    Portfolio/Tutorials: http://chadreddick.com

                    Comment


                    • #40
                      Thanks for posting Tim! It is great to read how things went from your point of view. Way back in Unreal Tournament days while working on my mods I always wanted more and more access to the internals. Eventually I got my wish when I got my first job in the industry. I don't think any of that would have ever happened without Unreal. Such happy times. Still talk to a friend I made from my first publically released mod (we lived in the same city at one point too!)
                      Last edited by sandboxgod; 04-11-2014, 03:03 PM. Reason: removed mention of UT mods (felt a little spammy)
                      Godz for UT '99 / UT 2003

                      Comment


                      • #41
                        Originally posted by Shadowriver View Post
                        When i first used c++ i felt free like a bird.
                        This. C++ made me feel empowered to tackle anything (within my far more limited scope than a AAA big name studio coder for sure but nonetheless).

                        Comment


                        • #42
                          When i first used c++ i felt free like a bird.
                          Couldn't agree more.

                          Comment


                          • #43
                            c++ vs .net managed (c# etc etc)

                            .net is created by Microsoft, and they are not well known for making things cross-platform. This results in your code being Windows only without the possibility of converting it to cross platform if you wish to do so. So that rules out mac and Linux for example.

                            C++ is used by most platforms, this means you can make your code cross platform without to much work, of course there are api functions that are platform specific but its much easier adding a couple of #if statements then re-writing the whole of your code into a different language.

                            Your .net application gets processed via a middle man (the best way I can describe it with out going to technical)
                            c++ gets compiled to assembly - the closest readable language before it gets processed.
                            This results in a speed difference, dependant on the software depends on how much.

                            Im trying my hardest to write this without making it an Anti-Microsoft tant so im going to keep it short.

                            .Net is way to reversible.
                            .Net is slower
                            .Net is not multi-platform friendly
                            .Net is bloated

                            a down side to c++?
                            Its not as easy to learn compared to the .net languages.

                            just my opinions
                            cheers

                            Comment


                            • #44
                              Greetings MinionPhil. Check out Mono C# which is multi-platform

                              Some guys are also trying to integrate Mono into Unreal. See this thread.
                              Godz for UT '99 / UT 2003

                              Comment


                              • #45
                                Hi sandboxgod,

                                Yea Iv seen mono before, I seen it years ago for running asp.net websites on a Linux server.
                                To be honest iv never actually tested mono to see how it performs.

                                So with that, This could be a unity issue, mono issue, or just the game developers issue.
                                For background reasons, I am a local memory hacker, tho the reason I am here on UE is im teaching myself how to develop games not for hacking purposes.
                                The game im going to talk about is the only game I know that is MP only and uses the unity engine.
                                This game has one big problem when it comes to hackers, what we do is simply edit the .net dll's to manipulate the game, no hooking, no debugging, no working out functions in assembly, it also meant that we could reverse the source to pretty much 100% usable source - this resulted in the end user being able to change things like the user id to stop them being able to be banned. Un-Ban able hackers? its destroying this game.

                                Performance:
                                The network for this game because everything is wrapped in .net has made its network performance slow, its made a simple network communication jump all over the place before actually being sent - when I debugged the game - it literally jumped via the .net framework and then to Winsock without the data actually being modified.

                                But like I said this could have 3 points to blame, it could be any - Only real way to find out is to have the source

                                Im not dead set against the .net languages, I just have a big problem with it for games. For standard windows applications it has got nice widget library's that make it very simple to create native styled applications as well as custom styled application.

                                If UE was to go .net I Personally think they are going to open more doors people want to shut then doors people want open.

                                Comment

                                Working...
                                X