So I’ve been running into a debate at work about what the proper role of a scripting language is in game development. As far as I can tell there are two schools of thought on this:
1) The scripting language is powerful and full featured. Large portions of game code are written in the language and code is only moved into C++ when performance dictates that it’s necessary. This is usually something like Lua or Unrealscript.
2) This scripting language is extremely limited. Almost all game code is in C++ and the language is only there to expose the underlying functionality to designers.
My frustration comes from seeing approach number two frequently abused, with large systems implemented in a language that does not have the features that make that code maintainable.
So I started out supporting approach number one, but after talking to some designers I realized that many of them seem to prefer number two, and its mostly programmers who prefer one.
So I’m still left wondering which approach is better. Am I just seeing bad code and blaming the tool instead of the programmer, or do we need really need a more complex tool?
I think designers need to see a language suitable for them. That’s not negotiable: they have to spend their time designing, not programming.
If scripting allows fast development of product-worthy game code, then the programmers should be doing it too. But it has to be product-worthy: doing everything twice doesn’t save time. So you have to keep scripting in its place. If a developer can script the inventory system in a week, or write it in C++ in a month, then you want full-featured scripting, if only to give you more time to hand-optimise the parts that might conceivably hit performance limits. So not the inventory, or the high-score table, or the key-mapping system, or high-level game logic like what the characters are supposed to be doing. That can all be scripted if doing so saves you any time at all to spend on speeding up the graphics and the physics: programmers need to be able to work out exactly what the bottlenecks are, and senior programmers can make a reasonable prediction what won’t be.
Designers probably shouldn’t know or care whether the programmers are using the scripting language to implement game code. They shouldn’t have an opinion whether (1) is good or bad. So even if the programmers are right to want (1), why is this inconveniencing the designers? How have they even noticed that the scripting language is full-featured, if all they ever need is a fairly small number of standard recipes? Something has gone wrong, but I don’t think it’s that Lua is too good a language.
One possibility is that using the same scripting language for both, becomes an obstacle to drawing a sharp line between the interfaces used by designers, and the interfaces internal to the game code. That, as I said at the top, is not negotiable. Even if they’re using the same scripting language, programmers still have to provide the designers with the functionality that they need to do their job. Just because designers use Lua to code up AI strategies and conversation trees, and Lua is full-featured language capable of writing a physics engine, doesn’t mean your designers are expected to write their own physics engine. Or use more than 10% of Lua’s capabilities.
You can probably do both (1) and (2), mind. There’s no reason you can’t give the programmers Lua, and the designers some miniature under-featured DSL which is ‘compiled’ into Lua with a Lua script.