How much should you use a Scripting language when writing a Game?

Ask 10 game developers if you should use more script code or less, and you will get 11 different answers. They are all correct: it’s very situation-specific. Use of scripting languages is highly dependent on the humans and the practical / project-management issues.

Why?

One language to rule them all

There’s an interesting theory in abstract Maths (bear with me):

1. There are infinitely many ways to solve a problem
2. On average, for all possible problems, they are equally good/bad
3. If you have less than “infinitely many” problems, for any set of problems, there is a set of approaches that average better than all others

Or, in other words:

1. For a given set of games you want to make, there exists a perfect programming language (you might have to invent it, but it mathematically “exists”)
   • NB: if you’re using multiple languages to make the game, we can mathematically say that’s a “super” language made by combining all the languages together
2. If you make any change to the design of the games, or add or remove a game: the perfect programming language is no longer perfect, because there’s a subtly different one that would be more perfect for the new situation
3. If you don’t yet know all the games you will ever make using this codebase, or don’t yet know the EXACT design of EVERY feature in your game … you cannot pick the “perfect” language to program it in

So, choice of language here is all about risk-reduction, compromise, educated guessing, etc.

Why scripting languages?

Code written “well” in Assembler runs faster and more efficiently than any other source code. It is hard for humans to write in Assembler, so we invented C – which is easy to convert to “good” Assembler, but easier for humans.

C is not easy for humans; it is merely “easier than Assembler”.

C++ is an extension to C … C++ is not *itself* fast or efficient: but we have very good compilers that convert it into extremely fast or efficient Assembler. We don’t code in C++ because it’s a good language for humans to write code; we code in it because it’s a decent compromise between “good for humans” and “easy to convert (compile) into something that’s good for machines”.

In contrast: Scripting languages … were invented for humans. They generally suck for machines, but are awesome for humans.

Scripting vs C++

…but it turns out that forcing humans to work in a non-friendly language (anything C derived, for starters) has some unexpected benefits. When you have a problem, and you try to explain it to a friend, the act of explaining it – of talking it through – often helps you to better understand it, or even solve it.

Writing code in C/C++/etc has a similar effect: it forces us to define our ideas more precisely, more clearly. It makes us consider interactions and side-effects we’d ignored or glossed-over. Often that results in programs that do “what I wanted, not what I thought I wanted” sooner than otherwise.

The never-ending compromise

Which leads us to the Programmers’ aphorism:

When programming, there’s no “best language”, there’s only “the best language for this particular job”. Often, it’s a combination of different languages: horses for courses.

When making a game, you should never feel bad that you have too much, or too little, scripted code.

I know hardcore C++ programmers who’ve written complete games in crappy, slow, scripting languages (ones so inefficient that they shuddered to even think about it). But it was the right decision for them at the time. e.g. if I were to write Pong today, I know performance is irrelevant, and that I have no intention of extending it beyond the simple Pong gameplay: I’d ideally write it in some obscure, esoteric language that lets me finish the thing in 6 lines of code and a total of 10 minutes coding.

Conversely, I know many game designers and artists with zero programming background who’ve gained n00b skills in C (or even C++) to enable them to write bits of their game that needed special, computer-friendly code. In particualar: GPU shaders to achieve unique, artistic special-effects.

Both are right.

Tendencies and Targets

But we can notice some bad habits we tend towards:

“When all you have is a Hammer, every problem in the world starts to look like a Nail.”

The more skilled a given programmer, the more likely they are to lean towards using a computer-friendly language: it plays to their strength. They are leveraging their hard-learned skills to make things easier for the computer.

Similarly, the more that a given game designer is focussed on the end-goal, the more likely they are to avoid computer-friendly languages: they distract from the artistic vision. They are preserving their focus on the finished game itself, while still exploring the details of the vision they’re aiming towards.

In small and indie teams, we generally value one thing above all else (AAA teams have this problem, but it’s not their biggest one):

1. Ship it.

Which means that smaller, Indie, teams should be leaning towards scripting languages everywhere, as much as they can. So long as “using a scripting language” doesn’t itself cause them increased cost!

(for instance, if you’re using Unity, you have cut-down versions of C# and Javascript available; you can add others, but that addition can cost you a lot of time and effort, so it’s only to be done when you’re sure it will save enough time to outweigh the cost)

An extreme example

There’s a personal game I’ve been working on for a few hours a month; it will take a long time to finish. Terrain is a very important part of the game, and I need extreme control of the terrain generation and the underlying data.

Here’s an early test render:

The terrain in that screenshot was hand-sculpted. This is standard trick: hand-paint your early levels etc, so you can test and refine the core gameplay. Later, when you’ve proved that the gameplay is fun enough to justify continuing development, you create procedural algorithms that approximate the hand-written ones.

I hit the point where I needed to go procedural, and trying to match my hand-created things was proving very very difficult and time-consuming. So I invented a new graphical/visual language for interactively editing and previewing procedural terrains:

Normally, this would be a huge waste of time – don’t make a tool if you’re only using it once! But for this particular project, I will be spending such a huge amount of time tweaking the terrain-generation that this mini-language / graphical tool will save me a lot of time.