In the last couple of posts I’ve presented the pros and cons of using scripting languages such as LUA and Python in commercial games. To summarize, there are some powerful reasons for and against using them, and you need to think carefully about it before using them.
This time I’m going to present an alternative which is commonly used, but let me say up front that this method also has pros and cons, and I’m not attempting to say that this method is better than scripting languages.
Most games have some kind of editor for building levels. In these editors you shape the environment, and also fill the world with objects of different types. Some types of objects you might place might be, player start position, enemies, crates, trigger volumes, pickups etc. Each object will have some configurable properties. Enemies might have health and strength, crates might have a configurable number of gold coins in, etc.
The alternative to scripting languages comes in by these gameplay objects ‘sending messages’ when different events happen. In the properties for the object, you specify that when ‘X’ happens to the object, send a message called ‘Y’ to object ‘Z’. For instance, on the trigger volume object there might be an ‘on volume entered by player’ event, which could be configured to send a message called ‘Appear’ to another object called ‘Enemy62’.
This simple connecting of objects together using events and messages allows simple scripting of the game, and basically gives simple ‘if…then…’ functionality. There’s a lot of stuff missing though. What about variables, complex conditionals, timers, functions, passing parameters with messages etc? Well, you can tack these on by adding gameplay widgets which perform these goals, and generally follow the same theme of having an point-and-click style of scripting, rather than writing code.
Advantages
- You don’t have the problem of novice programmers writing bad code.
- You don’t have to use a third party scripting language (i.e. the stepping into someone else’s code problem) or have to write your own complex scripting language interpreter.
- You can tack scripting onto your game using the level editor which you’ll need anyway.
- You’d rarely have performance problems as this method doesn’t give script files which need interpreting, but also due to having a limiting simplicity, the amount of scripting is usually light.
Disadvantages
- The power of the scripting ability is pretty limited. Normally you just get simple ‘if…then…’ type operations.
- Just because you’re not giving them a coding language, it doesn’t stop the users from making convoluted scripts.
- Reading how the game scripting works can be much harder, as instead of a single list of instructions, you have a sea of objects, each firing little messages at each other.
- You’ll likely have a similar lack of IDE-like debugging tools for your scripts.
So there we go. Scripting languages – can’t live with them, can’t live without them.
Or something like that…
2 comments:
I had read somewhere previously that Half-Life does something like this, and the end result was that a simple three-floor elevator needed hundreds of separate entities to properly manage the events and state.
I believe they went back through in HL2 and modified the message type so that you could fire stateful messages; this is a good alternative to your strict if-then system, in my mind.
I don't know the specifics of Half Life, but I think you're saying that parameters can be added to messages. Yes, this helps. Instead of saying 'do damage' you can also specify a parameter of how much damage. Or you can refer to other game entities, such as saying to an enemy 'attack this' and passing the name of another entity. It helps a lot, but you can still end up with a 200 event elevator :)
Post a Comment