Ask HN: Why is visual programming so popular for game programming?

Many people working on games have graphic design backgrounds rather than programming, so they're more comfortable with it.

A lot of game programming is tweaking parameters, which the blueprint systems provide in a click-and-drag UI rather than editing numbers in text files and recompiling.

I'm curious to hear other suggestions.

I'm working on a survival horror action RPG^1 with a friend. We're two people^2. At a high level, I write the code, he does the art. I use visual scripting a lot. Here's why:

  1. He is comfortable tweaking parameters in a visual environment. This means he can iterate without me which is faster. He comes to me with a list of things he wants accomplish. I create a bunch of tools. He's off to the races.
  2. For certain problems it's faster for me to whip together some visual code using re-usable code-building-blocks I've written. For example, sequencing through a series of states for some moment in the game or reacting to a game event.
  3. He is familiar with finite state machines -- for example the entire animation system is built on them -- and can therefore make changes to the game without my input, say changing how the boss works in combat.
  4. Plus these changes don't require recompilation, which helps speed up iteration.

As a programmer I'll say once you get your head around the paradigm it's pretty cool. A ton of game code is just glue or event handling. Visual coding is often a good fit for those problems. It also forces me to write my code in a more SOLID way -- I end up writing a bunch of atomic "tasks" that get mixed and matched in creative, unexpected ways. That means my code is usually simpler and therefore less bug prone.

The flip side is that it's very easy to wind up with a huge pile of visual code spaghetti strewn across a dozen places, and it's impossible to refactor safely -- pretty serious issues ... but when you're just two people trying to scrape by and release something before flaming out, they're not at the top of my list!

[1]: Very out of date screenshots for those curious: https://store.steampowered.com/app/1446350/You_Will_Die_Here...

[2]: Plus contractors who help with the art, sound, marketing.

With the availability of game engines, gameplay programming is actually very high-level. Most of the logic is handling some input or some collision or updating some position or timer every frame. The more complex parts of a game (collisions, physics simulation, rendering, asset management, networking, etc.) is handled by the game engine itself, so the games programmer usually only need to interface with the high-level API of these systems.

Also, games programming is HIGHLY agile. Most of the logic you implement will be thrown away. It's all about rapid prototyping and finding what is "fun". Of course, once you've found something fun you might want to build it into a solid and scalable system, but even in such a system you might want to keep the flexibility for designers to extend and add new elements as they see fit (using visual scripting!). The ability for non-programmers to be able to make gameplay changes is also an important factor.

Why the heck wouldn't it be?

Game design - especially in 3D environments - is an incredibly visual process!

Unless you are incredibly familiar with programming to start - why, if you were approaching game design, and - for instance - had level layouts, character and enemy designs, etc - prepared in advance - wouldn't you?

It's literally the most logical way to approach filling in those gaps with functionality with a visual system of design like that.

I remember hearing that studies have shown that the biggest impediment to absolute beginner programmers is the strictness of language syntax. Visual programming makes syntax errors impossible, and that's a huge benefit to those who don't have programming experience. (This was the whole motivation underlying Scratch's visual programming language, by the way.)