Obsidian#

Exploring options

2010-01-11T22:46:00.000-08:00

One of the original goals of this project was to have some good test coverage, for once. Embarrassingly, I've never worked within any unit testing framework.

To that end, with the rewrite of Citrine, James and I are exploring two Microsoft Research Lab projects: Pex and Code Contracts.

Code Contracts provide a language agnostic .NET API for design-by-contract. At the simplest level, these allow for specifying guarantees with regards to function pre-conditions, post-conditions, and class invariants.

Hand-in-hand with this idea, Pex is a framework for generating parameterized unit tests (PUTs). Pex analyzes the code under test for branches and uses a constraint solver to generate input combinations that provide maximal coverage. It has great synergy with Code Contracts, capable of creating unit tests to check edge cases that one might not normally come up with on his/her own. In addition, the Pex library provides an easy-to-use API for mocks and interceptors.

I need to get more accustomed with these new tools before we delve too far into Citrine. :)

Just kidding

2010-01-07T21:34:00.000-08:00

We're now refactoring most of Citrine to adhere to good testability standards, and as an exercise in unit testing. More to come later.

Citrine is stable.

2009-12-26T19:17:00.000-08:00

Ha, it only took several months, but I'm now happy with the interface of Citrine... furthermore, it works.

Now it's a matter of edge testing and beginning design of Obsidian's architecture.

News!

2009-12-26T15:05:00.001-08:00

I've been working hard this week to finish Citrine. It's in a very useable state now (the interface is basically finalized). We're polishing though... finalizing an internal data protocol, bug-testing, etc. Hopefully Obsidian will pick up again soon.

Reporting in

2009-09-12T19:50:00.001-07:00

No progress lately because school's started and I'm getting in a groove. This week is busy with interviews and netting a part-time job, so work will continue to be slow.

Slow Citrine news

2009-08-10T01:51:00.000-07:00

Not much exciting happening afraid. I cleaned up the test suites for my own sake:

Server

Client

Aside from that, I've started the serializeable-object server/clients to build on the raw data model. Not much working code there yet, though.

Oh, and I fixed all the compiler warnings as far as XML doc goes. Exciting!

Citrine update

2009-08-06T00:35:00.000-07:00

I made a lot of progress on Citrine today. It seems the most cases of clean and faulty disconnects now properly raise events. I'm sort of torn between using separate events for the two cases, but right now it's just "ConnectionLost" and "ClientDisconnected". It works pretty well, and I have a working Silverlight policy server done too.

Testing and serialization to come.

Citrine is underway

2009-08-03T01:00:00.000-07:00

I've been working most of the weekend on the new Citrine project. It's taking a little more planning than anticipated; designing a robust TCP networking library and handling thread-safety, etc, has taken a lot of research.

More news to come when I have it.

Networking update

2009-07-31T22:08:00.000-07:00

I started a new repository for our System.Net.Socket networking library, located here. It's called Citrine, in the vein of naming my projects after minerals with no real value, heh.

Citrine is open source, and I've currently settled on the Microsoft Public License (Ms-PL). I like the idea of sharing my code as I learn how to work with sockets, but I hate the concept of viral licenses. Hate on me all you want, but I'm going to side with Microsoft on the "GPL is a cancer" front.

I was originally going to try to allow users of Citrine to use the client aspect in either Silverlight or regular .NET applications. Since the Silverlight assemblies are completely distinct, this is not going to be as easy as hoped. I might started two projects in VS and link the source code together (reference the same files), since it will mostly be identical.

Musings on framework design: Client Details

2009-07-30T12:21:00.001-07:00

I was having a discussion with James earlier. He got a little flustered when I described the Silverlight socket limitations to him.

Namely:

Limited to port range 4502-4534

Must have an additional server socket running on 943 to serve a policy file

A discussion ensued in which he advocated uses web services and polling to communicate between server and client. At this point, I'm pretty latched onto the idea of either sockets or WCF duplexing such that the server has a firm latch on a client object to call upon.

As a result, we're now thinking about just implementing as many protocols as we can. WCF, web services, and sockets are all currently on the list. Note: I'm still not bothering with PollingDuplexing. WCF duplexing will be for non-Silverlight clients.

This would rely on the implementation of a client interface that allowed the server to specify various messages/events to be sent out. We'd then provide an implementation for each protocol. The socket implementation would write out data as it arrived on the underlying stream. The web service implementation would queue data up for a polling client to read. So on, so forth. The server would be blind to the implementation of each client, as each object would be instantiated at the initial connection and then thenceforth referenced as an IClient. Details to follow pending coding.

Musings on framework design: WCF v. Sockets

2009-07-29T21:59:00.000-07:00

If we're abandoning WCF in favor of sockets, we lose out on something special - the ability to have well-defined communication between clients and server.

PyMUD worked on the concept of basically no protocol. Raw text was sent back and forth between client and server, and it was up to the server to maintain a sense of what was expected from the client in terms of input. Since we're abandoning telnet support completely, that leaves us open to develop our own protocol. Exciting!

I'm currently envisioning a system of serializeable Packet objects being transferred between client and server. The client and server projects would both reference a common assembly that defined the message interface. Similarly, for the purposes of this project, we would probably extend the base Client/Server objects that we've written and add event handlers. These handles would be used for extended Packets... such as CombatPacket, HPUpdatePacket, LootPacket... etc, I dunno. These would again be all defined in a common assembly. This assembly would ideally be well documented and then posted for distribution, so that others can implement our protocol if they want.

Nevermind

2009-07-29T20:58:00.000-07:00

Wow, what a headache today. Apparently it's too much to ask to get a Silverlight application to play nicely with a self-hosted WCF duplex service. I thought it'd be simple after my tests last night, but hell no. This blog post by Michael Braude summarizes my pain.

Following a tip off of the Silverlight game dev forums, I'm now investigating sockets again. They're not as cool as WCF, and it'll cause potential problems with firewalls, but I am not dabbling in Silverlight WCF duplexing anymore until it stops making me want to gouge out my eyes.

WCF, revisited

2009-07-29T14:10:00.001-07:00

It turns out that Silverlight does not support the Duplex model I have coded as my test case. Instead, it relies on a new method created for SL3, called polling duplex binding. I am currently investigating whether this is lightweight/fast enough, and further whether it scales well enough, to fit our needs as the primary communication channel between client and server. It may be prudent to switch tracks and investigate regular old sockets instead.

Thanks again to Timothy Khouri of SingingEels for pointing me in the right direction.

Musings on MUD design: World Structure

2009-07-29T13:58:00.000-07:00

This will be the first in a potential series of free-form posts where I dump a flash of inspiration, a brainstorm, or just thoughts.

In PyMUD, we deliberately avoided the idea of a "mappable" world. We felt that sticking to a grid-based system was too constraining, especially after coming from Ishar, which does all sorts of quirky things with layout and exits. As such we defined some exits as de facto "standards" (N, S, E, W, Ne, Nw, Se, Sw, U, D, In, Out) and allowed for customization beyond those standards. Good idea, maybe, implemented in a messy fashion.

I was thinking today about the idea of mapping, and in particular its merits. It's obviously beneficial to the player, but in particular it makes it easy to design a world for. When the world is mappable, it's much simpler to populate. However, I still feel constrained if a grid system is the only option.

I figure, why not have the best of both worlds? Create a world grid in 3D space. It would be tiled in the XY-plane, and layered vertically on the Z-axis. For the most part, this would be intuitive to map for. A room one tile in any direction would correspond to a shift U, D, N, E, S, W. What becomes slightly more complicated is how to handle diagonal lines (what if the slope is not a whole number?) and exits that span a location of "empty" grid locations. If (0, 0, 0) and (0, 2, 0) are populated and I want to link them, I need to know that (0, 1, 0) does not exist.

At the moment, I envision the following rudimentary model:

interfaces IRoom and IExit. An IRoom knows about its exits, and an IExit knows about its endpoints.

implementations GridRoom and GridExit. These are for use in "standard" space. A GridRoom has a concrete, unique coordinate and is mappable. A GridExit points to a GridRoom, has a concrete direction, and a length.

This would allow for other implementations that define complex Exit behavior (random Room targets, loops, wormholes, etc) as well as Rooms that exist outside of the grid-space. How exactly this model would be mapped to the database is material for another posting.

WCF

2009-07-28T22:25:00.000-07:00

The basic WCF (Windows Communication Foundation) infrastructure is up and running. A lot of work done today!

I initially added a new Commander project in a premature effort to try and emulate my previous reflection-based command parsing endeavors. That didn't work out so well because I realized I needed clients' input to actually parse. Instead of reflection, I devoted the evening to actually setting up client/server communication.

Sadly, it seems documentation for getting WCF configured with Castle in a console application is pretty spare. I had to look far and wide and tear apart numerous WCF tutorials to get a grasp of what I'm doing. Much, much thanks to SingingEels for their client/server WCF primer, it was exceedingly helpful. As far as Windsor goes,


using (var host = (DefaultServiceHost)
    new DefaultServiceHostFactory().
    CreateServiceHost(typeof(IObsidianServer).
    AssemblyQualifiedName, new Uri[0]))
{
    host.Open();
}

seemed to be the magic words.

The result is that I now have a rudimentary client/server model going, sharing common interfaces for their WCF contracts. I'll probably work on documentation tomorrow since James and Steven B. still need to get their dev environments set up.

A little bit of progress

2009-07-28T00:13:00.000-07:00

I got logging working today, and Windsor is all configured as of yesterday. Tomorrow or later I can start actually structuring the project. :)

And, we're off

2009-07-26T15:00:00.000-07:00

I finished researching technologies last night. Currently working on getting a Mercurial repository up and running on Bitbucket. This weekend will primarily consist of design, since James is unable to do any development yet, and Steven B. is out of town.