October 18, 2017 at 15:00Visual scripting: has the future come yet?
This article can be considered as a review-discussion on the topic of visual programming. I have the most experience creating games on Unity, in Unreal Engine 4 I am new, so we will talk about the phenomenon of visual programming in general, and not just about UE.
We will not go too deep into history, but be aware: visual languages as such appeared a very long time ago, long before the visually beautiful Unreal Blueprint was released. Having analyzed the concept of visual programming more closely, we will see that it is based on the dataflow programming paradigm. This approach was invented back in the 70s of the last century. It consists in the fact that any program can be represented in the form of a digraph, which displays the data flow between the program components (in fact, this is the same block diagram). Unfortunately, this paradigm is now very far from trending trends, but we can return to it in the heyday of visual programming.
The desire for visualization of algorithms in humans arose almost simultaneously with the emergence of the very concept of “algorithm”. It comes from a natural desire to more accurately define and outline their goals and actions. In addition, visualization helps to better understand the idea and develop it. For example, the hieroglyphic entry in the pyramid “Mummify should be like this ...” may well be considered a visualization of the algorithm.
If we talk about programming, the first thing that comes to mind is a block diagram, the most obvious example of visual programming. When you were students at the first laboratory work, you may not have completed the tasks on the computer, but drew and handed over flowcharts on paper.
The flowcharts (at least in the days when I was studying) were followed by Pascal, followed by the divine Delphi. When I first saw Delphi, I was amazed: I could make a simple program by writing 10 lines of code (another 20 were generated by Delphi itself, but who cares). In fact, Delphi, Visual Basic, and other environments in which everyone was actively working then, were the first massive examples of visual programming. Yes, you wrote most of the code yourself, but it was already possible to throw events, change data and make an interface through convenient UIs.
Probably, the process of visual programming was so attractive that people fell ill with button-philia ... Incidentally, the screen from the 2008 program, from the article " The Interface to Kill for "
Where did this desire come from - to write a program without code? Well, first of all, it is believed that code is complicated. It `s Magic. These are terrible squiggles that cannot be understood without a matrix operator. But with all this, programming is great, prestigious and, as a rule, pleasant from a financial point of view. Hence the desire to be a programmer, which is faced with reluctance or fear of writing code (and laziness, where without it). Therefore, we are always looking for tools that have powerful functionality, but are easy to learn. This process can be traced everywhere: simplification of the software concept, simplification of interfaces, simplification of web services and the like. By the way, these same processes occur during the evolution of "ordinary" programming languages. Just compare COBOL and Python.
Obviously, you will choose the right side, at least it is pleasing to the eye.
In addition to the above reasons, visual programming is great for learning. In my opinion, this is one of its best applications. Visualization allows you to better understand the algorithms and relationships of classes and functions.
Considering modern visual programming tools, it is not necessary to immediately climb in 2017. There is a good Google Blockly project , the main function of which is educational. A small overview of the language has been Habré. Blockly is very interesting and great for teaching children programming, it can be used for school activities. Although, personally, in my opinion, the "puzzle" language system does not allow you to immediately feel all the connections of your program. I have to unravel the puzzle, like a ball.
If we take the last ten years, we can note quite a few attempts to implement a convenient and efficient system of visual programming, although so far no one has managed to take off. In any case, technological progress is on the side of visual languages. Capacities and technologies are now such that you can easily draw any constructions in the browser using smoothing and various visual effects.
The performance of the average computer has also increased: now you can run Unity or Unreal Editor without any problems and not be afraid that your PC is smoking. These changes led to the emergence of a new word in visual programming - Unreal Blueprint.
On March 19, 2014, Unreal Engine 4 was released to the public and began free distribution for everyone with a subscription for $ 19 per month. One of the most striking features of this version of the engine is the new Blueprint development environment (in our opinion, drawings).
Where did the name
Blueprint come from - a visual scripting language that allows you to write game logic without using programming languages. At least that's what he claims to be. The project consists of nodes (nodes), which are connected by data lines. Each node can represent a function, event, operator, and so on.
Examples of Nodes in Blueprint
When I first saw this system, I was delighted. It looked insanely simple and elegant. In this case, the program was read as easily as a block diagram. One could, with a bare glance, understand what the algorithm does.
Sort example. It looks quite normal.
In terms of visual programming, Blueprint is a superbly designed concept that is likely to accelerate the development of this technology. At the same time, systems like Unity Playmaker already existed before him, but, in my opinion, they are far from being so well implemented and serve as just a small add-on for the code. At the moment, other solutions with similar technology have already begun to appear, for example, a tool for creating SQL queries - VAX . In the article, the author indicated that the idea came to him just after meeting Blueprint.
In my opinion, the creation of games is an area of activity where visual programming can be used really effectively. If we take a simple puzzle or arcade (I emphasize: simple), it can be divided into elementary gameplay blocks, which the developer rewrites over and over again in each project (well, or just copies it). Why not create a library of these elementary blocks? It is with them that you work at Blueprint. Moreover, already now it is possible to divide the functionality between programmers and game designers. Some will write the filling for the blocks, while others will combine them into ready-made functionality.
For all the pleasantness of Blueprint, I did not find large projects made exclusively on it. There are a couple of products from small teams, and they are, for the most part, quite “small.” Apparently, at the moment it is impossible to create a serious project on “pure” Blueprint, you will definitely need to write C ++ code.
In addition, there are problems with really large blocks of our drawing. You can write poor code even in a powerful visual programming tool, so if you don’t think through your algorithms, you will get something like this ...
This, of course, is an exaggeration, but believe me: you can do something terrible in Blueprint that you want to burn immediately. In addition, even a well-structured project can take up a lot of space and look like an octopus that wants to eat you.
Of course, the whole project consists of separate classes, but large algorithms still look strange and scary.
Implementation of A * by one of the users of the engine. Taken from the Unreal Engine forum.
As you can see, not everything is so simple. Games still cannot be made with one click of the mouse, programs cannot be written without code, but we are gradually approaching such technologies. The main question - is it good or bad? One way or another, the future has not yet arrived.
A bit of history, or briefly about visual programming
We will not go too deep into history, but be aware: visual languages as such appeared a very long time ago, long before the visually beautiful Unreal Blueprint was released. Having analyzed the concept of visual programming more closely, we will see that it is based on the dataflow programming paradigm. This approach was invented back in the 70s of the last century. It consists in the fact that any program can be represented in the form of a digraph, which displays the data flow between the program components (in fact, this is the same block diagram). Unfortunately, this paradigm is now very far from trending trends, but we can return to it in the heyday of visual programming.
The desire for visualization of algorithms in humans arose almost simultaneously with the emergence of the very concept of “algorithm”. It comes from a natural desire to more accurately define and outline their goals and actions. In addition, visualization helps to better understand the idea and develop it. For example, the hieroglyphic entry in the pyramid “Mummify should be like this ...” may well be considered a visualization of the algorithm.
If we talk about programming, the first thing that comes to mind is a block diagram, the most obvious example of visual programming. When you were students at the first laboratory work, you may not have completed the tasks on the computer, but drew and handed over flowcharts on paper.
The flowcharts (at least in the days when I was studying) were followed by Pascal, followed by the divine Delphi. When I first saw Delphi, I was amazed: I could make a simple program by writing 10 lines of code (another 20 were generated by Delphi itself, but who cares). In fact, Delphi, Visual Basic, and other environments in which everyone was actively working then, were the first massive examples of visual programming. Yes, you wrote most of the code yourself, but it was already possible to throw events, change data and make an interface through convenient UIs.
Probably, the process of visual programming was so attractive that people fell ill with button-philia ... Incidentally, the screen from the 2008 program, from the article " The Interface to Kill for "
The modern concept of visual programming
Where did this desire come from - to write a program without code? Well, first of all, it is believed that code is complicated. It `s Magic. These are terrible squiggles that cannot be understood without a matrix operator. But with all this, programming is great, prestigious and, as a rule, pleasant from a financial point of view. Hence the desire to be a programmer, which is faced with reluctance or fear of writing code (and laziness, where without it). Therefore, we are always looking for tools that have powerful functionality, but are easy to learn. This process can be traced everywhere: simplification of the software concept, simplification of interfaces, simplification of web services and the like. By the way, these same processes occur during the evolution of "ordinary" programming languages. Just compare COBOL and Python.
Obviously, you will choose the right side, at least it is pleasing to the eye.
In addition to the above reasons, visual programming is great for learning. In my opinion, this is one of its best applications. Visualization allows you to better understand the algorithms and relationships of classes and functions.
Considering modern visual programming tools, it is not necessary to immediately climb in 2017. There is a good Google Blockly project , the main function of which is educational. A small overview of the language has been Habré. Blockly is very interesting and great for teaching children programming, it can be used for school activities. Although, personally, in my opinion, the "puzzle" language system does not allow you to immediately feel all the connections of your program. I have to unravel the puzzle, like a ball.
If we take the last ten years, we can note quite a few attempts to implement a convenient and efficient system of visual programming, although so far no one has managed to take off. In any case, technological progress is on the side of visual languages. Capacities and technologies are now such that you can easily draw any constructions in the browser using smoothing and various visual effects.
The performance of the average computer has also increased: now you can run Unity or Unreal Editor without any problems and not be afraid that your PC is smoking. These changes led to the emergence of a new word in visual programming - Unreal Blueprint.
Unrealistic drawings
On March 19, 2014, Unreal Engine 4 was released to the public and began free distribution for everyone with a subscription for $ 19 per month. One of the most striking features of this version of the engine is the new Blueprint development environment (in our opinion, drawings).
Where did the name
Blueprint come from - a visual scripting language that allows you to write game logic without using programming languages. At least that's what he claims to be. The project consists of nodes (nodes), which are connected by data lines. Each node can represent a function, event, operator, and so on.
Examples of Nodes in Blueprint
When I first saw this system, I was delighted. It looked insanely simple and elegant. In this case, the program was read as easily as a block diagram. One could, with a bare glance, understand what the algorithm does.
Sort example. It looks quite normal.
In terms of visual programming, Blueprint is a superbly designed concept that is likely to accelerate the development of this technology. At the same time, systems like Unity Playmaker already existed before him, but, in my opinion, they are far from being so well implemented and serve as just a small add-on for the code. At the moment, other solutions with similar technology have already begun to appear, for example, a tool for creating SQL queries - VAX . In the article, the author indicated that the idea came to him just after meeting Blueprint.
In my opinion, the creation of games is an area of activity where visual programming can be used really effectively. If we take a simple puzzle or arcade (I emphasize: simple), it can be divided into elementary gameplay blocks, which the developer rewrites over and over again in each project (well, or just copies it). Why not create a library of these elementary blocks? It is with them that you work at Blueprint. Moreover, already now it is possible to divide the functionality between programmers and game designers. Some will write the filling for the blocks, while others will combine them into ready-made functionality.
The future has not come yet ...
For all the pleasantness of Blueprint, I did not find large projects made exclusively on it. There are a couple of products from small teams, and they are, for the most part, quite “small.” Apparently, at the moment it is impossible to create a serious project on “pure” Blueprint, you will definitely need to write C ++ code.
In addition, there are problems with really large blocks of our drawing. You can write poor code even in a powerful visual programming tool, so if you don’t think through your algorithms, you will get something like this ...
This, of course, is an exaggeration, but believe me: you can do something terrible in Blueprint that you want to burn immediately. In addition, even a well-structured project can take up a lot of space and look like an octopus that wants to eat you.
Of course, the whole project consists of separate classes, but large algorithms still look strange and scary.
Implementation of A * by one of the users of the engine. Taken from the Unreal Engine forum.
As you can see, not everything is so simple. Games still cannot be made with one click of the mouse, programs cannot be written without code, but we are gradually approaching such technologies. The main question - is it good or bad? One way or another, the future has not yet arrived.