Scripting Philosophy
A key component of the Metaplace architecture is the back-end scripting system that drives the game server. This system has been designed based on lessons learned from the team members’ 50+ years of combined experience developing and producing on-line games and web applications. Exposure to the internal workings of many MMOs and MUDs has given the Areae team a rich source of both successful and not-so-successful examples of scripting engines for on-line games, and general programming language development. Even though MetaScript is still at the alpha stage, it is the result of applying these lessons and integrating them with modern programming language ideas.
The goals of MetaScript are conflicted - it must be easy to use, but it must also be powerful. During the process of developing MetaScript and fighting with these requirements, we came up with a list of goals for the programming environment. Below is a summary of that list that was cut&pasted directly from our internal wiki:
- Easy to learn
- familiar or easily understood coding syntax
- familiar or easily understood scoping rules
- small number of new keywords
- limited number of language infrastructure API functions
- consistent behavior of API functions
- consistent behavior of data objects
- Ability to write code quickly
- avoid boilerplate code and redundant code
- consistent and uniform behavior of objects
- minimize workflow dependencies on outside tools
- type inference (don’t require users to specify type when it can be inferred by the system)
- scope inference (don’t require users to specify scope when it can be inferred by the system)
- Others
- Prevent users from making mistakes
- Performance
- Stability
- Ability to debug
- Practicality of implementation
- Security
- Ability to expose meta-data to external tools
The concrete nature of this list was extremely useful is guiding design discussions and implementation choices. One of the most interesting items is “limited number of language infrastructure API functions”. What this really means is that a lot goes on behind the scenes in the framework that makes it easy for users to write powerful scripts – even when they know what is happening in the background. The results of this are a system that really allows you to get work done fast. Once people are familiar with MetaScript and the surrounding framework they will be able to make all kinds of interesting things very quickly and easily.
The MetaScript Framework
So, with all this theory in the bag, what does the actual framework look like? MetaScript is an event-driven environment like Flash or Director, and not coincidentally, this is also how many on-line game servers work. The components of the framework are templates, commands, triggers and scripts. At a very high level, templates are meta-data that define types of game objects, commands define entry points into the system from users and NPCs, triggers define events that occur within the system, and scripts define handlers for commands and triggers. These components are described in more detail below.
The scripting environment uses the programming language Lua as the scripting language. To quote www.lua.org, “Lua is a powerful, fast, light-weight, embeddable scripting language”. These characteristics make it ideally suited to be the language for writing behavioral code in virtual worlds and on-line games. It matches well with the philosophical goals outlined above, and its open nature allows us to sand-box it to allow safe execution of user written code in our servers. There is a tension in any programming sand-box between giving users power and imposing restrictions to ensure safety and stability. In a pure web environment, CGI scripts give users the ability to write almost any kind of on-line application, but they can easily bring down the web server or even the entire machine. The MetaScript environment will (at least initially) be more restrictive than a pure CGI environment. For example there will be no direct file I/O, from server side lua scripts, and no way to execute shell commands from server side lua scripts. However, it will still provide plenty of power for making cool games.
Scripts are small, modular pieces that are attached to game objects. They implement behavior as responses to triggers and commands. As scripts are independent of each other, they make it easy to do collaborative development. You can have multiple developers writing and using scripts in the same game world at the same time without stomping on each other. This type of setup dates back to the collaborative, real-time development that took place on text-based MUDs and has been proven to be very effective.
Scripts are a convenient packages of inputs, commands, triggers that can implement chunks of functionality such as WASD movement system, or a user interface for an RSS feed reader. Since scripts are self-contained, you can drop-in or cut and paste a script into a world to add functionality. We already have a bunch of scripts internally for common game tasks, and as the community grows, we anticipate that the amount of re-usable scripts and script libraries will become a powerful tool.
Triggers are events that are generated by user code in scripts, or generated by the game engine. Each trigger causes script handler functions to be invoked on scripts that are attached to the objects involved in the interaction. Triggers are the events in the event-based framework. They convey information between game objects and allow objects to respond to changes in the game world. For developers familiar with event-based systems, triggers should be a natural mechanism for making game behaviors. Here is an example of a simple trigger function:
function trg_enter()
MoveObject(self, 16, 16, 1)
end
This particular trigger is invoked automatically by the game engine when the object enters a place. The code in the body of the trigger function causes the object to be moved to a specific location in that place.
function trg_rotate()
newRot = (self.rotation + 1)
if (newRot == 5) then
newRot = 1
end
Debug("NewRotation: %d", newRot)
-- try new rotation
if (try_rotate_blocks(newRot) == 1) then
return
end
-- actually rotate the blocks
rotate_blocks(newRot)
self.rotation = newRot
end
This trigger is from an implementation of a falling block puzzle game – it accesses object properties and calls local function defineds in the script such as try_rotate_blocks.
Commands are inputs from users that come in from the network. They are the entry points for user interactions into the system, so they have an additional layer of validation and privileges that triggers do not have. To support different types of users in worlds such as administrators, developers and players, access to commands is controlled by a role system. So, players of a game will not be able to create any type of objects or kick other players – even though commands for these operations could exist in the world. As Metaplace has an open client and network protocol, the only way to ensure commands are secure is to do the validation on the server. The old axiom of “never trust the client” applies doubly here as the client could have been written by anyone!
Below the scripting level of the framework are what we call Platform Services. These are game-like infrastructure that would be inefficient to write in script and is commonly required to make different types of worlds. The set of platform services will grow over time based on user demand as the metaplace platform evolves. It will provide specific services such as collision detection, pathfinding, web operations, user interface and persistence. Usually each platform services exposes a set of functions to the scripting interface, and in addition some platform services will generate triggers when events occur. For example, when a bullet collides with a spaceship, a collision trigger would be generated to the objects involved.
So to summarize, the core of the engine behaves like a traditional on-line game server – it has user connections, game objects, a log file, a physical simulation, etc. At a high level, the flow of operations through the server is:
- a command arrives from a user and is validated
- the command handler function is located in script
- the command handler is executed
- triggers are generated by user code and by the game engine
Sean Riley
Lead Programmer
Previous Post | 13 Comments | Next Post
Posted on Friday, October 12th, 2007 at 8:35 AM PDT
Reader Comments
Chris Threlfo said:
I missed the alpha but I'm a multi-tier programmer and now I'm really keen to get into the beta after reading that. It makes a lot of sense, and theres no real limits on the type of advanced logic/data manipulation you can do - since you can always offload more complex logic to an off-site webservice that wraps some C# code, for example.
By the sounds of it though, most of your game logic can be implemented very sensibly and powerfully, which definitely shows that you guys have thought this through.
on Friday, October 12th, 2007 at 1:27 PM PDT:
Allan Melsen aka Raam said:
Thanks for the posting this... LUA is definately becoming more and more adapted in the gaming world by various parties...
I'll be looking forward to seeing how this works in 'the real (meta) world'.
- Raam
on Friday, October 12th, 2007 at 3:05 PM PDT:
naum said:
on Friday, October 12th, 2007 at 7:31 PM PDT:
Simon said:
Any details about interworld objects? Ie if I go to Bob's island adventure world and kill the mighty T-Rex boss and the loot it's head is it possible to return to my own world and plop it on my dining room table so I can show my friends (assuming the looted head was a trophy item in Bob's world)?
on Friday, October 12th, 2007 at 10:54 PM PDT:
NinjaInhibitor said:
on Saturday, October 13th, 2007 at 2:58 PM PDT:
Tide said:
How are you guys going to manage data? What kind of connection libs will be available to what kinds of databases? Cause there's nothing in LUA to manage data driven apps.
on Saturday, October 13th, 2007 at 4:08 PM PDT:
NinjaInhibitor said:
Oh, there will be data, there will be lots of data. In MetaScript, there are user-configurable data objects called Templates that live in the game's stylesheet. I mentioned them briefly above. These are for meta-data (no pun intended) - they are for defining types of parameterizable game objects and behaviors. Then, when the game is running "game objects" can be instanced from templates.
It is a very data-driven system. At the risk of invoking meta-fatigue, I'd even say it was a MetaData-driven system.
on Saturday, October 13th, 2007 at 5:35 PM PDT:
m3mnoch said:
sounds like a ringing endorsement of lua for what we needed, eh?
m3mnoch.
on Saturday, October 13th, 2007 at 6:30 PM PDT:
Akkarin said:
on Friday, October 19th, 2007 at 6:33 PM PDT:
Ycros said:
on Friday, October 19th, 2007 at 6:53 PM PDT:
nectarine said:
Finally we'll have game worlds just for us!
I'm seriously considering the possiblities of a game that's essentially a MetaBlog.