 |
| Yeah, this is the model I was trying to evoke, sort of. |
I've had a number of articles sitting in draft form for a long time now, so I guess I'll just publish them, maybe polishing them up a little first (or finishing them, in some cases). I will note that, with this particular article, some of my ideas have changed a bit. Mostly in reaction to the excellent
"Classic Traveller: Out of the Box" series, and especially
this article and
its sequel, I am less certain that the "task chain" idea is necessarily the
best idea, though I do still think that it was a useful innovation (and it may still be the best idea for the way I want to play - this is something that I am still working through in my head, so don't take my current indecision as a final attitude). Even more, though, I am questioning the baseline assumptions of
MegaTraveller in regard to assumed skill and other asset levels. According to some designer's notes in
Challenge magazine and elsewhere, the DGP crew were assuming a base skill + attributes and other bonuses of +4 for a competent character. Any further development along the
MegaTraveller line of design, such as I am working on, is going to have to tackle that assumption and assess it in practice. To a great extent, I would like to get back to the simpler characters of classic
Traveller, but with the better systems support (such as the expanded variety of "task chains" I discuss in this article) found in
MegaTraveller - but this is now digressing in some ways from the point of the article I had written here. So, without further ado, let's get on with it, shall we?
---
These seem like two different topics, but I am really using the one as a way to talk about the other. I am increasingly fond (even beyond my original preferences for the edition) of the ways that
MegaTraveller chose to do things, even as I am not always fond of the particular setting decisions made or the failures of the game's production. The edition earned its nickname of "MegaErrata", with the current consolidated errata for the edition weighing in at 69 pages, a book in itself.
One of the useful formalizations that
MegaTraveller brought to the game was the "task", a unified format for describing methods of resolving actions in the game. Tasks were broken down by difficulty, usually one or two assets that promoted success, and various complications and risks inherent to the task, along with the amount of time that attempting the task takes. Along with this, the game included formal rules for retrying failed tasks, and this was where the
Jack of all Trades skill was given its moment to shine, since characters would have to come up with a new approach to failed tasks (so that they aren't doing the same thing and expecting different results), and the skill gave characters a leg up on that as a way of modeling the flexibility and broad knowledge of such a Renaissance person. Helpfully, the game also included a realistic assessment of the benefits of having computer assistance with tasks, the effects of working quickly or cautiously, and so on. It's an elegant system that has many deep implications regarding the nature of the game, and even provides insight into the nature of roleplaying games generally.
One of those implications was never explicitly spelled out, to my knowledge. Tasks were sometimes presented in what might be called a "task chain". These are the flowcharts and stepped procedures that the game used to break down complex actions into discrete tasks that would be checked in order, and that could be varied to provide the players' characters the highest benefit. It's that last element that makes the task chain really useful in terms of playing a roleplaying game.
In a sense, a roleplaying game can be thought of as a random event generator, with the events generated being used to drive the players to make choices that, combined together, outline the events of the game that are constructed into a story. In the earliest games, the random events were of two main sorts: encounters and conflict resolution. This is fine, but leaves an emphasis on combat as being the main source of events due to complications. Some games choose what we might call "diegetic" (referring to the film distinction between diegetic sounds that originate from elements within the story, such as music playing on a radio, and non-diegetic sounds that are used to help illustrate the story, such as the score) considerations as the primary source of events, while others look to "narrative" considerations of pacing, action, and so on. There are also "game rule" considerations, which are those that relate to the game rules specifically, as distinct from the diegetic and narrative considerations, such as the tracking of abstract "hit points" and similar elements. These last typically intersect with the first two considerations (such as when hit points are understood as a marker of the narrative importance of the character, or when they are used to represent the physical toughness of the character).
MegaTraveller decided to expand resolution to provide potential event complications from various failure points in normal activities, and provide tools for the Referee to easily and quickly outline unusual activities. Combat is the main task chain that most players are familiar with, and is usually one of the more detailed elements of any given set of roleplaying rules. It consists of a set of tasks that can be chained together according to player choices which affect game state variables (character and equipment damage, resource expenditure, and so on).
MegaTraveller further outlined a number of other task chains, though mostly in third-party materials. Digest Group provided the most of these, from medical procedures (in a series of articles in
Travellers' Digest) to exploration (in
World Builder's Handbook), all the way to various starship operations (in
Starship Operator's Manual, Vol. 1). The Keith Brothers expanded on some starship operations related to starports in a pair of articles in
Far and Away magazine. In each of these, the procedure is broken down into discrete steps, each step presented as a task. The steps might rely on different assets to promote success than other steps, which is how complex activities requiring multiple assets were best modeled, rather than incorporating all of the assets into a single task roll. Frequently, the players are also given choices as to the specific order of some steps, skipping steps to cut corners, and other methods of modifying the details to achieve the precise levels of risk and reward related to the task chain that they are willing to take on. Failure at any given point in the task chain has defined effects that introduce complications into the game with which the players will need to deal. Task chains also include the random encounter tables and similar normal event generators, as in the starship task chains where certain steps include checks to see if pirates or customs inspectors show up. In a broad sense, a campaign can be understood as one long, complex, and somewhat freeform task chain (in which case, the "campaign frame" I've discussed elsewhere can be understood as the specific task chain being used) into which a variety of other task chains are fitted.
Those complications generally take up some amount of resources, whether that is time, equipment, medical treatment, money, ammunition, or whatever. Each complication introduces an effect into the ongoing campaign and alters the precise trajectory that the characters take as a result.
What players need in order to feel like they are playing a roleplaying game rather than just rolling dice is the ability to make choices that affect the outcome of activities. This is incorporated into the task chain by allowing the specific order of events to be altered with appropriate consequences, the configuration and nature of risks to be determined (such as protecting an injured character behind a defensive line of healthy characters, adding to the risk of the latter while minimizing the risk to the former, performing a task hastily, saving time but risking failure, or the like), determining the allocation of various resources, and so on. In addition, the players can introduce a particular task chain by attempting to resolve a situation using a given method. Interacting with a person encountered might involve an interpersonal task chain, a combat task chain, or some other sequence, and the specific choice of which to use and the results that come from it will have an impact on the subsequent events in the campaign.
Because task chains can introduce a number of story elements autonomously, without significant Referee input, they are a very useful tool. They allow the Referee to concentrate on higher-level aspects of the setting, such as ongoing plots by recurring NPCs, setting events, and domain-level activities, while still keeping the players' characters grounded in the specific events that affect them. The Referee has a number of predefined task chains related to common activities (approaching and leaving a system, combat, medical care, trade- and commerce-related activities, wilderness travel and exploration, and so on) and only has to worry about unusual activities (changes to encounter tables due to setting events such as a coup d'état in the area, for instance).
This concept of task chains provides an alternative or complement to the common concept of breaking a roleplaying session into "scenes", modeled on traditional fiction. Certainly,
MegaTraveller made use of that concept of scenes as well, with the system of "nuggets" for presenting adventures as a series of scenes or scene clusters that flowed into following events depending on how the nugget was resolved. Nuggets were never formally incorporated into the game, though, and were mainly a way to think about the structure of scenarios. In practice, the nugget method pushed scenario designers toward linear, or "railroad", adventure styles, so they seem like a net liability.
Combined with the system of various NPC types and other encounter rolls found in the
basic game flow, task chains help define an approach to gaming that enhances the open nature of a roleplaying/adventure game.
---
That was the article I'd previously written. I want to add that my idea of "task chains" is not limited to what we might conventionally think of as "tasks" in the
MegaTraveller sense. An item like rolling for random encounters or events is part of a task chain, in the sense I am using it here, as are other events and items that aren't under player character influence. The point is that it is a resolution system that is a sub-game of the whole game being played. Task chains can consist of other task chains, such as the "main loop", as it were, of the basic game flow I mention and link above being an overall task chain, which can be composed of subroutines (again, as it were) of combat, finding cargo, landing a spacecraft, or whatever. I think that computer programmers will probably see what I am going for here pretty quickly, and others might be able to relate it to the general structure of a computer program as well. That said, it would be a computer program written in pseudocode, with the Referee and players being generally able to parse even the most abstracted "commands" in the loop, and to break them down into further detail as the situation warrants.
