PBBG Engine Architecture

by Cameron Albert 26. February 2008 22:37

Thought I would go ahead and post a little about the architecture I have set up for my PBBG engine so far. Basically, the engine is a library that other projects can reference to make building PBBGs a little easier. All of the logic for handling incoming requests and parsing commands is contained within the engine. My PBBG engine is kind of like a MUD driver, it requires a MUDLib to define objects, persist data, etc. Some interfaces are defined within the engine library to make it extensible while it also contains base class implementations of those interfaces to make building on top of working logic possible. When the engine starts up it raises a set of events and when it processes commands it also raises events to allow the implementing application to control loading of commands, determining the server implementation and creating command instances.


Not the best diagram in the world but kind of gives you the idea of how it works. The column down the middle are the interfaces defined by then engine, which also define base classes, except for the CommandManager which is just a static class for processing commands.

In addition to the classes here are the Verb abstract class, the ICommand interface and the Command<Verb> instance for creating commands from Verbs. The CommandManager raises an event when it finds the command text that allows an external library to set the ICommand instance that will execute the current command. When the engine starts up though it raises an event that will allow the implementation library to set all the commands into memory rather than creating a new instance with each command.

The IServer interface defines an IConnectionManager property where connections into the server are managed, either socket or http.

On the WEB side, which is actually a namespace ".Web"; the "Server" instance writes out a JavaScript reference to an embedded js file containing the script required to submit commands to the engine using AJAX. A separate RequestHandler class actually parses the input from the AJAX call and then attempts to locate or create an IConnection instance on the Server's IConnectionManager instance. The Server in this namespace actually sends the command to the CommandManager.

On the NET side, which is actually a namespace ".Net"; the "Server" instance actually contains the socket used to listen for incoming connections on a port specified during startup. From there the individual IConnection instances contained in the IConnectionManager instance handle processing the input and formatting it into a command. The IConnection instance contains the connected socket and will send the command to the CommandManager.

Both IConnection instances in both namespaces allow messages to be sent to the client along with custom data such as stats, gold, map data, etc. The difference between the two is that the WEB instance sends all of this back as JSON in the HTTP response and the NET instance sends the messages down the socket as they are added to the IConnection instance and then sends the additional data once the command completes execution.

That is all I have completed at this point on the engine side, it processes commands from the web and the implementation library sitting on top of it handles the commands and persists the data. There is plenty of work on the implementation library side still yet to be completed.

PBBG Engine Update

by Cameron Albert 27. November 2007 16:06

Work continues on Perenthia and my PBBG Engine. I think I got the core PBBG engine framework complete, at least complete enough to start porting over the content items from Perenthia. My goal is to get a small area working with a few items, monsters, etc. before I port over the entire database.

I am hoping to improve performance in this new version as well as complete several of the features I didn't get implemented in Beta 1. The engine uses a lof of in memory objects while still persisting the world to the database. Running a lot of this in memory will eat of memory on the web server but will hopefully improve performance in regards to interactions from users. The main bulk of the places or rooms will be loaded up into memory when the application starts. Along with this load will be a load of NPCs and items located in towns and designated areas. Then, whenever a player logs in and begins playing their player object will be loaded into memory as well. At regular intervals the world state will be updated and player objects persisted to the database. Inactive player objects will be saved and then discarded from memory until the next time the player logs in.

Loading these objects into memory will keep the database connection initialization and IO traffic to a minimum and help speed up actions such as moving around and engaging NPCs. Since I don't know of anyone actually doing this I'm not completely sure it will work. :) My testing so far is working great and at most I may need to beef up the RAM on the web server.

I am still planning for a January release of Beta 2 and depending on how that beta goes; a full release in the early Spring.

PBBG Engine Core Object Structure

by Cameron Albert 6. November 2007 13:20

The core of my PBBG Engine consists of a Place and an Object. A Place is a spacial definition and can represent a room, world, universe, etc. An Object is anything that can reside within a place, meaning all people, monsters and items are Objects. The Places and Objects are defined using meta data so that properties of an Object are the meta data of the object. This meta data is stored in a seperate table from the object and retrieved as XML when an object is queried. Places work in much the same way with a few pre-defined fields such as the name and x, y, z location of the place. Going this route will allow me to have different objects defined in different games without having null database fields that are not used in all games.

Another example would be a Sword. In Perenthia a Sword dervies from Weapon which dervies from Thing which implements the Object interface required by the PBBG Engine in order to persist the properties of the Sword in the database. I can then create instances of the Sword class when Swords are crafted or purchased. Each level of inheritence can implement properties that will persist for each Sword instance created.

Sword : Weapon : Thing : IObject 

So far it seems to be working pretty well and with the XML features of SQL 2005 the querying of the data is very fast. I am hoping to get Perenthia ported over to this new framework soon as it will provide a more flexible system and allow me to manage game content a little easier. 

Engine Structure

by Cameron Albert 30. October 2007 00:05

I am structuring my PBBG game engine to be as flexible as possible in order to build various types of games. In order to do that I need to abstract out the components of the engine. Since persistent browser based games are, well, browser based, I decided to follow the normal n-tier model. I am creating a data tier, my actuall database, an application tier which is the engine and will handle client connections, authentication, commands and reading and writing to the database. On top of the application layer will reside the game layer which will be customizable libraries that will use and access the application layer. This follows along the MUD driver and MUD lib pattern where my engine will be the driver which will persist data and handle all communications and my MUD libs or games will be written in an OO fashion to take advantage of the game engine.

The engine is being written in C# and in such a way to take advantage of features of ASP.NET such as HttpModules and HttpHandlers. 

Command Processor

by Cameron Albert 23. October 2007 00:10

For my PBBG Engine I am developing a command processor independent of the client interface. The reason for this is that I want to be able to build different interfaces such as a mobile interface, silverlight and/or flash interface. I want all the interfaces to process the same commands and be able to handle the same output from the server in order to update the UI components.

What I have come up with for the command request to the server is a simple pipe delimited string:


Where CMD would be the command to send to the server and the AUTHKEY would be a key generated when the player logs in through the authentication service that uniquely identifies the player for that session.

The response from the server will be JSON formatted objects and I still have not figured out the complete structure yet. The things I need to send back to the client would be:  An array of messages to display to the player, player's new position should they move, the player stats when in combat, their current target and any other players or mobiles they encounter. Could end up being a large set of data for certain actions so we'll see about performance there.

Tags: , , , , ,

Game Development | Perenthia PBBG

PBBG Game Engine

by Cameron Albert 3. July 2007 10:38

While building the persistent browser based game Perenthia I have been putting together a PBBG Engine that I am going to use to build additional games. Among those additional games will be Aelerion, which will be a space adventure game in which I plan to use Silverlight as the front end user interface.

The Knights of the Realm 2 uses a mixure of some of the code I wrote for the PBBG Engine and some of the code I migrated from the first version of the game. I also chose to try something new with Knights of the Realm in that I stored XML serialized objects in the database using my XQuery class. I decided to try this method to see what kind of impact it would have on game play performance and maintainability. Since Knights of the Realm is not a real time game and executes tournaments in the early hours of the morning I figured this would be a safer test.

Since writing Knights of the Realm 2 I decided not to use the XML serialiazation for my PBBG Engine because I want the engine to be able to support real time game play and serialization is just too slow. I did some perf testing with a database, xml serialization and flat text files and found that flat text files were the fastest when saving information, xml serlization was the slowest and database fell in the middle. When loading information back into objects the database was the fatest because I didn't have to do a lot of conversions from strings to integers like I did with the flat text files. Xml serialization came in last in loading as well and not just in miliseconds but was a good 3-4 seconds behind the database and flat files in both loading and saving. However, using an XmlReader and XmlWriter to read and write the Xml values into an Xml data type column in the database turned out to be faster than serialization but still slower than straight database access because of the need to convert Xml node value strings to integers.

My PBBG Engine will utilize a mixure of regular data type columns and xml columns in the database. The reasoning is that static things such as player name, race and gender will be static columns but the player table will also feature and xml data type column for storing custom properties. A base player object will contain a key/value collection where custom properties can be stored and that collection will use the XmlReader and XmlWriter to save the key/value pairs in the xml data type column.

I also plan on making use of the application cache in ASP.NET for some of the common objects such as rooms so that I am not making thousands of database calls everytime a player moves around in the world. Some of my initial tests have worked out quite well using a lightweight set of objects that represent rooms or tiles on a map. These objects contain just enough information to determine whether or not a player can move into the room and their coordinates in the overall map. 

Powered by BlogEngine.NET
Modified Theme by Mads Kristensen

About the Author

CameronAlbert.com I am Senior Software Development Consultant specializing in Silverlight, WPF and the Microsoft .NET Framework. 

I have released an iPhone game called the Adventures of Puppyman that was built using ExEn and am currently working on a WP7 and iPhone version of Perenthia soon to be released.

View Cameron Albert's profile on LinkedIn
See how we're connected

Follow cameronalbert on Twitter


Recommended Books

Silverlight 4 Business Application Development - Beginner's Guide:


Microsoft Silverlight 4 Business Application Development: Beginner’s Guide