Announcement

Collapse
No announcement yet.

Easily convert BP to readable/edtable C++ code and back.

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

    [PROGRAMMING] Easily convert BP to readable/edtable C++ code and back.

    I know this has come up a million times already, but in light of recent upcoming Unity updates with exactly this feature. I thought to voice it again here. I think this feature should be standard at this point, it is most incredibly helpful for indie devs with small teams.

    Its upsetting to see Epic beat Unity at being first to go with visual scripting yet have Unity intend to do it right when it decides to implement it for the first time. Meanwhile 4.21 has more mobile features than i can count. Do devs even use this engine for mobile games?

    #2
    From 2017.x to 2018.x Unity has drastically changed

    UE4 already has that "nativization" thingy, but I guess the generated code isn't readable?!
    Also vertical visual scripting looks convenient, looks like YoYo Game Maker's visual scripting.
    | Finite State Machine | Savior | USQLite | Object-Pool | Sound-Occlusion | Property Transfer | Magic Nodes | MORE |

    Comment


      #3
      Originally posted by BrUnO XaVIeR View Post
      From 2017.x to 2018.x Unity has drastically changed

      UE4 already has that "nativization" thingy, but I guess the generated code isn't readable?!
      Also vertical visual scripting looks convenient, looks like YoYo Game Maker's visual scripting.
      Yes by not making the converted C++ code readable creates all sorts of issues. primarily vastly limiting artists from "helping out" programmer(s) in the team. If UE4 really wants to help out small teams to work well together ( small teams of 3 or four or five) then it needs to make this feature work, only then can a BP created by an artist be well integrated within a "cleaner code" created by the programmer or even amended in certain areas but not entirely rewritten in C++ by the programmer.

      By keeping BP separate from C++ it makes it harder to be uniform and work smoothly given all the advantages in speed that C++ offers by a simple yet good conversion.

      Unity seems to be really thinking about this and it is definitely on the right path.

      Comment


        #4
        BP code converts to C++ in almost 1/1. I think this would be a great livestream. If epic ever wants to take a bp, and convert it to C++. It would be cool if skookum would do this also. Programming is a totally different world than art. It's why Visual scripting is really awesome. You can see your connections, and nodes. It allows for a noncoder to learn quickly. I think performance isn't as bad now that the nativization is in place. It also allows you to test on an ios device without xcode. Kind of a win/win but with a dent in performance.

        Comment


          #5
          It would be great if there was an option to compile BP to C++ classes at development time - but bear in mind that the code it spews out will be equally as good/bad as the blueprint and it'll never be a good as someone actually writing it. All you do by moving to C++ is eliminate the virtual machine layer.

          In all honesty if you want readable C++, there's no substitute for hiring a C++ programmer or learning the basic Syntax. If it exists in Blueprint it exists in C++, you can very very easily tie C++ classes together based on blueprints you've already made. C++ is for some reason cordoned off by a lot of folks as being insanely difficult, but it really isn't.
          Last edited by TheJamsh; 11-15-2018, 04:55 AM.

          Comment


            #6
            Originally posted by TheJamsh View Post
            In all honesty if you want readable C++, there's no substitute for hiring a C++ programmer or learning the basic Syntax. If it exists in Blueprint it exists in C++, you can very very easily tie C++ classes together based on blueprints you've already made. C++ is for some reason cordoned off by a lot of folks as being insanely difficult, but it really isn't.
            This! Hats off to this summary!

            Unfortunately, the official Epic docs are formulated in such a way that they make beginners feel like they have to choose between BP and C++ and/or that it would be hard to port your code back and forth "manually", which is not the case, not even by a long shot. And I'm saying this as a guy who knew nothing about any sort of programming until I installed UE4.

            Comment


              #7
              Originally posted by TheJamsh View Post
              It would be great if there was an option to compile BP to C++ classes at development time - but bear in mind that the code it spews out will be equally as good/bad as the blueprint and it'll never be a good as someone actually writing it. All you do by moving to C++ is eliminate the virtual machine layer.

              In all honesty if you want readable C++, there's no substitute for hiring a C++ programmer or learning the basic Syntax. If it exists in Blueprint it exists in C++, you can very very easily tie C++ classes together based on blueprints you've already made. C++ is for some reason cordoned off by a lot of folks as being insanely difficult, but it really isn't.
              Sure no one denies that there is no substitute for a good programmer, but all i'm saying is that instead of hiring 3 programmers and have 3 more artists work on just art, we can have 3 artists work on art and BP (which they can) and one programmer to oversee it all. The cost overruns would drastically decrease and is doable IF the BP development time conversions where manageable by the programmer and easily done by artists to sort out.

              I think this is what Unity is aiming to achieve with C# , maybe C# is easier to convert or maybe other reasons i am unaware of, but i can't see why it can't be done with c++ as well.

              Sometimes this is the result of making or breaking a game from cost to functionality. For instance spawning 100's of units on screen with C++ is much more performant than doing it in BP (or even current method converted ship build code) so by the time a programmer steps in, the would be converted code from BP to C++ would yield the same speed results and not bother with having a programmer custom code that setup for that particular spawner and instead have time to focus on other important tasks. Such things save a lot of time in a production and makes choosing to hire a programmer from an artist/indie dev standpoint a much more specific job for specific scenarios, because $$$.

              Comment


                #8
                Originally posted by William K View Post

                Sure no one denies that there is no substitute for a good programmer, but all i'm saying is that instead of hiring 3 programmers and have 3 more artists work on just art, we can have 3 artists work on art and BP (which they can) and one programmer to oversee it all.
                You game just lost the gross of its potential for quality. A programmer understands OOP the way an artist wouldn't. You switch roles, you end up with PUBG-level of quality. Maybe your idea is good enough to also generate hundreds of millions while setting new lows for quality, but that's statistically very unlikely.

                A programmer knows where to abuse the UE infrastructure and where NOT to. An artist doesn't. A programmer knows when to use RPCs and when to use replication. An artist replicates 110% of things because that's the easier way. Overseeing that will not save time because you'd either waste it teaching the artists or remaking their entire work. And that's just the first example that came in my head.

                BPs are a tool which is useful in 2 fundamentally different ways: for an artist, they let them prototype things easy (not necessarily fast, but without forcing them to fully learn programming); for a programmer, they let them work much faster without sacrificing quality (the BP speed disadvantage will not be visible in good BP scripts, even without nativization). Try to combine the 2 and it's a recipe for disaster and a financial black hole when it comes to QA (bad design can't be "bug fixed" and needs to be overhauled entirely).

                It's always better to invest early, think of something 50 times and do it once, than do it poorly and fast and hope to be able to stay on top of the issues which will arise.

                Comment


                  #9
                  Please, don't get me wrong: I'm all up to giving all the power I can to artists and designers - where it makes sense. That's one of reasones why I prefer Unreal over different engines.
                  Also: where actually Unity uses C#/C++ besides of "C# nativization" for packaged game? (Perhaps I'm simply not aware of something)

                  The thing is "artists writing chaotic code without carefully thinking about systems" (because that's what most artists would do) isn't something we would desire in the first place.
                  The goal of hiring a person called "programmer" is to design performant systems, write is easy to #mantain and "future-proof". And it doesn't matter is programming language is C++, Blueprints or Lego bricks.
                  Artists (and lot of designers) love to write quick and messy scripts, repeat lot of code, make it difficult to understand and mantain.

                  - No, simple conversion of "artist script" to "programmer language" won't usually save you time. Often you need write this code differently in order to make it clean, usable and perfomant.
                  - "For instance spawning 100's of units on screen with C++ is much more performant than doing it in BP". AFAIK Calling C++ methods from blueprints doesn't cost much more than calling it in C++. Performance usually suffer because of the way the script is done.
                  - If given artist/designer is "technical" - understand how things in engine works, how to properly separate data from logic (which is so easy to mix in BP) and how to organize code... he's already a programmer.
                  - UE4 gives you this incredible opportunity to read and change engine code as you wish. This boost any "implementing person", allows to learn engine better, debug complex issues faster, truly understand method he's using.

                  I'd advise anybody to think often if doing something in blueprint or leaving it to "blueprint people" is actually cheaper... Time of "making feature simply work" isn't the only or even the most important factor here. Actually sticking to blueprints could lead to bad situation of "being locked to blueprints". Example: you can't implement custom editors - i.e. based on behavior trees.
                  Or custom dialogue plugin (based on Dialogue Plugin) which I also used as "screenplay editor" in one game - working on such editor in C++ is as easy as blueprint scripting. Allows to do things impossible in blueprints, i.e. analyzing all nodes in tree. And that allows me to pre-load assets (this is huge gain!), simplify some actions, properly separate assets from logic.

                  Seriously, once you learn write blueprints really well and you get understanding of algorithms, object-oriented programming, systems of UE4 and principles of writing features that are easy to use for other people - jumping into C++ doesn't seem to be rocket science anymore.

                  The best way to save money is to hire programmers and technical designers/artists who understand how to designs systems and tools which would be easy to use by the rest of team. This is what helps the most. It will often take longer to prototype sth, but the savings will be much bigger.

                  And I'm saying this from perspective of person which started as QA, moved to be "quest designer" (used special quest editor, some scripting and all the engine tools to implement game) in AAA company, then moved to be "gameplay designer" in indie space (which requires scripting, Kismet/Blueprints) and then voluntarily moved to C++ (still a designer, but technical one) what allows me to write better systems.

                  At some point you don't want a faster horse (non-technical people creating blueprint spaghetti), you want to get a C++ car. ~ Henry Ford
                  Last edited by Doctor Ergot; 11-15-2018, 09:13 AM.

                  Comment


                    #10
                    Originally posted by William K View Post
                    Sure no one denies that there is no substitute for a good programmer, but all i'm saying is that instead of hiring 3 programmers and have 3 more artists work on just art, we can have 3 artists work on art and BP (which they can) and one programmer to oversee it all.
                    Why hire 3 artists, when you can have 3 programmers working on code and art, and one artist to oversee it all?

                    Comment


                      #11
                      I understand both sides and find it interesting that this same conversation happened when "PlayMaker" landed on Unity (programmers weren't happy about it).
                      So what actually happened? With the advent of Antares / PlayMaker over there...

                      Turns out both sides were right and wrong, just the details vary.
                      Artists developed bad code yes, but small (tiny) studios saved money too, yes.

                      I am not sure EpicGames would ever do this, from their POV doesn't seem to make sense since they are filled with C++ programmers and solo indies aren't exactly the target demographic.
                      The only thing they need is to free the VM from excessive overhead which is already accomplished...
                      Converting the VM to readable C++, who actually would need to read them at all at Epic? I have no idea.

                      So, being as busy as they are lately, implementing something that makes little sense from their POV would be a surprise to me.
                      | Finite State Machine | Savior | USQLite | Object-Pool | Sound-Occlusion | Property Transfer | Magic Nodes | MORE |

                      Comment


                        #12
                        Originally posted by ambershee View Post

                        Why hire 3 artists, when you can have 3 programmers working on code and art, and one artist to oversee it all?
                        This can't be overstated. Game development has become so accessible and both Epic and Unity (wrongfully) tout it as easy when it really isn't. Sure you can prototype easily, but that will only serve for you to dig yourself deeper into a hole and once the project inevitably falls apart the only way forward is to start over.

                        But let's ignore that.

                        Let's assume all things being equal, and you hired 1 great programmer and 3 artists to do BP code under the programmer's supervision. Now the time comes to do a review.

                        Situation A: Readable code can be generated from BPs. Programmer reads code, reviews it, drinks himself to sleep.

                        Situation B: There is no code generation. Programmer reads the BPs just as easily, reviews it, drinks himself to sleep.

                        [Submitted] Advanced Data Validation

                        Comment


                          #13
                          Originally posted by ambershee View Post

                          Why hire 3 artists, when you can have 3 programmers working on code and art, and one artist to oversee it all?
                          Perhaps I should've clarified, the example I gave is not just 3 artists who work on assets but technical artists who can do both art and BP if required (which is what we do) and can do so pass prototype stages, but anyone in this knows they need a senior dedicated programmer early on, no denying this.

                          A programmer in my reference is someone who is a specialist in code is very well versed in using C++ in this case with UE and knows where to look as many suggested here. But sometimes we can't afford hiring more than 1 and in many respects one good one is sometimes enough for a medium sized game and if you know what you want from the game.
                          For instance the game might have "basic" setups but a lot more art. So we work accordingly.

                          None of us here would claim we are "programmers" even if we are well versed in using BP's and other script languages to create our own tools (or maybe you can do so nowadays to one degree or another) Perhaps we are just old fashioned out of respect to the respective fields ...

                          I am simply looking for a cleaner workflow to bridge gaps with BP's and C++ or maybe better documentation so we can learn and know where to look, so we can calculate expectations.





                          Comment

                          Working...
                          X