What I Learned: From C# to Blueprint
In my ventures into game development, I have noticed an ongoing stigma against visual scripting languages. In a world that’s changing pretty darn quick from the days of MS-DOS, the barriers for digital development are at an all time low, and that’s a very good thing.
As a long-time Unity user, I happen to love scripting in C#. It’s a powerful language when used in conjunction with Unity’s component based architecture. However, some see Code and immediately go cross eyed. For a long time I was one of those people, and for those who are visual thinkers, there should be alternatives that cater to their talents.
Over the past year, I worked on my first Unreal project, GasLight. Initially, I was put off at the lack of proper scripting language support. (C++ being the only supported language) And though there was an initially hurdle to cross, I eventually came to love Unreal’s Blueprint system.
For those uninitiated, Blueprint is the visual scripting language Epic rolled out in UE4 to replace and serve the function of the Kismet language from UE3. In Blueprint, you can essentially perform any of the actions you’d expect to find in a typical scripting language, though the format is as expected quite different, at least in terms of its presentation. Epic has an extensive tutorial series on how to get started using the visual language (as linked above) and generally has fairly well put together documentation for beginners.
That being said, as someone who made the transition from Unity to Unreal, I would like to describe my personal experiences, and what I’ve learned from bridging the gap between the two different formats.
Introduction: Player Controllers
To open the discussion, I will be specifically pulling examples from two different Player Controllers I built, one from a 2D Unity project, and the other a 3D Unreal project. For my C# Example, I will be pulling a script from my 2D Unity game, girl, i see right thru u.
The mechanic illustrated above is one that allows a “Ghost Mode” to be toggled when an action button is pressed. When the player is in ghost mode, they can travel through physics objects. When in a normal state, pressing the button will turn on ghost mode, and vice versa.
The organization is fairly straight forward. The action is contained within a nested if check. The toggle variable, “iIsAlpha” is what is being checked for to determine what state the player is currently in. After this is determined, colliders are set and sounds and animations play accordingly. I’ve found that you can essentially organize Blueprints in a very similar format.
In this example taken from GasLight, a simple movement function is illustrated. On the left are Blueprint events which track inputs from the player. If an input has been pressed, it will continue along the line from left to right. Events are color coded as red blocks. The next block is what’s known as a “Branch”. Branches are essentially if checks, with a boolean conditional attached. After the function has checked weather or not movement has been disabled, a movement function is called from the pawn controller parent class. (Remember, Unreal is Inheritance based!) It is also notable that functions are denoted as blue blocks.
A valid question then arises; “Where the heck do those middle circuits come into play?” Let’s take a closer look.
While not always the case, I refer to these green blocks as “Getters”, as they often perform this function. Often times, they are used to get variables, or components of vectors. In this example, on the leftmost block, Control Rotation is got from target “self”, a reference to the Player. The next block breaks the rotation into components Pitch,Yaw and Roll. Then, a new rotation is created with the Yaw component isolated. (In this game’s context, only Yaw is preserved.) Lastly, the forward and right vectors are got from the rotation, and these vectors are passed into the movement functions.
Organizing Your Blueprint: Economy of Space
If this all seems a little daunting, that’s understandable. It’s easy to get lost in your own code at times. And believe me, as character controllers often go, by the end of the project it got more and more complex.
Given the visual and sometimes awkward nature of node networks, it can be challenging to organize and comment your code. Despite better efforts, it definitely shows through that this was me teaching myself how the heck it worked. But more importantly, how to best comment and organize my code so it was readable to others.
Before we move on to best practices, commenting your code is just as important, effective, and easy to do in Blueprint than it is in other languages. By pressing “C” you can create a box around code blocks and give it a name. You can use these boxes to organize and color code your work for others to easier understand.
Above is an example from a “Level Blueprint” in GasLight that showcases some improved organization. (Level Blueprints are scripts attached to a given level or scene) Functionality demonstrated above revolves around color based movement mechanics, and I thought that having most of the script contained in a larger box shape made connecting blocks easier, as well as making it easier on the eyes. Going from left to right, “VO” and “Door” segments are placed to the farleft as they do not reference other parts of the script.
In the center is a logic loop named “Yellow Wall Check”, which checks collisions against Event triggers, as well as “Powerups Enabled” an initializer function. Because “Yellow Wall Check” is the largest block, organizing it vertically seemed to make sense to keep in line with the other smaller horizontal blocks. (Again, maintaining an overall square shape) It also feeds directly into “Yellow Upgrade”, so it is somewhat necessary to centralize. Between “Yellow Wall Check” and “Powerups Enabled” is a player reference, looking kind of like an octopus. It is somewhat self explanatory why this is centralized as well, as the player reference is used throughout the script to activate triggers. “Magenta Volume” functions similarly to “Yellow Wall Check”, taking a player reference and checking triggers.
Lastly, the rightmost “Kill Volume” and “End of Level” operate similarly to “VO” and “Door” as they do not reference many other segments. The reason for their right placement is to maintain a legible shape, as well as to provide a readable and easy avenue for a Player Reference to feed into the Kill Volume trigger checks.
Takeaways
I don’t claim to be an expert of any sort, but I hope my experiences in grappling with visual scripting languages can provide some insights. As previously stated, there are a wealth of tutorials online to get you started, but many of them do not discuss how best to organize your code. In a language strictly visual, this seems too important a detail to overlook, as was the inspiration behind this article. Hopefully you have taken away that visual scripting is no excuse for sloppiness, but rather an excellent opportunity to improve.
