Announcement

Collapse
No announcement yet.

Why C++ for Unreal 4?

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

    Originally posted by furrykef View Post
    John Carmack probably knows a lot more about performance than you.
    Sure, and I tell you even more - I'm nowhere near the league John Carmack is in. Period. Most likely never will be.
    This is not the point.

    Also when I said "nothing beats C++" I didn't just mean performance. I meant flexibility, power, portability, with C++ YOU ARE UNRESTRICTED. Period.

    Comment


      Originally posted by Gigantoad View Post
      The notion that AAA game developers would use C++ only because of performance while ignoring development productivity is actually hilarious in that context.
      C++ isn't used just for it's performance. It is used because gives you unlimited possibilities. Performance with C++ you're getting for free.

      Comment


        For smallB:

        flexibility, power, portability, with C++ YOU ARE UNRESTRICTED. Period.
        This is pure fantasy/hype/nonsense...
        There is no such thing as "unrestricted" and there never ever will be.
        What DOES exist in reality, are "relations" between "constraints" and "requirements".
        Every language has it's own set of real-world constraints.
        Every game has it's own set of requirements.
        If your requirement-set easily falls well within the boundaries of a language's set of constraints, then you would be "effectively" boundless in what you need to accomplish - this would create a "sensation" of unlimited-power/flexibility - which is only a feeling, and not a true description of reality - an is entirely "contextual" - meaning, it exists within the "relation" between what you want to accomplish (a game's requirements) and what you are able to accomplish (a language/platform's constraints).

        Yeah, I get it. It looks like mobile market to me and I'm in AAA industry not in mobile that's why I would never ever drive my Ferrari in such place. It is simply not my kind of place, as I'm considering myself and the work I do as AAA and not mobile as the picture shows.
        Nothing to do with mobile...
        I'll describe the "intended" analogy:
        Crowded-area = all non-scripting tasks that are going on (rendering, physics, AI, etc.)
        Available room to move = the CPU-clocks available for scripting.
        Slow-moving vehicle = all game-logic using a scripting-engine
        Fast-moving vehicle = all game-logic using C++

        Meaning:
        You can drive a Ferrari in a crowded-area, but you would not benefit much from it - you could drive as fast as possible in that environment just as well with a Fiesta.
        You can code game-logic in C++, but you won't benefit much from it - your code would run just as fast written in a scripting-language, given that *any* game-logic code would probably be "waiting" MOST OF THE TIME for other NON-game-logic-code to complete...

        Many people here with years of AAA game experience have already given you real-world examples.
        ALL AAA games use a scripting language and a scripting-engine - with no apparent (or even in-any-way "measurable") performance-penalties...

        If anything, MOBILE and NON-AAA games are actually the ones that could suffer from a scripting-language - as they are more resource-constraint, so the same scripting-environment's resources would constitute a larger-portion of the overall system resources available (!)
        If anything, AAA games are the ones in which a scripting-environment's resource-cost would be MOST NEGLIGIBLE (!)
        They tend to have much more intensive GPU-work, more/larger-textures, more complex shaders, etc.
        Plus, they tend to target faster machines with more/faster CPUs and more/faster-caches/ram - and as of yet it is still difficult to take advantage of all the multi-cores of machines like that - it's an on-going research these days/past-few-years.
        And so in such machines running AAA games, you tend to have much more "idle" CPU-cycles for a scripting-environment to take advantage of...

        So, it seems you got it all completely 180-degrees backwards...

        And as for productivity, we're talking about "game-logic", which is ideally NOT done by software-engineers.
        As you could see in the Snowdrop Engine, most of the benefit comes from being able to quickly iterate and prototype new ideas, optimally by as many people in the production as possible. A close friend of mine actually worked on that exact project (Tom Clancy's "The Division") at Massive in Sweden for almost 2 years, as a creative-director - and he has some programming-background and is very technical. His impression was that the free-flow of ideas and free-experimentation capability was the single strongest factor in making a quality game.

        So, to conclude:
        C++ for game-logic-scripting ESPECIALLY FOR AAA GAMES (!!!), gives you little-to-no advantages, and costs you A LOT by raising the barrier-to-entry for MOST of a production's personnel, keeping them from being able to experiment/iterate on game-logic ideas quickly - Hence Blueprints was created by Epic (to mimic what engines like Snowdrop have...)

        A scripting-environment is not much different then a Visual-Scripting environment - except for potentially being a little faster, and much more flexible, while keeping the barrier-to-entry still very low - here is a real-world proof:
        http://vimeo.com/94585251
        http://vimeo.com/93956478
        Attached Files
        Last edited by EruArnold; 09-06-2014, 01:04 PM.

        Comment


          Originally posted by EruArnold View Post
          This is pure fantasy/hype/nonsense...
          There is no such thing as "unlimited" and there never ever will be.
          What DOES exist in reality, are "relations" between "constraints" and "requirements".
          Every language has it's own set of real-world constraints.
          Every game has it's own set of requirements.
          If your requirement-set easily falls well within the boundaries of a language's set of constraints, then you would be "effectively" boundless in what you need to accomplish - this would create a "sensation" of unlimited-power/flexibility - which is only a feeling, and not a true description of reality - an is entirely "contextual" - meaning, it exists within the "relation" between what you want to accomplish (a game's requirements) and what you are able to accomplish (a language/platform's constraints).



          Nothing to do with mobile...
          I'll describe the "intended" analogy:
          Crowded-area = all non-scripting tasks that are going on (rendering, physics, AI, etc.)
          Available room to move = the CPU-clocks available for scripting.
          Slow-moving vehicle = all game-logic using a scripting-engine
          Fast-moving vehicle = all game-logic using C++

          Meaning:
          You can drive a Ferrari in a crowded-area, but you would not benefit much from it - you could drive as fast as possible in that environment just as well with a Fiesta.
          You can code game-logic in C++, but you won't benefit much from it - your code would run just as fast written in a scripting-language, given that *any* game-logic code would probably be "waiting" MOST OF THE TIME for other non-game-log-code to complete...

          Many people here with years of AAA game experience have already given you real-world examples.
          ALL AAA games use a scripting language and a scripting-engine - with no apparent (or even in-any-way "measurable") performance-penalties...

          If anything, MOBILE and NON-AAA games are actually the ones that could suffer from a scripting-language - as they are more resource-constraint, so the same scripting-environment's resources would constitute a larger-portion of the overall system resources available (!)
          If anything, AAA games are the ones in which a scripting-environment's resource-cost would be MOST NEGLIGIBLE (!)
          They tend to have much more intensive GPU-work, more/larger-textures, more complex shaders, etc.
          Plus, they tend to target faster machines with more/faster CPUs and more/faster-caches/ram - and as of yet it is still difficult to take advantage of all the multi-cores of machines like that - it's an on-going research these days/past-few-years.
          And so in such machines running AAA games, you tend to have much more "idle" CPU-cycles for a scripting-environment to take advantage of...

          So, it seems you got it all completely 180-degrees backwards...

          And as for productivity, we're talking about "game-logic", which is ideally NOT done by software-engineers.
          As you could see in the Snowdrop Engine, most of the benefit comes from being able to quickly iterate and prototype new ideas, optimally by as many people in the production as possible. A close friend of mine actually worked on that exact project (Tom Clancy's "The Division") at Massive in Sweden for almost 2 years, as a creative-director - and he has some programming-background and is very technical. His impression was that the free-flow of ideas and free-experimentation capability was the single strongest factor in making a quality game.

          So, to conclude:
          C++ for game-logic-scripting ESPECIALLY FOR AAA GAMES (!!!), gives you little-to-no advantages, and costs you A LOT by raising the barrier-to-entry for MOST of a production's personnel, keeping them from being able to experiment/iterate on game-logic ideas quickly - Hence Blueprints was created by Epic (to mimic what engines like Snowdrop have...)

          A scripting-environment is not much different then a Visual-Scripting environment - except for potentially being a little faster, and much more flexible, while keeping the barrier-to-entry still very low - here is a real-world proof:
          http://vimeo.com/94585251
          http://vimeo.com/93956478
          Utter, utter nonsense. I disagree with what you've said.

          Comment


            Originally posted by smallB View Post
            Utter, utter nonsense. I disagree with what you've said.
            I stand in awe of your detailed and eloquently argued rebuttal, sir.

            Comment


              And as for the C++ code examples? You simply don't understand what Bjarne is trying to explain.
              Since I've been reading his writings, listening to his interviews/talks, and watching him lecture for many many MANY hours these past few months, I think I have a very clear understanding on his outlook by now. I would be far more comfortable betting on THAT then of your obscure/vague statements of "my misunderstanding him"...

              He has been frustrated by the situation of C++, fully acknowledging it's problems and dangers (even giving real-world examples, like with the NASA's space-probe that failed to reach Mars...) and openly discussing them (which is something that I never saw you do), and has been for many years now, and is very excited about the C++11/14 standard that he and his colleagues have been working on this past decade or so...

              He talks about how compilers from different vendors produce artifacts that are incompatible with other vendor's compiles, mainly due to political-factors, and how bad this is for everyone.

              He talks about the issues of "resource-ownership" that is SO EASY to get wrong, and why RAII, move-semantics and smart-pointers are so important and how they circumvent many of the potential pitfalls relating to resource-ownership (and thus why STL's "containers" and other such "handles" as he calls them, as so crucial for the future of C++).

              He talks about how the current implementation of Templates creates a situation in which compiler-errors are so overly verbose, obscure and unintelligible, and why "Concepts" are so important to resolve that (by providing point-of-use checks/error-reporting), and why he pushed for "concepts-lite" for C++11/14 (ultimately unsuccessfully... they will be a C++14-TR, and a C++17 feature...).

              He talks about how inevitably SLOWLY the industry is going to adopt the new standards, due to how slowly academic-curriculum and their reading-materials change, and the huge mess of "legacy code" laying-around that people would have to suffer through in the next few decades, and what can be done to ease this pain. While the new standards don't brake backwards-compatibility in existing code, the DO BRAKE existing LITERATURE and CURRICULUMs, which will be a grate difficulty for C++ in the decade to come.

              He talks about how SMALL the standard-library is, compared to "commercial" languages, due to the fact that C++ has no owner and hence no financial-backing, and what a disastrous-effect that has had on the immense FRAGMENTATION of disparate-incompatible solutions to common recurring use-cases (like file-system, sockets, GUIs, etc.), and how this is finally starting to be addressed...

              He talks about how the existence of the "#include" model has made compile-times go through the roof, and how there is no standard-description of avoiding that, and how badly C++ is in need of a "module-system" (which is in the works for C++17).

              He talks about all of these things (and many more) that are very well know inside-and-outside of the C++ community, and make it look-bad and rightfully-so, things that you are NOT even considering.

              So yeah, I'm sorry, but I'll take the words of the word's biggest C++ standards contributor and inventor of the language, much more then I would take some anonymous obviously-overly-enthusiastic poster on some forum... (No offence...)

              Really, given the enormous plethora of issues plaguing the C++ language, that are so well-known and wide-spread, and so often talked about, you would have to be willfully and intentionally blind, deaf and mute to ignore all of them and still admire it...
              Kinda like this:
              Click image for larger version

Name:	Guess-The-Emoji-78-8.jpg
Views:	1
Size:	5.8 KB
ID:	1056359

              Really, the more your current attitude persist, the more you are making a fool out of yourself...
              So just stop...
              Last edited by EruArnold; 09-06-2014, 01:10 PM.

              Comment


                Originally posted by EruArnold View Post
                Really, the more your current attitude persist, the more you are making a fool out of yourself...
                So just stop...
                It is you who is making fool of yourself by writing something that long and pointless. So perhaps you should stop.

                Originally posted by EruArnold View Post
                Since I've been reading his writings, listening to his interviews/talks, and watching him lecture for many many MANY hours these past few months, I think I have a very clear understanding on his outlook by now.
                Months? Wow, boy, I program with C++ over a decade now, had personal conversations with Mr Bjarne, etc etc, and you, you, someone who cannot grasp concepts says that after a few months of watching some videos you understand? Let me tell you, you understand very little and there is pretty huge chance that this will not change in future.
                Seriously, months? You are just making huge fool of yourself saying such things and showing how limited you are if you are really thinking that way.
                Last edited by smallB; 09-06-2014, 01:52 PM.

                Comment


                  Just a heads up; lets stop calling each other fools and continue the discussion in a more mature and friendlier manner please.
                  FREE Lightshow
                  FREE VR Drum Kit Project

                  FREE Color LUT Collection
                  FREE Physics Driven Spacecraft Project
                  FREE GTA Style Vehicle Interaction
                  Dynamic DoF(Depth of Field)
                  Camera Crossfade

                  Comment


                    Hence Blueprints was created by Epic (to mimic what engines like Snowdrop have...
                    kismet is more old that Snowdrop and node scriping even more old.

                    Comment


                      Look, smallB, everything you've said so far may be perfectly true and may work perfectly fine for you. But that doesn't mean that your insistence that people who operate with different standards and priorities are wrong is correct too. You got your approach, we (and, as far as we can tell, a good part of the industry) have ours.

                      Comment


                        Originally posted by smallB View Post
                        Utter, utter nonsense. I disagree with what you've said.
                        You know, admitting you're wrong isn't the most horrible thing on earth. Much better than disagreeing on very valid arguments brought up here without any actual counter-argument. Not once have you touched on iteration time, enabling more people in the team to create game logic, CPU performance being less important in todays often GPU-limited games etc., or why in SnowDrop they clearly state they use visual scripting for way more than just "trivial" stuff including AI (which you denied being feasable in blueprints earlier).

                        By the way, how do you like this? Not very much I presume.

                        http://skookumscript.com

                        Comment


                          Months? Wow, boy, I program with C++ over a decade now, had personal conversations with Mr Bjarne, etc etc, and you, you, someone who cannot grasp concepts says that after a few months of watching some videos you understand? Let me tell you, you understand very little and there is pretty huge chance that this will not change in future.
                          Seriously, months? You are just making huge fool of yourself saying such things and showing how limited you are if you are really thinking that way.
                          Now you're just being defensive...

                          From what I gather, the reason that "Concepts" are going to help in error-reporting at compile-time for Templates, is that they provide a mechanism for defining compile-time checking of Template-argument requirements. After a programmer clearly defines a set of requirements, the compiler uses those to impose them onto all "specialization" occurrences in the code that uses these templates - and it does that at the calling-code's location (meaning, at instanciation/specialization-point). This allows the compiler to first check/validate each template-use-point, with better-defined granularity, as well as associate this with each usage-point.
                          I think I understood it quite clearly. If I am wrong, I'de be happy to be enlightened...

                          Look, I didn't claim to be an expert on C++, you probably know more about it than I do (and obviously Bjarn knows more than the both of us combined).

                          I am just quoting things I have read/heard/seen him say.

                          There is a very obvious and strong impression expressed by Bjarn and others (such as Herb Sutter, the chair of the ISO C++ committee), of grate dis-satisfaction with the past-and-present state of affairs of C++. They all love this language, and that is exactly why they are/have-been hurting, hence the C++11 standard (previously known as C++ 0x) which they have worked very hard on for many years now, as well as the whole huge initiative that Herb is currently promoting and leading, for bringing more/fresh people into the committee's research-projects (Study-Groups) for further remedying the situation. There wouldn't be this push and this momentum of work, had C++ been this perfect language/ecosystem that you imagine. They all know very well how much it is flawed, and are working hard to fix it. They don't achieve this by "pretending" the problems don't exist (as you are doing) - they do it by acknowledging their existence and admitting how painful it is to deal with many of these issues, and inviting people to contribute and help. This is a very mature and responsible attitude that I very much like, and is actually the main reason I am studying C++ these days - It all gives me much hope that C++ might still have a very bright and even exciting future.

                          I am getting very little of this attitude (if at all...) from you - all you do is generate unsubstantiated hype and unjustified idealization, that none of the leaders of this language has ever expressed (at least from what I've seen thus far).
                          You are consistently painting a "rosy" picture of the current state of affairs, that has no baring in reality, and just makes you seem very disingenuous (even immature).
                          If you are really excited about coding C++, at least for UE4, all the fun for you - I have seen stuff you made, and they are pretty impressive.
                          But you have to at least acknowledge your own bias, and take it into consideration, when recommending a route for others - it's just the responsible thing to do.
                          Yes, UE4 is compiled with a C++11 compiler, which is more than I can say for a lot of other C++ code-bases/development-platforms, and that is a very good thing.
                          But to go one from there to claim that all game-studios and their personnel have nothing to gain from other environments for UE4, is just a pie-in-the-sky - it's just a fantasy of yours...
                          As far as Epic is concerned, the main tool suited/targeted-for rapid-prototyping of game-logic, is Blueprint - NOT C++.
                          Meaning, for most people in any EU4 game-development team, Blueprint should be their go-to system to use for most cases (and as for other scripting-languages, they are proposed by others as a substitution/additional-alternative to this layer).
                          They should use it by consuming existing Blueprint modules, as well as extended/custom ones written by the team's C++ developers which should mainly use it for exactly that purpose (writing extended/custom-modules), as well as for re-writing huge blueprints that either get too large to reason-about/maintain, too heavy in their performance-impact, or both.
                          So it's not so much that C++ is useless, or that it's a bad idea for Epic to have opened-up their code-base for extending-it/building on-top of it - claiming that would be just ridiculous, and so nobody does (at least not on this thread - including me). It is much more about not fixating on a single tool for all jobs, and also looking for a middle-ground between Blueprints and C++, that kind-of offers the best of both in many respects (that is basically what the SkookumScript-UE4-Integration is aiming at becoming).

                          So to summarize - I'll just shout it out:
                          NOBODY, ESPECIALLY NOT EPIC (YOU KNOW, THE GUYS THAT MAKE UE4?) ARE SHARING YOUR VIEW(!!!)
                          Also, NOBODY, ESPECIALLY NOT THE LEADERS OF THE C++ STANDARD (YOU KNOW, THE GUYS THAT MAKE C++?) ARE SHARING YOUR IDEALIZATION OF IT(!!!)
                          How do YOU think that makes you look?

                          Despite what you insist on stating, not all issues people tend to have with C++ relate "exclusively" to their competence-level.
                          There are in fact MANY issues that are "systemic" to the language-design itself - a fact that C++ leaders are admitting quite openly and publicly. None of them share your view that "any issue any C++ developer is struggling with, is solely due to his own lack of knowledge/experience". Quite the opposite, in fact.

                          That is a very big factor contributing to the appearance of other/new languages that strive to substitute C++ for systems-programming - in particular, "D", "Rust" by Mozilla, and to-some-extent "Go" by Google. These are no minor projects/initiatives, and no puny companies - I am pretty sure Mozilla's/Google's engineers are quite competent in using C++, and these initiatives didn't just come out of nowhere - there are very real and well known problems that such organisations are facing with their C++ code-bases, so much so that it was enough for them to justify trying to create an alternative (for them and other). It just wound't possibly have happened had C++ been this perfect-shiny-gem you seem to try and make it look like...
                          In fact, I would go so far as to assume/guess that the recent momentum in C++ standards developments, is to some degree in response to such expressions-of-dissatisfaction by major players in the C++ arena...

                          And so, regardless of your personal experience with C++ and UE4, there are far too many heavily-experienced and highly-credited professionals that disagree with your view - so you'll excuse us for preferring their word as opposed to yours. But even without "appealing to their authority", the arguments speak for themselves.

                          So here is what I think is REALLY going on here - because it's not your NORMAL kind of rationality (argumentatively, you've already lost a long time ago...):
                          You've hit some hard spots in your C++ development career - perhaps even got bitten by it really painfully - so much so that you've worked hard at constructing intricate and very clever work-around(s) - but that was a long time ago, so you don't remember much of it - you're probably mostly used to the quirks and using your hard-earned work-around-code that you have accumulated, and you are very proud of it and of your skill-set. You have become "invested" in your ability to deal with such torments. So much so, that it starts feeding your ego/self-esteem as the competent developer that you are. When you look at other people struggling with such pain-points, you think to yourself:
                          "Ha!... They don't know what I do - that's why they are suffering! It's not the language's fault, it's just that I am better at it then them... I actually kinda like my evolving ability to tackle such challenges - they make me feel good about myself. I even like the fact that these pain-points exist - they enable the gap between me and other lesser programmers - this language is just the best... I love it...".

                          In that case, admitting that it's actually the language that is at fault, would render your achievements futile, and thus degrade you self-esteem (deflate your ego).
                          If any of that sounds familiar, it's because it's actually pretty common - congratulations, you've fallen-in-love with your tormentor, and there's a name for it in psychology - it's called a "Stockholm-Syndrome" (look it up...). It is actually quite easy to rationalize once you get the hang of it - it's a self-defense mechanism of the brain, and is very useful/beneficial in certain circumstances. It's a way to spare yourself the pain of acknowledging the fact that you are being tormented, by re-framing/re-interpreting reality is a distorted way from which your circumstances seem beneficial. It's a very commonly-recurring phenomenon, especially among people that deal with very difficult and painful problems (such as programmers...)
                          Well, most of us aren't at that stage (yet) regarding C++, and "hopefully" never will be.
                          So try to look at it from our perspective, if you can...
                          Last edited by EruArnold; 09-06-2014, 09:52 PM.

                          Comment


                            Originally posted by The_E View Post
                            Look, smallB, everything you've said so far may be perfectly true and may work perfectly fine for you. But that doesn't mean that your insistence that people who operate with different standards and priorities are wrong is correct too. You got your approach, we (and, as far as we can tell, a good part of the industry) have ours.
                            This thread is called: "Why C++ for Unreal 4". It isn't called "Why C++", it isn't called "Why UE4" either. In the spirit of that title my point of view I'm presenting is correct. Unreal Engine is build/designed mainly to allow build AAA games with highest standards of graphics, performance and usability just to name a few. That's why C++ is used in this engine. Because C++ gives you all of this and more. Just to name a few.

                            If you are not interested in highest possible performance, flexibility and best achievable look then yes, you don't have to use neither UE4 nor C++. But if you are, then you have to.

                            And yes, C++ isn't ideal for everything. Sure. But for most things it is. Especially in gaming industry.
                            Last edited by smallB; 09-07-2014, 04:57 AM.

                            Comment


                              Originally posted by EruArnold View Post
                              Now you're just being defensive...

                              From what I gather, the reason that "Concepts" are going to help in error-reporting at compile-time for Templates, is that they provide a mechanism for defining compile-time checking of Template-argument requirements. After a programmer clearly defines a set of requirements, the compiler uses those to impose them onto all "specialization" occurrences in the code that uses these templates - and it does that at the calling-code's location (meaning, at instanciation/specialization-point). This allows the compiler to first check/validate each template-use-point, with better-defined granularity, as well as associate this with each usage-point.
                              I think I understood it quite clearly. If I am wrong, I'de be happy to be enlightened...

                              Look, I didn't claim to be an expert on C++, you probably know more about it than I do (and obviously Bjarn knows more than the both of us combined).

                              I am just quoting things I have read/heard/seen him say.

                              There is a very obvious and strong impression expressed by Bjarn and others (such as Herb Sutter, the chair of the ISO C++ committee), of grate dis-satisfaction with the past-and-present state of affairs of C++. They all love this language, and that is exactly why they are/have-been hurting, hence the C++11 standard (previously known as C++ 0x) which they have worked very hard on for many years now, as well as the whole huge initiative that Herb is currently promoting and leading, for bringing more/fresh people into the committee's research-projects (Study-Groups) for further remedying the situation. There wouldn't be this push and this momentum of work, had C++ been this perfect language/ecosystem that you imagine. They all know very well how much it is flawed, and are working hard to fix it. They don't achieve this by "pretending" the problems don't exist (as you are doing) - they do it by acknowledging their existence and admitting how painful it is to deal with many of these issues, and inviting people to contribute and help. This is a very mature and responsible attitude that I very much like, and is actually the main reason I am studying C++ these days - It all gives me much hope that C++ might still have a very bright and even exciting future.

                              I am getting very little of this attitude (if at all...) from you - all you do is generate unsubstantiated hype and unjustified idealization, that none of the leaders of this language has ever expressed (at least from what I've seen thus far).
                              You are consistently painting a "rosy" picture of the current state of affairs, that has no baring in reality, and just makes you seem very disingenuous (even immature).
                              If you are really excited about coding C++, at least for UE4, all the fun for you - I have seen stuff you made, and they are pretty impressive.
                              But you have to at least acknowledge your own bias, and take it into consideration, when recommending a route for others - it's just the responsible thing to do.
                              Yes, UE4 is compiled with a C++11 compiler, which is more than I can say for a lot of other C++ code-bases/development-platforms, and that is a very good thing.
                              But to go one from there to claim that all game-studios and their personnel have nothing to gain from other environments for UE4, is just a pie-in-the-sky - it's just a fantasy of yours...
                              As far as Epic is concerned, the main tool suited/targeted-for rapid-prototyping of game-logic, is Blueprint - NOT C++.
                              Meaning, for most people in any EU4 game-development team, Blueprint should be their go-to system to use for most cases (and as for other scripting-languages, they are proposed by others as a substitution/additional-alternative to this layer).
                              They should use it by consuming existing Blueprint modules, as well as extended/custom ones written by the team's C++ developers which should mainly use it for exactly that purpose (writing extended/custom-modules), as well as for re-writing huge blueprints that either get too large to reason-about/maintain, too heavy in their performance-impact, or both.
                              So it's not so much that C++ is useless, or that it's a bad idea for Epic to have opened-up their code-base for extending-it/building on-top of it - claiming that would be just ridiculous, and so nobody does (at least not on this thread - including me). It is much more about not fixating on a single tool for all jobs, and also looking for a middle-ground between Blueprints and C++, that kind-of offers the best of both in many respects (that is basically what the SkookumScript-UE4-Integration is aiming at becoming).

                              So to summarize - I'll just shout it out:
                              NOBODY, ESPECIALLY NOT EPIC (YOU KNOW, THE GUYS THAT MAKE UE4?) ARE SHARING YOUR VIEW(!!!)
                              Also, NOBODY, ESPECIALLY NOT THE LEADERS OF THE C++ STANDARD (YOU KNOW, THE GUYS THAT MAKE C++?) ARE SHARING YOUR IDEALIZATION OF IT(!!!)
                              How do YOU think that makes you look?

                              Despite what you insist on stating, not all issues people tend to have with C++ relate "exclusively" to their competence-level.
                              There are in fact MANY issues that are "systemic" to the language-design itself - a fact that C++ leaders are admitting quite openly and publicly. None of them share your view that "any issue any C++ developer is struggling with, is solely due to his own lack of knowledge/experience". Quite the opposite, in fact.

                              That is a very big factor contributing to the appearance of other/new languages that strive to substitute C++ for systems-programming - in particular, "D", "Rust" by Mozilla, and to-some-extent "Go" by Google. These are no minor projects/initiatives, and no puny companies - I am pretty sure Mozilla's/Google's engineers are quite competent in using C++, and these initiatives didn't just come out of nowhere - there are very real and well known problems that such organisations are facing with their C++ code-bases, so much so that it was enough for them to justify trying to create an alternative (for them and other). It just wound't possibly have happened had C++ been this perfect-shiny-gem you seem to try and make it look like...
                              In fact, I would go so far as to assume/guess that the recent momentum in C++ standards developments, is to some degree in response to such expressions-of-dissatisfaction by major players in the C++ arena...

                              And so, regardless of your personal experience with C++ and UE4, there are far too many heavily-experienced and highly-credited professionals that disagree with your view - so you'll excuse us for preferring their word as opposed to yours. But even without "appealing to their authority", the arguments speak for themselves.

                              So here is what I think is REALLY going on here - because it's not your NORMAL kind of rationality (argumentatively, you've already lost a long time ago...):
                              You've hit some hard spots in your C++ development career - perhaps even got bitten by it really painfully - so much so that you've worked hard at constructing intricate and very clever work-around(s) - but that was a long time ago, so you don't remember much of it - you're probably mostly used to the quirks and using your hard-earned work-around-code that you have accumulated, and you are very proud of it and of your skill-set. You have become "invested" in your ability to deal with such torments. So much so, that it starts feeding your ego/self-esteem as the competent developer that you are. When you look at other people struggling with such pain-points, you think to yourself:
                              "Ha!... They don't know what I do - that's why they are suffering! It's not the language's fault, it's just that I am better at it then them... I actually kinda like my evolving ability to tackle such challenges - they make me feel good about myself. I even like the fact that these pain-points exist - they enable the gap between me and other lesser programmers - this language is just the best... I love it...".

                              In that case, admitting that it's actually the language that is at fault, would render your achievements futile, and thus degrade you self-esteem (deflate your ego).
                              If any of that sounds familiar, it's because it's actually pretty common - congratulations, you've fallen-in-love with your tormentor, and there's a name for it in psychology - it's called a "Stockholm-Syndrome" (look it up...). It is actually quite easy to rationalize once you get the hang of it - it's a self-defense mechanism of the brain, and is very useful/beneficial in certain circumstances. It's a way to spare yourself the pain of acknowledging the fact that you are being tormented, by re-framing/re-interpreting reality is a distorted way from which your circumstances seem beneficial. It's a very commonly-recurring phenomenon, especially among people that deal with very difficult and painful problems (such as programmers...)
                              Well, most of us aren't at that stage (yet) regarding C++, and "hopefully" never will be.
                              So try to look at it from our perspective, if you can...

                              You must be joking...

                              I don't claim C++ is perfect. I am aware of many flows of it. Sure.

                              But (from the experience) I know that there is simply no substitute for it at the moment.
                              C#? javascript?

                              Just look at the software made with C# (Visual Studio for example), the way it behaves and answer to yourself:
                              Do I want my product to behave like it? (mostly performance wise, but there is more to it than performance).

                              Am I biased in my opinion? Sure, aren't you?
                              Last edited by smallB; 09-07-2014, 04:51 AM.

                              Comment


                                @Epic

                                Please tell me that C++ isn't best (at the current state of affairs, that is available languages, hardware etc) for developing AAA games.

                                Please state that, give alternative (but not blueprints because they are not designed to replace C++ as a developing tool) which is superior to C++, and I will never take part in discussion about superiority of C++ over other (available at the moment) languages for AAA game developing.
                                Last edited by smallB; 09-07-2014, 05:11 AM.

                                Comment

                                Working...
                                X