In June 2004, not long after Cory had introduced me to Second Life, version 1.4 was released which added Custom Character Animations. In the accompanying press release Philip said “My fantasy is to be Uma Thurman in Kill Bill”, “I’d pay $10 for her yellow jumpsuit and sword moves and I’m sure other people would too.” I’d been looking for something to build in SL and also been thinking about melee combat systems in RPGs which traditionally just leave the tanks hacking away while the others get loads of different fun and interesting abilities to use. At the other end of the spectrum arcade fighting games give players lots interesting choices to make, but require twitch reflexes that require low latencies that are difficult to achieve over networks let alone in SL. Building a tactical melee combat game in Second Life sounded like the kind of interesting challenge I was looking for, so at the end of 2004 Doc Boffin and Jaladan Codesmith set out to build what would become Combat Cards.

The early versions of the game were built in to weapons and employed a simple llDialog interface for selecting moves, but the core mechanics were very much as they are now. HUDs were introduced In October 2005 with Second Life 1.7 and I immediately started thinking about converting the game in to a trading card game — a business model that seemed to fit perfectly with Second Life’s micro currency based economy.

A trading card game needed an artist and after looking for one on the SL forums I was very lucky to find the wonderful Osprey Therian who preceded to blow my mind producing amazing artwork and taking incredible pictures of the fantastic avatars of Second Life for what became Combat Cards.

Working on the game while working at Linden Lab gave me insights in to how Second Life felt from a residents perspective. Despite Second Life’s flexibility, it’s a lot harder to build complex systems than it should be. Building systems that can send out product updates is fiddly, error prone and something that should be in the platform, LSL’s memory limitations mean that I often spent more time cutting scripts up or trying to save memory than building features. When the number of cards and so data increased, Combat Cards ended up having to incorporate a paging system to load lines of notecard data in to memory asynchronously in order to continue to work. This hugely frustrating and time consuming experience led directly in to the discussions and design around Script Limits which will allow Mono scripts to request as much memory as they needed.

Learning about building businesses in Second Life was also incredibly valuable. As a multi-player only game, Combat Card’s biggest challenge has always been getting enough people together at the same time to play, something that has resulted in a series of wonderful parties and regular events often hosted by the amazing Kat Burger. It also resulted in the exploration of linking Second Life with social media that led to Combat Cards arenas tweeting game results and then the LSL Twitter OAuth Library that allowed players to tweet results from their own accounts without disclosing their Twitter passwords. When we finally found a print on demand service that allowed Combat Cards to make the jump to RL it also allowed us to explore the possibilities for linking RL and SL businesses that resulted in the system for buying gift certificates for L$ in SL that can be redeemed for physical Combat Cards in the online web shops.

Keeping my Babbage Linden and Doc Boffin identities separate for over 6 years has given me incredible insight in to what it’s really like to be a Second Life resident, but it has been exhausting. There was an awkward moment in 2006 when I had to tell Philip that I worked for him when he came to check out Combat Cards, Osprey only found out that I was a Linden in 2008 when I emailed her a version of the RL rules sheet that Word had helpfully annotated with my name and I had to come up with a dweeby Doc Boffin voice to disguise my identity when commentating on Combat Cards matches on YouTube. It’s a huge relief to finally be able to come out of the closet and talk about Combat Cards openly. I’m incredibly proud of what Osprey, Jaladan and I have achieved with the help of Kat, Comragh, Spin and our amazing player base, to whom I apologize to for sometimes not being able to devote as much time as I’d like to Combat Cards. My other Second Life as Babbage Linden often kept me pretty busy.

Now that I’ve left Linden Lab I hope to still find some time to work on Combat Cards and hope that it will now be easier to pursue the full publication of Combat Cards in real life that Osprey’s amazing artwork deserves. I’m very happy to announce that Combat Cards 3.0 and the long awaited Robot Series of cards will be launching on 31 October and hope to see you all at the launch party at 2PM Pacific (Second Life time) at the Combat Cards Arenas in Europa. I’ll leave you with Osprey’s latest amazing promo for the event.

Since leaving Linden Lab I have been talking to a number of people about doing freelance consulting and development work while I get my start-up off the ground and last week got round to setting up a UK limited company so that people will actually be able to pay me.

Setting up a company is insanely easy these days: if you go to companies made simple it will cost you less than £17 and 10 minutes of form filling. Coming up with a name is harder, but within a couple of hours I found that 18dex was available as a .com TLD, twitter account and facebook username. Meaningful 5 character .coms are pretty tricky to come by these days, so I snapped it up and 18 Dexterity Ltd. was born — a pretty fantastically geeky name for an agile software engineering company I hope you’ll agree.

A few minutes later I had a holding page up for 18dex.com, but it looked pretty sad with no content, so I started thinking about setting it up as a blog. I have a stack of relevant software engineering posts on jimpurbrick.com from the last few years, but they are sandwiched between less relevant posts on 100robots, Second Life and various miscellany. I didn’t want to move the software engineering posts from jimpurbrick.com as they’re part of what I do and regularly updating a single blog is quite enough work. I also didn’t want to copy the posts from one blog to another as it would potentially end up with 2 independent comment threads on each blog. There would be no definitive version of a post, a blatant violation of Don’t Repeat Yourself.

Luckily Django includes a piece of machinery to deal with this problem in its sites framework, something I’ve been meaning to have a closer look at for some time. The sites machinery simply lets you associate a piece of content with a site and keeps track of the current site, allowing you to filter the content in the database to only show a subset on each site.

While the byteflow blog engine I use for jimpurbrick.com supports the sites framework, each post is associated with a single site via a ForeignKey. In order to allow posts to be shown on both jimpurbrick.com and 18dex.com I had to change that ForeignKey field to be a ManyToManyField: a single line change in the python code, but something that requires a little wrangling to massage the existing data to fit the new model.

I’ve been using the excellent South in all my recent projects to allow me to easily migrate data across django model changes. Although jimpurbrick.com dates from long before South was available I managed to convince south to manage the migration by dumping the blog_post table to json, dropping the table and recreating it with south, reloading the data and then letting south migrate the data to the new ManyToMany schema. While this was slightly more fiddly than it could have been it means that the blog app is now being managed by south, which will make future development on the blogs much easier.

Once I had migrated the data to the new model and associated the software engineering posts in jimpurbrick.com with both sites in the django admin interface all that remained was for me to clone the jimpurbrick.com directory with mercurial to create an 18dex.com directory and choose and tweak a byteflow theme for the new site.

Once again I’ve been very impressed with Django and Byteflow, which have proven to be incredibly powerful tools that are very easy to work with. In a few hours I was able to create professional and personal views on to my blogging which can be easily administered from a single interface and allow comment threads and users to easily flow between them. If you’re just interested in my software engineering posts, head over to 18dex.com, if you want to hear about music, Second Life and everything else I get up to, stay subscribed to jimpurbrick.com. If you notice anything broken on either blog, then please leave a comment to let me know.