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?
Scripting languages are a type of programming language. They are interpreted rather than requiring compilation. These are languages designed for specific runtime environments to provide additional functions, integrate complex systems, and communicate with other programming languages.
Scripting, also known as coding or programming, is the way to write instructions for the execution for your game using a very specific language. This is similar to rules for a board game, which explain the order of turns, determining the first player, and different options at a particular moment.
Scripting languages allow players to modify game behavior without access to the code base. Just as important, they provide a sandbox that—unlike a traditional programming language—limits the types of behavior the player can introduce.
A video game programming language, or scripting language, is the code that game programmers use to produce the game's settings and mechanics.
The compile-link-run-test cycle for compiled C++ code when you're dealing with something as complex as a video game is very, very slow. Using a scripting engine allows you to make large functional changes to the game without having to compile the program. This is a massive, massive time savings. As you say, things that need optimization can be moved into C++ as required.
AAA engines are highly driven by scripting. Torque, used for Tribes II (and many other games!) is scripted, Unreal has Unrealscript and so on. Scripting isn't just for mods, it's key to efficient development.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With