The Story So Far

In 2010, when a group of gamers at The Conclave decided to have some fun with a game of the Warhammer 40,000 roleplaying series called Dark Heresy.

Being somewhat geographically distributed -- the current players are distributed across the UK and the Netherlands, but we've also had a player from the USA -- there was a need to make some of the more random parts of the game mechanics visible to everyone.  So we installed IRC and a dice bot and went at it. One of our players -- our current GM -- kept disconnecting every few minutes though.  We never got to the bottom of that, but I hypothesised that his router was throwing idle connections away.  That just wouldn't do.

Having previously played, developed, and designed muds during my university life so long ago, I suggested I might be able to knock something together to help with that.  After being greeted with the requisite "Yeah, whatever," I did so.  A couple of lunchtimes later I had a simple straight-forward Telnet server that could do some chatting and roll dice.  I even fixed the disconnection problem by making sure that it sends an invisible telnet no-operation packet every now and then.

Fast forward a couple of years and I've put some more evenings of work into the creation of Paradice 9.

From the simple scrawl of text that it once was, the Paradice codebase now boasts a component-oriented graphical user interface framework that is implemented using ANSI and VT-100 escape codes in order to provide a better user experience.

A few months ago, after releasing version 1.1 and soliciting the GM and the players for features they thought might be useful additions, I found myself asking what it was I wanted to do with the codebase.

I came up with several answers, all of which can be done in order:

• Continue developing features that are useful in general in order to support the tabletop roleplaying experience.
  
  Currently on the cards is the Encounter feature, which will allow the GM to organise combat encounters with the bad guys in advance.  It should support tracking of stats such as initiative rolls (to determine the order in which characters perform their combat actions), disposition towards the party, damage taken, and so on.
• Further develop features to allow the server to support multiple concurrent gaming sessions.
  
  Eventually, I would like to advertise this as a service to fellow internet roleplayers, of which there are many, and for it to perform both as a gaming and as a social hub.
  
  For this to happen, there are two big changes that need to go in: one architectural change and a feature.
  
  First, add multi-threading to enable the server to scale to potentially hundreds of players.  One current limitation is that since the sophisticated UI is actually rendered server-side before being transmitted, it's possible for a player to 'hog' the single thread that it runs in.  There has been some work towards this goal, but it needs a few other key things to be in place before it happens.
  
  Then, introduce and implement a room concept that allows gaming sessions to segregate themselves away from the others.
• Isolate portions of the codebase that are generic to applications so that it can be re-used in different applications.  Note: code isn't reusable until it's been reused.  So this might actually involve writing a new application as well.
• Implement a new set of renderers so that applications can host clients that do not have sophisticated ANSI capabilities -- there are some that do colours and that's it -- can still be used.
  
  At this point, I can also advertise it to the mudding community as a new custom codebase.  It's my hope that it will add diversity and thus improve the mud server ecosystem at least a little.

So these have ended up as the road map for Paradice.  This blog is to chronicle design decisions both old and new on the path towards those goals.