Published Author

Many apologies for the silence, but my writings have been directed elsewhere for the time being.  I re-worked and expanded upon my intro story for the resurrected Imaginary Realities journal.  My article, "A Journey Through Paradice," begins what I hope will be a long string of publications into how to design and develop graphical-style output using the older protocols, in an attempt to persuade modern mud client authors to implement full ANSI and also the Xterm protocols as additions to their clients.

Anatomy of a Screen 2

The aim of this article is to demonstrate the composability of the Munin UI; a key feature in the Paradice codebase.  We begin by looking at one of the simpler UIs: the main screen.  This is the screen that is active most of the time for most players.  It comprises four major components: a list of the people currently playing (the "who-list"); a text area for feedback about events such as server entries and exits, dice rolling, people chatting, that sort of thing; a command prompt; and a clock.

The Munin UI is structured around a few major entities:

• munin::element represents the smallest possible drawable object.  It comprises an attribute, which includes data such as the foreground and background colours, underlining, bolding, etc., and a glyph, which represents the character being displayed, the locale for the character, and the character set from which to take the character.  This allows for a great variety of display, as this includes graphical characters such as the double-lined borders you can see in the image above.
  
• munin::component is the base class for all viewable objects.  Classes derived from it implement a number of functions, including a method for receiving events such as key-presses or mouse clicks, and a method for drawing itself onto a canvas (which is, essentially, a grid of elements).  One special component is munin::container, which is a component that contains other components.
  
• munin::layout is the base class for lightweight objects that know how to arrange components.  For example, munin::grid_layout arranges a number of components in fixed-sized x/y chunks.  munin::compass_layout is a layout that arranges components according to compass points (north, south, east, west and a special 'centre' direction).
  
• munin::window is the top layer of the user interface.  It has a container component called "content" that is used to hold the entire UI.  It also controls the repainting function, which compares the canvas at the last repaint with the canvas after the current repaint, and produces a string of ANSI control commands that can be used to update the client's UI with the new information.

In terms of the image above, it is created roughly as follows:

• A container called inner has a compass layout.  To the north is the who-list, in the centre is the text area, and to the south is the command prompt.
  
• A container called outer has another compass layout.  To the centre is the inner container, and to the south is the clock.
  
• The window's content has a grid layout whose [x,y] dimensions are [1,1] (that is, a single component that fills the container).  It contains the outer container.

Naturally, the who-list, text area and command prompt are composed of further subdivisions, and working these out is left as an exercise to the reader.  Or you can just examine the code itself, now that you know what you're looking at.

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.