Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    #76
    Guys Im not sure Unity has a place in a topic titled "Why C++ for Unreal Engine 4", sorry to break up the discussion but back on topic aye, Unity have their own forums.

    Comment


      #77
      Thank you Epic Devs for UE4 C++!

      I was only able to make my new game mechanic thanks to this awesome C++ opportunity that you've given us!

      Here I demo how players can use my in-game editor at Runtime to combine meshes into larger physics objects.

      And these runtime physics combinations can be destroyed and will break into realistic subgroups of physics objects!

      The power of UE4 C++ has enabled me to offer my end users the ability to do this at runtime, in-game!

      The editor was never loaded in this video, and as you see in video these combinations can be changed or added to any time.

      Thank you Epic!



      Rama
      Last edited by Rama; 04-14-2014, 12:56 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

      Comment


        #78
        Originally posted by MonsOlympus View Post
        Okay so Im not going to disagree but I would like to highlight a few things in terms of interop barriers I have witnessed in regards to c++ and blueprints so while I agree that C++ was the logical move and while on the strict topic of C++ its easy to gloss over extended topics.

        ....

        I cant deny the benefits of having C++ there if its required but we came to an agreement amongst the team that modifying the engine code wasnt required and we should focus on the gameplay layer which actually gives us an interop layer that there never used to be, unless ofcoarse we were using UScript and Kismet. Its been easier for me to pickup the Blueprint code so thats a bonus and my experience, its also far more powerful than Kismet so thats a big reason for making use of it, it also supports replication too. My main issue with the interop between C++ and Blueprint is that some things are actually easier done in the editor and theres no way to get that back out into text based code, typing out components is something Im sure you get used to eventually but still picking things up I find it easier to work with the component tree in the editor but Core Blueprint changes dont propagate back into the Core C++ without manual porting unfortunately.

        I would be curious to hear how Epic has been dealing with these things on Fortnite as it could give me some insight before I move forward, Im happy with where Im heading but as stated 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
        I'm not sure exactly what you mean by dependencies in terms of Blueprints. Blueprints in C++ are just normal UObject classes that have some meta data via UPROPERTY and UFUNCTION macros that make blueprints aware of them so the engine can instantiate and connect them together. Any dependencies you have should only be your direct parent class.

        You should be able to place any common code you want to reuse in non-blueprint cases in a simple class of your own that is called from your Blueprint class and your non Blueprint class (i.e. a class that has no blueprintcallable properties and functions).

        Maybe I'm not understanding the complete picture?

        Comment


          #79
          Originally posted by MonsOlympus View Post
          I would like to highlight a few things in terms of interop barriers I have witnessed in regards to c++ and blueprints so while I agree that C++ was the logical move and while on the strict topic of C++ its easy to gloss over extended topics.
          This is a great point, that an interop layer must necessarily be present at the interface between code and sufficiently powerful visual tools. The layer enabling C++ programmers to expose features to Blueprint layers is one example. Another example is the visual material system, where code generated for shader nodes is essentially strcat'd together behind the scenes into a shader program that is sent to DirectX or OpenGL for realtime execution on the GPU.

          The big question for engine developers is whether to utilize different programming languages for different parts of the programming pipeline, introducing an interop layer where they are partitioned.

          BTW: It's fine to compare to Unity and other engines here. Each engine arrived at a very different solution to gameplay programming, and comparing their decisions is a valuable exercise that increases everyone's understanding of the tradeoffs.

          Comment


            #80
            Originally posted by Tim Sweeney View Post
            The big question for engine developers is whether to utilize different programming languages for different parts of the programming pipeline, introducing an interop layer where they are partitioned.
            Dear Tim,

            I know I speak on behalf of many beta and new licensees when I tell you that I absolutely adore your choice to share UE4 C++ with all of us!

            Thank you for sharing your heart with the world!

            Programming in UE4 C++ has been one of the greater joys of my adult life



            Rama
            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

            Comment


              #81
              Originally posted by zoid View Post
              ...

              GC is probably the best thing C# really has going for it. BUT it's not all roses either: let's not gloss over some realities that all managed (Unity) programmers have dealt with as well: Memory leaks. In C# you either get nullrefexceptions or you leak memory. Because its a managed language, a programming mistake can often lead to leaks instead of crashing. Both behaviors are arguably wrong. And C++ doesn't really have clear win.
              You wrote a great post but I would like clarification on this point. If you search the Unity forums this is not a topic that pops up in the last couple years. Are you referring to a very long time ago? Do you mean something else? What do you mean by 'null exceptions'?

              You seem to know Mono in much more indepth than I do. So I am curious why the discrepancy on this point. Thank you
              Godz for UT '99 / UT 2003

              Comment


                #82
                I can only agree with going the C++ route, professional game programming has been traditionally done in C++ not only because it has been for a long time but mainly for it's performance, flexibility and low level control. With UE4 being totally C++ you can port the engine to every possible platform, with unity you have to wait until unity does the first steps.
                Sr. Engine Programmer @ www.playspace.com - moritzwundke.com
                Remember: be polite and respect other peoples opinions - Join the Unofficial Unreal Discord Channel - Found a bug? Then use the Bug Report Form to get it fixed ^^

                Comment


                  #83
                  Originally posted by sandboxgod View Post
                  You wrote a great post but I would like clarification on this point. If you search the Unity forums this is not a topic that pops up in the last couple years. Are you referring to a very long time ago? Do you mean something else? What do you mean by 'null exceptions'?

                  You seem to know Mono in much more indepth than I do. So I am curious why the discrepancy on this point. Thank you
                  Hi Sandbox,

                  Sorry this wasn't clear on my part. I meant that in terms of errors committed by a programmer related to memory allocations they typically fall into 2 types of end result in C#: NullRefException or memory leaks (i.e. you set some something to null but didn't check your access in another place, for example another thread, or you aren't releasing memory at all).

                  In C++ there are even more types of errors you can commit, in addition to the ones in C#, but in C++ your nullrefexception is a crash, your leaks are leaks, and then there are all sorts of cases in between, because in C++ you can release memory back into the heap without setting all your references to null. This means that in the above example you would free the memory, and then when you accessed it (this is the error committed by the prorgammer) somewhere down the line you would likely crash, since future access to the object (which was freed) may have been recycled for use as another object somewhere. That means you are overwriting memory and the results are almost never deterministic.

                  In C# if you don't set all your references to null you just leak the memory (in other words it's not released until the last reference is removed).

                  Comment


                    #84
                    Originally posted by Moss View Post
                    I can only agree with going the C++ route, professional game programming has been traditionally done in C++ not only because it has been for a long time but mainly for it's performance, flexibility and low level control.
                    Very true, very true. There's also a very interesting conversation to be had about other languages. C++ is not the only language that a project the size of UE4 could have been done with.

                    Haskell and functional languages for example bring many very interesting things to the table in terms of the types of bugs that can be committed by programmers. These are very important considerations when you think about the fact that UE4 has millions of lines of code. A defect rate of 0.001% per line of code written is still going to have 100's or 1000's of bugs. When you look at what those bugs are a large swath of them fall largely into things relating to memory access and corruption, and multithreading issues etc.

                    Functional programming eliminates those cases which should give anyone who really thinks about it at least a moment of pause.

                    The existing tools ecosystem including compilers, debuggers, and 3rd party integration and the available talent pool still outweighs those benefits right now.

                    An interesting community project would be an integrated functional language component. That's one of the best things about having the source. The academic and research side of this is wide open now.

                    Originally posted by Moss View Post
                    With UE4 being totally C++ you can port the engine to every possible platform, with unity you have to wait until unity does the first steps.
                    Just to clarify this point, Unity is also written in C++ and could be ported by the community if they released the code like Epic has done with UE4.

                    UE4 is undercutting the competition with a superior product and that's gonna put real pressure on Unity and Crysis and I wouldn't be surprised if we see some pricing revisions and source access made available. I think Epic has forced their hands.

                    Comment


                      #85
                      @zoid, Awesome! Thanks for clarifying.
                      Godz for UT '99 / UT 2003

                      Comment


                        #86
                        Originally posted by zoid View Post
                        These debates are bound to happen and they get emotional because the choice of language is often based on "what you are comfortable with". I can tell a lot of people here are coming from a Unity background and appreciate its accessibility from C# through the documentation etc. My background: 15 years in professional game development as an engine programmer, I've used C++, C#, Java, extensively.

                        First off all, I think there is a misconception and people are latching too much onto C++. Epic has a far more elegant solution to scripting: Blueprints. Anyone who is comparing Unity C# to UE4's C++ has missed the entire boat. Unity is also written in C++, they just don't give you the source code. Any criticism leveled at UE4 because of C++ is equally applicable to Unity.

                        Secondly, everyone who is coming from Unity and is used to C# should be looking at Blueprints not at the C++ engine source. UE4's C++ source code is not for people who are used to scripting GameObjects and MonoBehaviours in C# in Unity.

                        And the final much more heated debate are the merits of C# vs C++.

                        Let's start with the "language" part of C# vs C++ and ignore the performance aspects of the situation first:

                        As a language, C# and all languages built around the IL specifications are inferior to C++ because they lack several major features: compile time const-ness, a true Turing complete template meta programming solution, pre-processor macros that support substitution and reduction, the ability to do full static analysis, and multiple inheritance.

                        For the beginning programmer what does this all really mean? Let's take a good example with const: multi-threading. In C++, because of const, it is much easier for me to produce a set of classes or an API that effectively communicates threading semantics between two classes that is enforced at compile time. If I have two systems A and B and they need to share an object, (where A can modify and B should only read) then it can simply be done by passing a "const" (cannot modify) version of that object to B. B can no longer ever call a method on the object that will modify its contents. This is enforced at compile time: if you tried to modify it it would fail with an error when compiling. That alone eliminates an entire class of thread synchronization bugs.

                        There are equally powerful cases for all of the other C++ language features. They range from convenience, to extraordinarily important if you want to be able to do something truly the right way.

                        C# has some superior language features as well but they don't tip the scale in its favor:

                        C# has anonymous functions and closures: This is incredibly powerful. C++ added this in C++ 11 and it is arguable more powerful there but there is an elegance that C# has because it is GC'ed that C++ does not. If I truly had a wish though C# would have first class methods like Lua.

                        C# has (at least on windows) has windows forms. Not a language feature but it's nice for tools.

                        C# has reflection, which is awesome. UE4 also has a reflection system as well, but it's not a language feature of C++.

                        Now let's discuss performance in C++ vs C#. This is arguable more important than the language features (at least from some perspectives).

                        I will begin with some follow up information if anyone really wants to get into this: http://www.codeproject.com/Articles/...-Csharp-vs-NET

                        The bottom line on this point is that C# is slower than C++. And if you use mono to compile your C# (like Unity does) then it is significantly slower. Using the microsoft class of IL compilers C# at its peak can almost match the speed of C++, but those are during its best cases. Generally C++ outperforms C# by a significant margin.

                        The types of optimizations that C++ goes through are more advanced and more significant than what are possible with C#. For example, did you guys know that every time you index an array in C# there is a bounds check in the array? Also C# has its own set of issues and concerns, specifically with mono: Almost all Generic.Collection<> classes in the C# runtime return structs from their IEnumerator interface (as they should). However, mono does not compile this correctly: and it converts structs to object types on the heap causing boxing/unboxing overhead on each iteration. Bottom line: foreach() is slow in Unity so it can't be used as efficient alternative to avoiding the overhead of indexing in C#.

                        C# also makes it impossible to modify a value type without indexing because it lacks reference-to-value-types. Example:

                        void DoSomethingWithArray(MyStruct[] arrayofvalues)
                        for (int i = 0; i < arrayofvalues.Count; ++i) {
                        if (arrayofvalues[i].shouldBeModified) {
                        arrayofvalues[i].modifyValue = calculateNewValue();
                        }
                        }

                        The above requires two indexes into arrayofvalues, requires two out of bounds checks. Can this be optimized out? No it can't, the compiler has no guarantee that arrrayofvalues won't be modified on another thread during the if() and the assignment inside the if.

                        People say C# bad because it is garbage collected, but isn't UE4 also garbage collected?

                        This is a blessing and curse for C# and all GCed languages. Generally speaking GC (managed languages) are a net positive for the programmer.

                        The reasons aren't always really what people think: yes in C# you don't have to explicitly free memory, but that not the biggest win. The big win is that when I'm writting 50,000 lines of C# I don't have to arbitrate what system is responsible for any given allocation. Because I don't have to do that for literally thousands of places where an allocation occurs you eliminate a massiave swath of common mistakes: freeing a memory multiple times, overwritting free'd memory, overwritten memory you thought was yours but was free'd and then reallocated and given out to someone else. There are lots of expressions of these types of errors that can happen in a large project. They all lead to terrible issues: one of your objects gets overwritten by random garbage, you get a crash when you try to allocate or free memory because someone overwrote memory and stomped on the internal C++ heap house keeping structures. All kinds of nastiness.

                        GC is probably the best thing C# really has going for it. BUT it's not all roses either: let's not gloss over some realities that all managed (Unity) programmers have dealt with as well: Memory leaks. In C# you either get nullrefexceptions or you leak memory. Because its a managed language, a programming mistake can often lead to leaks instead of crashing. Both behaviors are arguably wrong. And C++ doesn't really have clear win.

                        However, if you make a mistake the behavior in both cases (managed/unmanaged) it is still incorrect, just differently bad.

                        Why C#'s garbage collection is bad, and why UE4's GC is better.

                        Both C# and UE4's UObject and blueprints and gamecode generally are all GC'ed as well. So why did Epic do this? Because there is one major pitfall with C#'s GC: performance and predictability. Anyone who has done anything of complexity in Unity knows the bane of the GC hitches. You're crusing along just fine and then BAM, a 500 ms pause hits you. Or the lovely continous stutter step every 2-3 seconds.

                        These are garbage collection spikes and there is no way to control when they happen or for how often, in other words there is no predictability.

                        UE4 is garbage collected but the way their object system is reclaimed and disposed is designed to be predictable and have a flat performance profile. C#'s GC is designed to work for spreadsheet applications and database front ends. It's a general purpose GC. It's not designed from the ground up to be a GC for a real-time application where a flat performance profile is the most important requirement.

                        Adding C# to UE4 is redundant and not a good idea

                        So for the above reasons C# is not a wise addition to UE4, UE4 already has a scripting system: Blueprints. Use blueprints for everything you want to do with C#. Use C++ to extend and modify UE4 in any way you want to. You can't extend or modify Unity at all, unless you want to fork over the cost of a source license. And Epic has made it clear from their Twitch broadcasts that they are working towards an integrated system with github to provide instant access to checkins on the main source branch as they happen.

                        Epic actively wants the community to dig into the engine and extend and improve it. That's why they've given us the C++ source code.

                        Aside from Blueprints, GC, and C++ UE4 is superior to Unity in every other way

                        Point for point, system by system, Unity is not competitive with UE4 (except it exceeds in documentation). Not even the slated features of Unity 5 matches UE4, it only narrows the gap a little bit.

                        There are major systems in UE4 that Unity totally lacks, and they are not trivial things, they are systems that it takes expertise in to replicate. They could be done in Unity of course, and the Unity community has provided addons to fill in some of the short comings, but they aren't done in an integrated system like in UE4. Here's some of those missing things that UE4 has but are lacking an integrated solution in Unity:

                        * A real networking solution with client side prediction and authoritative network architecture.
                        * Built in platform agnostic online subsystems and match making with support for Steam, Game Center etc.
                        * Behavioral trees and AI systems: Unity has no system for you to create and produce AI or NPC login. You have to start at the lowest level and write your own code to move objects around. Then pathfinding etc.
                        * Unity's mechanim system is not as robust or sophisticated as UE4's.
                        * Unity has no material node graph. Unity's renderer (even Unity 5's) is inferior.
                        * Unity's built in GUI is terrible, but there are replacements like NGUI and Diakon Forge. UE4 is about to get Coherent UI and I'm sure the community will fill this void unless Epic gets to it first.

                        There's more than this but it's just an example of the really hard stuff you still have to implement yourself in Unity or buy piecemeal solutions for on the Asset store. And the asset store solutions aren't always the quality needed to actually ship something.

                        TL;DR

                        * If you are upset that UE4 uses C++ you are missing the bigger picture: UE4's Blueprints are the equivalent to Unity's C#, but blueprints are superior.
                        * C# is slower than C++ in almost all cases, and much slower when compiled with mono which Unity uses.
                        * UE4's method of garbage collection is better than C#'s generic GC.
                        * UE4 is superior to Unity. It's not merely an equal or an alternative.


                        Wow, so much opinion being passed off as fact. Always be wary of posts like these.

                        A hacked on template system, multiple inheritance and the lack of pre-processor as POSITIVES for C++??? Really???

                        Completely disregarding programmer productivity as a plus? Or the safety the CLR grants? To give preventing leaks or multithreaded programming as a positive for C++... is there an emoticon for mind blown on these forums?


                        Each language has it's merits, and C# is nowhere nearly as dire as zoid attempts to paint it.

                        Comment


                          #87
                          This thread is silly.

                          People are correct in saying that C++ can outperform C# (either MS's CLR or Mono's) if written correctly. However, writing performant code in *any* language isn't a trivial task. Just writing in C++ isn't going to give you any automatic performance boost. Just as with managed code, much care needs to be taken in how you [de]allocate memory, exploit caches and architect your code.

                          There very much is a sort of poisonous mentality in the games industry that native code is the only appropriate choice for all game and engine logic. I think this comes from inexperienced developers who heard someone say once that C++ can outperform C#, and didn't take the time to understand the context of that sentiment. Frankly, I wouldn't trust a developer who makes the blanket claim that C++ is the only correct choice in game development to have the experience or knowledge to correctly use C++ in the first place. The whole thought process behind people pushing C++ as the only viable language in games reeks of immaturity and unprofessionalism. An alternate explanation is that C and C++ are taught at many schools for programming and game development (for good reason: learning C++ is an excellent experience that I wish on all programmers who want to further their skills).

                          The three biggest reasons why I say this are:

                          1) Writing performant code is difficult and requires rigorous testing and deep knowledge of general computation and the specific algorithms used in this domain. A person with good programming sense can easily write managed code that outperforms native code written by someone who lacks the proper background and experience. Please don't push C++ because "it's faster" if you do not understand, for example, cache lines or proper memory allocation.

                          2) The vast majority of a game is not performance critical (http://en.wikipedia.org/wiki/Program...on#Bottlenecks). There are things that should be written to squeeze every ounce of performance out of the machine - such as collision detection, physics simulation and similar systems - yet, most of the code that you will actually write on a per-game basis will *not* be executed many times in a frame. Furthermore, with proper multi-threading (and/or writing algorithms that can be executed over the course of many frames), many of these non-realtime tasks can be offloaded onto a separate core: thus not impacting the main game loop in any substantial way.

                          3) Ease of use. Ease of use is not an excuse for non-programmers to be able to write code - on the contrary. I use this term to say that a language such as C# will allow an experienced developer to write correct code more quickly; and give them the tools to architect their logic in such a way as to promote reuse and modularity (thus decreasing the amount of time required for maintenance, fixing bugs, prototyping or adding new features).

                          So what exactly am I suggesting? Basically: Unity's scripting model. I'm not going to go on a general U4 vs UE5 debate here: but I think one of the things that the Unity folks did better than Epic was expose a scripting API in C#. People can, and will continue to, write poor C# in Unity that negatively impacts performance - but the vast majority of the time, properly written code has no noticeable impact. The architectural and stability advantages are very much worth the insignificant performance penalty. Of course, Unity did the right thing by writing their core engine in C++. They employ expert game engine developers who work around the clock to maintain their C++ codebase; so they can afford the additional complexity introduced by that language choice. The benefit is that we get our performance critical logic written by experts in a low level language - while enjoying a high level scripting experience for game logic that encourages correctness and rapid development.

                          I know that one counter-argument that people will love to point out is Blueprint. I am simply not convinced that Blueprint will be an appropriate choice for all game developers to write high-level logic in. I've seen no implementation of a visual scripting language that provides the same logic density and flexibility as more traditional programming languages. Does it have a place? I'm sure it does. But saying that it replaces where C# would fit in is very much to ignore the power of written code. I've invested many, many years into programming; and I would expect that the game engine I choose to reward that investment by providing a scripting interface that I would immediately be comfortable and productive in.

                          Which brings us to the fact that U4 is now open-source with direct C++ access for writing game logic. I think this is a great move - and it will allow people much more extensibility than Unity currently does with its closed-source model. We can now write performance-critical modules that live side-by-side with the ones written by the developers of the engine itself. This is huge.

                          However: if I am not to use Blueprint for the aforementioned reasons, the logic I wish to express isn't performance critical, and I wish to use a more productive and safe language: what do I do?

                          I say this all simply to suggest that there is a gap between C++ extensibility and Blueprint scripting. Hopefully that will be filled soon by a community-provided C# scripting API for U4.

                          Comment


                            #88
                            Does Epic have some sort of style guide for C++ programming, that you either use internally or recommend for users of Unreal Engine 4?

                            (C++ is arguably a very "large" language, and every successful large C++ project that I've seen has chosen a certain subset of the language and adhered to that subset. For example, the google C++ style guide advises against exception, and the MISRA C++ standard (for industrial/embedded devices) prohibits heap allocation. And I can't find the video right now, but I remember John Carmack saying in a Q&A that he also has in his mind a "sane subset" of C++ he used for Quake 4/Rage/etc. I would love to know if Epic has something similar.)

                            Comment


                              #89
                              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:

                              AActor -> AFortPawn -> AFortAIPawn -> AFortAIPawn_Husk -> HuskGeneric -> HuskThrowing

                              FortPawn is C++ and has code to deal with things like our animation implementation. FortAIPawn is C++ and has the hooks for the behavior tree AI system. AFortAIPawn_Husk is very light and has a few things for increased performance. HuskGeneric is a spawnable blueprint, and has the majority of the data references built into it. HuskThrowing is a variant of HuskGeneric that throws bones, so uses most of the same data references and overrides some behavior. This structure has worked pretty well for us, but the specific decisions depend on how the team is setup. We could probably do without AFortAIPawn_Husk, it's mostly there for historical reasons, or you could make that layer an abstract blueprint or "Core blueprint". What basically happened for us is that the designers and programmers worked towards each other as we implemented new functionality, and we met in the middle. Most of the replication logic is inside the native code, most of the visual logic is in the blueprint, and most of the gameplay logic is inside other objects referenced by the blueprints. For instance the HuskGeneric blueprint actually dynamically decides what it should look like, based on random chance. That system works well the way the artists implemented it so it's implemented in the blueprint event graph. But, if something was too complicated to implement efficiently in blueprint, we'd move it to C++ and refactor the blueprint.

                              A key part of the fortnite setup is that we try to avoid referenc data assets from C++ classes, and we're currently removing most of the rest of the references. We do this primarily through Object Libraries, the Async Loading doc page has a good overview of how to set that up. We use Object Libraries for things like weapons, items, enemies, etc. We load an entire directory of assets, and then expose methods to find the desired asset based on game-specific queries. It'll be something like "spawn the enemy named husk". The other method we use extensively is to have data references hanging off of a GameSingleton, I discuss the general method over at this AnswerHub question. That singleton has pointers to things like the player's initial inventory, what blueprint to use for the player's pawn in different situations, etc. Using those two methods we've removed most of the data references from our C++ classes

                              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?

                              Comment


                                #90
                                Originally posted by Serapth View Post
                                A hacked on template system, multiple inheritance and the lack of pre-processor as POSITIVES for C++??? Really???
                                Yes absolutely. Those features are totally valuable and very powerful.

                                Originally posted by Serapth View Post
                                Completely disregarding programmer productivity as a plus?
                                Programmer productivity is heavily influenced by the actual task you are talking about and C# and C++ both have merits in that regard. Saying C# increases productivity as a blanket statement is probably not correct. The lack of const in IL based languages alone can lead to an entire class of bugs.

                                Originally posted by Serapth View Post
                                Each language has it's merits, and C# is nowhere nearly as dire as zoid attempts to paint it.
                                There is no need to make this into some sort of personal conflict about which language is better. In the context of a large real time application like UE4 I think I painted an accurate picture of the strengths and weaknesses.

                                All languages have their relative strengths. C# is a good language, one that I've used for many years. There is no reason to not use it as a scripting language in your project or game as long as you are aware of the pitfalls of a garbage collected language in a real time application and can mitigate them.

                                I don't think there is anything to be gained by integrating C# into UE4.

                                Comment

                                Working...
                                X