UP | HOME

RPGs, Time, and Travel

Table of Contents

Approximately 15:27 minutes of reading time.

1 Why Travel Matters

1.1 The Illusion of Time

Roleplaying games, no matter the medium, try to preserve an illusion of temporal consistency. That is, they try to simulate the passage of time.

In tabletop games, we find evidence for this in the rules for combat, as games often presuppose 'combat turns' which abstract time in combat. A roleplaying system that does not compare its turns to a 'real' unit of time, or one that omits combat turns, still follows a chronological order. The fact that roleplaying games are narrated necessarily leads to a linear structure of occurences in the game.

For computer-based roleplaying games, this holds even more strongly. Both real-time and turn-based combat systems necessitate the illusion of passing time to exist on a combat scale, and many games even simulate the passing of days and months by including elaborate calendars, changes of seasons, and day cycles.

1.2 Time and Travel

This simulacra of time is closely connected to the simulation of travel. Moving through space and experiencing the passage of time are strongly associated in many narratives (consider The Hobbit, Lord of the Rings, American Gods, etc.).

Roleplaying games are inspired by these works, and part of the fascination of these games lies in bringing wanderlust and travel into the safety of one's home. This is part of the reason of why so many roleplaying games present strange new lands and often attempt to simulate travel.

Many games even try to make travel an integral part of the gameplay. Travel is then interpreted as a more or less simple optimisation problem wherein time is weighed against risk (and sometimes resources and opportunities). The trivial travel problem is "Do I take my time, or take a risk?".

It is clear that in order for this basic mechanism to work, loss of time has to have some consequence. The most common way to push players into a more risky travel style therefore is to give them an external time limit. More complex systems often include food logistics, making taking your time more expensive, which can make external motivators less of a necessity.

Games more focused on the travel portion often don't complicate the central problem further, but go into more detail concerning the factors time, risk, resources and opportunities.

  1. Adding the time of day as a factor for what risks the players are likely to encounter, handling smaller and smaller timesteps, and including large scale developments such as seasons or slowly moving fronts of a war are all ways of adding depth to time as a factor.
  2. Instead of risking 'just' a hostile encounter by taking a shortcut, players might also get lost or stuck, lose rations or fuel, or perhaps even get lucky and come upon friendly travellers. All these additional outcomes don't change the actual optimisation problem, but simply complicate weighing the various parts against each other. On top of this one can add less route-dependent risks such as diseases.
  3. The factor of resources can be complicated further by adding food and water logistics, salaries of porters, or tariffs on borders.
  4. Time, risk, and resource cost can be balanced against opportunities of discovery, experience, and treasure.

For such complications to deepen the problem, they ideally should connect the factors in new and non-trivial ways. Taking one's time while travelling usually would – by way of increased food consumption – raise the cost of the trail. But depending on the road taken there might instead arise opportunities for foraging, exploration, or trading.

In the trivial travel problem, the connections are clear; Complicating the problem then should happen by obscuring these relationships. This can happen both by adding non-trivial, 'minor' links, and by hiding the expectable effects behind random chance.

1.3 Limitations and Outlook

The level of detail implemented is limited by both what the designer is content with, and outside factors dependent on the medium. Tabletop games' detail is bounded by the willingness of the involved people to engage with complex systems of tracking fatigue, rations, and the time necessary for actions, whereas for computer-based games the temporal consistency clashes with the creator's vision of the overall game experience, and the player's demand for fast-paced action and instant gratification.

The value of more consistent time tracking for tabletop roleplaying games has already been noted (Getting there is Half the Fun), and this text will merely try to examine how travel is handled in traditional and digital roleplaying games. Hereby we will to come to an understanding why video games handle travel the way they do and will check how travel systems in computer-based roleplaying games could be improved.

2 Travel in Tabletop Games

Tabletop games are rather fluid in their attentiont to detail, and the passage of time is one of the clearest examples of this. Whereas some roleplaying games do not even present rules or tips for tracking time, the old school approach puts high importance on being precise, as evident from Gary Gygax' own writing:

Game time is of utmost importance. Failure to keep careful track of time expenditure by player characters will result in many anomalies in the game. […] YOU CAN NOT HAVE A MEANINGFUL CAMPAIGN IF STRICT TIME RECORDS ARE NOT KEPT. – Dungeon Master’s Guide (page 37), Gary Gygax

Many modern editions of roleplaying games hailing from those times retain their systems on time tracking as a sort of archaic, often-ignored vestige. Newer roleplaying games often forego these complexities by simply ignoring the passage of time out of certain, closely defined situations such as combat. Including the burn time for various light sources or craft time tables (as in Dungeons and Dragons), or monthly salaries and research times in days (as in Call of Cthulhu), seem out of place for the modern, streamlined approach.

Still, there are players and gamemasters intent and willing to use more elaborate time tracking to strengthen the simulationist appeal of their roleplaying adventures. Two major approaches (mesh-based pointcrawl, hexcrawl) to travel have proven themselves over time.

2.1 Pointcrawl (Mesh-based)

In this approach, the locations that players are aware of are treated as nodes of a mesh, with the edges of the mesh having their corresponding travel times. The main advantage is playability, as all important gamemaster rulings of travel (duration, likelihood and types of hostile encounters) can be done in advance and easily assigned to the edges of the mesh. In play, longer travel times can be calculated by summing over the player's path through the mesh.

This mesh-based approach also is easily extensible in play; newly found locations can simply be connected to existing ones, and new connections can be added just as easily.

Another advantage of this system is the ease with which large, empty swathes of land can be represented next to densely populated regions, by merely increasing the travel times between some of the nodes.

The main disadvantage lies in the restriction of player choices. As the strictly mesh-based approach greatly depends on the gamemaster to prepare all possible paths in advance, the amount of options relies on the density of the mesh and the diligence of the gamemaster. As everything basically has to be prepared, it is hard to maintain a sense of exploration for the players. Especially as they have to specify a target when setting out.

Sorry, your browser does not support SVG.

Figure 1: How a point-crawl might look interpreted as a mesh. Note that visually (or even 'geographically') close locations do not necessarily share an edge. Also note that different paths between points (e.g. A–E cw. vs. ccw.) can have different lengths, representing different speeds of travel.

It is not unusual for gamemasters to roll for encounters just once for each edge travelled. This can feel somewhat unrealistic if distances between nodes vary in a region where the population density is somewhat constant, as one would expect the average amount of encounters to scale linearly with the distance travelled. As a compromise, the gamemaster could roll for encounters dependant on time passed, but this necessitates additional notekeeping for little gain.

2.2 Hexcrawl / Gridcrawl

Repopularised by the West Marches campaign (Grand Experiments – West Marches), this approach is focused on strengthening player agency and emphasising exploration. This is accomplished by allowing players full freedom of movement on a twodimensional grid which has been prepared by the gamemaster. Due to the isotropy and lack of diagonals of hexagonal grids, they are the most common type used nowadays.

With this approach the players are generally allowed to go in any direction they choose, with the gamemaster checking their location and trajectory against the grid to choose which random encounter tables to roll against and to see whether they come upon any pre-planned locations. Dependent on the terrain of the hexes, varying travel speeds can also easily be applied.

The big advantage of this method lies within a more close simulation of 'real' travel preparation and execution. Instead of marking their target location on the map, the gamemaster should give them directions as one would in the real world (eg. 'Go west until you come upon a river, then follow it downstream for a day.'). Some systems even advocate for simulating the possibility of misidentifying one's current heading.

Instead of this more 'obscuring' take on hexcrawling where players generally have to create their own map so they don't get lost, one can also prepare the travel part of a gridcrawl as more of a boardgame. Presenting the players with an accurate map of the prepared grid allows them to plot their entire journey in advance and to weigh different paths carefully.

With the aid of virtual tabletop software (such as for example the excellent Maptool) it is easy to merge these two approaches by allowing players a limited overland view to inform their next travel day, while still keeping most of the map hidden from their view. This however necessitates a lot of preparation, and the fact the players do not have to make their own map can of course also be seen as a dealbreaker for some.

3 Travel in Computer-Based Games

Computer-based games obviously also vary greatly in their attention to detail, but as a given video game is the same for all players, some general trends are easier to identify.

Looking at older video games it is also clear that tabletop game systems inspired quite a few of these games in terms of travel, as rather close implementations of the aforementioned systems can be found easily.

3.1 Pointcrawl (Mesh-based)

Implementing a pointcrawl in a computer game is comparatively easy. The individual locations can simply be represented as local maps between which one may move by traversing them in turn.

The original Baldur's Gate roleplaying game features this approach. Locations are presented on a world map as points of interest, with the player expending time and risking random encounters on travelling from one region to the next. As time also passes on the local map, crossing the local maps is a flaw of this system, necessary to keep travel consistent; It is only omittable when distance within the nodes are negligible compared to the worldmap distances.

One example of an adapted version of this method is FTL: Faster Than Light (although this of course hardly qualifies as a roleplaying game), where the local 'maps' simply are random encounters connected by jump points. As no traversable local map exists, time passes only during jumps, and – in keeping with the idea of jump points – a constant time independent of distance covered.

3.2 Pointcrawl (Pseudo-Cartographical)

A little more demanding in implementation, this method requires a contiguous world map to exist. Furthermore, the game engine needs some way of defining regions by which encounter tables might differ.

Fallout 1 is a great example of how to bring this approach to the computer. Although the execution is simplistic, it allows the player to move to any point on the worldmap. Due to hardware limitations of the time, and the state of software engineering at the time of coding, the player is limited to moving at constant (processor-bound!) speed in straight lines, however. Furthermore, the world is presented as a grid – with a handful of predetermined locations already in place –, and only the player's position in the grid is relevant to determining which random encounters may occur.

Another example of this is TES II: Daggerfall. The system is augmented by the choices of travel mode and speed, and the option to camp out in the wilderness in order to cut down travel costs. As the worldmap is huge and filled with countless locations, the player has to narrow down his target to a province first. In this province view the game offers a search function which locates his target for the player, which is especially useful for previously unvisited locations. Another neat feature of Daggerfall's travel system is the fact that not all places are marked from the beginning, with the possibility of the player randomly stumbling upon new dungeons, or being led to one by a quest or found map.

3.3 'Simulationist'

This way of handling travel is of special interest as its former prevalence explains why focus on travel in games is uncommon nowadays, as bad implementation of this idea has poisoned the well for travel systems of any kind.

This method generally forgoes including a seperate, dedicated travel system completely, with all possibilities of fast travel being immersively integrated into the game world. This might be realised by including vehicles capable of high-speed travel, or a transport network.

This focus on immesion means that if no suitable means of travelling quickly exists lore-wise (or the developers were too focused on other things to include one), the player has to traverse the world 'on foot', that is, the travel is simulated by the same system responsible for local locomotion. This also means that all reachable land has to be continuous, often necessitating large and elaborate, 'open' worlds.

The classic example of this would be TES III: Morrowind. Besides paying for the local, bug-based variant of public transport, the starting player only has his own two feet, and even far into the game only a few additional means of transport make travel quicker and easier.

A more modern example of this can be found in Minecraft. A player generally has to traverse the game on foot, and the various modes of faster travel are firmly rooted in the type of world the game constructs.

In a similar vein to Morrowind, the original Dark Souls has the player traverse its world by foot for a large portion of the game. Once bonfire travel is unlocked, however, large-distance travel is almost trivialised by the vast bonfire network.

3.4 'Instantaneous' / Non-Existant Travel

The simulationist approach obviously has its shortcomings, especially when designer's are unaware of the necessity to include transport networks, or space them out to thinly. The average player's desire for quick entertainment exacerbates the disfavour this approach has fallen into. Instead, many games include a fast-travel system wherein the destination not only is merely a click away, but where the travel is abstracted away so completely that not complications exist at all.

A good example of this is TES IV: Oblivion – and in fact all Gamebryo and Creation Engine games since then –, where the player may simply 'jump' to any discovered location in an instant. Were it not for the fact that the player sometimes has to go to locations not yet marked on the map it would even be a 'pure' example of this idea in practise.

It is clear both from Oblivion's development history as a successor to Morrowind, and the remnants of half-implemented transport networks in the aforementioned games, that this instantaneous approach is a sort of 'natural' evolution of the simulationist approach. As the game world grows, implementing a working transport network becomes more and more complicated, and high-speed vehicles increase to become less and less feasible and manageable, both for the player and the designer.

4 Ideas and Notes on Handling Travel

4.1 Tabletop Games

4.1.1 Pointcrawl (Pseudo-Cartographical)

In extending the mesh-based pointcrawl the gamemaster may forego precalculating the travel times in favour of simply measuring the distance between start and end point, if he is using a cartesian map of somewhat homogenous terrain. From here on it is only a small step to emulating real cartographic routing at the table. If the gamemaster is willing to put in the effort of defining suitable regions with their corresponding encounter and weather tables, travel could hardly be more precisely represented at the gaming table.

The advantage of this approach lies in creating a highly immersive environment wherein players can live out their lust for meticulous planning to their hearts' content. But this approach obviously requires a lot of work to be done by the gamemaster and also will take a lot of buy-in from the players. It is furthermore quite hard to solidify and generalise the rulings on travel times, especially when changing terrain, weather, or time comes into the mix. This can lead to subtle inconsistencies where multiple or rapidly changing factors apply. This approach therefore requires a lot of careful judging by the gamemaster and suffers greatly where trust between players and gamemaster is not firmly in place.

4.2 Computer-Based Games

4.2.1 Factors of Travel

It is interesting that the factors of the travel problem noted in Time and Travel scarcely feature in video games. Although almost all of the aforementioned video games simulate the passage of time as the travel system is used, there only a handful games in existence where this actually makes a difference. Similarely, few games actually track something like rations or recurring costs or profits. This is especially puzzling as the existence of manual tracking systems for these features shows that people do enjoy such features enough to struggle with careful notekeeping to have them, while the medium best suited to automated notekeeping hardly features such components.

The recent action RPG Outward deserves a honourable mention for tackling exactly this idea. Featuring a fully simulationist approach to travel completely void of vehicles or transport networks, this game also burdens the player with a comparatively harsh inventory weight limit and a need to sate hunger and thirst.

4.2.2 Cartographical Simulationism

It is similarely strange that although functional examples of pseudo-cartographical fast travel systems exist, going back as far as 1996, no further development of this idea seems to have occured.

It seems very much possible to include a similar, but more feature-rich version of Daggerfall's travel system in almost any roleplaying game. With advances in computing power and pathfinding, more complex routing trough the wilderness, and basing travel speed on the terrain seem far from impossible.

As graphical fidelity and variety grew, so it became harder and harder to present large, coherent but varied fantasy worlds. Nowadays, there are hardly any worlds large enough to warrant travel systems that simulate entire days of game time.

  1. Getting Lost

    One possibility of deepening travel may lie within emulating systems of losing one's direction on long stretches of featureless land. A central necessity to this idea would be an inaccurate way of tracking the player's position on the map, and a way for the player to plan his route before setting out. There are multiple ways how inaccuracies in one's position may arise:

    • In plotting his course, the player constructs his path by straight lines and changes of heading. Each change of heading comes with a certain margin of error in the angle. From this, one may construct the player's path as a cone wherein the player must be.
    • As the player moves over the terrain, the 'probability cloud' of his position grows dependent on the surroundings. This approach would likely require inaccuracy to grow more strongly on the 'angular part' of the path in order to seem realistic. This means that we have to construct the path on a polar coordinate system, and find a way of augmenting an arbitrary 'area of probable position' by growing in certain directions.

    No matter what method is used, certain boundary conditions apply. As a player gets close enough to a known location, his 'probable position area' should shrink again in order to simulate realigning oneself. Dependant on the type of game, certain locations (e.g. Dungeons, small Villages) should not reduce this area. See Discovery and Placing Map Markers for an idea how one could handle discoverable locations.

    This idea also allows adding depth by extending the system of possible travel speeds, where larger speeds obviously should increase the risk of getting lost.

  2. Discovery and Placing Map Markers

    In tabletop games an interesting part of travelling the world lies in constructing one's map. In bringing this to the computer, we could allow the player to place his own map markers between he may travel.

    This would work especially well in compination with systems of wilderness travel, but in keeping with the idea of Getting Lost, we also run into a problem. As the player does not fully know his position, we may need to mark locations in an inaccurate way as well.

    One possibility of letting the player influence the accuracy of his discoveries (and thereby increase the likelihood of succesfully returning to discovered locations) lies within the proposed option of changing up one's travel speed, but we can give the player an even better option. In the same manner of thinking by which we came to construct simple routes from lines and angles, we may use more complex constructions. In order for players to construct flawless maps, we may allow them move on the trajectory of a simple Space-Filling Curve. As a player character clearly has a finite range of vision, a finite density (and thereby finite length) would be sufficient to provide full knowledge of a given region.

Author: rov (trymonv@cock.li)

Date: 2020-08-29 Sa 00:00

Emacs 26.3 (Org mode 9.1.9)

Validate