Imagine you had a game engine that makes the game development process so easy it felt like cheating. I feel I almost have that engine.

I am testing the Gamepress/Hyperpad app on IOS that implements a node/flow-based scripting language (yes, it is a scripting language).

GamePress - Create, Share, and Play Mobile Games ...

It doesn't use textual programming.

When I look at the forum topics on here now with all of the technical jargon and such, I wonder why such jargon is normal on a game development website. All we want to do is make games right? If that process becomes easy enough, do you think I should be considered less of a game developer?

Is it like cheating? What do you think?

It certainly doesn't make you any less of a game developer.

Arguably it makes you less of a games programmer and more of a games designer, which is not in any way a negative, unless you plan on applying for games programmer jobs.

At this point in time, we use technical jargon because no easy venue for game creation exists. "Difficult" programming languages give us the maximum flexibily for us to be creative, whereas simple game design software like Construct limit our imagination and budget. Your notion of a simplistic piece of software to accomplish this isn't quite there yet. But maybe some day in the future.

Don't worry about it.

If it works for you, it works for you

You don't have to hand-roll your own assembly or mess around with low-level C/C++..

What really matters, though, is what goes on in your mind.

Wording matters.

Does it make you "less of a game developer"? No, you are still developing games.

If playing with the state machines and data tables are the ONLY thing you are doing the job title is likely different, perhaps "script developer" or a type of "designer", probably not "programmer" or "GPE".

If manipulating the flowcharts represents a PART of what you are doing, it can still be included under various programming umbrellas.

Many times the programmers will write both the front and back ends of these graph tools --- they write the engine side that exposes the values, and then the graphical script side that manipulates the values. The graphical values can be easily edited by other game developers, such as artists, animators, designers, and sometimes even testers. Even if the programmer is the main person who manipulates the graphical tools, if they're working on the code as well they're still programming.

Many times programmers are the best person on the team to manipulate the graphical versions of scripts, since they frequently understand what is going on under the hood. There may be several closely related functions but with different performance profiles, there may be slightly better fit to use one method or another.

I do wonder if the day is near where such a system will be acceptable as a requirement for a job in the game development market. One of the developers say that they are close to making the "language" turing complete.

I am excited because it seems Bret Victor was onto it:

Bret Victor - The Future of Programming on Vimeo

"The Future of Programming" ...

Bold claim.

Until a new future of programming comes along.

In the end of the day it's just yet another tool.

Which is cool.

Considering that processing power gets cheaper and more powerful I'd expect our tools to become increasingly powerful.

However..

Great tools doesn't make you a master craftsman.

Game developers make games -- there's no rule that says you must use or cannot use specific tools. If you make games, you're a game developer. Period.

That said, there's a reason that people who consider themselves programmers write code for the most part, rather than use these sorts of WYSIWYG graph-based langauges -- for complex problems traditional code is usually simpler to grok and is a more efficient means of expressing the solution. For example, expressing things like recursion, or loops, or variable re-use is often kludgy or impossible in graph-based tools. You're still learning some programming skills -- breaking down a problem into discrete steps, solving them, recombining for a result -- but the lack of scalability of graph-based programming generally means that there's a ceiling on the amount of complexity you will be exposed to, or could even express if you wanted to. In that sense, these kinds of tools will limit your progress as a programmer eventually, unless you are working within the bounds of a domain that fits a graph-based language well.

Graphs sometimes work well where a graph is a natural projection of the problem/solution (as in a FSM), or for straight-forward logic that can be expressed as a Directed Acyclical Graph (DAG) -- as graphics shaders often are. An unrestricted graph-based language, inevitably it seems, comes to resemble a spaghetti-plate of assembly-like statements, and is just not a viable direction IMO.

Visual program is complete garbage. (in my opinion) I completely brush it off. You always need a back end that performs the "show graphic" label you have. Does this feature add much more? How easy is it to debug?The only thing I've ever seen done well like this is AI where its simply visual State Machine nodes visually where you can double click to view the state's code. You don't write code in bubble logic, it is just a means to show state transitions.

I prefer regular programming to any visual design like this. I can say I worked on Frostbite engine and the moment I saw their diagrams like yours with thousands of lines all over the place and the amount of time we spent deciphering and debugging.........it's awful. It doesn't give you any more control. It complicates coding and it can never replace a programmer. It certainly is a bad idea when you give this "bubble programming" concept to designers so that they can "code" or "write logic". When you do that, problems happen.

Imagine you had a game engine that makes the game development process so easy it felt like cheating. I feel I almost have that engine.