Silverlight Dependency Property Snippet

I created this snippet for Dependency Properties in Silverlight. If you are creating custom Silverlight controls you might find this snippet useful. I stored my code snippets here "My DocumentsVisual Studio 2008Code SnippetsVisual C#My Code Snippets" so all you need to do is copy the file to this location. Visual Studio should load the snippet the next time you start it up. If it does not then you can go into "Tools", "Code Snippets Manager" and load it up manually.

Now when you type "propsl" and hit tab you will get a stubbed out property like below, where tabbing through the items allows you to change the type and name of the property, set the owning class and provide a default value.

public int MyProperty
	get { return (int)GetValue(MyPropertyProperty); }
	set { SetValue(MyPropertyProperty, value); }
public static readonly DependencyProperty MyPropertyProperty = 
     DependencyProperty.Register("MyProperty", typeof(int), typeof(MyClass), 
     new PropertyMetadata(null, new PropertyChangedCallback(MyClass.OnMyPropertyPropertyChanged)));
private static void OnMyPropertyPropertyChanged(DependencyObject obj, DependencyPropertyChangedEventArgs e)

Here is the code for the snippet and a link to the file:

<?xml version="1.0" encoding="utf-8" ?>
<CodeSnippets  xmlns="">
    <CodeSnippet Format="1.0.0">
            <Description>Code snippet for an automatically implemented dependency property in Silverlight.</Description>
            <Author>Cameron Albert</Author>
                    <ToolTip>Property type</ToolTip>
                    <ToolTip>Property name</ToolTip>
                    <ToolTip>Owner Class</ToolTip>
                    <ToolTip>Default Value</ToolTip>
            <Code Language="csharp">
                <![CDATA[public $type$ $property$
                get { return ($type$)GetValue($property$Property); }
                set { SetValue($property$Property, value); }
            public static readonly DependencyProperty $property$Property = DependencyProperty.Register("$property$", typeof($type$), typeof($ownerClass$), new PropertyMetadata($defaultValue$, new PropertyChangedCallback($ownerClass$.On$property$PropertyChanged)));
            private static void On$property$PropertyChanged(DependencyObject obj, DependencyPropertyChangedEventArgs e)

Silverlight Dependency Property Snippet


Client/Server Communication Data Formats

While developing Perenthia I tried several different communication formats from sending JSON serialized objects back and forth to sending byte arrays containing mostly integers indicating what should be loaded and displayed, what commands to execute etc. What I eventually settled on was a bit of a hybrid. I've created a simple set of "tags" that can be sent to and from the server. The tags are nothing more than pipe delimited strings contained within curly braces and there are a limited number of tags that provide simplicity yet flexibility with the data that is transmitted. The tags are represented in C# by tag objects allow me to create them, query them, etc.

A simple command tag for the SAY command might look like this: {CMD|SAY|"Hello World!"}

I wrote a custom tag writer class that parses the tag objects into strings to be sent to the client and likewise a tag reader that reads the strings sent from the client and parses them into tag objects.

The client can only send commands to the server but the server sends commands, messages and objects to the client. The commands are all the same, the CMD text then the one word name of the command and then a list of arguments, messages are system, chat and tell messages but objects have a bit more information. For instance, an object tag encompasses several different types starting with a base ACTOR, a PLACE, a PLAYER and a PROP or property. The ACTOR, PLACE and PLAYER tags all define the ID, Name and Descriptions of the objects, with some additional data per type but the PROP tag defines the object id of its owner and a name/value pair. An example of a PLAYER tag with properties for x, y and z coordinates might be:

{OBJ|PLAYER|3756|"Aldarian"|"My character description…"}




The client can find and parse the player tag and then find the properties associated with that player instance. The way the server works now it will send the full player tag once logged in and a character is selected and then from then on out it just sends property updates.

Using this type of tag structure allows quite a bit of flexibility for the client. I could choose to write a very simple client that only displays MSG tags, much like a MUD, I could write a simple 2D interface client and display and move sprites about the map using the properties from the server, etc. Once Perenthia is up and running I will probably post some information on the tags and how to talk with the server should someone feel the need to write their own client. 🙂

SQL 2005 XML Data Type, Stored Procedures and Lists

I've seen a lot of stuff out there regarding the SQL 2005 XML data type but most of it is just regurgitates the MSDN documentation. That's fine and all but what about practical uses of it? Well, I have a practical use sample. In building my persistent browser based game Perenthia I have a concept of a Place. A place is a virtual space in which objects are stored. For Perenthia the places represent the various rooms or tiles players move around on. The place or room has exits defined that allow the player to move from one place to the next. The exits are the typical directions; north, south, up, down, etc. In the database I have a Places table and a PlaceExits table. The Places table stores all the information regarding a place and the PlaceExits table stores the placeId along with a directionId and destinationId so I know what exits are available in any room and what rooms they lead to.

The simplified schema for the places would be:

 Places Tables

 In the stored procedure that retrieves the place information I use the following query snippet in the select clause:



                e.DirectionId        AS "@directionId",
                e.DestinationId        AS "@destinationId"
                dbo.PlaceExits e
                e.PlaceId = p.PlaceId
            FOR XML PATH('exit'), ROOT('exits')
        ) AS ExitsXml

    FROM dbo.Places p 

 This creates an XML fragment I can then parse in the application to fill a collection of Exits on the Place object.

When saving place information I pass XML generated from the Exits collection in a stored procedure like so:

CREATE PROCEDURE dbo.Places_SavePlace  (@PlaceId int, @ExitsXml xml)

From within the save procedure I perform an update or insert of the place data and then execute the following sql to insert and update the exits for the current place:

    — Exits

    — Process the existing exits first

        DestinationId    = e.ex.value('(@destinationId)[1]', 'int')
        @ExitsXml.nodes('/exits/exit') as e(ex)
        PlaceId = @PlaceId
        AND DirectionId = e.ex.value('(@directionId)[1]', 'tinyint')

    — Process any new exits

    INSERT INTO dbo.PlaceExits
        ObjectId, DirectionId, DestinationId
        e.ex.value('(@directionId)[1]', 'tinyint'),
        e.ex.value('(@destinationId)[1]', 'int')
        @ExitsXml.nodes('/exits/exit') as e(ex)
        e.ex.value('(@directionId)[1]', 'tinyint') NOT IN
            SELECT DirectionId FROM dbo.PlaceExits WHERE PlaceId = @PlaceId

This is working pretty well and keeps me from having to loop through the exits in the application and make multiple database calls. 

Engine Structure

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. 

.NET PBBG Engine

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. 

ASP.NET AJAX Server Controls and PBBGs

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

Adventures in Silverlight

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.