The Problem

Some friends of mine were running a game that required a log of items to be maintained with things being added, removed and changed. The original system was just a simple excel spreadsheet, and to make matters more complicated most of it's use was at a laptop in a location without internet access. As time went on version control for the file became completely unmanageable, with multiple people editing items and no clear policy regarding who is permitted access or how the file gets stored between events. I wasn't usually involved in the log's use, but it became clear to me that I was in an excellent position to provide a better system when wireless access became available on site.

Lessons learned

Overall this project went very smoothly. Writing an application for clients with a very general idea of what they want requires a good deal of planning, flexibility and additional work. Being familiar enough with the operation gave me the ability to anticipate what they would want from the interface and also solve some additional issues, like automatically generating the pdf handouts.

Known Problems

The export to XML excel doesn't seem to work with Open Office.

This was the first personal project of mine that still exists in a working form. Two or three years ago I spent some time playing the Flash game Skyrates, getting to know the community under the alter-ego Captain Waffles. The core gameplay element was purchasing different types of aircraft and fitting upgrades and improvements to the plane within a set of rules. Seeing as how there were thousands of possible combinations of aircraft and upgrades I decided to put my web app skills to good use and make a tool for testing out potential combinations.

Known problems

It's visually bland. I had originally planned to fix this in the second version when certain ship statistics changed, but I stopped playing the game before that happened.

The comparison system is a bit of a cludge. I started the project a little gung-ho and plane comparison wasn't in the feature list until the users demanded it. Unfortunately the way I had organized the code didn't allow for the kind of flexibility I wanted for a proper compare interface so I ended up just doing what worked.

Lessons learned

This was a good exercise in interface design given how much information and tools needed to be displayed on screen. Years on I can see a lot of room for improvement and what I would have done differently, but I never received any complaints that it was difficult to use or hard to figure out

The Problem

A friend of mine running a game found himself without a player management software when the author of the previous one retired when a new version of the game was released. I had thought before that a web application was a better solution to the problem than the old desktop program, whitch was plagued with manual versioning of save files, so I volounteered to write a new one.

The Sad Part

At the time I had recently gotten quite good with Javascript and Ajax and was very excited to put it to use on a high concept idea. So I set out building a web app that resembled the windowed feel of the old desktop software, with a robust framework so that adding new screens and functionality would be a snap. Sadly the start date for my friend's game wasn't really enough time to write much of any sort of software and he was forced to use a kind of hacked version of the old version. Having solved most of the technical hurdles but not having much reason to continue I cleaned up the interface a bit and turned it into a demo.

Details

The windows are done via a third party javascript that I wrapped in an additional class to add the operating system behavior and generally make it easier to use. A call to open a window is all done via Ajax with window information and content coming back via JSON along with inline javascript to add further functionality to the window's content.