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.

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:

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.

Tags: , , , , ,

Game Development | Perenthia PBBG

ASP.NET AJAX Lessons Learned

by Cameron Albert 25. September 2007 17:40

I used the Microsoft ASP.NET AJAX Extensions pretty heavily for the user interface of my persistent browser based game Perenthia and after about two weeks of live server testing I have discovered some performance issues that may cause me to abadon the use of the UpdatePanel for straight AJAX calls using JSON objects.

The reason being is that I have UpdatePanels that update various sections of the game and instead of just setting a value as supplied from the server they send back the entire HTML blog of changed text. For orderinary web sites this wouldn't be a problem and in fact when allow them to perform faster. Since Perenthia is a little more interactive in so much as players can move around, which are post backs, and do battle, which are post backs, sending all this HTML back is causing too much bloat.  I am thinking of creating some very simple Javascript objects that I can send down from the server that will contain only values that need to be changed rather than HTML. This way I am not sending down tables, spans and the like.

Anyway, we'll see it how it goes, hopefully it will improve performance of the game because that is lacking right now. 

Tags: , , ,

ASP.NET Development | Game Development | General | Perenthia PBBG

C# Socket Server for Flash/ActionScript

by Cameron Albert 27. July 2007 15:13

After doing some research on available socket servers for Flash I decided to write my own in C#. Most of the server out there are written in Java and while there are some open source implementations I prefer to stick with a code base I know and understand.

I got the Flash movie to connect to the C# server yesterday using JSON protocal instead of XML as my transport mechanism. I used a .NET JSON library and an ActionScript 2.0 JSON library to build the objects on both sides. I created a C# class for passing data, serialize as a JSON string and send it the Flash movie. On the ActionScript side I created an AS class that mimics my C# data gram class and use the AS JSON lib to serialize and send that same object structure to the C# server. Working pretty good so far, I am able to login to the server and send and receive messages.

My next steps will be creating a basic flash game that I can use to run around and do battle while sending and receiving messages from the server. 

I have plans to make a Flash based PBBG with real time combat, we'll see how it goes. :) 

Powered by BlogEngine.NET 1.5.0.7
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:

http://www.packtpub.com/microsoft-silverlight-4-business-application-development-beginners-guide/book

Microsoft Silverlight 4 Business Application Development: Beginner’s Guide