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.
10/30/2007
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:
CMD|AUTHKEY
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.
10/23/2007
One of the main things I am concentrating on for Perenthia and my PBBG Engine is performance. A lot has to go on in a game, each action be it movement, combat, etc. causes a lot of code to be executed and database calls to be made. What I am striving for in Perenthia and ultimately in my PBBG Engine will be as few database calls per command as I can get away with. Right now Perenthia makes several calls, one to load the Character and depending on the action 1-4 more database calls and then the final save Character call.
For Perenthia, I was able to get movement into the Character load call, then make one call to determine if the player can move and if any monsters are encountered, then a final call to save the character. That is probably as small as I can get movement but it still does not perform the way that it should.
I thought about caching or storing the map in memory but with over 150,000 records in the table storing the map data that is just not a good idea. Just not sure of the best approach for this. The database procedure for movement runs in under a second so I don't think that is the bottle neck, I think the bottle neck is sending all that data from the server to the client. I may try to asnychronously download the map data to the client while they are playing and just send smaller amounts of data for the map. Maybe a JavaScript file that can be auto generated using custom handlers that would contain the entire map structure with X,Y,Z and Terrain values. Then I can just use the player's current location to position them on the map. since I validate their position on the server I can still perform the monster check and move check and just not send the whole map down the pipe.
Attack is another performance bottle neck that I plan to devote some time to once I get the map movement sped up.
10/19/2007
In between updating Perenthia and adding new features I have been pulling parts of the code base into a more generic PBBG Engine I am writing in C#. I started working on it when I upgraded the Knights of the Realm game and used parts of it for Perenthia. I am hoping to put Knights of the Realm Beta 2 on the new engine once I get it finished.
I am building the engine as generic as I can but it will incorporate a base rules set and some basic concepts. The base objects will be Avatars, Places and Things. These objects will contain the properties required to function within the rules set and all objects will derive from a base GameObject class that will provide a properties collection for creating custom properties on derived game objects.
The game will be driven by commands sent from the client. Some objects will handle the commands in the engine framework while other commands will cause events to be raised that deriving implementations can handle and provide custom execution or additional execution of the commands.
The egnine will basically be a commands/rules processor that I will hopefully be able to build a variety of games on. I have plans and ideas for several types of games and do not want to continually build the same thing over and over, hence the PBBG engine.
10/17/2007
I ran into a major performance issue with the ASP.NET AJAX Server Controls while testing my persistent browser based game Perenthia. I had initially used update panels fro the various regions on the main game interface such as the player stats, map and chat window. Programming this was simple as I could do everything in the server side code and just send back the results. With the partial page rendering feature of the ASP.NET AJAX Extensions only the update panel html was sent back to the browser.
Once I moved the application into a production environment and had people on there playing and testing the web starting running out of memory, the application was consuming the server memory at an alarming rate. What was happening was that IIS would jump 1 to 2 MB of RAM for each request made by the client, that means every time someone moved on the game map 1 to 2 MB of RAM were being held and not released. I tried a bunch of different stuff from optimizing stored procedures to caching the map data but none of it helped.
I used Firebug to watch the AJAX request and response and to see if I could reduce that down some. The response was simply HTML fragments so I wasn't too worried about that but the request sent the entire ViewState up to the server with each post. The ViewState for the game page could be quite large since I was appending messages to the chat window which was a server control.
I was able to eliminate the ViewState issue with the chat window but the app was still consuming RAM and not releasing it.
I decided to try just a simple JavaScript only AJAX post using the Microsoft AJAX Client Libraries. After doing some basic tests on the chat window I decided to rebuild the game interface using only client side AJAX calls, no update panels. This has resolved the server memory issue, why, I am still not sure, must be something with the way the resources are handled in .NET. I have not encountered the slow downs or crashes from before and the app is actually running a little smoother on the front end as well.
What I settled on was a custom ASHX handler class that handles the commands from the client and returns JSON strings that the UI can then translate and use to update the interface components. I had to rebuild some of the interface components as JavaScript objects but overall it was the right choice. Not too mention that I can now use that same handler with other interfaces such as Flash or Silverlight.
In conclusion, while the AJAX Server Controls might work great for most web sites they are definitely not optimal for a persistent browser based game (PPBG).
10/1/2007