Scripting Design Pattern for Games

Question

I'm a web developer and I'm trying to create a game. After some research didn't really find any kind of definitive Design Patterns for games except the State Based (which seems to be what everyone does).

People talk about the Scripting in games but I simply couldn't find a good resource for that, or better yet, a good example of running code.

I checked out Lua and Groovy but I'm kind of lost on how do I use those scripting languages integrated with the base code of the game.

Any help is appreciated (books, sites, etc.)

Answer 1

There are various ways to support scripting in games; it's a sliding scale.

On the one extreme, you can have practically everything running using the scripting language, so you define all of your data, logic and so on using the scripts and just have some core engine functionality in C/C++. In this scheme, nearly everything on the C/C++* side is just on that side of the divide to make it efficient enough, or because it's already been written in that language and would be costly to reimplement.

On the other extreme, you can have most of your game code & data defined in C/C++ and implement bindings and or callbacks to allow some customisation via scripts. Bindings (e.g. LuaBind) allow your scripts to get and set values / call functions that aren't defined in the script code, but on the C/C++ side. Callbacks allow scripts to listen in for game events being triggered; .e.g you may have a script that is invoked when an entity is about to take damage. You can then customise / extend your game logic via scripting.

The book Game Engine Architecture does a good job of explaining the possiblities, though it doesn't include sample code or anything like that.

The how of scripting is very much dependant on what your implementation style is and which core & scripting languages you choose. If you want something more concrete, try homing in on some language choices (e.g. C++ & Lua) and then track down some tutorials like this one.

The why depends on the approach taken, but it's generally to split gameplay functionality / behaviour / data from the guts of your game engine. This makes it easier to change since you can reload scripts at runtime without rebuilding the rest of the project. A nicely implemented scripting system also makes it easier for people to get involved or to mod/extend the game without bothering a programmer.

A concrete example:

You might want to build a piece of functionality that tells a player how much damage they dealt over the course of a round.

If you do this on the C++/core side, it means getting a programmer to put in a load of very specific code to serve a very specific function, rebuilding the whole project and deploying a new version. They then check with a designer that everything is grand. If it's not, they have to recode and rebuild, sapping lots of time.

With a well designed scripting system, it's just a case of dropping a round_damage.lua script into a scripts folder. The script is automatically hoovered up and activated when the game starts, and each time a player takes damage, the "OnDamageReceived" handler is triggered. When the round ends, the OnRoundEnded callback is triggered and the script displays a message.

Providing a rich set of hooks is exposed, a scripter can do all of this without a programmer's help. If they make a mistake or want to try something else, the scripter can immediately reload the script without shutting down the game.

*Note, I say C/C++ for the core engine stuff because that's the common choice, but it could be any language that's fast enough for your purposes.

Answer 2

The question as posted is about games, but the same logic applies to any application that behaves differently at runtime based on user interaction. As Mark says, you can implement this in scripts which your application interprets, or build the features directly in your core application. Why would you want to do the former?

1. It makes your game moddable; users can add features or specialize your game.
2. It separates the platform (hardware or OS) from the game logic; this allows different teams to work on different aspects of the game simultaneously. It also makes it much easier to port or update your game.
3. It separates the application (files, networking, UI) and game (quests, graphics, sound) data. Application and game creation are different skill sets, trying to do both is about as easy as trying to make a movie where you are both the director and an actor.

So you decide you want to create a scriptable game; how to do this? First decide if you want to be a director (write the game engine) or an actor (run the scripts). Noctrine posted some good links for writing game engines.

If you want to script the game, you will be better off choosing an existing game engine. Neverwinter Nights is a published game with a good modding community. If you want a free, open source, scriptable game, consider Dungeon of Despair.

I do not recommend trying to create the game engine, scripting language, and game logic yourself. While possible, this is a titanic amount of work.