This document serves as a “brain dump” of ideas for what the precise goals of the Silt server should be.
The current state of the art in online text gaming is woefully inadequate. As a result the hobby as a whole is dying. These are the deficiencies in the current approaches which have led to this long decline.
For most online text games (MUD, MUSH, MUCK, MOO, et al) the technology used to interact with the end-user is centred on telnet, an ageing protocol initially designed to provide remote access to a system shell. For such access purposes telnet is more than adequate since an operating system session is typically a mostly-synchronous environment in which information is printed to the user's screen only upon receiving a command.
Raw telnet, however, is not suited to online text gaming because it is a mostly asynchronous environment in which information is frequently displayed without user input and, as a result, default telnet implementations will have scrolling screen “spam” destroy anything the user types thus rendering the user's ability to edit interactions impossible. Since the only way to link to an online text game of this sort from a web page is with a URL beginning with telnet://, this means that the first impression that casual browsers of online text gaming will have is starkly negative.
Custom clients (which most gamers use) solve this problem through the use of a separate input field, but the initial impression remains the most powerful in most human interactions. Consider the issue from the end-user perspective: the game being tried looks ugly and someone on the game is saying “no, you just have to install X software and it looks great!”. (The fact that this is a flat-out lie—nobody could ever call online text games “good-looking” by any stretch of the imagination—doesn't do much to help the perception.)
The fact of the matter is that at the end of the 20th century the world moved to the World Wide Web as the universal remote access mechanism. The current generation of Internet users is familiar with the World Wide Web and its general look and feel and will not really find raw, plain text scrolling by on the screen to be a compelling gaming experience.
Enhancement is another problem with most online text game engines. Some of them are rigidly constructed and permit little to no customization short of difficult programming work with systems programming languages (typically C). Some permit varying degrees of end-user customization but are extremely limited in capability (MUSH), use a powerful language that has very little coverage outside of the minuscule hobby (MOO) or use a reasonably well-known, powerful language that is prone to obfuscated code (MUCK).
The result is that even when customization is theoretically possible it is not done because there is too small a pool of people capable of doing the customization to draw upon. The end result is a large number of games that look and feel identical to other games on the same engine because that is all anybody knows how to code. (For an example of this consider what percentage of MUSHes are based on the World of Darkness and little else.)
One of the foundations of good software design at any level of building software is modularity. A good system for writing software (and making a game on a platform is writing software) must support modular software components in some form or another to prevent code from one person from trampling over the code of another. Since most (perhaps even all) current text game platforms lack this basic requirement of good software the barriers inherent to building a game which already exist (c.f. “Enhancement” above for some of these) are made even higher.
Without modularity it is not possible to reliably build generic pieces of code which can be just plugged into an existing game. This means that every game needs a dedicated coder (a rare resource for reasons already detailed) to build anything more complicated than what amounts to a glorified chat room.
Building on most (perhaps all) online text game platforms is a tedious chore that is prone to failure. Consider, for example, the process of building just a single room on a MUSH:
The @dig command is invoked to make a room object. It may optionally be immediately linked to the current location by providing an additional argument that constructs an exit object leading from the current location to the newly-dug location as well as an exit object leading from the newly-dug location to the current one. For purposes of this description assume that this is the format of the @dig command used.
The exit leading to the newly-dug room must have a description provided.
In addition some standard, typically boilerplate code must be provided for the messages seen upon people entering or emerging from each exit. These are the
@success,
@osuccess and
@asuccess attributes.
The room itself must have a description at a minimum as well.
Further complexity is instituted through the use of a bewildering variety of locks, room parents, exit parents and other such items.
This complex suite of attributes must be manually entered each time, there is no system-provided checking for compliance or completeness (unless this is self-coded, adding another barrier to starting an online text game) and there's a great deal of opportunity for error, especially given the often unintuitive naming of the attributes.
There have been many attempts to solve the problems highlighted above. Many of these efforts have been laudable, but have failed because they only partially addressed the issues with online text games.
There are numerous projects available where people have attempted to code an online text game from scratch in a more popular, more flexible language like Python or Ruby or the sort.
These efforts have largely failed because they do not address the simple fact that a telnet-based game server is not going to attract a lot of attention in the modern age, and those who play on telnet-based games are already used to what they have and see no need for learning an entirely new system.
Some of the client software available for online text games is impressive in its capability. There are clients that not only provide input fields, but MULTIPLE input fields; that provide filtered views to help ameliorate the tangle of words and information on the screen; that provide complex client-side scripting capabilities complete with triggers and timers; that provide, even, custom editors to work around the more horrific aspects of some of the scripting languages used.
These efforts only stave off the inevitable problem caused by the limited core of an online text game. Individual players can be helped with this, but the community as a whole cannot because it cannot be guaranteed that each player has the same client nor that each player has access to the same suite of client-side code.
There have been attempts to embed clients for online text games into web pages. This approach can be a simple embedding of a telnet client into a Java applet on a web page or as complicated as customizing a text game engine with some web enhancements and then writing a comprehensive client in a Javascript toward that modified engine.
The first of these—an embedded Java applet—does not solve the issue of an ugly interface. If anything it serves to highlight just how ugly the interface is in comparison to the 20th century interface around it. It also assumes too much of end-user's environment, to wit:
The user must have Java installed.
The user must have the correct version of Java installed.
Neither of these assumptions is a safe one.
The second of these is a more promising approach, but its sole user—Skotos Technologies—can only be regarded as a failure. While the failures of Skotos' games can be attributed to a great many causes with intense negative synergy, the fact that the client was still, at its core, interacting with technology made in the late 1970s and early 1980s with a wobbly heap of extras piled on top in an ultimately vain attempt to bring it into the 20th century was undoubtedly a contributing factor.
Another approach used is to embrace the web format fully and use only web tools (most notably web forum software) to play games. This technique does work, admittedly, and indeed the popularity of play-by-post games far exceeds the older telnet-based games at this time. The approach, however, does not lend itself well to the intensity and immediacy of a good role-playing game. It is acceptable to many, but leaves room for improvement.
The Silt server is intended to deal with all of the above issues.
It will be based entirely on the most modern of readily-available technologies: the World Wide Web. The browser will be its primary (but not only!) home and it will make full use of the browser's capabilities.
The language of implementation will be Java, one of the most popular programming languages currently in use, and the language of customization will be any language capable of working in the JVM environment and interacting through the Bean Scripting Framework package. (At time of writing this is at least a dozen languages including popular languages like Tcl, ECMAScript, Ruby, Python and Groovy.) This not only renders the platform easily customized, it allows for a very sizable pool of possible developers.
By building the Silt server in the Java EE environment it is not only possible to use modular components, it is indeed mandatory. Extensions to the engine will be in the form of “Enterprise Java Beans” (EJBs); managed components which the Java EE application server will strictly control and separate from each other.
By employing a web framework as the native interface (but, again, not the only!) it will be possible to have the building of games be rendered easier, to wit:
Forms-based data entry ensures that nothing is overlooked.
Data validation ensures that data that is entered is compliant with game standards.
Intelligent forms design allows boilerplate to be inserted by default and past entries to be provided as choices.
The same intelligent forms design provides for human-readable and descriptive names for the items being entered, avoiding some of the confusion that surrounds many of the legacy systems.
In comparison to the other attempts to improve the online text gaming experience, Silt will provide the following advantages:
It will address all of the shortcomings of the current approach in a single, coherent package.
It will be an application native to the modern remote computing paradigm instead of a throwback to decades-old technology.
It will not rely upon the user having a specific, third-party client for a good experience. The browser is the client and everybody will have access to it from any standards-compliant browser.
It will not, however, restrict itself to the browser as client. Third-party clients through protocols like SOAP or similar will be supported if desired.
Its web access will not be a thin wrapper over the old approach, nor will it be a wobbly heap of adapters sitting atop of the old approach. It will be built from the ground up to support web (and other) connection approaches.
It will have the immediacy of real-time, extemporaneous game interaction.