thoughts on Blueprint

NOTE TO SELF: this section could really use some screenshots
- I don’t have UE installed on my home computer yet, so you’ll have to take my word for a lot of these things
- anyways back to your regularly scheduled bullet points, *ahem*
Blueprint, my arch nemesis!
- WHAT! you don’t remember me? how rude!
actually I really like Blueprint
- lots of visual languages generally feel really unpleasant to write (looking at you Scratch), but somehow Blueprint feels like exactly the opposite
  - (it’s possible Scratch got better since I last used it like 5 years ago but I remember it being pretty cumbersome to use. I had no reason to revisit it since so I simply don’t know if it’s any better now, but if it is, let’s chat!)
writing Blueprints is actually pretty darn nice and there’s a lot to learn from the editor UX and basic refactoring tools
- when you drag your mouse out of a pin, and a window will pop up giving you suggestions on what could be connected there
  - then you select from the list and it creates the node, autoconnecting stuff as necessary
    one of the nicer autoconnections it can do is when you want to call a function on an actor component
    instance functions require you to pass in a self to call the function on
    so what it does is it suggests functions to call on all the concrete components you already have in your actor, and when you select something like Destroy Component (DefaultSceneRoot), it’ll not only create a function call node, but also hook up DefaultSceneRoot as its self parameter
- when you try to connect two pins of incompatible types, it’ll automatically insert a conversion node for you
  - Blueprint is strongly typed so you can’t just pass in a Float where a String is expected, but luckily this makes the system way less painful
  - I do have a gripe with this though and it’s where it places the node. it tries very hard to center it but unfortunately never succeeds.
    perhaps a bug I could fix one day?
- from Oskar Kogut: if you change a BlueprintCallable function to const (or otherwise make it pure,) the editor will automatically correct the Exec pin flow for you
the design of Blueprint the Language is pretty dated - it is still an imperative language and has a concept similar to statements (Exec pins), which breaks the entire idea of pure data flow and introduces control flow into the mix
- this split is called pure and impure nodes, where impure nodes are those that perform control flow (ie. those with Exec pins)
- this results in weird edge cases like needing two separate node types to handle branching (one that can have side effects - Branch, and another that can’t - Select)
  - Branch is used to shuttle control flow between two Exec lines, based on a Bool. you get a True branch and a False branch
  - and Select is used to choose a value based on another value, kind of like a ternary in C++
    however it is quite annoying because you can only switch on enums (and other stuff that has a finite set of values,) whereas with Branch you can use any Bool condition you want
    this would be fine if not for the existence of Gameplay Tags, which precisely do not have a finite set of values
    there is a Switch on Gameplay Tag node, but that is for control flow and not data flow!
    this isn’t an unsolvable problem but it illustrates the pure vs impure issue pretty well - you’d have to duplicate the implementation of Switch on Gameplay Tag to have a version without an Exec pin
- I’m seeing a bit of a semblance to the classic function coloring problem
  - except where it usually applies to the async concept found in most modern programming languages, here it applies to the concept of control flow vs data flow
    and speaking of async, Blueprint handles the classic async problem very gracefully!
- despite its flaws, one of Blueprint’s strengths is asynchronous and latent tasks
  - since control flow is based on those Exec pins, you can easily map your classic concept of callbacks to simply firing off the appropriate Exec pin
  - for example the node for playing animations (Play AnimMontage) has a few pins coming out of it that signal playback events like On Ended, On Blend Out, On Interrupted
    and you wouldn’t even know these are implemented as delegates in C++landia. it just feels like a first-class feature
  - the only gripe I have is that you can only have latent nodes in the main event graph (you cannot have them within functions)
    which is annoying but not terrible, since most of that latent, high level gameplay logic happens inside the main event graph anyways
the editor UI, despite being helpful as it is, is far from perfect
- it’s actually quite janky and there tend to be brief flashes of content falling into place
  - this is true of other parts of the Unreal editor UI but I’ll focus on Blueprint here
- node UIs are laid out lazily, by default using an algorithm that does not produce precise results for pin locations
  - which means that when you first load a Blueprint, some of the wires will be bent in weird ways, and will fall into place as you zoom out and explore the graph more
    the effect looks quite janky and really upsets my inner perfectionist
- as you zoom out, the nodes start looking just a little bit different due to font sizes being snapped to integers
  - at very low zoom levels, nodes stop rendering their text altogether, which makes their layout shift even more.
    the effect of this is that nodes themselves take up less space, and it appears as though there is more space between them than there actually is
    which can make it frustrating to lay nodes out on a large scale, because you’ll only find out your nodes are overlapping when you zoom in real close
  - there’s a Straighten Connection feature, which you can use to make your graphs look more aesthetically pleasing, but it only straightens the nodes such that they look good on the current zoom level
    so what’ll happen with it sometimes is you’ll straighten a connection, then zoom in, and the connection won’t be quite straight because of the aforementioned layout shift
maintaining Blueprints in a large project could be a lot better
- with regards to your graphs becoming really large
  - everybody kinda sorta just formats nodes however they see fit, and there is no unified autoformatter
    there’s a reason people say Go’s tooling is frickin’ amazing, you know. it keeps codebases consistent!
    this results in what we Hat in Time modders used to call Kismetti in the Unreal Engine 3 days but nowadays we’d call Blueprintti
    which is a portmanteau of Blueprint and spaghetti.
    I can’t believe I remembered the spelling of that word. portmanteau.
    there are plugins on the marketplace that solve this, but I refuse to believe Epic Games doesn’t have this problem themselves
    I’d guess it’s just not very high up their priorities
  - refactoring your nodes is a hell of a pain. Blueprint is kind of write-only
    say you’re calling ApplyGameplayEffectToTarget a bunch of times and you want to replace those occurrences with a custom function that wraps ApplyGameplayEffectToTarget with some extra semantic information, to make it more discoverable, searchable, and easy to use
    well then good luck
    in a text-based language you could use a dumb search and replace to accomplish this task, but there is no such thing in Blueprint.
- with regards to assets (how long this darn stuff takes to load)
  - the biggest offender here being that hard references are the default
    thus you can add a Mesh Component to your Blueprint and it’ll load the entire mesh with all the textures and skeleton and everything when you wanna tweak a variable or some logic in the event graph
    and not asynchronously in the background, you will have to wait for it to finish loading. which is pretty annoying
the runtime performance isn’t the best for a few reasons
- the VM isn’t implemented in the most optimal way
  - I’ve analyzed this in my dispatchers repository if you wanna have a read
- and that hard reference thing can make gameplay stutter when you’re loading in new assets, but that’s a more widespread issue than just with Blueprints
- but in reality most of the logic you’re implementing in Blueprints (high-level gameplay stuff) shouldn’t be that performance sensitive
  - and it’s not hard to extract the performance sensitive parts to C++ because Blueprint offers tools for refactoring your code
but all that doesn’t prevent me from liking it!
- since it’s way more pleasant to write game logic in than C++, given that you don’t need to wait a minute for your code to recompile.