Why continue with unrealscript if it's getting removed?

[Javier]

And after UE4 could come UE5 and this could be the endless story ... Lol. Is a joke.

Seriously speaking, I agree with Spoof and NickP. Also, in my opinion the most consistent is to work with the tools currently availables and not to base the work on assumptions... I say this because for example if there is a possibility that the new version can take 3 or 4 years this is reason enough to forget it for a while.

Concerning to the ease of porting the code from one version to another, for free users, I think this will depend of the parser (if any), that is, the syntactic analyzer which will have UE4 (as UnrealScript in UE3) and / or the header files (. h) and library function available. They are those who will condition the level of ease or difficulty and accessibility to the code.

So I think it's best to wait and once the new version comes out to learn the library functions, etc. available to us and of course only study previously the basics of C++, the overall structure, because surely many things like pointers, etc. will be useless.

For example, here insert a code fragment of a small engine using XCode (Mac) and C++ that shows how to call library functions.

#include "OtherEngine.h"

void OtherEngine::Begin ( void )
{
   OtherEngine::LoadImage ( 1, "sprite.png" );
   OtherEngine::LoadSound ( 2, "beep.wav" );
}

void OtherEngine::Loop ( void )
{
   if ( OtherEngine::GetPointerPressed()==1 )
   {
      OtherEngine::PlaySound ( 2 );

      int iThisSpriteIndex = OtherEngine::CreateSprite ( 1 );

      OtherEngine::SetSpritePosition ( iThisSpriteIndex, OtherEngine::GetPointerX(), OtherEngine::GetPointerY() );
   }
}

As you can see in this case it can not be easier. So do I not think you have to worry too much...

But it's just an assumption and an opinion.

Greetings


Petria Mud 1.989

[Solid Snake]

NickP

I see blue prints as an advanced form of archetypes. In any case, the method you've described is pretty old. The back end programming is always going to be necessary regardless.

For example, I can usually program a weapon system which allows anyone to create new weapons without the need for new code. The only time when new code is needed is when the weapon functionality is unique.

Kismet also helps game designers to prototype something, which then programmers can then implement.

[Henrik]

I agree with Solid Snake, it feels like Blueprints are essentially an advanced version of what we already have rather than a true game changer of any kind, sure, for certain applications it may be but I remember when Kismet first arrived Mark Rein was marketing it that exact way - "no longer will game artists need to run down the hall and get help from programmers".. so if anything they're just pushing things further in that direction. Enabling artists. Good, I'm an artist and can definitely appreciate that. I'm glad though that I learned early on in my life some basic things about coding syntax and so on, the more I look at different languages as above in Spoof's example the more I realize that very very little has changed since I was in school 15-20 years ago, and that I can still look at at least a fair amount of code and get the gist of what it's doing, regardless of what language it's written in. I know well enough that sometimes Kismet is not enough and that won't change with Blueprints. I'm confident that there won't be any real setbacks of any kind, and when you think about it, it would be very inefficient for Epic to go in a direction that 99% of their own staff would have to spend a long time re-learning just to get back to the level they were at before.

[NickP]

@Solid Snake, Henrik: This isn't just marketing jargon. During Alan Willard's tools walkthrough, you can clearly see that the Ourory asset was created entirely with a Blueprint in the editor. Watch Game Informer's video of Shane Caudle walking Mark Rein through his airplane prototype. Again, sans art + sound assets, the airplane was created entirely with a Blueprint in the editor, including the physics and weapon systems.

@Solid Snake: I never implied back-end programming would become unnecessary. What I am implying is that Blueprints are a step in the right direction because things like weapons, characters, vehicles, and pickups should not be part of back-end programming. It should be left to the artists and designers. Hence my excitement.

[Henrik]

@Solid Snake, Henrik: This isn't just marketing jargon. During Alan Willard's tools walkthrough, you can clearly see that the Ourory asset was created entirely with a Blueprint in the editor. Watch Game Informer's video of Shane Caudle walking Mark Rein through his airplane prototype.

I must have missed that one.

[NickP]

I must have missed that one.

You can check it out right here.

[Henrik]

Thanks I checked it out earlier. Purty cool.

[Solid Snake]

I never implied back-end programming would become unnecessary. What I am implying is that Blueprints are a step in the right direction because things like weapons, characters, vehicles, and pickups should not be part of back-end programming. It should be left to the artists and designers. Hence my excitement.

They simply have to be. The back end programming however, isn't about something that specific. It's more to do with general systems. For example, you need an object to be able to be carried by the player. The back end programming encompasses the concepts of things like what is an inventory item, what is an inventory manager and what is a player. This is mostly what I do these days in Unreal Engine 3. I don't really generally ever care about, this inventory item is a gun, a rock or an axe. Blue prints is definitely a step in an awesome direction; but it's not a dramatically new thing. It's a refinement on an existing system that has proven to work very well in UE3.

[NickP]

They simply have to be. The back end programming however, isn't about something that specific. It's more to do with general systems. For example, you need an object to be able to be carried by the player. The back end programming encompasses the concepts of things like what is an inventory item, what is an inventory manager and what is a player. This is mostly what I do these days in Unreal Engine 3. I don't really generally ever care about, this inventory item is a gun, a rock or an axe. Blue prints is definitely a step in an awesome direction; but it's not a dramatically new thing. It's a refinement on an existing system that has proven to work very well in UE3.

Right. I understand what back end programming is. The point I'm trying to make is that programmers must currently do many things that, in my opinion, don't belong in the back end. They should be in the designer's hands so the programmers can focus on more important things.

Look at Shane Caudle's flight combat prototype as an example. A programmer likely defined the rules and concepts for the engine. When Shane decided to build an airplane, he didn't need to go back to that programmer. He created the art + sound assets, constructed the airplane piece-by-piece, conformed the airplane to those established rules and concepts, decided how the player would interact with it, added weapons to it, and finally, tested and tweaked it until it felt right. Shane was able to take the airplane from concept to completion on his own.

To create the same prototype in UDK, Shane won't get much farther than creating the art assets before needing the programmer to do everything else -- define the airplane class, construct the airplane using his assets, conform the airplane to the established rules, decide how the player would interact with it, add weapons to it -- then Shane gets to test and tweak the airplane in the editor until it feels right. And that's not accounting for the back-and-forth discussions and approvals that take place in between each of those steps.

Let programmers build systems while designers build airplanes.

[Solid Snake]

That's because the older systems in UDK were not designed with archetypes in mind in the first place.

[NickP]

That's because the older systems in UDK were not designed with archetypes in mind in the first place.

I'm not sure I understand what you're responding to, nor why you keep comparing blueprints to archetypes?

[Rogdor]

I'm not sure I understand what you're responding to, nor why you keep comparing blueprints to archetypes?

Well this is just going in circles, but from the looks of things: Blueprints are just a natural progression from Archetypes. Technically speaking, they seem very close. So yes, they're comparable.

The big theory here is that you may be able to create a game without programming. For people who you don't code right now, that's a barrier being taken down, so it probably sounds like this huge leap from where things are. Except it's not, technically speaking. At least the Blueprint part isn't (there are other bigger changes for UE4, clearly). If you do code, you can already create some of that functionality already, using Archetypes.

You can setup Pawn Archetypes with a bunch of variables for different clothing, hair colour, height, walk-speed, voice, dialogue choices, etc.. Coordinate that data with the related meshes, material instances, etc.-- and then your designers don't have to enter any code to create a new type of NPC. I imagine Blueprints extend that into deeper Kismet functionality, etc. but it's much the same thing that exists now. Archetypes need a programmer to set it up initially, but Blueprints will need code support too (might be Kismet, but that's still code).

Solid Snake's talks from Unreal University were an eye-opener for me on Archetype usage. There's a lot of UnrealScript in this video, but some of it may give you an idea or two: http://www.youtube.com/watch?v=IYutkUlZ9zg&t=36m00s

Edit: Updated the video link to jump to ~37m for an example of "making a new weapon using just Archetypes".

[NickP]

This has gotten far out of hand. I just set out to discuss Blueprints because they were important and relevant to the discussion taking place. Level designers were worried they would have to learn code because of the absence of Unrealscript, but that's not the case so I just wanted to put them at ease.

[Solid Snake]

Indeed. Blueprints is definitely a great step in the right direction.

[MereMortal]

Level designers skilled in unreal script need not be concerned...surely they are Gods amongst men.

Oh and that video link "The video below, art director Shane Caudle, who has no programming experience..."
Sure Shane has no programming experience...he doesn't even know what unreal script is right ?

[Henrik]

How to define "programming experience" seems a bit loose. Anyone who has messed around with Unreal Tournament modding knows a thing or two about Unrealscript. Shane? He's even done total conversion mods.. Some would define that as programming experience. Still the point isn't lost on me, for anyone with the most basic understanding of code logic this stuff is easy peasy.

[MonsOlympus]

Okay so on the topic of blueprints, I know Unreal Engine games have been accused of being samey in the past not just from a visual style but also the types of games created with it. I know this is shifting alittle bit but I wonder what peoples thoughts are on blueprints actually starting to ruin gameplay because designers might use an established formula (saving time) over using programmers to their full extent. Already we are talking about established functionality and games like borderlands show that most games feature weapons that are very proceedural in nature and dont have that human touch.

What Im talking about here is games as an art, a human art not something of a fractal nature. UE4 is a technological breakthrough and to me it just seems like a waste to approach it from the same perspective as we currently, I think as designers we need to start creating more and I truly hope UE4 makes this easier because I do see alot of repeatition in games. This isnt to say something needs to be original (whatever that is) but alot of games dont add anything. per see. to existing forumlas and I feel blueprints wont help this it will only exacerbate issues currently ingrained in the industry.

Thanks,

[seenooh]

I highly doubt that you can make fully complicated games with Blueprints. So replacing programmers is fair and makes sense only if one is trying to make a simple casual games.

[NickP]

I highly doubt that you can make fully complicated games with Blueprints. So replacing programmers is fair and makes sense only if one is trying to make a simple casual games.

I hope no one was trying to imply that programmers will go away; I know I wasn't. This is about programmers spending more time on important things and less time on things that should be left to designers and artists. That is what Blueprints will offer.

[seenooh]

I was actually responding to Mons on this particular comment:

but I wonder what peoples thoughts are on blueprints actually starting to ruin gameplay because designers might use an established formula (saving time) over using programmers to their full extent

Whatever Blueprint will put on the table, it can maximumly be used to make simple games without needing a programmer.

[skwisdemon666]

They might have a few template options that can be mixed and matched for simple games, but there will always need to be programmers. You can't make a blueprint for an original idea. Maybe if we are lucky there will be a tool to compile uscripts into c++...

[MonsOlympus]

I'm curious, what dobwe consider more important tasks for programmers? If designers are slowly moving to where gameplay programmers were does that mean a majority of these important programmers tasks could be considered engine level?

[Spoof]

I really don't think it changes much. Designers will have the power to tinker and prototype ideas without hassling programmers, but at the end of the day designers will continue to do what they do best, as will the programmers.

Beyond that, Kismet 2 will appeal to the growing middle-ground of casual developers and hobbyists who have big ideas - but are put off by the technicalities of programming.

[Alexander77]

What about like an UnrealScript to C++ converter.

I am thinking about it, I do not think it is something which is difficult. (I just do not have UE4 to do it )

[MonsOlympus]

Beyond that, Kismet 2 will appeal to the growing middle-ground of casual developers and hobbyists who have big ideas - but are put off by the technicalities of programming.

True true, but what happens when they reach the technical limitations of kismet 2? We all know programmers, especially ones who can dedicate their time for peanuts, dont grow on tree's. Infact I would go on to say theyre a rare breed, then narrow that to just gameplay programmers and youre left with not many options. I applaud Epic for trying to fill this middle ground but even on the forums you see the more technical minded programmers stand out against the designers dabbling with uscript, neither really venturing into the others territory too much.

Basically what I feel is most needed is the removal of engine programming almost entirely, I know this sounds a tad obsure in some respects but I find myself writing gameplay systems I shouldnt really have to and goes to my comments about game engines not containing enough game. I really want to be just a gameplay designer, I want to create games and whilst knowing the technical workings is always a plus it shouldnt be required knowledge for creating games. Ofcoarse design overlaps programming and vice versa with the use of tables, flow charts etc and a certain mindset on how to approach problems. Then again this could be just the way I see things and true programming (as opposed to scripting) is less creative and more logical process.

I feel Ive gotten lost by venturing too far into programming when really its not where I want to be, I intially started uscripting because I couldnt find a programmer worth their salt who would help. After all designers are just idea people and theyre a dime a dozen (not to be confused with CEO of company X seeking everyone to do their work for them).

I am thinking about it, I do not think it is something which is difficult. (I just do not have UE4 to do it )

I was actually working on this concept already but converting from an enhanced version of uscript to uscript pure, why not go that route and improve the syntax instead of leaving the issues with uscript in there. This way we get the benefits of the uscript language with the speed of c++, win/win