Category Archives: Uncategorized

Stan Theory

I have a theory when it comes to predicting the “end of days” within Christian tradition. I believe that…

There is an Angel somewhere — we’ll call him “Stan” for convenience — who has a great scroll. Written upon that great scroll is the Calendar of the Universe with every day that was, and is, and has yet to be.

When someone down on earth says, “The world will end on this day!” The Lord turns and says,

“Stan, strike that day from the Great Calendar!”

And he does so.

When someone down on earth says, “The world will end soon!” The Lord turns and says,

“Stan, strike that year from the Great Calendar!”

When someone down on earth says, “The world will end in our lifetimes!” The Lord turns and says,

“Stan, strike that generation from the Great Calendar! No man nor son of man shall know when the End comes. It shall be like a thief in the night!”

Or that’s my theory. 🙂

Peace,
-Steve

Non-ID’d Old Family Photos

Getting Nook Simple Touch (software 1.1.0) to work on Mac OS X Internet Sharing

So, this took me a day of grinding teeth to figure out, so I figure I might as well post it here for others to appreciate.

Long story short, my wife got a new, free Nook Simple Touch with a subscription to the New York Times, and it is awesome. Wonderful, easy to read display, very responsive screen (both to touch and refreshing), and we were both very very satisfied with it… until the 1.1.0 software update downloaded itself and broke its wifi access, and apparently we’re not the only ones complaining.

Our home network is managed by our iMac (running Snow Leopard), which acts as out base station via the Internet Sharing option in Mac OS X. In essence, it takes our Internet connection and turns itself into a wireless router so we can use all of our devices through it. The update doesn’t seem to want to play well with it at all as it changed some very low-level code with how it negotiates with a DHCP server (the piece of software that assigns IP addresses).

Mac OS X’s DHCP server, by default, ignores requests with a reply threshold of 4 seconds or less, and the Nook’s update apparently fails those criteria. However, I have found a way to fix this on the Mac end, and allow the Nook to connect anyways.

Step 1: Start Internet Sharing. In the Sharing panel of the System preferences. This creates the file we’re going to have to tinker with named bootpd.plist.

Step 2: Make a temporary copy of bootpd.plist. Go to the Terminal and type in:

cp /etc/bootpd.plist /etc/bootpd.plist

Step 3: Shut down Internet Sharing. This causes the DHCP server to delete its copy of bootpd.plist as it doesn’t need it anymore.

Step 4: Edit our copy of bootpd.plist. Go back to the terminal and type:

pico /tmp/bootpd.plist

In the text editor that shows up find the text:

    <key>reply_threshold_seconds</key>
    <integer>4</integer>

and change the 4 to 0. Then press [ctl]-X to prompt closing the file, “Y” to confirm writing over it, and then the return key to save it.

Step 5: Substitute our copy of the file for where the DHCP server expects it. In the Terminal, type:

sudo cp /tmp/bootpd.plist /etc

It’ll prompt you for your password, so enter it. This is the step that makes the changes permanent. If you simply edit the bootpd.plist file that’s already there, it’ll be deleted and re-written by the DHCP server.

Step 6: Restart Internet Sharing. Now that there’s *your* file there, the DHCP server doesn’t have the permissions to mess with it, so it reads it as-is.

Step 7: Re-connect the Nook. It should work.

Enjoy!

Peace,
-Steve

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

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.