Site operation discussions
Blueprints enable anyone to rapidly prototype and build playable content without touching a line of code. Use Blueprints to author level, object and gameplay behaviors, modify user interface, adjust input controls
WHAT CAN YOU DO WITH BLUEPRINT?
I'm not sure if there is anything new here. It is a visual data flow language like Kismet (can we say it is just Kismet with a new name?).
Two things that might be novel:
It has a nice meta-game interface through construction scripts, which runs only during level editing.
It seems to be naturally distributed in client/server settings; blueprints and variables can be replicated on clients to locally handle cosmetic logic; events can be replicated to clients as a form of RPC.
Perhaps the biggest point of the language however, is that it seems pretty full featured.
I get that, but as you probably would agree level designers have been scripting in higher-level languages for awhile now. This language isn't meant for game programmers (as those not designing levels), who are still mostly stuck in C++ land working on components needed by those designers. So I don't see much difference, except the scripting language used by designers is now visual. As far as I can tell, this tool still not meant for programmers, meaning nothing has really changed in the VPL field where VPLs are great for people whose primary job is not to program.
Perhaps Tim Sweeney could chime in; he's been known to drop by occasionally.
My view is that you are a programmer if you write programs. If you can do other things as well such as create art or music, that doesn't make you a non-programmer. I'd rather construe what you refer to above as "programmers" as people who will tolerate low usability in programming languages due to politics and job-security considerations - that normal people would not.
It's interesting that Blueprints is statically typed - contrary to the perception that dynamically typed languages are "easier".
Now, I'd be more impressed if they had created Unreal-ed with itself, however I still find the extent of programming tasks that are being carried out with Blueprints rather remarkable.
Those who program are obviously programmers, but we have to distinguish between those whose primary skill is programming, and those who use programming as a tool. A designer has higher needs for usability because they have other skills they need to focus on (like...design). This is less true with a developer, who wants instead more power and flexibility and is willing to pay for that with more tool investment.
Even this isn't perfect though: programmers specialize also and they are obviously using programming as a tool, just a tool so hard to use that mastering it gives them the title "programmer."
My point about blueprints is that it is seems like it is making the same old trade off between usability and power, which is completely fine...we know this approach can work! So I look at the language features instead and try to find what's new and interesting. The contextual code completion is nice (I didn't see static typing, but they might need it to support that).
I decided to revisit this thread after a friend showed me this recent post from Tim Sweeney, which basically argues against "scripting" and in favor of the "pure C++" code-base adopted for Unreal Engine 4 (which, to be clear, includes this Blueprint feature).
Sweeney lists several issues that arise from using embedded scripting languages, and which led them to drop their UnrealScript language. What I am having trouble understanding is why these same concerns don't immediately apply to Blueprint as well.
What might be the differences that make a visual scripting system like this preferable to a textual one, when measured against these concerns?
That was my original point exactly.
Why would blueprints not be considered a DSL in itself? Heck, we even know how to encode dataflow languages as text, so is Tim Sweeney basically claiming that...its not worth maintaining a procedural language aside C++, so let's just go higher-level data flow declarative instead as URE's scripting story? He doesn't mention Blueprints at all in his post, so I'm just speculating.
One of the common reasons to support a scripting language in a game engine is to support live programming (or at least hot swapping) to have better turn in applying design...you get that with blueprints I think, and even hot swapping can be really hard to achieve with C++. And these advanced dynamic features are what tend to make interop hard, as you basically have to implement live enabling features (e.g. dynamic dependency tracking) there.
I'm guessing (but I may have good guesses). When I look at Blueprint examples, the interface resembles a graphical PL I helped develop in '94, with boxes connected by lines, with inputs on the left and outputs on the right. It was dataflow with immutable lazy functional evaluation. Altering an input dirtied the dependents downstream, then recomputed any output value actually shown or consumed. I added oo support in dispatch by letting you graphically declare interfaces and conformance to interfaces, so anything with the same interface could be swapped-in provided covariance and contravariance was correct for types.
I noticed Blueprint examples start with an event as first input on the left, which implies immutable message passing is favored. This is important because it can be async. That matters because you are not building recursive call trees of synchronous C++ imperative execution, which would be hell on transitions between C++ and script stacks unless they shared a common runtime for stack representation.
I thought about the following quite a bit about fifteen years ago. Suppose you write a scripting language you call from C++, and you want to support stacks where scripts call C++ and vice versa in arbitrary nesting patterns. (Say you implement map using higher order functions, mixing C++ and scripts every which way.) Furthermore, you want any given script method to be able to execute in several forms, from byte-code to AST to JIT native code. In effect, a function pointer includes manner of execution in its type info. This would be hard unless C++ used the same stack calling conventions as every other variant. But C++ is very unfriendly to any other runtime beyond its own, so boundaries cause grief.
Issues Tim listed boil down to interop and debugging. Those would be made hard by call stack mismatch just noted. And then there's "impedance mismatch" (cf wikipedia on object-relational impedance mismatch), which folks used to say when describing model disagreement causing slow accumulation of conflict. For example, I'd expect very different memory management plans in C++ and a scripting language.