Announcement

Collapse
No announcement yet.

UE4 Scripting Language

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

    UE4 Scripting Language

    Tim Sweeney commented on this reddit: "It seems people at Epic are considering adding some intermediate script language between C++ and Blueprints"
    https://www.reddit.com/r/unrealengin...dering_adding/

    Posting here so the topic has more exposure.

    I would love to see Python tightly integrated in UE4. I think it's ideal for bridging that gap between BP and C++.

    I worked with Unity for a few months and hesitated to make the leap to Unreal because I wasn't sure my C++ could hack it. At first glance, I was lukewarm about Blueprints because they looked like feeble, fake programming (now I think BPs are superb, btw).

    There's often a cost / benefit analysis performed when starting new project or selecting a new engine...

    Python is a standard introductory language in school and is employed in countless projects around the world, So for many, the cost of learning UE's scripting language is low or non-existent.

    Likewise, if you do absorb the cost of learning a scripting language for UE, the benefit is huge because you will have learned probably the most pervasive and widely-applicable language there is.
    Last edited by Dayrook; 01-16-2019, 08:18 PM.

    #2
    I know we've been through the rafters before on this subject but here's my 2c anyway. The problem with C# in a nutshell is it's not massively different from C++, the reason it works so well in Unity is because of their component architecture. Sure intellisense always works properly, compile times are quick, it's far easier to read and even though UE has MM / GC ALOC w/ C++ so does C#, Unity's implementation was slow (due to GC) but C# can be very fast (In Xenko and a framework I made with OpenTK it was). There's apparently memory management options in C# 8.0 as well if anyone wants it..

    Standard C# will still confuse beginners and Unity defectors, it'll add some overhead (which may be a problem or not?) it's a massive effort to implement (even with binding scan tools) and then it'll need to be documented. Wouldn't it be more prudent to just document the C++ API properly with examples? Make sure hot reload works properly, uncouple and optimise some of the convoluted parts of the engine, help with intellisense issues and try to reduce compile times? Although if Epic did the implementation right then sure I'd snap their arm off for it.!

    LUA? Nah.! Debugging's a chore and you have to find issues at runtime, I've never once met a programmer who doesn't do things a little WYSIWYG with plenty of trial and error.. We all screw up, if that wasn't the case UE4 would be completely bug free and most AAA titles with some of the best programmers wouldn't crash etc. etc.

    Python could work there's a couple of "intellisense" (well sorta) options with pre-runtime debugging, visual studio and Eclipse are both super excellent with it.! Yes it's a fatter than LUA but worth it.

    Custom? Again not seeing the point.
    Last edited by ShadowKindGames; 01-17-2019, 03:48 AM.

    Comment


      #3
      If they go with scripting, its syntax must be easy like Python, but can't generate garbage like Python does.

      And no Virtual Machines, please.
      Whatever it is, must be compiled to "Unreal C++ Class" to avoid developers dealing with two separate engines in one.

      Then UBT compilation time must be reduced to 3000% faster. Otherwise all the effort won't be meaningful..
      | Finite State Machine | Auto-Save Plugin | USQLite Plugin | Object-Pool | Sound-Occlusion | Anti-Cheat Plugin | Property Transfer Tool | Magic Nodes |

      Comment


        #4
        I kind of like the idea of making a new Unreal Script for this problem. That is inspired by Python syntax for example, so is easy to use, to read, and to handle, and by that i mean debugging and the like.

        Comment


          #5
          Python is obviously not an option, far too slow.

          Comment


            #6
            Originally posted by Keyshooter View Post
            I kind of like the idea of making a new Unreal Script for this problem. That is inspired by Python syntax for example, so is easy to use, to read, and to handle, and by that i mean debugging and the like.
            UnrealScript was not easy to debug at all (from a programmers perspective).

            Comment


              #7
              Originally posted by project.gheist View Post

              UnrealScript was not easy to debug at all (from a programmers perspective).
              I'm not saying to use the UDK's UnrealScript, I'm saying that a new Unreal Script for the UE4 that is inspire by Python could be an option

              Comment


                #8
                I vote for SkookumScript, a language that was specifically designed for games and has been battle tested in games already. Python is not a good fit, its creator made design choices that make the language a poor fit for game development.

                Comment


                  #9
                  I start reading about the SkookumScript and yes, I kind of like it, it looks powerful and easy to use, the thing is, what about the license? I mean, I know I can use free, but is says debugging and other tools are available in pro version and stuff. I still quite yet no understand about the licensing of the tool

                  Comment


                    #10
                    Originally posted by Keyshooter View Post
                    I start reading about the SkookumScript and yes, I kind of like it, it looks powerful and easy to use, the thing is, what about the license? I mean, I know I can use free, but is says debugging and other tools are available in pro version and stuff. I still quite yet no understand about the licensing of the tool
                    The license would be irrelevant with epic solving that for everyone. But skookum script syntax/ide is super strange.. it has very cool async features but that's about it

                    Comment


                      #11
                      I quite like the syntax tbh, I think is just matter of getting use to it, like in everything, I haven't use SkookumScript, but I will sure try it out soon

                      Comment


                        #12
                        Originally posted by BrUnO XaVIeR View Post
                        And no Virtual Machines, please.
                        How do you want to make a Scripting Language without a Virtual Machine though?


                        What I want are three things:
                        More exposure to Blueprints (maybe "Expose by Default". So many things are hiddin in C++. It makes even prototyping hard in BP if I don't have the full functionality.)
                        Reduced Compile Overhead. Fewer / No Macros in any Source File. Plain C++ code should work with Unreals Memory Management.
                        Reduce the Base Classes (AActor, UObject, AGameModeBase, AGameStateBase) to the bare minimum of their functionality.
                        AActor for example is heavily bloated with stuff that should be decoupled into Components.
                        Replication, Spawning should be the only things present in AActor.
                        Input, Damage, Navigation, Rendering, Camera are things that should be either put into their respective Components or put into new components.

                        Comment


                          #13
                          Honestly, I would welcome something text based with the simplicity of C#. I am just worried that it could come at the expense of Blueprints. Right now, we are in the situation that occasionally one has to delve into C++ even if the intention is to use Blueprints only, because some obscure things aren't exposed to Blueprints yet.

                          I am worried that we could end up with 3 levels of that. That the new features would be only half-exposed in Blueprints, with the intention that the deeper usage can be accessed with the scripting language, and then even deeper of its feature would be accessible from C++ only. That could end up very messy.
                          Last edited by Rawalanche; 01-19-2019, 05:25 AM.
                          https://www.artstation.com/artist/rawalanche

                          Comment


                            #14
                            Originally posted by Raildex_ View Post

                            How do you want to make a Scripting Language without a Virtual Machine though?

                            They build a compiler that generates C++ code instead. Or use the already existing Blueprint VM.

                            If they add yet another VM then I won't use it..
                            | Finite State Machine | Auto-Save Plugin | USQLite Plugin | Object-Pool | Sound-Occlusion | Anti-Cheat Plugin | Property Transfer Tool | Magic Nodes |

                            Comment


                              #15
                              Just please, something with static typing, I don't think it would be handy to have variables that can change their type at any point and class variables that can be constructed at any time, so from me it's no for python and javascript. UnrealScript "4" would be probably best fit for the engine but new language means new IDE (or atleast plugins for available IDEs), tons of documentation, streams, active support and deep integration into engine and current workflow. Regarding the current activity of epic stuff on forums and community I don't find this options as best because it would need a lot of epic resources which likely are not available now.

                              Comment

                              Working...
                              X