User Tag List

Page 1 of 15 12311 ... LastLast
Results 1 to 40 of 592

Thread: Why C++ for Unreal 4?

  1. #1
    0

    Why C++ for Unreal 4?

    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

  2. #2
    1
    I am pretty sure Unity is written in C++ actually. It provides it's users the choice of scripting languages, C#, JavaScript or Boo. But, you have to pay a lot to get a source license to the Unity Engine itself.

    UE4 has Blueprints for it's scripting environment built in. People in the community are making plugin's to add C# etc.

  3. #3
    0
    The Unity core is not written in C#, it's in C/C++, they exposed the public API via a C# wrapper. I don't have the latest benchmarks on just how much slower C# is than C++ these days, but with anything but a toy engine the performance hit you'd take by writing your entire engine core in C# is not going to be acceptable.

  4. #4
    0
    I'm glad they haven't layered on any other kind of 'scripting' - C++ is where it's at and my years of learning that won't go to waste. C++ is fast, and direct access to the source code is a dream come true for coders. Learning C++ was also rewarding (though I should point out I'm now rusty with it and I still had much to learn on more advanced topics even back 10 years ago when I wrote my own simple D3D8 engine before I tacked my own game engine onto Irrlicht).


    P.S I hate Javascript and C# doesn't do much for me either. I went from 'BASIC' (on the Amiga) to C++ (didn't even know 'C' before starting) and it wasn't too bad in the end. I figured if I'm going to spend years learning something I may as well shoot for the top of the tree (no, not assembly or machine code lol). With C++ I felt there was literally nothing I couldn't create, on a technical level, and knowing it was may more likely to run my code at far faster speeds than higher level languages was a massive incentive to roll my sleeves up and dig in. I became addicted to learning C++ as geeky as that may sound, I never felt that way about the other languages I've since dabbled with (which if anything I find frustrating for all their hand holding and so called ease of use)
    Last edited by Sharpfish; 04-12-2014 at 01:44 AM.

  5. #5
    0
    Infiltrator
    Join Date
    Apr 2014
    Posts
    10
    As already mentioned C++ is the base to add other languages like C#, Java,...
    Now you have different layers that you can choose for your preference and purposes

  6. #6
    1
    @Sharpfish
    I am totally with you.
    C++ is the language to go for if you are interested in:
    a) performance
    b) flexibility
    c) power
    d) finesse
    e) beauty - yes! it is beautiful language which so much possibilities that no other (current) language can compare or even come close to.

    And may I just say that gaming industry is the industry where every "tick" matters and C++ is simply unbeatable where it comes to performance.
    If someone asks me why do I prefer C++ over anything else I simply reply:
    If I have a choice between ferrari and ford fiesta and the likes why on earth would I choose anything but ferrari?
    And just to post short disclaimer:
    I'm not a language zealot, fanatic or kid who thinks only the toy he has is best. I am not looking to start any kind of "language war". On the contrary. I programmed in many languages apart from C++: C#, Java, Javascript, AS2, AS3, you name it, and after using all those languages for some time and being able to compare them with C++ my conclusion is this:
    No modern language compares favorably to C++, in any respect really. C++ is the most powerful, the most flexible modern language, and now after getting updates and hard work from ISO commitee and new C++14 update on horizon and another major update foreseen for 2017 this is simply the language every professional game programmer should go for.

  7. #7
    1
    This is awesome, thanks everyone for the information. Good to know all the C++ classes I have been taking in my Game Programming degree won't go to waste.

  8. #8
    0
    There is some great work happening by the community to bring Javascript and C# as scriptable languages to UE4.

  9. #9
    1
    The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.

    I do believe C# is the future going forward without a doubt. But for now, C++ is still king of performance and memory management. I think it's a great idea for the core of the engine to be written in C++ but game code can be higher level (byte code, etc)

    Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn't be debugged, couldn't rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol

  10. #10
    0
    Quote Originally Posted by sandboxgod View Post
    Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn't be debugged, couldn't rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol
    I wouldn't necessarily say that they went wrong with UnrealScript. It was a language that was a bit more straight forward than quite a few languages. Also because of UnrealScript, I was able to jump right into the C++ code quite comfortably. I would be quite lost if I didn't practice UnrealScript before UE4 came out.

  11. #11
    0
    Infiltrator
    Join Date
    Apr 2014
    Posts
    22
    I worked on a project where we had Unity source access, indeed it is written in C/C++.

    C++ is useful but having access to a scripting language would be nice. C# is a very nice language with very good features, javascript is also becoming the most popular programming language in the world (if it is not already) and I would seriously help bringing new talent onto a project.

    Ideally there should be some mechanism to use whatever scripting language you want beit LUA, Python or whatever.

    I disagree that C# is the "future" though - it's pretty much tied to Microsoft and we're seeing less MS popularity not more.

  12. #12
    0
    C# isn't tied to Microsoft. Unity for instance, uses Mono.

    And don't get me wrong, I got my modding start in UnrealScript as well with Unreal Tournament. However, back in those days Epic Games provided some C++ source as well. Mods could provide DLLs etc. And it wasn't gimped like the UDK version, the native DLLs were directly tied into the engine (unless my memory is failing me). I stopped modding somewhere around UT 2004 and went into games industry where we able to use a debugger with UnrealScript. But the community didn't get the debugger with UDK for whatever reason (only licenses).

  13. #13
    0
    Agree with all the things everyone said. I program in C++, C#, python and sometimes touch javascript, LUA and even assembler. There is no doubt that C++ is king for game programming languages and will stay that way for many moons to come. Generally garbage collection doesn't have the determinism needed to understand the performance required of game, robotics, or general real-time coding. If people are making C++ code that 'stomps' memory they need to work on becoming better coders. Especially in C++11 or with smart pointers using RAII such memory management is far more automatic than it was in the past, you shouldn't be dropping new's and delete's everywhere.

    I love the decision to go with C++ for many reasons: less of a divide between some "game code" and "engine code", a great world of tools to work with/test/debug C++, so many external libraries for niche hardware devices and sensors, bringing all the skills already learned along, and for new users the ability to use general (stackoverflow) information to understand language issues... I could go on

  14. #14
    0
    Quote Originally Posted by sandboxgod View Post
    The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.
    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.

  15. #15
    0
    Average studio these days utilize C# for Tools at the very least. Out of all the issues I've seen over the years in C# memory leaks has never been one of them

    Now I have seen some C# apps accumulate a lot of memory and then it becomes a little trickier to find out where the memory is going due to the lack of a sizeof operator on managed objects. For those cases I hookup a profiler to see where the allocations are going

  16. #16
    0
    Quote Originally Posted by CHADALAK1 View Post
    I wouldn't necessarily say that they went wrong with UnrealScript. It was a language that was a bit more straight forward than quite a few languages. Also because of UnrealScript, I was able to jump right into the C++ code quite comfortably. I would be quite lost if I didn't practice UnrealScript before UE4 came out.
    UnrealScript was the wrong choice indeed. It's slow (20x slower than C++) and C# is way more powerful. I wound't say that C# is the future of game programming, but its very good. I prefer C/C++ as a programming language, C# is the second best.

    The "easy" transition from UnrealScript to C++ is because they rely too much on their macros, which makes it very similar to UnrealScript.
    Dumont Studios - www.dumontstudios.com

  17. #17
    0
    Quote Originally Posted by sandboxgod View Post
    The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.

    I do believe C# is the future going forward without a doubt. But for now, C++ is still king of performance and memory management. I think it's a great idea for the core of the engine to be written in C++ but game code can be higher level (byte code, etc)

    Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn't be debugged, couldn't rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol
    Well, there is garbage collection for Unreal C++, which essentially solves memory management issues. Or at least doesn't make it any harder than any of other languages with garbage collection.

    Most daunting thing in C++ are pointers. It's sometimes wery hard to decide whether something should access trough pointer or just directly (whatever it is properly called). I guess for seasoned C++ programmers is no brainer. But for everyone else, even if they understand concept, it still might be hard call to make, which can lead to issues like "why it compiles and does not provide results I expected".

    Other than that I don't really consider C++ to be much harder than any other language. I would call some of it's elements to be annoying to say at least. Like headers or macros.

    UPROPERTY() could be solved in more elegant way in C# by using attributes [Attribute], but to make C# implementation on pair you would need ability to compile C# to native code. Which... Was shown on BUILD recently .NET Native. Though it is not multi platform, so it is not solution either.

    I honestly don't see a reason to use managed languages or worse dynamic interpreted languages.
    What we need is native language with manual memory management and garbage collection. Which... As matter of fact exists. Like D, or M# (this is bit of convoluted by Microsoft worked on something that should replace C++, for native programming).

    The "easy" transition from UnrealScript to C++ is because they rely too much on their macros, which makes it very similar to UnrealScript.
    Well nothing really wrong with that. If you tried to code game in CryEngine, where they don't use macros, custom compilation tool-chain and rely on STL, you would now build altar, temple and shrine to Epic Coders who invented this entire thing, and you would make sacrifices every day to thank them .
    Last edited by iniside; 04-10-2014 at 12:26 PM.

  18. #18
    0
    Quote Originally Posted by iniside View Post
    ...

    Well nothing really wrong with that. If you tried to code game in CryEngine, where they don't use macros, custom compilation tool-chain and rely on STL, you would now build altar, temple and shrine to Epic Coders who invented this entire thing, and you would make sacrifices every day to thank them .
    I never said that there is a problem with macros, I was just point out the reason for the easy transition from UnrealScript. I'm fundamentally a C/C++ programmer, so none of that scares me.
    Dumont Studios - www.dumontstudios.com

  19. #19
    0
    Quote Originally Posted by sandboxgod View Post
    Average studio these days utilize C# for Tools at the very least.
    We are talking games here not tools. It does no harm for word editor to be written in C# (although Office is C++). On the other hand it does damage for game. And as I've said previously. C# isn't even good for IDE. Visual Studio since they went with C++ is slow and very hard to work with large code bases.
    Anyhow...
    I definitely stick with C++.

  20. #20
    0
    Like many, I've worked with C# in Unity in my spare time. Memory leaks is not something you find discussed on their forums. Was never an issue for my game there (I've been registered at Unity forums quite awhile under this same handle)

    [edit] I just searched their forums right fast and all the posts under that topic appear to be many years old
    Last edited by sandboxgod; 04-10-2014 at 02:46 PM.

  21. #21
    0
    C++ has been one of the best low-level coding languages for a long, long time. The compiled code runs efficiently and performance is hard to beat. Since it has been around longer than C#, C++ has been the core language for serious pro coders for a long time. With that said, what Epic is doing is catering to the upper echelon of serious programmers who probably have deeper skillsets and experience than do those who only code in C# or Javascript. That's not to say that the latter two are bad, they're fantastic languages, but C++ is the king of the pack. I've coded in all of them, and many others, and for serious game development, I'd do all my core game coding in C++.

    Just my $.02.

  22. #22
    0
    I don't think Unrealscript was ever the wrong choice because it originated from Unreal Engine 1. It wasn't a system designed for Unreal Engine 3...

  23. #23
    0
    UnrealScript was rough back then too. Sure it gave us a nice 'sandbox' environment. But we couldn't debug. Couldn't rapid prototype. Took quite awhile to compile

    I see these threads complaining about 2 min compiles and intellisense not working. Really? We had no IDE period back then and I am pretty sure compiling Unrealscript took awhile back then. And oh yeah, restarting UnrealEd....

    * State based programming and replication blocks were very nice tho. So were delegates, etc when they were added. Nice language it was.
    Last edited by sandboxgod; 04-10-2014 at 06:46 PM.

  24. #24
    0
    Veteran
    Join Date
    Mar 2014
    Posts
    453
    Coming from a Java/C# background a lot of these posts seems misinformed on how programmers who never Learned C++ looks at this monolith of a language.

    C++, while technically not that much harder to learn syntax-wise than the above-mentioned gives you SO MUCH POWER that it's intimidating like crazy.
    I've tried to do C++ from time to time but every single time I run into the problem of Pointers. I understand what a pointer is. I understand what a pointer is supposed to do. But I have no idea when to use one and I have yet to find a definitive explanation that says "These are the scenarios dum dum".

    All they do is tell you what a pointer is, how to access the data from a pointer and also how to get the address of a pointer. But other than that? Good luck!
    I have no idea where to start or where to end when I start on a C++ file. I have the header file which is an infuriating system to begin with (function prototyping? Seriously?) and then I have to match my cpp file with the header file and even if you manage that, good luck trying to understand any of the garbage debugging message it spits out at you which might even be a downright lie. I realize that other languages can lie to you as well during errors but at least most managed languages seems to remember that it's humans who code these programs and not electric engineers.

    And then there is the issue of mixed C and C++. Half the time I can't tell when it goes between the two, but even following books to the letter and posting about it on Stackoverflow reveals that even those books lie to you and have the approach of mixed C and C++ syntax.
    I would love to see D get the spotlight over C++ because in D it's at least build from the ground up as language that supports Objects and Data instead of a tagged on addition that is C++, the superset of C.

    Also in D you can write in-line assembly code, use all previous C code still and even in the memory management department you have options.

    * Garbage Collector
    * Partially Garbage Collector / Partially Manual
    * Completely manual
    * Define Blocks in Memory that are off-limits to the Garbage Collector

    You can have the best of all worlds.
    I love C# and Java languages. They are so d@mn easy to comprehend and the talk about memory leaks is absurd. I have not found anything on that other than age old articles . I don't say switching to C++ was a bad choice as I am convinced it was going to happen regardless, but I find it quite upsetting that there are not other options (Yes Blueprint but lets face it that gets tedious very fast).
    Last edited by Vipar; 04-10-2014 at 07:01 PM.

  25. #25
    0
    C++ is great language for epic things like UE4. And the whole engine is now extandable. You can use even V8 now, if you want to write a code so much. If you're not familiar with cpp you can possible create the whole game using blueprints, and that's really cool


    P.S. - Unreal Script was "easier", but not so flexible. And we have to use it because of old Kismet limits, now we can make games, not code.

  26. #26
    0
    The Rainbow Warrior



    Join Date
    Mar 2014
    Posts
    2,594
    Quote Originally Posted by Vipar View Post
    Coming from a Java/C# background a lot of these posts seems misinformed on how programmers who never Learned C++ looks at this monolith of a language.

    C++, while technically not that much harder to learn syntax-wise than the above-mentioned gives you SO MUCH POWER that it's intimidating like crazy.
    I've tried to do C++ from time to time but every single time I run into the problem of Pointers. I understand what a pointer is. I understand what a pointer is supposed to do. But I have no idea when to use one and I have yet to find a definitive explanation that says "These are the scenarios dum dum".

    All they do is tell you what a pointer is, how to access the data from a pointer and also how to get the address of a pointer. But other than that? Good luck!
    Dear Vipar,

    I did my best to provide a very inventive explanation of pointers and how they work and when to use them and why they are awesome here:

    I am linking you to my subsection on "Why Use a Pointer?" as per your quote above, since my article strives to specifically expand on this topic beyond just the basics.

    Why Use A Pointer?
    https://wiki.unrealengine.com/Entry_Level_Guide_to_UE4_C%2B%2B#Why_Use_a_Pointer.3F

    Please let me know if it helps!


    I first introduce the concept of pointers here:
    https://wiki.unrealengine.com/Entry_Level_Guide_to_UE4_C%2B%2B#What_are_-.3E.2C_..2C_::


    Again I tried to be very innovative with my explanations.

    Enjoy!

    (I am posting this for any other readers to enjoy as well)

    Rama
    Last edited by Rama; 04-10-2014 at 08:09 PM.
    100+ UE4 C++ Tutorials on the UE4 Code Wiki, including UE4 Multi-Threading!

    UE4 Marketplace: Melee Weapon Plugin & Compressed Binary Save System Plugin | Rama's C++ AI Jumping Videos | Vertex Snap Editor Plugin

    Visit www.ue4code.com to see lots of videos about my C++ Creations! ♥ Rama

  27. #27
    0
    GAH! Pointers, the one thing that wracked my brain in C++ classes. Pointing to memory addresses, changing them on the fly and reallocating the memory to be called a different variable..

    ....O_O. I WILL be reading and watching many of those tuts. I mean, I am alright at C++, but pointers always made me freak out. Thanks again guys!

  28. #28
    0
    C++ is the industry standard for game development. Since Unreal Engine targets more AAA it makes sense to keep it C++.
    C++ also gives you finer control over the little things, which can sometimes be essential for larger budget projects.

  29. #29
    0
    To guys having problems with pointers.
    Guys, nobody uses raw/naked pointers in modern C++ anymore. Check unique_ptr and smart_ptr, learn how to use them, and you will never have to think about memory management again.

    C++ is simply beautiful.

    As for headers and source files. Agreed, pain in the neck. Check out C++ modules though, and you'll understand what I mean when I say ISO committee is working hard on constantly and frequently improving C++.
    Last edited by smallB; 04-11-2014 at 02:42 AM.

  30. #30
    0
    Quote Originally Posted by sandboxgod View Post
    The main problem with C++ is that programmers think too highly of themselves, run out of talent, and introduces multiple memory stomps that other guys have to spend time tracking down and resolving.

    I do believe C# is the future going forward without a doubt. But for now, C++ is still king of performance and memory management. I think it's a great idea for the core of the engine to be written in C++ but game code can be higher level (byte code, etc)

    Where Epic Games went wrong in the past was UnrealScript. Which kept me away from UDK. It couldn't be debugged, couldn't rapid prototype, took awhile to compile, etc. It had all the disadvantages of a scripting language and none of the bonuses lol
    It is a common fallacy that C# performs worse than C++. C# and C++ can perform equally well when compiled to native code because C# is optimized in the same manner as C++ and in some cases better. It is true that the default behavior is to compile C# to IL, however, this can be changed. Even still, C# has a just-in-time-compile feature, which means the first time an application's execution path leads to IL, it is compiled to native code and from that point on it's just as fast as anything else compiled to native code. However, C# and managed languages have other issues at run time, which make them challenging for games development. This is also the reason managed languages will NEVER be used for game engines. I'm sure there are examples of attempts to make a game engine in C# but it will never be a serious contender in the AAA world.

    C# and other managed languages are only the future for applications where more hardware is the solution to memory and performance problems, aka business applications. In games, memory management is super important and managed languages don't really offer the degree of control you need in most cases. For example, garbage collection will cause rather large lag spikes if you don't consider strategies to deal with this. If I create an instance of an object each frame at 60 frames a second, it means I'm creating 60 instances of garbage that needs to be collected each frame. If I extrapolate that out over many objects, you can see that the garbage collector could easily become overwhelmed as significant pressure is applied to the CPU during garbage collection, which causes a visible drop in frame rate. In a large game, this can become very difficult to manage. In severe cases you can see situations where the game skips every couple of seconds due to garbage collection. Having shipped several games in Unity3D, this is a huge problem, which typically requires strategies like object pooling but, even with strategies like this, it's still a real pain to deal with. In C++ you have complete control over memory so you can make it work exactly the way you need it to work, rather than being forced to deal with a memory management solution that is not optimized for games.

    In C#, resolving a property on a reference type requires a memory read where resolving a property on a struct does not because it's a value type that lives on the stack. Also, value types can be boxed inside a reference types (aka object), so you need to be aware of this. While this is a very minor optimization example, it's one of many you have to be aware of when dealing with managed languages that either don't apply or have a more elegant solution in C++. The bottom line is that managed languages have a place in games but it's not the future. Business applications are different story because they usually don't have the same type of performance and memory requirements that games do.

    When looking at what language is the best tool for the job, it's important to consider both functional requirements AND non-functional requirements, aka memory and performance...
    Last edited by Jarhead; 04-11-2014 at 09:22 AM.

  31. #31
    0
    ^^ 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

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

  33. #33
    0
    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 at 10:37 AM.

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

  35. #35
    0
    Quote 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 at 01:39 PM.

  36. #36
    0
    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 at 02:08 PM. Reason: Made language more neutral

  37. #37
    3
    Unreal Engine Developer
    Join Date
    Mar 2014
    Posts
    142
    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.

  38. #38
    0
    Quote 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.

  39. #39
    0
    The Words of Wisdom from Tim Sweeney himself ! Still am thankful for you and the hundreds of developers for this powerful and beautiful engine!

  40. #40
    0
    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 at 03:03 PM. Reason: removed mention of UT mods (felt a little spammy)

Page 1 of 15 12311 ... LastLast

Tags for this Thread

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •