Unrealscript will be removed from UE4!!

[Neongho]

they weren't going to make it like c++ but using all the stuff of UnrealScript?

SetTimers will still be there , Objects actors to and this stuff , so there's no problem at all no ?

That wuld be great for performance : )

[DennyRocket]

Will UDK guys actually get acces to UE4? Is that even officially confirmed yet?

[reinrag]

Will UDK guys actually get acces to UE4? Is that even officially confirmed yet?

no as far as i know it has not been confirmed yet,

[sconfoy1]

this thread was revived... on page 19, the comments jump from mid june to a few days ago. i dont think anyone realized how old it was

[BmB23]

Does it matter one bit? There's a new discussion going on now. Just because it's old doesn't mean it can't still be useful.

[MonsOlympus]

lol yeah cuz a month is like waaaay old man, this is internet years here My biggest concern here is exactly whats happening, everyone is making assumptions (for this best which is great to see actually) but I really wish Epic would step forward and give us some more technical information. I really dont think it'll risk their place in the market place one bit to talk about it especially considering we can see the offerings other companies have that it'll be competiting against right now.

C++ is just such a large scope and it can virtually do anything so if I said UE4 was going to have a waffles n cream machine built in, its technically possible but is that the direction Epic is taking things? That's the question we've been waiting to hear about.

[gironecna]

My 2 cents...

The transition to C++ will only be as awesome as the black box is small. As much as I love UDK, the one recurring and infuriating issue that crops up constantly is the discrepancy between what is documented, and actual behavior. If Epic does not grant any further access to engine objects, then things won't really change; I'll still spend 3 months implementing something that should take ~30 minutes just because someone arbitrarily decided that geometry access is too low level. However, I do think transitioning to C++ is the best move Epic will have made with one exception, C++ is a harsh language; UScript is very much like HTML in that it allows for sloppy code to be run without crashing. While I personally don't have problems with the harshness of C++, having a high level scripting language(that isn't kismet) is very useful for games that encourage player modding. As mentioned many times throughout this post, adding a existing scripting language to the project could fix things, but that won't solve the overall problem of fragmentation(if adding a scripting language becomes a popular thing to do).

[NickP]

no as far as i know it has not been confirmed yet,

That is incorrect. Weephun confirmed it a few months ago in my thread about the Wired Magazine reveal.

So glad everyone is enjoying the very 1st look at UE4. I can't wait for everyone to see even more soon!

We have confirmed that Epic will release a UE4 UDK down the road, however we do not have a time-frame for that release right now. We're still shipping games using UE3, which is well-supported, and being constantly improved. I love seeing what everyone is doing with the UDK and can't wait for lots more great games/simulators/animations/etc. from everyone here!

[280Z28]

Finding people who can program something in C++ is pretty easy. Finding effective C++ programmers is one of the most challenging tasks a team can undertake. While C++ may have a performance advantage over other languages in various benchmarks, the gap shrinks (and is sometimes reversed) when you consider the experience level of developers actually involved in a project. The latter problem is more likely to affect licensees than the team working on UE4 itself. The native code of UE3 has many examples of the separate issue of "just because you can do something in a language, doesn't mean you should."

During the development cycle, C++ has a major disadvantage due to the algorithmic complexity of its compilers combined with the size of its input source files. It's theoretically possible to maintain a C++ project with consistently short compile times, but unfortunately the static analysis tools necessary to make this a general reality do not currently exist. In the end, programs written in C++ will have longer iteration times than the same program written in syntactically simpler languages.

We've been considering building a tool designed to achieve and maintain rapid C++ builds, and the shift towards native code in UE4 gives more incentive. We already have tools for batch translation of US to other languages - if a clean translation becomes apparent for the public UE4 API (if/when we ever see it), then we could include a migration aid in a future build of nFringe.

[Neongho]

i'll really miss wotgreal damn ! : P but not the slow performance

[blaklion]

Sweet!!!!! Soo much easier!!!!

[XilenceX]

I think together with the sleek looking Kismet 2 we'll have much more control over how exactly our game will turn out with the new UDK.

[ambershee]

Given the new emphasis on C++, you're free to implement whatever scripting language you so desire.

[Matheus Martino]

UDK and Unreal Engine are based on C++ so it is easy to remove support for the language Uscript (which in my opinion is nothing more than a mask for the real C++ code), they just need to remove the part which handles the translation from Uscript for C++, since the core engine is already programmed using C++. Remove support for this scripting language brings no great effort for the developers, but adds some extra time that could be spent on more important features and it may be possible that games will run faster without the scripting language. If Epic Games really remove support for Uscipt, I believe this should happen as a matter of necessity rather than by a prior decision. I always believed that the scripting language Uscript is the main responsible for the lack of dynamism in the engine, since the next version should be a little more dynamic, the development team probably should have had no alternative but to remove support to Uscript.

My only concern is if future versions of UDK are totally based on kismet with little or no access to C++ code. I hate Kismet and I am happy that I'm only using it to control some few mechanisms in animations. Just as whith me, I believe many have learned some programming language, in my case, I learned assembly and C++ when I took a electronics course, my head works much better when I look at a lot of code, than when I look to those boxes with a jumble of lines!

[StingReay]

My only concern is if future versions of UDK are totally based on kismet with little or no access to C++ code. I hate Kismet and I am happy that I'm only using it to control some few mechanisms in animations. Just as whith me, I believe many have learned some programming language, in my case, I learned assembly and C++ when I took a electronics course, my head works much better when I look at a lot of code, than when I look to those boxes with a jumble of lines!

I don't see why they'd do this if they're moving towards pure C++ for game and engine code.

[Zeqzy]

They can't give out the source code of udk for free but having kismat only sounds bad they could have given the ability to write c++ classes in udk

[Henrik]

my head works much better when I look at a lot of code, than when I look to those boxes with a jumble of lines!

For many including myself, it is the exact opposite. I understand a certain amount of code but it's so much less efficient for me to debug.

[Henrik]

I don't know where everyone is getting the idea that it's kismet only now. They even show a C++ editor window in one of the videos.

[MonsOlympus]

My biggest concern is we are losing a language that was created specifically for the purpose of gameplay programming and related tasks, there is not many of these around and of those UScript would have to be the best (if alittle old in some respects). I do appreciate it might take a reasonable investment on Epic's part going into the furture and keeping the language moving but it had alot of potential to do things raw c++ cant offer.

I do like the look of event flows and charts such as this are very common amongst designers, programmers and planners alike so it allows some transferable skills to be used but it does also limit us. For example if new events cannot be defined from gameplay code we end up in the same position we are in now

[Zeqzy]

That was visual studio
I think udk using ue4 will have no c++ or like in cryengine just one game dll

[StingReay]

That was visual studio
I think udk using ue4 will have no c++ or like in cryengine just one game dll

You can actually do a lot with a game DLL. People have even integrated different scripting languages with the CE3 SDK using just the game code.

[Hello_World!]

I really hope that UE3 UDK keeps seeing active development along side UE4, even if its less updates Im sure there are things we all require in one way or another out of UE3 UDK that arnt provided.

Exactly. Personally I don't care a bit about this Unreal Engine 4.
What I care about is the current Udk, which we can use to create great games and simulations starting from NOW. Epic just needs to tell us for how long they'll keep supporting it.