Anatomy of a Screen 1

One of the foremost features of Paradice is its component-based user interface.  Whereas most applications that run on Telnet technology are created with a line-mode spew of text from top to bottom, Paradice uses a character-mode interface with explicit control over everything the user sees.

The primary advantage of this is the use of graphics, obviously.  To re-use a screenshot from the first post:



Here, you can see that the Name field is highlighted, and data entry will take place within it.  Hitting the tab key (or clicking on it) will move you to the Password field.  Tab again and you'll be back at the Name field.  This is not possible with line-mode.

There are other possibilities as well.  I could have the leaves on my palm tree change colour, or rearrange themselves to appear to rustle in the wind, if I liked.  The same with the water, and this happens with minimal characters written to the output.

Admittedly, there are a couple of disadvantages to the approach as well.  

The primary disadvantage is that there are only a limited set of Telnet clients available for use.  The screenshot above is taken using the version of XTerm supplied with Ubuntu Linux, and my players all use PuTTY.  The only MUD client that comes anywhere near working with it is TinTin++ (hat-tip to Scandum).  Other clients, many of which come with excellent features, only support enough of the ANSI escape codes to provide colour; cursor positioning is not part of their feature set.  Additionally, some have their own data entry box -- admittedly a fine idea for line-mode applications, as it means that output from the server will not interrupt your own input, but it is incompatible with the idea of data entry fields such as those shown above.

There is a secondary disadvantage, although it has yet to play a significant role, due to the usage of the server being minimal.  That disadvantage is lag.  Because the output is rendered server-side, this may mean a delay before you see an update.  Unlike line-mode applications where the client uses local echo to immediately display what you are typing, updates in character mode require a round trip to the server and back.

This lag may have two sources: the Internet, and the server application itself.

For the Internet, there is little that can be done in general.  The difference between lag for character mode and line mode is that you will see a bunch of lag after each character for the former, and only after each line for the latter.  This will matter more for some players than others.  For example, if you are connecting from the other side of the world, then you will naturally have higher latency.  For those players, a line-mode style may give better performance.  For those people, I have written Issue 100, a second user interface backbone, to provide some kind of line-mode output.  It is currently expected as the primary feature of version 2 of Paradice.  You can see the Development Roadmap for the current development plans.

The server application itself might have lag.  Since it is currently a single-threaded application, this means that anything that keeps the server busy will have a knock-on effect for other connections.  There has been some design work and a little bit of implementation to move it towards a multi-threaded application, and this is tracked in Issue 67.  This is scheduled as the primary feature of version 1.6.

With that background out of the way, the next article will focus on deconstructing a couple of the screens within the application and showing how the component-based UI is used to create them.

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.