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.
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.
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.
Attack is another performance bottle neck that I plan to devote some time to once I get the map movement sped up.
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.
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.
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).