5

Happy Thanksgiving, First of All, I have been searching to know if Visual Scripting is a new thing that have been made for game engines. Let me show you some example of visual Scripting visual scripting

the other thing is just regular coding like writing c++ code in IDE now I tried both of them but the question that I have been trying to figure out is, since I tried both of them it seems visual scripting is more easier, and more understandable for at least me I feel it makes sense when I connect nodes comparing it with when I am writing a code some thing like "Player controller" I will tell you how long it took me to write an enemy controller ! writing code for player controller in c++ it took me about 2 hours whereas it took me only one hour connecting nodes to make a player controller using visual scripting it , but even though it was an easy process and fast, I did not feel good about it, and I started to think more about what would be the advantage of writing c++ code rather than just connecting nodes? so here is the question: What are the advantages of writing code ? what are the advantages of using Visual script? What are the disadvantages of both of them? I know this advantages of Visual Scripting it is not as complicated as writing c++ code

Also would writing code be faster than the "already created scripts"(Visual Scripts)

Last question if you have to choose between both what would you choose Visual or writing code?

Note: I decided to ask the question here instead of game engine websites, is because here where I can find "Programmers" where in most games engine websites they all prefer the "happy way" as they call it which is (visual scripting) not the "sad way" which is (writing code)

I hope this time I did not ask some "bad" question that will result in too many negative votes :) be easy on me it is Thanksgiving ;)

Update: Here is some more information about the Visual Scripting that I am using in Unreal engine I got it from Unreal Engine website "The Blueprints visual scripting system in Unreal Engine is a complete gameplay scripting system based on the concept of using a node-based interface to create gameplay elements from within Unreal Editor. This system is extremely flexible and powerful as it provides the ability for designers to use virtually the full range of concepts and tools generally only available to programmers. Through the use of Blueprints, designers can prototype, implement, or modify virtually any gameplay element, such as: Games - set up game rules, tweak gameplay conditions, etc. Players - create variants with different meshes and Materials or character customization. Cameras - prototype new camera perspectives or change the camera dynamically during play. Input - change the player controls or allow players to pass input to items. Items - weapons, spells, pickups, triggers, etc. Environments - create randomized props or procedurally-generated items." I do not think there is such a thing like if you have to make something complicated you need to write code for it (my opinion)

  • 4
    If you need to write anything complicated, you will want actual code. – SLaks Nov 28 '14 at 00:41
  • Can you be more specific, because based on my experience I saw a lot of complicated ways to create enemy "brain" in which enemy move around listen chase and attack all done using visual scripting –  Nov 28 '14 at 00:45
  • 1
    Visual Scripting is not a new concept in Game Engines. The node system in Blueprint is a successor to Kismet from UE3. It's easier to express complex ideas in C++. I wouldn't implement an AI search algorithm or AI simulation algorithm in Blueprint for example. I wouldn't even try to do threaded code from Blueprint. – BlamKiwi Nov 28 '14 at 01:14
  • 1
    Also C++ is much much faster, from what I can tell digging around in the source code Blueprints are run in an execution engine. – BlamKiwi Nov 28 '14 at 01:16

3 Answers3

9

Visual Scripting is often used in many game engines like Unity, Construct 2, Unreal Engine etc.

Why is that? Because it's much easier.
Code written in VS is easier to understand, often single node can replace 100 lines of normal code.
To add to that, it's much more understandable, it's easier to get your head on what's going on.
More importantly, it's easy to learn so a person with small knowledge can actually use it.
There's a lot of stuff going on behind such scripts and you actually don't need to know what's happening to use it.

When you type normal code, you need to know what you are doing, it allows skilled user for far more flexibility and performance (visual scripting often lacks this). Although it's much harder to organize such projects, and code can get easily out of hand. But yeah, performance and flexibility, that's a REALLY big thing.

For example, in some engines you can just write Player Jump or something like this, and you dont care how it is happening, you dont even have to know the game mechanics, physics mechanics etc.

If I had to chose one, I would pick depending on a project. It's the same question as:
If you could create a game in Game Engine or create it from scratch with code, which one would you chose?

All of us have their own preferences. Big companies tend to create their own technology and engines so that they can work faster, and to make the work easier.

So the Adv/Disadv:

VS:
+ Rapid development
+ Easy to maintain
+ Easy to learn
+ Easy to work on in a team
+ Often portable
+ Hidden a lot of stuff that you dont have to care about
+ Much more clear
+ Often doesnt contain "code errors"
+ Clumsy-friendly (you wont forget that semicolon)
- Lack of flexibility
- You dont really know what is happening
- You will learn how to solve a problem but you wont be able to do it outside of specific engine
- Often is much slower than code
- You cant do performance updates
- Engine dependent (each uses other way of coding)
- You need to learn how each engine works
- If there is an engine bug, you cant fix , you have to wait for patch
- They are often paid, or they lack possibilities
- Oh right, limited possibilities

Code:
+ Allows you to learn how to actually do something
+ Give you way more possibilities
+ If you learn how to code, you can code anything
(if you learn engine scripting you are limited to it, you wont write any other application than game)
+ Basically no limits (outside of technical stuff)
+ If you learn 1 language, its much easier to understand any other modern language
+ You are actually in control of what is happening
+ Gives you true knowledge about how to write algorithms and program stuff
+ Code is independent of companies
+ Most things are free
+ It can be MUCH faster than scripting
- Harder to learn advanced stuff
- Harder to maintain big projects
- You are able to be clumsy and destroy stuff
- Often hard for others to understand
- Not as clear as Visual Scripting
- At some point its hard to maintain
- Lots of platform dependent stuff
- To actually do something you need to learn pretty decent amount of things

The choice really depends on situation, company, team preferences, deadline, platform, objectives etc.

I hope I kind of sorted it out for you : ).

Patryk Krawczyk
  • 1,342
  • 1
  • 14
  • 25
  • 2
    Man! That was pretty much everything! you even answered questions that I even did not think about! Thanks! –  Nov 28 '14 at 01:43
  • I dont agree with the 'Much more clear' adv of VS. – tul1 Aug 14 '17 at 08:15
  • I really doubt "single node can replace 100 lines of normal code". What I've experienced is the exact opposite: to achieve what 100 lines of code could do, you have to make huge amounts of nodes and interconnections. – CarlLee Mar 05 '18 at 03:33
6

If you look at UML, it is a modelling language that pretty much encompasses everything you can do with code, and it is great for modelling a system, however it falls short when used for program generation. Basically it takes a lot more diagramming, and a lot more diagrams, to describe really complex interactions than it does to write the equivalent code.

Take a simple 5 way switch statement. Easy to write, complicated to draw. Modelling different path-ways through a system can become very cumbersome, very quickly.

The drag-drop-connect model of code generation works very well when there is a simple data pathway, but once you are talking complex interactions between state machines, it becomes quite complex. In the past I've noticed these sort of Visual Modelling system end up with scripting on the connections to cater for the complexity, which often ends up making them more difficult to understand than straight code, and much harder to find where things are happening.

Finally, the higher level the language, the more trade-offs you have to make in terms of performance and control. So the more important these are, the lower the level of language of choice. If you are writing a highly time critical device driver function, you may end up writing assembler, while a high level menuing system for automation can happily be written in a scripting language. A visual language is a very high level language, so the trade-offs are likely to be quite high. However, the time to market tends to go down the higher the language level. So how much time and effort you want to put into something also becomes a factor.

Simon Parker
  • 1,656
  • 15
  • 37
  • 1
    EXACTLY! I forgot to mention this issue, when I am making AIbot for example I will have like more than 15 nodes connected to each other and I can barely know which one fire to the other, and to me its more harder to debug in visual scripting than in actual c++ code Thanks for the great info Simon! –  Nov 28 '14 at 01:30
1

"Visual Programming" is neither a "new" concept, nor new to game programming.

It's also a very broad concept: the idea of "visual programming" has many applications in many different domains.

You've mentioned "game programming". Another is "education". For example:

Hour of Code: Coding with Anna and Elsa

FoggyDay
  • 11,962
  • 4
  • 34
  • 48