Engineering is the art of balancing trade offs. Besides the well known joke “fast, good, cheap: pick two”, there are many different constraints to be taken into consideration at every level, and there is no “one size fits all” approach to game development.
What is sure is that there are different types of programming, from the low-level core engine code to the high-level “tweakable” gameplay code, and depending on the task at hand one tool or the other might be better suited.
Gameplay code tends to be less performance critical and can hence be written using high level languages, and it can also be sandboxed so that nothing too bad can happen. Game modders all around the world keep on brilliantly demonstrating how much cool stuff can be created without drilling into lower level code.
At the end of the spectrum there are even games created without any kind of low level programming, or any kind of traditional programming for that matter. The whole logic is still here, but the tool is completely different. Exit pages of rigid syntax, enter drag&drop and boxes linked together, enter visual programming and lightweight scripting.
Sure, you are not going to create the next Battlefield this way (well, not all of it), but by working more intuitively you can unleash creativity. Look at what can be done with the level editor of Little Big Planet, all that with a gamepad!
Without going so far in that direction, visual programming can help people with little or no programming knowledge start contributing to the game. If the handles of the engine are properly exposed through a safe interface, everyone can start creating gameplay by trial and error. Some games demand only the most efficient code, but a lot will work just fine with a bit of lousy programming. Visual programming might be the long awaited return of 10 print “hello”, only that now you get a fully animated character on screen instead of some boring text. Thorough understanding is not required, as long as it works…
At this point you should be fantasising about strangling me into unconsciousness, I know I would. Shall I continue a bit? I could start ranting about “do we still need programmers?” or “what is an SPU good for anyway?”, but that would feel a bit too much like juggling with steaks in front of starving lions, I am not suicidal.
Let’s get serious. Programming is programming. It breaks down into 20% technique and 80% logic (1). You can do a lot about those 20%, change the tool and the language, make it higher level, fool-proof, visual and easy. But believing that anyone can turn into a programmer overnight is madness.
The famous article “teach yourself programming in ten years” wonders why it seems that programming is the only discipline you can learn over the course of a few days. Why can’t you teach yourself brain surgery the same way? The answer is that you can only become a very bad programmer real quick, and I just realized yesterday that my brain surgery skills were awful (2).
Am I implying that games created with more accessible tools are poorly done? Are all these flash games simple hack jobs? According to Sturgeon’s law, most are. But the others involve some brilliant programming. Not brilliant in a Knuth way, but brilliant in their balancing of constraints. Lowering the entry barrier to programming is no substitute to logic, practice and understanding. A good Flash game is a good game. Regardless of the tool used, a solid game requires solid programming.
In larger projects, I have often seen what seemed like a good idea progressively backfire: “let’s delegate work by externalizing parts of the game functionalities”. It starts with a few simple hooks and evolves into a whole programmable system as requests for flexibility get added. And it ends up being so complicated that people it was aimed at either stop using it or use it the wrong way. In both cases, programmers who made the tool to ease their work start spending increasingly more time maintaining the system and teaching others how to use it. They eventually end up being the only end users of a Turing machine gone wrong.
So be wary, programming in disguise is still programming. It is nothing intrinsically difficult, but something that has to be learned over time. Don’t expect anyone to get into it instantaneously, or be prepared for the worse. And respect the drag&drop programmers, doing it right is an art.
(1) which is completely made up, just like 87% of statistics.
(2) dude, if you can still read this, I am sorry.