RPGs, Time, and Travel

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.

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.

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.

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.

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.

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.

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.

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.

Interestingly, Medieval Engineers, though primarily focused on building and landscaping in a medieval setting, also features a surprisingly elaborate travel system of this kind, optionally limiting players to travel along pre-defined roads.

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.

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.