Unrealscript in Unreal Engine 4?

[macattackk]

Sorry if this post has already been made, ive searched and havnt found anything. I was just wondering what people's thoughts were on how much Unrealscript may change in Unreal Engine 4. I know these arent answerable with facts but maybe people have insight.

Will the language be relied on more or less?

Will kismet possibly gain more footing over Unrealscript in the future?

Will the language change a lot or is that mostly done in patching and updates to Unreal Engine 3?

Generally how easy is it to update code you have for a game to a next generation engine?

Basically I am just curious on the permanency of Unrealscript and if people think or know about any major shifts to look out for.

[Spoof]

Will kismet possibly gain more footing over Unrealscript in the future?

Kismet is no substitute for script. Some people leverage it's power to make complete games, but it's purpose is really to support level designers in adding interactive elements to maps. It also relies on script for most of it's functionality.

[ambershee]

I'm expecting UnrealScript to still exists, but largely exist for the purposes of being a data structure. Gameplay code would probably find it's way into a hot swappable DLL.

[macattackk]

I'm expecting UnrealScript to still exists, but largely exist for the purposes of being a data structure. Gameplay code would probably find it's way into a hot swappable DLL.

can you explain this more? do you mean it will be more C++ oriented?

[100GPing100]

Unreal Script exists since Unreal was created back in 95 and it still remains the "same".

Yes, it has been changing over the years, but it's just some minor changes.

[Crusha K. Rool]

I really hope it will remain the same, but the stagnation of it's recent development (no compiler optimization, lack of multidimensional array support) may seem like rather bad omens and can raise the thoughts that it is no longer looked into because it's role will be less significant in UE4.

That's the pessimistic view, though. The realistic one could also be that Mr. Sweeney is fully into the coding of the UE4 himself and holds any additions to UnrealScript until the next engine generation.

[macattackk]

im just scared that the development of my game in unrealscript now will become an issue if I want to upgrade to unreal engine 4 because of the language changing dramatically or because of it being used less.

[willyg302]

Most of the reason for a new engine is to handle next-gen platforms, which doesn't necessarily affect code (we're assuming a lot of stuff happens between the hardware and high level UScript that handles all of this for us). And a lot of the changes since back in the day are new functionality, not scaling back on the usefulness of UScript. If anything, moving your game to the new engine would provide more opportunities and options.

Short version: I wouldn't be worried

[MonsOlympus]

I'm not sure what will happen to unrealscript but I don't believe c/c++ is a substitute when it comes to gameplay code! I believe game theory whilst mathematical in nature delves into areas where only extensive knowledge of those languages can yeild similar results to a language designed specifically for game events. I do know that these lanuages see alot of general use so it makes for an easier entry point for any computer science major to swap fields but to me game design requires alot more than mimicry.

I would like to see where this collaboration between Epic and Adobe goes because I believe UnrealScript could learn a thing or two from ActionScript, it still has the benefits of other Ctype languages but its syntax is akin to unrealscript in that its neat, it is ofcoarse less strict so there does need to be a middle ground. The event handlers are one thing that are useful and after using C# I can see the benefits of generic types but I found the syntax there to be sloppy and more full of junk than really needed.

Im not saying I dont like c/c++ but I do believe there are better alternatives than messing about with libraries, thats one of the things I most enjoy about UnrealScript is its up and running in literally seconds. To lose that plug and play over spending time installing a huge IDE and setting up all the niggly bits would be very sad.

[ambershee]

can you explain this more? do you mean it will be more C++ oriented?

If it's a hot swappable DLL it doesn't matter what language you program it in, only that it can take and pass the relevant basic types.

[MonsOlympus]

I thought there was only a selection of languages that could be compiled to DLL files, or maybe Im wrong.

[ikifenix]

I would like you can change script and see the changes in game in real time (at least a preview), no the actual way: close udk, compile, run the game.

[ambershee]

I thought there was only a selection of languages that could be compiled to DLL files, or maybe Im wrong.

Well yes, you can't program a DLL using javascript, it does have to be a language that supports it.

[Mougli]

I don't believe c/c++ is a substitute when it comes to gameplay code! I believe game theory whilst mathematical in nature delves into areas where only extensive knowledge of those languages can yeild similar results to a language designed specifically for game events.

To me, this is about the same as saying that (for instance) German is better than English to write a book (which doesn't make much sense). The complexity of a framework has little to do with the language itself.

[Blade[UG]]

im just scared that the development of my game in unrealscript now will become an issue if I want to upgrade to unreal engine 4 because of the language changing dramatically or because of it being used less.

If you're changing game engine versions, you'll likely need to re-write it from scratch anyway, or at least very large portions of it. I wouldn't be surprised if this time there's a lot of housecleaning in the way the base scripts work. Assuming that there will still be a large quantity of script, opposing ambershee's viewpoint that it could be something else entirely.

To me, this is about the same as saying that (for instance) German is better than English to write a book (which doesn't make much sense). The complexity of a framework has little to do with the language itself.

Some computer languages are far better suited to specific purposes than others. There's not really much of an analog to that in human languages, though, other than the occasional word that has no translation to another language. (ie, the Klingons have no word for surrender, or some such)

[MonsOlympus]

Yes but both german and english are also dialects, maths on the other hand is different and without the inclusion of standard libraries (and non standard ones) the mathematical language is limited. German for instance includes english words and vice versa, so with that said its more about the libraries as I mentioned.

The issues are which library fits the requirement ,and not everyone will have experience with said alibrary so other than the core language itself pepple will still need to learn (and relearn) how to get what they need from UE.

Unrealscript is designed to be at a differnt level so it can be made for this purpose alone with enhancements to match. Its more akin to a court typewriters shorthand vs the language in question not the core language itself.

Basically in my eyes its far more beneficial to work with scripting languages then to know every minute detail behind the scenes and wrestle with those requirements. I should be able to get everything I need in gameplay without knowing exactly how renderers work, that's what engine level programmers are for.

[RNG]

It would be nice if they switch to another high level language (like python) rather than C++, but thats just my humble opinion. Language doesn't really matter anyway.

[macattackk]

If you're changing game engine versions, you'll likely need to re-write it from scratch anyway, or at least very large portions of it. I wouldn't be surprised if this time there's a lot of housecleaning in the way the base scripts work. Assuming that there will still be a large quantity of script, opposing ambershee's viewpoint that it could be something else entirely.

If this is true then atleast ill have my game outlined in some kind of code so it wont be from scratch really right? I mean programming languages are very similar to each other so Ill just transfer what I have and its ideas to the new language or new unrealscript base.

[Blade[UG]]

While this is true, if you compare something like going from unreal engine 2 to unreal engine 3, while your basic controller and pawn code is largely unchanged, merely expanded upon.. Large numbers of subsystems were completely replaced with significantly different and far more powerful systems. I guess it depends on how extensively you're getting into the code now.

Of course, I'm not saying anything from an authoritative point of view, I'd doubt that any of us here have actually seen ue4 and epic hasn't said much about it.

And I'm sure the people who have seen it are under NDA regarding it.

I'd be annoyed if there was a complete change in paradigm as to how the game is scripted, but as long as the concepts remain the same, it shouldn't be much of a transition, if you know what you're doing. If you're "faking it" by copy-paste-modifying code (not that there's anything wrong with that) you'll have a lot more difficult of a transition.

4 years or so into unreal engine 3, and I'm still learning new things I swear every day.

-- Sent from my TouchPad using Communities

[MonsOlympus]

This is certainly true if the engine shifted say to c++ for gameplay code and the functions operated the same as did the subsystems it wouldn't take a great deal of getting used to.

I want to see the subsystems change and new ones implemented, I believe too much messing with what already works so well is unwarranted n the time should be put into performance and enhancements

[A.M.M.D.]

I for one hope that they are going to get rid of the keywords local and var, they are pretty redundant. It would also be pretty neat to declare and initialize vars in the same line and to allow delectation everywhere in the script, rather then just at the top of each function/class.

[Derp]

I for one hope that they are going to get rid of the keywords local and var, they are pretty redundant. It would also be pretty neat to declare and initialize vars in the same line and to allow delectation everywhere in the script, rather then just at the top of each function/class.

Allow deceleration of a variable ANYWHERE? Now, sir that would be messy. I think the whole variable declaration system should stay the way it is, it's fine if not perfect. Who doesn't love default properties?

[GeekyPayback]

The unreal engine has always been a virtual machine. Part of the virtual machine means a language that can be compiled to the machines code. That language is unrealscript. I don't see that changing (eg those speculating about replacing unrealscript with drop-in dlls) because Epic are pushing to make the engine available on more platforms (apple products, android, R.I.P their linux support) and if you switch away from the virtual machine concept then you also loose the cross-platform functionality. Given all that, I'd put good money that unrealscript is here to stay.

The VM also allows them to de-couple the graphics engine from the physics engine, allowing UE4 to be built upon the game language that's already there, although as Blade said I'm sure the will be sub-system changes. I've coded for each of the UT engines now (AUT beta for UE 1, AUT for UE2 AUT2k4 for UE3 and now just trying to get various projects to get some traction in UDK) and each time the pawn/controller and Game/Replication structures have stayed the same, but the HUD, weapon logic and other aspects have changed paradigm.

Generally it doesn't take too long to figure out the new concept and port the old code over, but you'll never be able to just cut and past between engines unless the code you've written is a sub-class of actor or object.

[A.M.M.D.]

Allow deceleration of a variable ANYWHERE? Now, sir that would be messy. I think the whole variable declaration system should stay the way it is, it's fine if not perfect. Who doesn't love default properties?

The way it currently is, is quite a mess. Especially when you want to declare constants.

In C++ and any other decent C ripoff:

const int THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42;
//Rest of the bloody program

In UC:

var const int THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING; //Notice the redundancy of var 

//Over 9000 lines of code

defaultproperties
{
   THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42 //No semicolon
}

What where they thinking?

[Spoof]

What where they thinking?

I'm not disagreeing with your point, but if you want an untyped constant you can declare it in-line.

const THE_MEANING_OF_LIFE = 42;

But you're right, it's no substitute for the real thing and a feature I dearly miss. TBH all UnrealScript needs is an overhaul of the parser to accommodate a more standard/fluid coding style, and perhaps some optimisations under the hood.

[Derp]

The way it currently is, is quite a mess. Especially when you want to declare constants.

In C++ and any other decent C ripoff:

const int THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42;
//Rest of the bloody program

In UC:

var const int THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING; //Notice the redundancy of var 

//Over 9000 lines of code

defaultproperties
{
   THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42 //No semicolon
}

What where they thinking?

Well, to be far you can have a semicolon in the defaultproperties if you wanted, but I don't think it's really that bad!

[ambershee]

The way it currently is, is quite a mess. Especially when you want to declare constants.

In C++ and any other decent C ripoff:

const int THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42;
//Rest of the bloody program

In UC:

var const int THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING; //Notice the redundancy of var 

//Over 9000 lines of code

defaultproperties
{
   THE_MEANING_OF_LIFE_THE_UNIVERSE_AND_EVERYTHING = 42 //No semicolon
}

What where they thinking?

You're wrong: notice no var, no type and value declared on the same line. Looks like someone was thinking after all

class myclass extends someotherclass;

const MEANINGOFLIFEBLA = 42;

//2.65 million lines of bad code

defaultproperties
{
}

The unreal engine has always been a virtual machine. Part of the virtual machine means a language that can be compiled to the machines code. That language is unrealscript. I don't see that changing (eg those speculating about replacing unrealscript with drop-in dlls) because Epic are pushing to make the engine available on more platforms (apple products, android, R.I.P their linux support) and if you switch away from the virtual machine concept then you also loose the cross-platform functionality. Given all that, I'd put good money that unrealscript is here to stay.

I strongly disagree. I'd expect Epic to shift almost entirely to C++; UnrealScript was once designed to 'shield' non-programmers from having to handle overly complex game code, but at the same time it is fast becoming exactly that; overly complex game code, with nuances that are entirely unique to that language, and an awful lot of them to the point where it is becoming increasingly difficult for a C based language programmer to simply start writing code. Epic do now have Kismet, which is probably what will be advanced in favour (you can already see elements of 'Kismet 2' in Unreal 3). Hard game logic will be the realm of programmers, but minor gameplay will move to scripting in Kismet.

[A.M.M.D.]

You're wrong: notice no var, no type and value declared on the same line. Looks like someone was thinking after all

class myclass extends someotherclass;

const MEANINGOFLIFEBLA = 42;

//2.65 million lines of bad code

defaultproperties
{
}

I strongly disagree. I'd expect Epic to shift almost entirely to C++; UnrealScript was once designed to 'shield' non-programmers from having to handle overly complex game code, but at the same time it is fast becoming exactly that; overly complex game code, with nuances that are entirely unique to that language, and an awful lot of them to the point where it is becoming increasingly difficult for a C based language programmer to simply start writing code. Epic do now have Kismet, which is probably what will be advanced in favour (you can already see elements of 'Kismet 2' in Unreal 3). Hard game logic will be the realm of programmers, but minor gameplay will move to scripting in Kismet.

Hey, I didn't know that. Awesome. Regarding C++ and UC, I am of the opinion that classes are way better handled in UC then in C++. I just hate the separation between declaration and implementation. Not to mention the :: operator.

[ambershee]

I like to think of default properties as a 'constructor', and that there are no header files (and indeed, no need for them) - hence the degree of separation.

[A.M.M.D.]

But what is a constructor worth without any arguments?

[macattackk]

what exactly do you guys mean by sub-system changes?

[VendorX]

In my opinion, there will be no big change except part with 3D rendering - Tesselation etc... For sure will be more Kismet - some sort of it was already implemented in UE2.5 and they add only visuals and more complexity in UE3. UScript will stay like it is - from the beginning, because is faster than Kismet and it keep community running - maybe only more functions will pass to native.
Switch to C++ only..? I don't think so...
More open - yes... It's a Kismet job to do that...

[100GPing100]

class Me extends Actor;

/* Totally non-random variable. */
var string MyString;

DefaultProperties
{
     MyString = "Non-empty string"; // Notice a semicolon
}

// If you notice, this is found AFTER the DefaultProperties.
event PostBeginPlay()
{
     MyString = "I love Epic!";
}

/* More code here. */

Yes, it compiles.

[VendorX]

Why should not..? It's wrong place for DefaultProperties, but it seems that Epic is took into account this nOObish approach...

[100GPing100]

Why should not..? It's wrong place for DefaultProperties, but it seems that Epic is took into account this nOObish approach...

Why is it the wrong place if it is allowed?
Maybe what you wanted to say was that it's not the recommended place for it.

Saying that it is "nOObish" would allow me to say that doing this:

function Timer()
{
     // Some code.
}
function PostBeginPlay()
{
     // Whatever.
}

is "nOObish", because Timer and PostBeginPlay are events and not functions .
(The Timer event is used with SetTimer)


By the way, I do write my DefaultProperties at the end because it's faster to navigate to it like that (CTRL+END) and everyone knows where it is.

[VendorX]

Saying that it is "nOObish" would allow me to say that doing this:

function Timer()
{
     // Some code.
}
function PostBeginPlay()
{
     // Whatever.
}

is "nOObish", because Timer and PostBeginPlay are events and not functions .
(The Timer event is used with SetTimer)

There is nothing wrong if you understand the difference between an event and function...

[100GPing100]

There is nothing wrong if you understand the difference between an event and function...

At unreal script level there's no difference.

[VendorX]

You're sure..? Well, let see what we can find in Unreal Wiki...

Default properties:
The compiler removes defaultproperties and cpptext sections from source files during import. Cpptext lines will be replaced by the comment // (cpptext) to prevent line number changes, the defaultproperties block is removed without replacement, which is why it should always be placed at the end of the file after all other code.

Functions:
A function in UnrealScript is a subroutine associated with a specific class. Functions can define zero or up to sixteen parameters and optionally a return type. Various modifiers can be used in the declaration to change the way the function can be accessed or how it behaves when called.

Events:
...the keyword event may replace the keyword function without any effect on the UnrealScript level. However, when exporting native header files from script code, event functions will have calling stubs generated so the UnrealScript function can be called more easily from C++ code. These generated C++ methods have the name eventNameOfUnrealScriptFunction and their parameters and possible return type reflects the UnrealScript function declaration.

Most important difference is, that that native call -event- you can enable/disable - function not.

If you want to know how, look in to Object.uc...

//
// Probe messages.
//

native(117) final function Enable( name ProbeFunc );
native(118) final function Disable( name ProbeFunc );

[TK-Master]

How is that some of you guys prefer Unreal Script?

Ideally UScript should be removed completely from UE4 since with C++ not only you practically have infinite information resources all over the web (for UScript all we basically have is this forum, udn and unrealwiki) but it is also faster, native code and to my books it's not that harder to learn than UScript.

Of course i know that's not going to happen but, oh well.. just saying.

[MonsOlympus]

what exactly do you guys mean by sub-system changes?

For instance the Components sub-system were added in UE3 and sub-systems like effects was completely revamped in each iteration of the engine. Over the years classes extending from Object have swollen right out, now we have sub-systems for scaleform(gfx), apex physics(nx) and all kinds of other things

Ideally UScript should be removed completely from UE4 since with C++ not only you practically have infinite information resources all over the web (for UScript all we basically have is this forum, udn and unrealwiki) but it is also faster, native code and to my books it's not that harder to learn than UScript.

When was the last time you needed to manage memory (other than struct replication) in UnrealScript? There are concepts in UnrealScript that arnt contained within C++ specs for a reason, ofcoarse you can expand by using C++0x. UnrealScript is also around 15 years newer than C++ and has undergone more changes in its life than C++ has since UnrealScripts creation.

Lets put it this way, compare a weapon from a game written in C++ like say halflife I think to a UT3 weapon and you might start understanding why UnrealScript is very useful for gameplay code and events.