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:
- A Region Server – Which stores MySQL region tables, which in turn store all of the objects in the game.
- An Art Server – Which stores a mirror of the game’s artwork and images.
- 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.