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.

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.

I spent some time last night and today playing around in Silverlight to make a final decision on whether or not I will use it in my PBBG Perenthia. I had already started building out a Flash UI but just keep running into the same issues with Flash; the IDE sucks and I keep having to rebuild C# classes in ActionScript. So, I decided to dig a little more into Silverlight to see if using the 1.1 version would be feasible. The word from MS is that the beta 2 with a go live license should be available sometime later this year. That might work out pretty well for me and my current timeline. I have most of the server functionality for Perenthia complete but just can't find a UI combination that gives me what I want and keeps the overhead down. Anyway, I am going to spend the next few days playing around with a Silverlight UI and see if I can come up with something I can use in place of Flash.

Here is a screenshot of the UI (user interface) that I am building in Flash for my PBBG Perenthia. I am converting the AJAX/HTML elements to Flash so it it somewhat incomplete but does give you the overall feel of the interface. The place where that gray square is will be the map and next to the map will be displayed the name of the place/room you are in and a listing of other players, NPCs, etc. in that place/room.

I am going to do a write up with my findings in regards to the Perenthia PBBG UI using AJAX, Flash and Silverlight. Might do that sometime later today.

 

I've decided to use Flash to provide the UI for my persistent browser based game Perenthia. I went back and forth between Flash and AJAX and even looked into Silverlight a little and Flash just has the maturity needed for a good PBBG interface.  I originally had the main game UI written using AJAX but found it to be a little cumbersome when a lot of activity was occuring on the back end, just too much traffic generated for one user. I looked into Silverlight a little but I am going to wait until the 1.1 version is released so I can program in C# on the backend. Flash seems to be able to provide me with what I need and I wrote custom ASHX handlers on the ASP.NET side to handle commands from the Flash UI. The UI is basically just an advanced MUD client, in that the primary output is text based. However, with Flash I will be able to provide a better map and add some additional graphical features later on down the road. Since the command handler is a custom ASHX handler in .NET I could really allow any type of client to connect, as long as that client can send XML as an HTTP POST and receive the and parse the XML response from the page.

I will post a screen shot of the UI in the next day or so. 

 

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. :) 

I've been looking into Flash as a possible alternate UI for my PBBG Perenthia because of the benefits of being able to write a socket server that Flash can connect to and provide real time updates to players. The only way to accomplish this in a web scenario is to constantly poll the server for updates, rather than have them pushed to the client. I am trying to weigh the options and impact of this along with the UI beneifts Flash would deliver, such as animated characters, mobs, etc.

I've been developing persistent browser based games using ASP.NET and AJAX for a little while now but an emerging technology from Microsoft called Silverlight that I believe will re-define how browser games are built for .NET developers. Silverlight is Microsoft's answer to Flash but with advantages for .NET developers in that I can program C# on the backend and have Silverlight on the front end.

My current PBBG Perenthia will be ASP.NET and AJAX but another game I have in the design phase called Aelerion will feature a Silverlight front end using (hopefully) the same game engine I wrote for Perenthia.