Form and Meaning: Computational Languages and RPGs
Computational languages were developed primarily from the need to be precise. Whether these are communication languages allowing messages to be passed between remote individuals or programming languages giving an unmistakable instruction set, computational languages are developed to communicate unambiguously. While some languages of this type existed before computers, such as military semaphores and laboratory procedures, it was the development of the computer that gave these languages a broader application and a stronger identity.
Syntax and Semantics
The fundamental feature of all computational languages is that they have prescriptive syntax and semantics. While there is infinite flexibility in terms of what can be expressed in computational languages, the structures used to build these programs and packets are much simpler and refined than those found in natural languages.
The syntax of a language, defines the form of the language, giving the required structure which must be obeyed to fit in the language. In natural language this can be whether the subject appears before or after the verb, while in a computational language it can be whether '=' indicates equality or assignment. In either case, the syntax does not involve meaning, just the form.
By having a definite syntax, it is then possible to associate rules of meaning to the language. These are the semantics. In computational languages there are a variety of methods of specifying semantics, from describing axioms which are preserved as the language is interpreted to breaking the language down into operations which act on the local context of a program. Semantics can even be the interpreter or compiler which allows the language to turn into action. In any case, ambiguity is removed by these semantics, and the exact functioning of the language is represented.
From the perspective of RPGs, syntax is the structure of play, it defines what pieces can be put in what order. If a damage roll is always found with an attack roll, this is an example of syntax. Likewise if character creation follows definite flow, and that process is described by a syntax. On the other hand, semantics enters into the interpretation of the mechanics. Semantics defines what the result of the attack and damage rolls will be (loss of hit point, death saves, or perhaps insanity). Semantics defines what a character can do, based on the choices and results of the character creation process. While syntax can be highly variable, effective semantics often prove to be much more standard. This is reflected both in computer science and in RPGs.
Talking to Strangers
One of the simplest kinds of computational languages is the communication language. Typically treated as a protocol to organize information, communication languages define succinct and expressive ways to send messages.
The simplest communication languages just convert other languages into symbols, and transmit each of those symbols, such as with semaphore flags. As messages and communication needs built in complexity, these protocols acquired headers, to identify relevant information, such as sender and receiver, as well as possible formats for content. Even more advanced approaches incorporate encryption and error corrective redundancies.
In the sense that an RPG describes the communication between its players (including the gamemaster), the facility of an RPG to successfully communicate concepts, actions, and details is a communication language. Often this aspect of RPGs is less though out, and ends up being developed by the players themselves. As such groups which have played together for some time often develop their own protocols for communication, acting as a barrier to communication. Providing a sample communication protocol, often within an example of play, can make a significant difference in helping players adapt to different groups, and make the game generally more accessible.
Building Worlds
Another type of computational language is the specification language. This is a language which is used to define objects, rather than actions. Some specification languages are used to organize information, such as organization diagrams and planning languages. Others focus on defining the limitations and capabilities of things. Interfaces are usually designed in this way, interacting with communication languages by defining what a receiver can do with the message.
Since all specification languages are limited by their syntax and semantics, each is developed to describe a subset of properties and features. The language used to specify heraldry is concerned with relative proportions, shapes, and colors, but does not concern itself with the size of a coat of arms, since this is meant to vary. Likewise, an interface specification for a CD drive doesn't need to worry about what the CD in the drive might be. The most fundamental task of a specification language is to describe what is important and to exclude unimportant details.
RPGs typically possess at least one specification language, often more. These languages can be found in the way a character's details are defined, how challenges they might face are encoded, and in the way that the world is described. The subtle feature of any specification language, though, is the it implies what is important and what is unimportant. This could be the design decision to have skills and attributes, or only one. It can be found in the decision to give combat ready statistics to all people encountered. It could be the decision to detail the mysterious places as much or more than the populated ones. These are the decisions that affect how the game is played, not just how it is read.
What Must Be Done
Probably the most well known computational languages are programming languages. These are languages used to write instructions and methods. Unlike communication languages which guide interpretations and specification languages which guide definitions, these languages guide action. Programming languages bear considerable similarity to the active mechanics of many RPGs, which decide what events occur and the outcome of character actions.
Dialects and Exotica
Programming languages have come in many different varieties. Each can be viewed as a different way to look at RPG mechanics.
Imperative - The simplest form of programming language, imperative languages are simply lists of instructions, containing directions as to when to move to a different list. These languages form the basis for all programming, as the structure of the basic machine language instructions. Many early RPGs had similar mechanics ideas, with largely sequential instructions and specific rules for each situation.
Procedural - By introducing of abstraction, procedural languages became (and largely remain) the dominant languages used in programming. Procedural languages reduce similar parts of instructions into a single procedure, which is then called where needed. This contributes to a hierarchical design of programs. Many modern RPGs use this same approach, such as Storyteller and d20's singular mechanic approach to design.
Object Oriented - Rather than organizing a program with procedures, true object oriented languages build and define objects. The interaction of these objects generates the dynamics of the program. Building such a program becomes the act of adding smaller objects together to build larger objects, until the entire program becomes a small number of objects which are initialized and change as the program executes. In an RPG this approach is often found in games where the characters define the world around them. Thus the mechanics are driven by interaction and self-action, rather than acting on the environment. Also, these games often work well with an influential resources mechanics. Some examples of games with a strong object oriented feel are Sorcerer and Nobilis.
Functional - Functional languages are based on mathematical functions as models of programming. In its most basic sense a function is a transformation, taking some information and processing it to become some new form of information. However, because functions are themselves information, they may be written to act on themselves, producing higher level dynamics very easily. In RPGs a functional game would hinge on transformation, characters would not act, but transform the situation and each other. These games would also possess a pervasive recursive structure as situations and characters transform themselves repeatedly to the appropriate depth to resolve.
Logical - Logical languages again use a different model to describe programs. This model is that of building a proof. In a logical program, first you define what deductions can be made, and then you ask a question. The production of the answer, whether it be a truth or falsity, or a specific answer is generated by searching through the possible deductions to build a logical argument from the question itself. In an RPG this would be a game of flashbacks, where each event is not resolved into the future, but supported into the past, filling in details as needed.
Concurrency - While the languages I've already discussed are largely distinct types of languages, concurrent languages are found within those other types. A concurrent language is one which allows different parts of a program to execute at the same time. Applying this same principle to RPGs is one of the basic requirements for a well designed-larp system.
A View of the Frontier
As a researcher, one of my specific areas of interest is the design of languages for distributed systems. These languages are built on an assumption of local information. Each device in a distributed network can only know its local situation. Global information about the network is either impossible, or expensive enough to be impractical on all but small networks. Rather than rely on coordination, these networks need events to travel via simple transactions. This intuition also applies to the problems of designing live action roleplaying games. These games are often run with a large number of players and locations. This can prove more and more difficult to coordinate at the highest level. Thus a different strategy can be attempted, making the system distributed, built only on local transactions, to avoid the scaling problem that many live action systems encounter as the game grows.
The relationship between computational languages and systems can be very fruitful. The analogies often run very deep, and can be reveal a great deal of subtle design principles from mixing these two fields. On the frontier of both, new ideas are still being developed, and a great deal still remains to be explored.
Next Month: Formal (Mathematical) Languages