Sandbox: Embedding PHP as a Scripting Language *in* PHP

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

Dollar Coins – Why We Should Use Them

So even with the bad economy, there is one tradition that we’ve turned into a weekly affair that adds a bit of whimsy to our everyday lives, and to those we purchase everyday items from: Dollar coins.

A Little Bit of History

Lots of people remember the Susan B. Anthony dollar, a coin that everyone (apparently) disliked. It looked and felt like a quarter with its silver color and rolled edge, and as such was often confused for a quarter in circulation. Because of this, they only were minted for three years (1979-1981) but since they became so popular with vending machine manufacturers and train and light rail systems that the Treasury nearly ran out of them  in the late 1990s, which is when Congress discussed minting the Sacagawea Dollar to replace Susans in 2000.

The fact of the matter is that a full implementation of the Dollar coin would save nearly $500 million a year by a simple matter of resources necessary for circulation. Each dollar  bill costs about 9 cents to manufacture where each dollar coin takes about 20 cents. However, a dollar bill’s lifespan in circulation is about 18 months before it falls apart, where a dollar coin could last 30 years… or more.

This means that keeping a dollar bill in circulation for 30 years costs $2.70 vs the 20 cents of the dollar coin.
(That’s a savings of ~8.3 cents per year, per coin. Over millions of coins, that is significant.)

This however, scared paper manufactures that supplied the cotton/linnen components for the dollar bill enough to form a collation known as “Save the Greenback” which lobbied heavily to pass the “Save the Greenback Act” which would ensure that the dollar bill would not be eliminated. In the proposal by Rep. Thomas F. Davis (R):

  • “[P]ockets will be weighted down with heavy change instead of having a few bills tucked into their billfolds . . . one might suspect a conspiracy by clothing manufacturers in drafting the dollar coin proposal, as everyone’s pockets begin to wear out.” (Really?)
  • “[L]egislation designed to eliminate the dollar bill will an excuse by the special interests to raise prices on everyday items–a future sales tax, to be levied on all Americans but falling the hardest on those who can least afford it.” (Er… what?)
  • “The costs of changing to a 1 dollar coin would be significant to many in the private sector including but not limited to the small town banks which would have to retool their coin counting, wrapping and sorting equipment–costs which would inevitably be passed on to their customers.” (Nowadays this is a non-issue.)
  • No one like the Susan B. Anthony dollar. (Which was very true, and perhaps the only relevant and consistent point he made.)

No surprise that the the Act was never passed.

It almost seems that in spite of the proposed Act that the need for more coins in the Treasury caused Congress to order another strike of Susan B. Anthony Dollars in 1999.

Then in 2000 there came the Sacagawea Dollar which completely re-worked the look and feel of the dollar into a brilliant, thick golden coin, while keeping its metallic signature identical (so that vending machines that could accept Susan B. Anthony dollars could also accept them without any need for an upgrade).

Still feeling weird about the Susan B. Anthony dollar, the Sacagawea Dollar received mixed reviews. Some people loved it. Others hated it. Polls even to today are mixed (but I have some theories about that).

Giving the dollar coin its latest try, in 2005, Congress enacted Pub.L. 109-145 to give a new face… or rather new faces to the dollar coin: All of our (dead) Presidents.

In two years from the Act, the plan was to release 4 (dead) Presidents a year (similar to the State Quarters) until all eligible Presidents were honored. So in 2007 George Washington, John Adams, Thomas Jefferson and James Madison were engraved onto the obverse, where the Statue of Liberty is on the reverse. Also at this time, the minting mark and date were no longer struck into the face of the coin, but instead were engraved along the edge.

And this year (2011) we’re expecting to see Johnson, Grant, Hayes and Garfield.

So Why Do I Use $1 Coins?

First of all, I love how my kids react to them.

What child (or bit of child in all of us?) does not like a pile of golden treasure?

This past Christmas I gave little sacks of 10 shiny $1 coins to my daughters, nephews and daughters’ best friends that were mixed with glass “gemstone” blobs and tied with a little “guardian” dragon figurine at the top.

Not only that, but they’re a great tool to teach history. Every time we get a random pile of them from the bank, I sit down with my eldest daughter and we go over each of them, sorting the Presidents out. It’s gotten to the point that she’ll be able to identify the them on sight and when she put together one of her Presidential puzzles we got her from Barnes & Noble, she’ll exclaim, “Abba! It’s John Adams! Like on my coins! Sit down, John!” (that last bit she picked up from the musical 1776 🙂 ).

It literally gives weight to their purchases, and lets them understand the value of a dollar.

Second, it’s patriotic and saves our country money.

As I mentioned, each dollar coin that’s in circulation saves our country on average a little more than 5 cents a year. That kind of savings adds up quickly. If steps were taken for us to adopt the dollar coin as our base currency and do away with the dollar bill (as many other countries have done with their base currency), we could save a very significant sum of money.

Third, it saves *me* money.

This is a little known fact but the government currently has in place a direct shipping program to get dollar coins in circulation.

You can order them in bulk denominations of $250 and get free shipping.

Now, if you have a credit card that has “cash back” rewards

My debit card gives me $1 back for every $100 I spend on anything when I use the card with a credit card transaction. This means that for every $1,000 of coins I order from the Mint, that I get back $10. To put this into perspective, my savings account (which is a lot more than $1,000) gives me a measly couple bucks of interest every year, so purchasing and using $1 coins in this manner is a better investment than what I’m currently getting from my bank, and since we use the coins for our everyday purchases, we comply with the circulation program.

Of course if you want to give this a try, many credit cards with “cash back” systems do not count cash-like purchases towards your cash back totals. You’ll have to check your cardholder agreements.

Also if you purchase coins through this program and deposit them directly into your bank account in an effort to order more, you’ll be in violation of the program (which has some stiff penalties). The coins you order through this program are meant to be used, not hoarded or cashed-in.

For those of you who think this is “cheating the system” let’s go over the math:

Let’s first make a few reasonable assumptions:

  • A 19 pound package sent via UPS standard delivery costs about $30 (a high-end estimate).
  • The credit card charges the government $20 (2%) on the transaction (a high-end estimate).
  • Each coin put in circulation saves ~$0.083 a year times 1,000 coins = $83.
  • So the first year, the savings to the government is $33.
  • The the additional 29 years in circulation, the savings amounts to $0.083 a year times 1,000 coins times 29
    = ~$2,440 total government savings over 30 years.

It’s money that saves money.

In either case, this is some food for thought.

Peace,
-Steve

A First Look at “Griddle” a PHP/MySQL/jQuery Virtual World

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.

Which Mushrooms Freeze Best?

So today I took an inventory of our freezer to see which types of mushrooms survived deep freeze better than others. I was quite disappointed to see that the only species that really “made it” throughout the winter was Chicken of the Woods (Laetiporus sp.). In fact, 90% showed no signs of degradation at all, however I did note a trend that the fresher it was frozen the better it held up. This is very promising as Chickens don’t dehydrate well *at all* (they become papery and gritty when they’re rehydrated, no matter for how long). Chicken “ends,” i.e. the bits that are corky to begin with and are destined for making into broth, work well when they’re dehydrated and then boiled in water to make soup, however they need to be scooped out after they’ve imparted their flavor to the broth as they are simply inedible.

All of our Oysters (Pleurotus sp.), Honey Mushrooms (Armillaria sp., including E./A. abortivum), Meadow Mushrooms (Agaricus campestris), and Puffballs (Calvatia sp., Vacellum sp. etc) didn’t make it through the winter months without serious freezer burn or going stale, no matter how well-packed they were.

All of our Hen of the Woods (Maitake / Grifola frondosa) that was in the freezer didn’t do so well either, but the dried Hens are still great, sealed in airtight mason jars.

This upcoming year I’ll be experimenting with more dehydration.

Peace,
-Steve

#09 Aborted Entoloma

Harkening back to 2010/10/16#08 where I *thought* I had found an Aborted Entoloma, I was correct!

Today, we found a huge mass of them, and they grow in heavy numbers wherever Entoloma and Armillaria (Honey Mushrooms) grow together.

In essence, they are what you get when those two mushrooms “graft into eachother” much like how apples are grafted onto orange tree roots to increase the size of the fruit and make it sweeter. Only this happens naturally, and the Armillaria causes the Entoloma not to open up, and become all lumpy.

The sad part, however, is that being so distracted in collecting them, I forgot to grab some samples of the Entoloma “parents” for identification (as some Entolomas can give you an upset stomach). I only took pictures. 😛 So now we’re going to have to throw out the lot or run back out to the patch tomorrow and scrounge up the “parent” samples again.

UPDATE (Oct 30 2010): Apparently, according to Tom Volk (a very well-published mycology expert at the University of Wisconsin, and a bit of a mushroom celebrity) Entoloma abortivum is a bit of a misnomer. It seems that the species is actually Armillaria that have been deformed some way by the Entoloma, rather than the other way around as was quickly snapped up into the literature. As such, all so-called “Aborted Entoloma” (since they’re more “Aborted Armillaria”) should be edible, provided you cook them long enough. As such I’ve also updated my tagging a bit.