PBBG Game Engine

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. 

7/3/2007