So with working on Griddle some more, I decided that in order to make it a viable platform for building a virtual world (specifically in my case a multiplayer RPG) I would need some means to script objects to do things.

Doing this with PHP objects that are ultimately serialized and stored on a database is potentially hazardous, as you’ll need to:

1. Write a new class for each object type (each NPC, rock, tree, etc.) which is time consuming and costly to process.
2. Write some very robust serialization functions to ensure everything updates properly as you alter the classes involved,
3. Deal with PHP errors related to improper unserialization.

For those of you who do not know what “serialization” in this context means, it is simply the process of taking a digital object and reducing it to something that can be stored to a database (usually a long string of characters) and then later turned back into the digital object, itself in the computer’s memory when needed.

Think of when you get a desk from Ikea or the likes and it comes in a nice flat-pack container, perfect for transport or storage. The desk in that form is “serialized” and when you put it together you’ve “unserialized” it; however, since it’s Ikea you can always break it down and “serialize” it again. 🙂

Extending this metaphor further, having to keep a different class for each different object would be like trying to assemble a bunch of different pieces of furniture from different sets of instructions, and if the models of furniture change and the instructions on how to put them together aren’t properly updated, it quickly becomes a mess.

What would be easiest is if you have *one* model with *one* set of instructions that you can, with a little practice, put together and take apart easily.

Scripting Languages

One of the ways to make this happen is to devise a way to extend the functionality of an object without altering its underlying structure in the computer, and the easiest way to do that is via a scripting language of some sort (i.e. a set of editable instructions that the object can store in a regular manner).

Nearly all well-developed virtual world systems that I’ve worked with have a scripting language. Second Life has LSL (Linden Scripting Language) which is a variant of Mono (which is ECMA compliant, i.e. JavaScript-like), and Metaplace (now defunct) and Blue Mars chose variants of of Lua (a lightweight embeddable scripting language).

I’ve come to like Mono and Lua a lot in my dabbling with them; however, neither one of them will snugly fit what I’ve wanted to accomplish with Griddle. I want to stick to JavaScript/jQuery on the client side, and PHP/MySQL on the server-side so that this will be able to run virtually *anywhere* without any fancy configuration. With shared hosting programs like GoDaddy, installing the proper software to get Mono or Lua working in such a way they would be useful on the server is next to impossible.

The only other real option I could think of would be to write my own, but doing so in PHP would be slow as molasses and not very robust.

It was then, that I had a crazy idea: If PHP is the limiting factor, why not let PHP be the scripting language?

I Dub Thee “Sandbox” – PHP Embedded in PHP

In order to make a scripting language *work* it needs to be:

1. Quick, as slow scripts frustrate users.
2. Easy to learn, so people will use it.
3. Locked down and isolated so that a malicious hacker can’t gain control of your server.

PHP fits the bill on 1 and 2, but 3 is tricky. The only ways that were well-known to lock down PHP are to mess with its initialization file, which allows you to turn on and turn off functions and features. However, that goes for all code that’s executed. If I wanted to, say block a user from accessing the database in this manner, I would also end up blocking my own programs from accessing the database (which would be of absolutely no help).

What I needed was that extra layer of control where I could “reach into” their code, but they couldn’t “reach into” mine.

It was then that I learned about the PHP Tokenizer functions. Tokenization is a process by which a computer takes programming language code and breaks it up into its constituent parts for interpretation. Since the tokenizer functions in PHP are actually part of the PHP engine, they’re lightning fast.

My idea was to build a system that could accept raw PHP code, tokenize it, and then compare the tokens to a set of parameters to determine what was allowable and what was not. If it found anything “bad” it would reject the code. Otherwise it would allow it to be executed.

My next question, thought, was “How the heck am I going to lock everything down?” Different PHP installs have different variables and modules, and since Griddle is a distributed system that may have different modules on different machines running, how am I going to nail every possibility? It was then that I remembered about PHP’s four functions:

1. get_defined_constants()
2. get_defined_functions()
3. get_defined_vars()
4. get_declared_classes()

Each of these returns a list of what they describe, so by using these I could determine exactly what a user *would* have access to, and block them *all* out, making PHP a blank slate. The checker would only give its thumbs’ up to user-defined code that did not use *any* of the PHP libraries or built in variables and functions. A step in the right direction!

Add onto that a “white list” of allowed parameters, and I now have complete control over the environment in which the code executes: A Sandbox. 🙂

Control Structures and Choices

From here I’ll need to figure out how I want to give the user access to World data, as well as under what conditions the script is triggered.

PHP is strictly procedural (with each line in its flow executed in sequence, one line at a time), quite in contrast to the event-driven Mono and flexibility of Lua, however I would need to figure out some method of passing events to the script and storing its own “session variables” for later retrieval.

What I’m thinking about is a series of callback functions (such as “onClick,” “onBump,” etc.) that will be appropriately triggered (sort of in a similar fashion to how LSL is structured). Then, give these access to a few “wrapper classes” that give the user some access to the object’s data and the means to access other nearby objects. For example, a code snippet that causes the object to chat “Hello there [name]! I’ve greeted someone like that [x] times.” every time someone clicks on it could be:

var $times = 0;

function onClick($clicker) {
    $this->times++;
    $this->chat('Hello there, '.$clicker["name"].'! I've greeted someone like that '.$this->times.' times.');
}

Or an object script designed to move within 2 squares of another object and stop:

var $targetId = "[target's id]";

function onTick() {      
    global $World;
    $targetPosition = $World->findObject($this->targetId);
    if ( distance_between($this->getPosition(), $targetPosition) > 2 ) {
        $this->moveTowards($targetPosition);
        $this->resetTick();
    }
}

Anyways, you probably get the idea: PHP embedded (and locked down in a sandbox) in PHP. 🙂

More later. Time for sleep!

-Steve

So over the past I don’t know how many years (actually come to think of it’s been since my highschool days) I’ve toyed around with writing small virtual-world games in Javascript or PHP/MySQL. Every time I would always come across the same problems that made me frustrated to the point of putting them down for months on end, only to pick them back up again and have to start from scratch.

• The computer was too slow to render all of the layers I needed or retrieve all of the databases entries I needed as fast as I needed them.
• What worked well in small applications wouldn’t scale, and what worked for a single user didn’t work with multiple users.
• The code to keep track of everything was a chore to keep track of, itself as nothing was standardized enough.

Recently however, I’ve found that browser technology has become sufficiently advanced enough that all of the theory I had worked out in my head and in my notes coalesced and I was able to put together a PHP/MySQL/jQuery virtual world framework by pecking at it in under two weeks time.

And now I see it has some promise. (Although the image above might fool you about that. 🙂 )

Since the first version looks a bit griddish (simply because of the horrible artwork I had to work with) I’ve dubbed this project “Griddle” both due to these superficial bad-art-grid-like qualities as well as in the sense of “what’s cooking.” 🙂

The Backend

What I have done for the backend of this operation was to try and make things as distributable as possible from the start. The game can run on one server up to as many as you wish, and additional servers can be added based upon processing needs for they fall into one of three general categories:

1. A Region Server – Which stores MySQL region tables, which in turn store all of the objects in the game.
2. An Art Server – Which stores a mirror of the game’s artwork and images.
3. A Game Server – Which hosts a mirror of the PHP scripts, queries the region tables, and points the user’s browser to a the least-stressed Art Server for visual content.

Region Servers

The actual objects themselves are stored, serialized in a MySQL database with enough metadata to retrieve them efficiently. Each “region” of the game can be up to and has its own table in the database to avoid table locking wars with the other regions. Players can move freely between regions to the point that particularly heavily-trafficked regions can be spun off into their own regions (or even onto their very own machines) without the players knowing, effectively balancing busy areas in a pinch.

Art Servers

These are kept mirrored closely as they hold all of the in-game artwork. If I were to open this up into a Second Life or Metaplace-like system where users can add their own content, these servers will have to communicate with eachother to share new data.

Game Servers

These are also kept mirrored closely, as they host the client PHP/HTML files, AJAX interfaces and all other executable scripts. It doesn’t matter which Game Server you use, as it’ll access the appropriate Region Servers it needs as well as point your browser to the content on the least-stressed Art Server. If it gets too clogged, it’ll pass you off to another Game Server with just a blink of interruption while the page reloads.

The Code

To smooth game-world development, I’ve written a library of game-object classes in PHP 5  which actually keep track of their own changes and updates, manage their own database connections, and arrange themselves within a world-interface that you can interact with. In essence, you load a “chunk” of the world into memory, manipulate it, and when the script terminates it saves all changed objects to the database automatically before cleaning everything up. 🙂

The game’s client is written completely in PHP/HTML and Javascript/jQuery (jQuery was a godsend). Via AJAX it queries the Game Server to keep on top of where things are in its immediate slice of the world as well as update the Game Server of the player’s actions. I currently have some buffering worked into the client, so the controls as well as objects moving about in-world are very responsive and fluid (although there is always room for improvement).

However, where the client is “thick” when it comes to display it is a “thin client” where it comes to calculating in-game effects and actions (leaving all of those calculations to the Server). The Game Server constantly keeps track of a number of parameters, so if the player’s client tries to (for example) update their position too often or execute too many commands at once, it has the capacity to prevent them.

Future Ideas

First, I am going to get some better artwork. The blocky textures are horrible, and I might do better with a more “orthographic” view. Besides, it’s easier to share an idea if it looks pretty. 🙂 Perhaps I should look into some in-browser image editing tools like Pixastic?

I also need to put together a good system for designing avatars. (Yes, the “men’s room icons” have to go.) Avatars are one of those things that can really make or break a virtual world experience. If there’s not enough ability to customize them, one might as well be walking among clones. Let’s see if can put together something in SVG that I can manipulate and then rasterize at least as well as the avatar options that are available in Second Life.

Third, I need to work on an editing interface. Perhaps something as simple as Minecraft (but obviously in 2D… or 2.5D?) where you can drop and destroy objects and tiles anywhere you wish. Laying down paths by walking, or even some sort of drag and drop palate using jQuery.

Fourth: Since the game-object scripting is currently all server-side, I’ll need to come up with some sort of scripting interface client-side for users to utilize for their objects. I’m thinking perhaps a simple Javascript library, or maybe even have some sort of Lua or Mono interface.

Finally, once I get the account and signup pages looking pretty, I want to put this out in the open for people to tinker with. If it’s something that people like, I wouldn’t mind developing it further.

I saw this on another friend’s blog, so I couldn’t resist.

What came out of it though beaned me on the nose. BOTH of them:

How freaky is that?!

Peace,
-Steve