Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    Stop crying and get to work. Seriously.

    "Why C++ for Unreal 4?" - Why are you crying? If you don't like it, fix it or use something else.

    Comment


      Unreal Engine 4 is one of the best engines and a Engines with all possibilities that we have to day needs c++.

      And by the way... for game programers is c++ one of the main languages what you learn at the universitiy.

      So if you want create a game just4fun... you don't need the unreal engine 4 or you use blueprints... more then easy as unreal script

      Comment


        I don't see any problem with the engine's C++. Honestly, C++ is a fact of life in professional grade game dev. At some point or other you will need that level of access and performance. Do you always? No. But when you do it needs to be there, or it potentially means grinding your entire project to a halt, because without that access you have zero capability to get it fixed yourself, and are totally at the mercy of the engine developers fixing what might amount to a very specific problem.

        Experienced devs will understand why that's not something they even want to touch.

        Further I don't really see the problem with the split between BP and C++. If you need more BP functionality - expose it via C++. If it's too slow in BP, same thing, etc. That's not really an unusual paradigm for any engine - almost all of them feature some sort of scripting functionality which must have underlying engine code exposed to it. It's the same thing here.

        If you want some specific scripting language for another reason, there's facility for doing that via plugins.
        Storyteller - An immersive VR audiobook player

        Dungeon Survival - WIP First person dungeon crawler with a focus on survival and environmental gameplay ala roguelikes

        Comment


          I agree that most language-debates are futile, but I am frustrated that most people here don't even understand what is being debated here, and mistakenly think this is a language-debate - it is not.

          Let me say it loud and clear so people won't have the slightest chance of continuing to misunderstand:
          "Unreal Engine 4 - like ANY modern game engine - MUST have been programmed in C++ (!!!)"
          No one in their right-mind would fathom coding something of this magnitude and quality in any other language! (at least not yet...)
          THAT IS NOT WHAT IS BEING ARGUED HERE, SO EVERYBODY PLEASE STOP REACTING AS IF IT IS!!!

          What IS being argued, is something entirely different - "What should be the ideal way of coding GAME-LOGIC?" (!!!)

          Let me give some analogies:
          Networking-code is very difficult to do right (by "right" I mean fast, efficient and flexible).
          So some smart people got together and coded a library called Zero-MQ (a.k.a: zmq, or 0mq), which implements the lower-levels of networking-code in an extremely optimized way, and exposes a pretty high-level API for system-engineers to be able to build whatever network-topologies they could even need (publish/subscribe, request/response, in-process, inter-process, etc.). After they had done so, many developers started to use it (by "use" I mean, "build-upon"), instead of starting from scratch and implementing lover-levels themselves. What's the benefit? You get many man-hours of development and many years of experience, already coded-in for you so you don't have to go through the pain of making all the past-mistakes all over again. Now, since it is C++, it is VERY fast always, and also very easy to "be wrapped" and "bounded-into" other languages. Nowadays, there are upwards of 40 different languages binding to it! 40!!! All the way to the "slowest" ones like Python and Ruby... And applications using it in these last 2 languages are, guess what, "every bit as fast as systems coded in C++ that are using it" (!), at least in terms of networking-performance and resiliency/stability. The idea is not new at all - the execution still happens at C++ native-speeds, but the input/output of the execution is routed to another language - whatever it may be.

          This is how you get the best of both worlds.

          I recently had performance issues with a server I was developing in Python, and I ended up solving it by using PyZMQ, which is a thin-layer of python around a ZMQ C++ compiled core. I went one step further, and optimized the encoding/decoding process by using another such solution, called Messagepack (a.k.a: msgpck). There is another example of such arrangement - you got a highly-optimized very target-focused library that does one thing and does it well, and you got thing-layered wrappers around it, that "binds" it to other languages (last I checks, msgpack had around 17 language-bindings) - it's fast, it's efficient, it's easy-to-use, even when you are using it from a "slow" language.

          Other examples may include:
          - simplejson - A Python package, that is a C-extention - is also C++ code compiled to efficiently decode/encode JSON formatted text, and wrapped in a thin layer of Python.
          - The Qt UI-Toolkit - Python has 2 binding-packages (PySide and PyQt) that are equally as performant as their C++ counterparts, because guess what - THEY ARE THE SAME CODE COMPILED IN C++ UNDERNEATH, AS ONE WOULD USE FROM A C++ APPLICATION(!)
          ...
          (I could go on forever with such examples...)

          Now, imagine people in the ZeroMQ forums, or the Qt forums, arguing about why it was good that the library was "written" in C++ and not Python...
          Then you would get how I feel when reading such posts here...
          Can you see where the confusion lies? Can you see why I am saying that "...this is not what is being argued here"?
          It's a total misunderstanding of the entire story.

          It's NOT about what langue to "write" a game-engine, it is about what other languages it should be "bound-to" (!!!) HUGE DIFFERENCE (!!!)

          I ended-up being able to code my server in Python (using ZMQ and msgpack), in a FRACTION of the amount of code and in a FRACTION of the time it would have taken me to do in C++ (using the same libraries without the binding-layer), and guess what - IT IS SCREAMING FAST (!!!) EVERY-BIT AS IT WOULD HAVE BEEN CODED IN C++ (!!)

          So, I say again - and please get it through your skulls already:
          It's NOT about what langue to "write" a game-engine, it is about what other languages it should be "bound-to" (!!!)

          95% of game-logic code is non-performance-critical (at the very least) - most-if-not-all of the code that IS performance-critical, has already been coded in C++ by Epic... Physics, collision-detection, rendering, particles, path-finding.... Even AI stuff is on the way and will get better GUIs...

          Most of game-logic is a huge pile of "glue-code" to put-together these awesome already-performance-optimized systems in all sorts of new and exciting ways - the essence, if you will, of the game-play.
          And NO, you DO NOT need C++ to write glue-code - there are MANY languages which are leaps and bounds superior FOR THAT TASK(!) then C++, no way around that, it's just a fact.
          And NO, for 95% of it is just NOT performance-critical by itself - you would NOT notice it AT-ALL, even if you REALLY-TRY with advanced profiling-tools...
          It is just a clever use of resources, and much more efficient and pragmatic to do that - it is simply silly not to...

          And just one note to finish this up:
          Epic engineers themselves has already stated on multiple occasions (I can provide references...), that "compiled" Blueprings are roughly 10X "S-L-O-W-E-R" (!!!) then coding the same in pure C++(!) Why? Because of the way their data-model is designed: To fit a Node-Based GUI. They are NOT (I repeat "NOT"(!)) "compiled" down to C++ native code(!) They are compiled to a binary format that is then (wait for it...) "INTERPRETED" (yes, you read it correctly...) by the UE4 run-time... And guess what - NOBODY NOTICES(!) You know why? Because it DOESN'T MATTER(!!!) It is non-performance-critical pieces of logic, that use otherwise "idle" cpu-cycles (for the most part...). NOW I want somebody to tell me why this same thing can-not be accomplished by a X2 (or even X3) "slower" programming-language run-time such as C#, or (god-forbid...) Python...

          There is simply NO reason whatsoever...
          Absolutely no reason, and some people already understood that and are working to fix the situation - please support them in any way you can, and stop posting BS posts about irrelevant-arguments that are not even being made...

          Comment


            Originally posted by EruArnold View Post
            It's NOT about what langue to "write" a game-engine, it is about what other languages it should be "bound-to" (!!!) HUGE DIFFERENCE (!!!)
            So, then use a plugin to provide a different binding?

            Epic engineers themselves has already stated on multiple occasions (I can provide references...), that "compiled" Blueprings are roughly 10X "S-L-O-W-E-R" (!!!) then coding the same in pure C++(!)
            That doesn't jive with you saying it needs to have other bindings - most scripting languages are even slower than 10x less than C++. By a lot.
            Storyteller - An immersive VR audiobook player

            Dungeon Survival - WIP First person dungeon crawler with a focus on survival and environmental gameplay ala roguelikes

            Comment


              Originally posted by EruArnold View Post
              I agree that most language-debates are futile, but I am frustrated that most people here don't even understand what is being debated here, and mistakenly think this is a language-debate - it is not.

              Let me say it loud and clear so people won't have the slightest chance of continuing to misunderstand:

              ...
              Good lord, is everything alright on your end? You seem overly intense and this is only your second post. It seems your incredible expertise (or what you perceive as such anyway) is doing you no good at all.

              Here's a quote of Tim Sweeney, you know, the founder of Epic Games. Nothing more needs to be said I think.

              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.

              Comment


                My favorite part of Mr. Sweeny's post:
                By making peace with complexity and writing code in C++, there is absolutely no limit to what you can accomplish ....

                Comment


                  That doesn't jive with you saying it needs to have other bindings - most scripting languages are even slower than 10x less than C++. By a lot.
                  A link has been posted here, twice, showing how C# is roughly x2->x3 slower then equivalent C++, so by this calculation it would be about x3->x5 FASTER then Blueprints...


                  Originally posted by Gigantoad View Post
                  Good lord, is everything alright on your end? You seem overly intense and this is only your second post. It seems your incredible expertise (or what you perceive as such anyway) is doing you no good at all.

                  Here's a quote of Tim Sweeney, you know, the founder of Epic Games. Nothing more needs to be said I think.
                  That's just how I write when I'm ******-off... It's not personal, or specific to this forum.

                  I have already read Tim's post (as I said, I have read this whole thread top-to-bottom).
                  What can I say, I am not convinced about his assessment...
                  To me, most of it sounds like a combination of after-thought-backwards-rationalizations and cleverly-disguised "marketing talk".

                  Blueprints ARE a form of inter-op layer...
                  A blueprint-node, when executed, is "invoking" a call to the underlying API, and a game-logic code written in C++ wanting to call some blueprint-node, would probably also have to go through the data-model layer of a blueprint to get to it's node, interpret it's class-instance and then it's corresponding API class-instance. And there you go, you already have an inter-op (albeit just a little shallower and more controllable).

                  I wouldn't presume to know how binding to, say, Python, works, but it being done all the time for many libraries, with not much trouble.
                  The CPython implementation is very C-oriented, so it is considered "relatively" easy to bind-to, compared to other languages.

                  I agree that UnityScript was a very bad idea, but I believe it was more due to it's immaturity compared to mainstream languages with decades of refinement on their back. .NET may also be an odd-ball in terms of breadth, complexity as well as licensing, I wouldn't compare it with most anything else (except, perhaps Java...).

                  The fact of the matter is, what I am hoping for is already being started to be facilitated - and by Epic itself, so apparently somebody somewhere had a change of heart since Tim's statement - and for good reason:
                  https://forums.unrealengine.com/show...ns-via-plugins

                  What really bothers me is that people seem to think we're asking for an engine with no C++ access...
                  No one is asking that - not that I have seen - what is being asked is IN ADDITION and NOT INSTEAD, so all these arguments are mute...
                  Will you NEED to write some C++ code for your game? Most probably, yes. It is GOING to be beneficial AT CERTAIN POINTS (!)
                  People have this dualistic black-and-white simplistic kind of thinking, and can't think in terms of "degrees" and "measures" and most importantly RATIOS.

                  Lets illustrate with a thought-experiment of a typical case-scenario, shell we?
                  You are developing a game.
                  Coding your game logic would take, let's say, twice as much in C++ as it would in C#.
                  (don't know how realistic this assessment, but to me it seems generous to C++)
                  Now, let's say 90% of it is non-performance-critical, so that means at least 10% you are going to code in C++ anyways.
                  Lets assume that coding in C#, for the rest of the 90%, would cost you a performance-penalty of 300%.
                  Now, since it's non-performance-critical, it updates infrequently so is spread-out across cpu-cores and time, which brings it's "effective" penalty (meaning, how noticeable it is) by at least 2 orders of magnitude.

                  You got 3% of "noticeable" performance-penalty, but sliced your development investment in half.
                  Is it worth it?
                  YES!

                  And to me, this sounds like a very pessimistic-scenario, except for a very specific target-audience:
                  Big Game Studios ! (Here we go again...)
                  Why?
                  Because that 10% in THEIR case would probably be a pretty-substantial code-base by it's own-right, that would explode into a nightmare of debugging for any custom-inter-op that would have to be implemented especially for it, as Tim said.
                  That is the ONLY case in which this scenario fails - and it is for an extremely "rare" audiences - how many big game-studios are there? How many small shops? How many indies? You see the picture? Epic is targeting big game studios specifically and explicitly with this line of thinking, which means they care more about their own bottom-line coming from a few high-profile customers than for the rest of their entire huge and growing user-base.

                  THAT is why I hear marketing-talk in Tim's statement.

                  Sucking-up for you top-tier-only with such statements and leaving the rest of the user-base in the dust, is not a way to to run a business long-term, and Tim would have to realize that at some point.

                  You HAVE to cater for the lower-level also, because that is where your long-term revenue will come from down the line - the bottom grows wide if you invest in it properly.

                  It might have been wise to not tie the core to a scripting-run-time for EVERYONE (like Unity did) so that your top-tier could work without it, but there is no excuse not to make it "optional" as a plug-in, if you can.

                  All the non-sense about language-performance is utterly irrelevant in this entire story - it just doesn't hold to closer scrutiny.

                  If you want to talk "inter-op debugging overhead", that is a very different story, but most commentators in this thread have not talked about that...
                  They just scream aimlessly "C++ is faster!!..." ... "Games need to be written in C++!!..." and such mantras...
                  That is what frustrates me in this entire thread.

                  Comment


                    Here is a crazy idea for cross-language scripting-support:
                    Since ZeroMQ and MessagePack are writtedn in C++, and also both supported by many languages, and since ZeroMQ supports extremely-fast inter-process communication, and since MessagePack supports custom-binary-formats, you could theoretically embed these C++ libraries in a Ue4 plugin, that hosts a socket to any external-language that supports both ZeroMQ and MessagePack. All you would have to do then is design an RPC protocol around them, that would do the inter-op.
                    Then, say, on the python-side, one just has to implement a thin-layer of translation as a c-extension that implements that protocol, and exposed a low-level API as a python-package. Since python as a scripting-language would be on the receiving-end of UE4 event-handlers, Python would act as the server, and UE4 as the client (2 separate processes). To make things low-latency on the Python's end, Gevent could be used for it's light-weight asynch-co-routines capability. From My experience with such an arrangement in python, it can handle thousands of requests per-second in a singe-process. And if Python gets CPU-bound, you simply launch more processes - and ZeroMQ could do the rest in terms of load-balancing (it can do that automatically in some topologies).
                    Similar solutions could be implemented differently for any language based on it's strengths and weaknesses.

                    Debugging would then become rivial, and there is a standard and clear separation-layer between the 2 languages as they run on separate processes, and you could very easily have 2 IDEs (VS for UE4 and, say, PyCharm for Python), and put breakpoints in both, and watch the flow of data through it's game-logic paths.

                    This may sound crazy, but that's just an idea - spaghetti-against-the-wall if you like...

                    Comment


                      Originally posted by Gigantoad View Post
                      Originally posted by furrykef View Post
                      The last I checked, it's not 10 or 15 years ago.
                      If by that you mean to say that Tappy Chicken was written in C++, you're wrong. It was done entirely in blueprint.
                      That wasn't what I meant at all, and I'm a bit baffled as to how you could read my post that way. Now, remember, I was responding to this:

                      Originally posted by Azarus View Post
                      Well 10-15 years ago a tappy chicken style game was written in c, for a good reason.
                      My point was, 10-15 years ago you'd write it in C (or C++) -- but it's not 10-15 years ago anymore. It's today. We don't need to write it in C or C++ now (and indeed it wasn't). So what relevance does this argument have to us today? We should be concerned with today's concerns, not yesteryear's.

                      I also think the performance wouldn't have been that bad for a Tappy Chicken-style game in a high-level language even back then. I saw plenty of simple games written in Visual Basic, and that was before the .NET days.

                      Comment


                        Originally posted by EruArnold View Post
                        A link has been posted here, twice, showing how C# is roughly x2->x3 slower then equivalent C++, so by this calculation it would be about x3->x5 FASTER then Blueprints...
                        Originally posted by EruArnold View Post
                        Coding your game logic would take, let's say, twice as much in C++ as it would in C#.
                        (don't know how realistic this assessment, but to me it seems generous to C++)
                        Now, let's say 90% of it is non-performance-critical, so that means at least 10% you are going to code in C++ anyways.
                        Lets assume that coding in C#, for the rest of the 90%, would cost you a performance-penalty of 300%.
                        Now, since it's non-performance-critical, it updates infrequently so is spread-out across cpu-cores and time, which brings it's "effective" penalty (meaning, how noticeable it is) by at least 2 orders of magnitude.

                        You got 3% of "noticeable" performance-penalty, but sliced your development investment in half.
                        Is it worth it?
                        YES
                        Originally posted by EruArnold View Post
                        All the non-sense about language-performance is utterly irrelevant in this entire story - it just doesn't hold to closer scrutiny.
                        I don't get this. On the one hand you talk about performance of blueprints vs. scripting being relevant, on the other you throw out some random numbers showing that a performance hit of scripting vs. C++ would be worth it for none performance-critical stuff. So why then is blueprint not sufficient option for none performance-critical stuff?

                        Blueprints really sort of is the scripting equivalent in UE4. It works really well, allows for rapid iteration, visual debugging and easy sharing of ideas. The 10x slower figure only concerns the CPU aynway. With most games today having a bottleneck on the GPU it may not even be an issue. Why are you getting so worked up about missing scripting in UE4 when there's blueprints?

                        I'm all for options and if Epic comes up with ways for more scripting languages to be used, I certainly won't mind, but I'm not sure I would personally need anything in between C++ and blueprints if I'm going to do performance-critical stuff in C++ anyway. Is scripting going to be something just for people who would just rather type than connecting blueprint nodes but not go through the hassle of C++?

                        Besides you make it sound as if C++ access is a given in other engines with your "going to code 10% in C++ anyway". What would you do in Unity with those 10%?

                        Originally posted by EruArnold View Post
                        That's just how I write when I'm ******-off... It's not personal, or specific to this forum.
                        Why are you ****** off in the first place? Take it easy, this is only a forum and your life doesn't depend on it. I think everyone should be able to articulate their thoughts without condescension.

                        Originally posted by EruArnold View Post
                        What really bothers me is that people seem to think we're asking for an engine with no C++ access....
                        I'm pretty sure nobody thinks that, makes no sense at all.

                        Comment


                          Originally posted by furrykef View Post
                          That wasn't what I meant at all, and I'm a bit baffled as to how you could read my post that way. Now, remember, I was responding to this:



                          My point was, 10-15 years ago you'd write it in C (or C++) -- but it's not 10-15 years ago anymore. It's today. We don't need to write it in C or C++ now (and indeed it wasn't). So what relevance does this argument have to us today? We should be concerned with today's concerns, not yesteryear's.

                          I also think the performance wouldn't have been that bad for a Tappy Chicken-style game in a high-level language even back then. I saw plenty of simple games written in Visual Basic, and that was before the .NET days.
                          Apologies, my mistake. To be fair though I did say "if by that you mean"

                          Comment


                            Originally posted by EruArnold View Post
                            Sucking-up for you top-tier-only with such statements and leaving the rest of the user-base in the dust, is not a way to to run a business long-term, and Tim would have to realize that at some point.

                            You HAVE to cater for the lower-level also, because that is where your long-term revenue will come from down the line - the bottom grows wide if you invest in it properly.
                            Here's hoping you're not serious. Last time I checked UE4 was a AAA game engine available with full source code for 19$ a month. Epic's attitude towards indies and newbies has been nothing short of stellar so far with help being thrown around in spades. They have recently donated 10k to Blender development because they realise how beneficial a free 3D production software could be for indies. Blueprints allow even artists to "code" like hardly any system ever did before.

                            What you describe there may happen with CryEngine from what I heard but certainly not here.

                            Comment


                              Originally posted by Gigantoad View Post
                              Here's hoping you're not serious. Last time I checked UE4 was a AAA game engine available with full source code for 19$ a month. Epic's attitude towards indies and newbies has been nothing short of stellar so far with help being thrown around in spades. They have recently donated 10k to Blender development because they realise how beneficial a free 3D production software could be for indies. Blueprints allow even artists to "code" like hardly any system ever did before.

                              What you describe there may happen with CryEngine from what I heard but certainly not here.
                              I am fully aware of Epic's contributions - I have read about them already. I was referring to Tim's statement in particular - I just struck a nerve, I guess.
                              I totally love all the benefits that UE4 already has, and I wouldn't be so upset if I didn't care...

                              Take it easy, this is only a forum and your life doesn't depend on it. I think everyone should be able to articulate their thoughts without condescension.
                              Since I am in Israel, and having rockets explode over my head daily these days, and almost ended-up being recruited to go into Gaza, I think I know pretty well what my life depends on and what not.

                              The reason I am getting upset, is that going back to C++ is something I was hoping never to have to do too much ever again, and because I like UE4 so much that it becomes totally frustrating realizing I might have to, in order to use it.
                              Investing in a career-shifting move is a very big and scary decision, that might have long-lasting impact on my life, so excuse me for not taking it lightly.
                              Whenever one get's "invested" into a platform, and having that investment dictate one's future-livelihood, emotions run high when a change is happening in that arena - Imagine the reaction of experienced Silverlight-developers that have invested years of their lives in it, and being payed daily for coding for it, suddenly discovering that Microsoft is discontinuing the platform... Or how about Flash developers... Development-platforms are, for developers, "investments" that sometimes have large impact on their lives. So, it is obvious why emotions run high.
                              I have been reading similar thread in the Unity forums, and let me tell you - they are very emotional.

                              I don't get this. On the one hand you talk about performance of blueprints vs. scripting being relevant, on the other you throw out some random numbers showing that a performance hit of scripting vs. C++ would be worth it for none performance-critical stuff. So why then is blueprint not sufficient option for none performance-critical stuff?
                              Don't get me wrong: Blueprints I think is basically the best visual programming language ever made, it's like something out of some long-wishing wet-dream of mine...
                              But I am still not sold on the idea that a programmer could make a living writing blueprints. A designer might, on occasion, for prototyping, but I doubt it's going to be any further than that.

                              I can summarize my argument is one sentence:
                              In games-development, access to the C++ code is a welcome-addition-to and NOT a substitution-for additional scripting-languages



                              Quote Originally Posted by EruArnold View Post
                              What really bothers me is that people seem to think we're asking for an engine with no C++ access....
                              I'm pretty sure nobody thinks that, makes no sense at all.
                              The fact that it makes no sense, does not mean that nobody thinks that.
                              Many people posting here that do not understand the concept of hybrid-development, somehow think that adding an external-binding to a scripting-language would somehow compromise/jeopardize their ability to access the C++ code (I have read several such reactions here, perhaps you missed them).
                              Why? Because they think that what is being asked in for an entire AAA game-engine to be written in another language - because they don't have in their head the concept of language-bindings.

                              I have recently watched a lecture from an Autodesk conference, about writing tools for 3dsmax - the pros/cons of scripting in say, MaxScript vs. writing C++ against the 3dsMax SDK, and there is a unanimous agreement that a hybrid-solution is almost always best.
                              LUA is being used as a scripting layer in many DCC applications as well as many game-engines for years now (even AAA ones, like CryEngine), and Epic is now adding it already, as has been shown here.
                              So, I find it odd that I am even put into a position in which I have to justify that approach, when it IS the standard-approach - If anything, the burden of arguing for the contrary should be put on Epic and the "C++ scripting" proponents here, not on supporters of scripting-language-binding such as myself - UE4 is the odd-ball here, not the other-way around. And no, I don't buy the argument that the ONLY reason other game-engines have provided scripting-ability is that they don't share their C++ code-base. Cry-Engine and Unity ARE providing C++ access to big-studios, so it's not an either/or scenario - there are many benefits to be able to script in a scripting-language, REGARDLESS of whether or not you have access to the C++ code.

                              And btw, other languages that are bound to a game-engine, does not necessarily have to be "scripting" languages, or be "slow" languages at all...
                              Just look at the work that is being done in languages like "Rust" and "D". There are many reasons not to use C++ if you can, that have nothing to do with even development-speed, such as guaranteed "memory-safety". Rust has a very interesting solution to a bunch of very long-standing problems that languages like C++ have been having for decades - take a look:
                              The Rust language: memory, ownership and lifetimes

                              And "D" provides similar benefits, with probably the fastest compile-time on the planet:
                              Three Cool Things About D - The Case for the D Programing Language

                              So it's not necessarily about "scripting languages" per-say, it's also about not having to waist time on a tracking-down subtle bugs that result in poor memory-safety-enforcement by a language-compiler, by having a different language that prevents whole "categories" of such problems, by making them essentially "impossible" to reach to by it's very design.

                              Should future game-engines be coded in D or Rust? Maybe. Maybe not. There are other factors to consider, like maturity and access to C++ libraries.
                              But could existing game-engines benefit from providing a layer of Rust or D for extensibility? I think the answer is "Probably yes".
                              And it has already been tried:
                              DConf 2013 Day 1 Talk 5: Using D Alongside a Game Engine by Manu Evans
                              Last edited by EruArnold; 07-25-2014, 08:06 AM.

                              Comment


                                Originally posted by EruArnold View Post
                                Since I am in Israel, and having rockets explode over my head daily these days, and almost ended-up being recruited to go into Gaza, I think I know pretty well what my life depends on and what not[/URL]
                                Sorry to hear, hope you'll be alright.

                                Originally posted by EruArnold View Post
                                Don't get me wrong: Blueprints I think is basically the best visual programming language ever made, it's like something out of some long-wishing wet-dream of mine...
                                But I am still not sold on the idea that a programmer could make a living writing blueprints. A designer might, on occasion, for prototyping, but I doubt it's going to be any further than that.
                                That's probably true if we're talking about jobs. Doubt there will ever be a UE4 developer job that does not involve C++. But since you do know C++, why not use blueprints as much as you can and then port the performance critical stuff to C++? Seems like the best of both worlds.

                                Comment

                                Working...
                                X