Hacker News new | past | comments | ask | show | jobs | submit login

UE4 Blueprints are visual programming, and are done very well. For a lot of things they work are excellent. Everything has a very fine structure to it, you can drag off pins and get context aware options, etc. You can also have sub-functions that are their own graph, so it is cleanly separated. I really like them, and use them for a lot of things.

The issue is that when you get into complex logic and number crunching, it quickly becomes unwieldy. It is much easier to represent logic or mathematics in a flat textual format, especially if you are working in something like K. A single keystroke contains much more information than having to click around on options, create blocks, and connect the blocks. Even in a well-designed interface.

Tools have specific purposes and strengths. Use the right tool for the right job. Some kind of hybrid approach works in a lot of use cases. Sometimes visual scripting is great as an embedded DSL; and sometimes you just need all of the great benefits of high-bandwidth keyboard text entry.




Exactly. Take as an example something from a side project of mine that I recently did:

https://blueprintue.com/blueprint/jt69wz7e/

Compare that with this bit of pseudocode:

  function inputAxisHandleTeleportRotation(x, y, actingController, otherController) {
    if(actingController.isTeleporterActive) {
      // Deactivate teleporter on axis release, minding controller deadzone around 0
      if(taxicabDistance2D_(x, y, 0, 0) < thumbstickReleaseDeadzone) {
        sendEvent(new inputTeleportDeactivate(actingController, otherController);
      }
      else {
        actingController.teleportRotation = getRotationFromInput(x, y, actingController);
      }
    }
  }  
Which one is more readable for someone who's even a little bit experienced in programming? Which one is faster to create and edit?


That nested if statement, in particular, looks especially awkward in the blueprint.


I use Unreal Engine Blueprint visual scripting a lot, and I like it too.

Regarding your point about complex logic and number crunching can be alleviated by using a 'Math Expression' node... which allows math to be written in textual form in a node.


Holy hell, I didn't know about Math Expression node. Thanks! Now I have a bunch of blueprints to clean up from half a screen of hand-dragged math each.


Blueprints gain so little from adding spatial movement to code blocks. A normal language has a clear hierarchy of flow from top to bottom, with embedded branches that give a stable backbone to what otherwise becomes a mess of wires. I think a DSL with a proper visual editor like JASS in war3, starcraft2 or visual LUA editor works better in the long run because it "fails gracefully" into learning a programming language, which ultimately should be the growth curve & workflow for using a visual scripter.

Blueprints are great for the material editor where everything is going to terminate in a specially designed exit node and there is little branching logic, but even for basic level scripting it is more messy than it used to be in the industry.


I agree about using the right tool for the job. And I know UE4 Blueprints are popular so they must be doing something right. Personally I tried using them for a while and gave up. My own experience was:

1) It took me longer to create blueprints than it would have taken to write the equivalent code. I kept finding myself thinking "I could do this in 5 seconds with a couple of lines of code"

2) The blueprints quickly became unwieldy. A tangle of boxes and wires that I couldn't decipher. I find code easier to read, as a rule.

3) I didn't find it any simpler than writing code. A Blueprint is basically a parse tree. It maps pretty much 1:1 to code; it's just a visual representation of code.


> And I know UE4 Blueprints are popular so they must be doing something right.

I'd argue that 90% of it is just that they work out of the box. You download the engine bundle and you can start doing blueprints. Being able to write normal code requires you to compile UE from source, which is a non-trivial thing for any large C++ project.

I'm pretty sure if they embedded Lua or Lisp directly into the engine, and provided a half-decent editing environment in-editor, that it would meet with success just as well.




Applications are open for YC Winter 2022

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: