Hi, guys, I watched last year’s review event and I got so excited to see the new scripting language.
I knew that it was in the work, but for a couple of years and I’ve been wondering why it was radio silent for such a long time.
It was such a relief that I saw Epic busy working on it and we will soon have access. hooray~!
My concern is just that by the time it is announced, it might be a little too late to make any changes, due to fundamental architecture modifications.
So I would like to start a discussion so that Epic guys know what we expect from them.
I know that the new IL has roots in SS (SkookumScript). As a scripting language, SS was very powerful and versatile with some minor quirks.
As a SS review, here are my observations. Highlights of SS.
Powerful coroutines such as Race, and Sync.
Very fast and dynamic compilation. Yes, it supports runtime hot-reloading (like Live++ without crashes and it just works) and you can’t live without it once you are using it, especially when encountering hard to reproduce bugs.
Versatile iterators. It had a clever iterator and Linq like syntax; good for functional programming.
Closure or Lambda expression.
REPL.
Lowlights of SS
Quirky syntax. It’s based on Smalltalk and it may work against adopting new users.
REPL. REPL is part of the highlight but SS REPL doesn’t remember states and it’s not possible to build up experiments.
Editor. It had a very basic editor and it’s not easy to work on a large-scale project.
The expectation from the new IL.
I expect that the new IL will include the SS Highlights from the above at least.
REPL is a standard feature these days. But it should remember the states so that we can build up experiments. It’s not really a REPL without it and all REPL that I know of works this way.
Write the Editor as an open-source plugin to the existing editor such as VSCode. Do not waste time making a custom editor. I personally use Rider and I like it a lot. I’m sure Rider guys will support it themselves and it will make it easier for them to support it. I saw you are using VSCode already but I just like to make sure that it is the case as Epic is not known to write good text Editor, coming from UE3 experiences. ^^
Please support FSM similar to UE3 Script. It’s not hard to have FSM but function, event overloading will not be possible without built-in to the language itself. The function/event overloading is not just a powerful feature but if it supports, it can help to port UE3 codes to UE5. If you had some UE3 scripting programming experiences, you will know how powerful it is.
Debugger. I expect it would be a lot better than the current Blueprint debugger. I hardly found any useful information from using it. ^^
Blueprint -> new IL converter. I’m not sure it’s possible to convert 100%, even if not, it will be very helpful to get the conversion work started. We can take immediate advantage of existing Marketplace assets and make them useful for production. In my opinion, Blueprint should be avoided in production except for prototyping and procedural stuff such as Animation, Materials, and VFX. They are not only slow but hard to understand/maintain. BPs can quickly get out of hands and so many Assets are made with blueprints they look horrible. It’s a big turn-off about UE in general. I hope the new IL will help remedy the problem and I expect much higher quality assets to be released once IL gets out the door.
I think that’s all I have to say at the high-level and please feel free to add your request or to discuss.
I hope this isn’t a complete necropost yet but I would just like to show how excited I am about the prospect of a new scripting language.
Of course I would not want to do away with Blueprint as they are very accessible even for people with no programming background whatsoever.
That said, they are not a very good tool for building a more complex game logic while the iteration times for C++ (create decorated headers and implementation, handle all sorts of cryptic template errors thrown on compile time, recompile restart editor) are abysmal.
So what I’m looking forward to:
Being able to declare a variable/parameter just by using it. No filling out input/output info about every function from some dropdown menus
Being able to define local variables just at the beginning of the scope that uses them: this is such a savior for more complex logic
Being able to do version control (merge, diff, all the standard operations in version control which you can not do with Blueprint (the BP diff tool is useless for Subversion workflow in my opinion))
Being able to write quick throwaway scripts: just write/copy some code to the REPL, see what it does. If it does what you want, promote it to a function.
Being able to simply refactor (For example moving a function to a different Blueprint is so painful now)
Being able to write long comments
Being able to organize functions by IDE regions (all functions are just on a single heap in Blueprint)
Not having to shuffle nodes around all the time. Yes, you can keep Blueprints tidy, but I find myself spending so much time just shifting nodes around so that the code is readable.
Not having to move my hand between keyboard and mouse all the time (J)
I think Blueprint is a wonderful language that has it’s place but I’m really excited about being able to write code again.
Visual scripting was great. If Verse will be instead of blueprints… good bye Unreal… If i compare Uscript (that was horror!!! :-D) with blueprints… Productivity in blueprints was 6 times shorter (maybe more and much better for teamwork). In the visual scripting I have better overview about overall vision, while the code cannot be said that way.
UE4 C++ may have negated the need for a dedicated text-based scripting language. After working UE4 Blueprints for a few years, I’ve come to appreciate Visual Scripting. Blueprints have really matured, and I think at this stage, the implementation of a text-based scripting language would be going in ReVerse. Unless it is the Visual Scripting Language too. For example, UE4 Blueprints uses text formatting to copy/paste. The BP-Text can be edited in text-editor. I’ve performed batch replacements using the method of copy BP to Text, edit Text, copy/paste Text to BP with changes.
If anything, visual scripting should be getting even more visual. Perhaps support a WebMedia Node to display Webpages, Images, Videos, Play music/sound within the Eventgraphs. I’m ready to go beyond basic Comments and would love to eliminate breaking my code emersion to go into apps for info. If we really want to push the limits, I’d vote for 3D Blueprints. We can already build levels in VR collaboratively in UnrealEditor, might as well be able to script logic in VR collaboratively in UnrealEditor.
It was very exciting to see the unveiling of UE5 yesterday but at the same time, it was very disappointed that there is no mentioning of the new scripting language. Last year’s video got me very excited about Verse. Yeah, I know. There are some haters but this thread is not about if it’s better than BP or not. I just wanted to discuss if we are going to get an IL and what we would like so that Epic will take them into the consideration before it’s written in stone. However, it’s not even part of UE5 yet. For people like me, the wait is too painful and we don’t even know what we are waiting for.
First, sorry for my poor English speech, is not my native language.
A solid game is made with solid game loop and solid subsystems. So, C++ is the way.
A tool to prototyping and help artists is welcomed. So, Blueprint is the way.
All this are ok and well think, but all this was planned for large teams.
IMHO, Epic must think about small teams. Need deals with a long term “ignored” fact: a small team can’t manage heavy programming (C++) in PROTOTYPE phase, nor programmers in a small team have to behave like artist with a tool (Bluescripts) . (BTW don’t matter the size of team, the programmer is always more productive with a scripted textual language for PROTOTYPIING).
Once Skoomscript is not supported anymore in recent Unreal versions; Unrealjs and Phyton are suiteable only for Editor and automation tasks; and Lua and Haxxe need compilation all the time, we small teams are putting heavy expectations in Verse.
IMHO, This misconcept “Blueprints for prototypiing” is about to be resolved by Epic: Verse is the answer? It seems Verse will be a language for rapid prototyping, good! If Verse can be transpiled to C++ (in build-time ony), excelent!
Also, it seems Verse will be like Smaltalk, which syntax is easy absorbed for small teams.
So, what we need now for real? We need a serious ROADMAP, MILESTONES, for Verse, from Epic.
Can we have big expectations about Verse? Please, Epic, publish some plains, some dates. Let we know if Verse will resolve small teams needs.
Mate, are you kidding, read the context, we are talking about UE.
I said it sounds like an incredible waste of time, i mean it, for the devs to develop it, just get out of your laziness and go learn code for real.
I am a software engineer already, but please do go on about how I need to “learn to code”. I just recognise that C++ isn’t always the best choice, especially in the prototyping phase. I’ve dropped as low-level as ASM before (not that I’d recommend it, but it was fun in its own way).
Most game engines support scripting languages as well, which is why Lua exists as a whole.
I wonder what that means to the design of the new scripting language.
Functional language is cool in academic settings but in games?? Sure it will help concurrency. But games are all about side-effects and in the pure functional world, side-effects are non-citizen.
Besides, I’m worried that it will further delay the already delayed introduction.
Hmm…
blueprints are great, fast to prototype etc. However there is limit how big code in blueprints can be, all because maintenance of such code, when it grows to certain size you waste more time fixing it that you “saved up” from fast prototyping and ease of use. Blueprints gets messy really fast.
C++ yes this is the way, however any mistake with those pesky pointers. Like for eg, removing actor and adding new version of it that has empty property with pointer, and C++ does not have exception for it. Usually this means crash to desktop and sometimes corrupted project. And i am so tired of fixing all that.
And there are more benefits to script:
i can copy/paste some examples, or just write them, to answer constantly repeated questions here without starting UE,
maintaining code is easier when function is done in 20 lines of text than few 4k screens
when unreal goes derp and disconnects some pins you wish it was text with some errors, instead of hanging variable with all wires deleted.
Purely functional language would be unusable for fast prototyping (unless it’s Haskell with monads). Language for gamedev would need to support both styles, because imperative style is convenient one half of tasks and functional style for the other.
Functional stuff such as first class functions, maps, folds, etc would be very nice to have. I envy Unity programmers with their LINQ, it’s so good, fast and clear way to do stuff over collections, C++ gets much more verbose. And Blueprints just get nothing because a lot of features are missing.
It’s so good that they got Haskeller for this job, I can’t wait for more updates.
Scripting language is obviously needed because it’s text (git, multi-cursor editing, fast search, shortcuts, and so on and so on)
Yeah, I agree that neither the pure functional language nor purely-non-functional language is ideal.
What I would like to see is to add functional language flavors to imperative language.
Linq would be a good example.
What I worried is that Simon would try to make Verse more like pure functional language where it doesn’t fit the bill.
One example that comes to my mind is Lisp vs Clojure.
They both look similar and people are saying Clojure is the modern Lisp but they are totally different animals.
However, having additional functional API support like Linq would be really cool.
The last few replies here have been disrespectful to be honest. Sure he created probably the most popular functional programming language, but that doesn’t mean everything he touches turns into a functional language! For what it’s worth, Tim Sweeney has been a (public) proponent of functional languages for a long, long time.
Things he likely would be working on would be compiler efficiency, language safety, concurrency, and of course performance. BPs themselves are fairly functional at times, in more of a visual way but still
We can only speculate on the lack of information. Epic hasn’t been vocal on the issue for a long time.
PS. I didn’t say I don’t like functional language. I like them but not the pure-functional language. If you programmed in pure-functional language, you will know what I mean.
I have programmed in a purely functional language, and I agree it’s not a great fit for every problem. It’s also a very different paradigm to wrap your head around, close enough to learning programming from scratch IMO.
That said, I trust a hire as high profile as this is going to be pragmatic with the context and requirements of their new position. C++ could definitely be a bit nicer if it had some more functional programming concepts, particularly the UE C++ flavour. Shoving incompatible workflows down our throat is not the end-goal of SPJ or much less Epic, I’d imagine.
