This unit marks a real first dive into Unreal Engine and furthermore, Blueprints. Upon first usage in tutorials and playing around, this visual scripting language felt foreign to me and rigid. Although I could make a case for the latter, the time spent using only blueprints has offered a different perspective. The “Flow chart” nature of the blueprints is in practice logical. It gives an idea of how and when things should be happening and clearly when they are not. It simplifies processes by only allowing the user to connect to a node in which the proper input is allowed.
After getting the feel for the engine, I wanted to make more complex systems with blueprints to get the hang of them. I started messing around with ideas that I could conceptualize in code, but not necessarily in blueprints. For instance, a puzzle room that allowed the user to only access one puzzle piece (actor) at a time. Each actor would be a duplicate of the other, so accessing just one of them would have to rely on switching the access to each separately. This is where my key issue/takeaway became noticeable.
After only using blueprints I found that I was stepping away from coding practices that I once had learned: “shy” programming.
This shyness is the idea of Encapsulation, which refers to the organization of data within programs, and to a further extent Abstraction, which refers to the programmer hiding information about an object or class to reduce complexity, but also for the user’s benefitted experience.
“Encapsulation is a way to restrict the direct access to some components of an object, so users cannot access state values for all of the variables of a particular object. Encapsulation can be used to hide both data members and data functions or methods associated with an instantiated class or object.” (https://www.sumologic.com/glossary/encapsulation/).
This is for many reasons. One main reason is security. Being able to hide information from the user is crucial. By decoupling information that is not wholly relevant from one object to another, the program can operate without revealing risky information about the user. This advertently also leads to a lack of complexity. By assigning Public and Private “Getters” and “Setters”, or only letting certain information be revealed, the other classes/objects that interact with the other, does not need to know how everything works, it just uses its functions and moves on.
Ex.
class example {
private:
int a, b;
public:
void set(int x, int y)
{
a = x;
b = y;
}
void display()
{
cout << "a = " << x << endl;
cout << "b = " << y << endl;
}
}
int main()
{
example obj;
obj.set(1, 2);
obj.display()
return 0;
}The above shows that we can create an “example” object, but not access it’s properties directly. However we can “set” properties and “display” those properties.
The above principle can be extended to properties, methods, or other classes. With Inhertance and abstraction, code can act “Shy” by only revealing what is entirely necessarily. Explained further in this great paper -> “Object-Oriented Programming: An Objective Sense of Style”, K. Lieberherr, I. IIolland, A. Riel, College of Computer Science Northeastern University, September 1988 https://www2.ccs.neu.edu/research/demeter/papers/law-of-demeter/oopsla88-law-of-demeter.pdf
I have been trying to implement these same practices within Blueprints as I have found myself, while learning how to use them, frustrated with how many repeat code blocks I have found myself creating. Not only is it a waste of time, but difficult to add in new features when objects are so tightly coupled, that changing one things means changing several others. This not only future-proofs code and makes it more readable/usable, but has the added benefit of being able add new features without having to go in and fix a million things.
Add it to the list of things to keep in mind…