Let's talk about increasing speed & productivity in Blueprint.

[]
I don’t really want to turn this thread into a C# vs C++ debate either way. The task at hand is to improve BLUEPRINT prototyping speed, not debate the finer points of text-based languages. The hope is that in doing so and providing some kind of common interface, prototyping / scripting productivity gets faster and circumvents the need for different languages.
[/]

Yeah, I’d personally like to see this, or something. I do feel that UE4 is missing a text based middle ground between C++ and BP, and I’d like to see some official support for something, that’s closer on the spectrum to text based BPs. Right now SK/UnrealJS/UnrealPython all fill this niche, but I would like to see official support eventually so we can rally around one standard in terms of community effort(not abandon the others, just have a decree so we can focus on making one extremely polished).

[]
BP Text could be a really powerful diagnostic and versioning tool…

[/]

Oh, yeah!

I actually think that a reasonably typed-out blueprint mode would be helpful, too.
But just a text format that git merges well would be nice :slight_smile:

[=VFe;581526]
Yeah, I’d personally like to see this, or something. I do feel that UE4 is missing a text based middle ground between C++ and BP, and I’d like to see some official support for something, that’s closer on the spectrum to text based BPs. Right now SK/UnrealJS/UnrealPython all fill this niche, but I would like to see official support eventually so we can rally around one standard in terms of community effort(not abandon the others, just have a decree so we can focus on making one extremely polished).
[/]

That right there makes absolutely no sense to me;
I’d rather a 1000x see them devote themselves to fix existing API bugs instead of adding one more language (which was a major strategy error Unity did with their Boo language and UnityScript).

[= ;581649]
That right there makes absolutely no sense to me;
I’d rather a 1000x see them devote themselves to fix existing API bugs instead of adding one more language (which was a major strategy error Unity did with their Boo language and UnityScript).
[/]

You’re not wrong about Unity, but I think this is expressly different. Boo/Unityscript were a solution in search of a problem, in UE4 we explicitly have a problem and are seeking a solution, so I don’t think the situations are relatable.

I don’t think this will work well at all. There is too much information which will get lost in the process and it will only end up in confusion for a lot of people. In the most basic cases it will work fine but anything beyond that it will end up being like scaling an image up, then down, then up again, then you wonder why your image is blurry. Even things as simple as node placement changes will put people off which is guaranteed to happen. You can also cheat a lot in blueprints and omit variables where you would normally put them in code. It will end up producing both hard to read code and a confusing blueprint experience if working between the two at the same time.

Ultimately it isn’t a great idea for Epic to implement and I can’t see it working out without creating lots of confusion. However, it is probably something that is worth exploring as a plugin where people can expect certain caveats. You could probably use the C# syntax, it fits well into the needed support for blueprint and has a great parser (Roslyn, see Microsoft.CodeAnalysis). Obviously you would lose access to all default namespaces but syntax wise it is probably a reasonable choice since the code parser is great for this kind of thing along with attributes and the like which comes in handy for the various blueprint access settings.

[=PixelTris;582406]
Text
[/]

I’m not sure what you mean bu the first couple of sentences in regards to image scaling etc, bear in mind that this extra window would be entirely optional and most people would never use it.

The way to think about this idea is more what @ said - in that it’s just supposed to allow you to create nodes faster, not be a new Syntax to learn. That doesn’t even have to come in the form of a text-editor at all. The key idea is to get the speed of node-creation and linking up to the same speed as a programmer can type in C++, so that seasoned programmers also get some benefit from Blueprint for rapid prototyping.

C# is something I’m trying to avoid, or any new language / syntax for that matter.

EDIT: I do have another idea actually, which doesn’t involve a text editor window at all and is just supposed to allow users to create code without using the mouse at all. I’ll update the thread with that later.

I have a feeling that this would kinda defy the nature of blueprint editor. I also think speed of working with blueprints can be improved, but the text idea seems strange to me. Maybe I would form a different impression after actually trying it.

I voted for it on the link. This would be a great feature.

I could cry for happiness if something like this is implemented. I Voted yes, absolutely.

This sounds ! Great ideas.

negative men over :rolleyes:

I my opinion, we need look forward in the search for solutions for improve, event more, the speed in blueprints, like merge different blueprints, can copy variables or use index in structures. Sorry, but this solution look like a step back.

[=;581394]
Yeah I think this might be more difficult to do than first appears. But, it seems to me that just adding more keyboard control options and making the context sensitive menu a lot smarter could go a long way to giving the functionality you want.

Through a combination of typing node names and control keys/shortcuts, it should be possible to build up a series of nodes, with connections, without taking fingers from the keyboard. It would take some smart design to make it natural to use, but would probably be a lot easier than a full on editable text representation.
[/]

I totally support this idea - it is easier to do but definitely improves a lot of blueprint experience. The points are:-

  1. Possible to do blueprint without using mouse (just keyboard).
  2. Much better context sensitive pull-down.
  3. Easier for EPIC to implement (I think so).

I know my way around in C++, but I still use blueprint extensively for input handling, UI, animation, mesh setup, particle spawning and story scripting. I’ve gotten used to dragging wires but switching between keyboard and mouse all the time, even more so because I like to add reroute nodes, is quite distracting to the thought process and being able to type out blueprint would be a tremendous boost in productivity for me. Its got my vote.

Sad this got flagged with “Won’t Fix”.

I voted but I also think that the workflow should be improved to have a mouseless experience, for example:

Once you put the first node you can navigate with the arrow keys through the nodes.
If you press CTRL you can select the left side pins, the right side with ALT and while pressed UP/DOWN to navigate.
With one pin highlighted press return to open the menu we have with RIGHT CLICK.
SHIFT+SOME KEY toggles Context Sensitive search on and off and can be used as a modifier for different actions.

This is just an example, the thing is to have the keys we already use (CTRL, ALT, SHIFT, ARROWS, RETURN…) with additional functionality.

I’m glad that you came to the same conclusion that BP is slow to work with and not maintainable. I say add a scripting language and be done with it.

They should add to Trello so we could vote on it… Simple but brilliant idea!!

In terms of a third language, there is SkookumScript… Epic even gave them some cash…

[=teak421;585637]
In terms of a third language, there is SkookumScript… Epic even gave them some cash…

[/]

Weird considering was against a scripting language. And you never know if SkookumScript will still exist next year or if it’s still going to be for free.

[=Errvald;585724]
And you never know if SkookumScript will still exist next year or if it’s still going to be for free.
[/]

The same reasoning can be applied to UE4, Unity, Cry, or any other program for that matter. Any company or product could be gone by next year.