WANDER (navigation proof of concept) | REUNION MISSION (demo game)

In the early 1970s, the original Dungeons & Dragons game grew out of the tabletop wargaming hobby, specifically miniatures games that simulated battles between two belligerent forces of medieval warriors. Scenarios were straightforward - lead figurines moved in from opposite sides of a table filled with model terrain - but play was generally limited to contained battlefields. Leaving the map, as in moving pieces beyond the table's edge, literally meant leaving the game.
The open-ended, freeform possibilities found in the new format of fantasy role-playing gaming pioneered by Gary Gygax and Dave Arneson were different. The "map" could be as small or as vast as players' imagination would allow. As individuals, players' characters could go in any direction, whether or not the game scenario's designer had anticipated or planned for such decisions.
Some game masters would respond by trying to limit players' agency through intimidation, sending increasingly unbeatable obstacles into the story as a way to signal to players their characters should turn back. Clumsy efforts of trying to "get the game back on track" from errant players soon were dubbed the pejorative term "railroading," a metaphor in use long before D&D to imply politically compelling others through coercion and threats. As defined by game historian Justin Alexander about the practice, "It is the precise moment at which the GM negates a player's choice."
(Alexander, J. [2015, March 13]. The Railroading Manifesto. The Alexandrian. https://thealexandrian.net/wordpress/36900/roleplaying-games/the-railroading-manifesto.)
A design reaction to such limited linear scenarios was the "sandbox" style of play, creating an open world that emphasizes exploration and emergent storytelling. The term played off a double meaning: a nod to the sand table miniature battlefields of D&D's wargaming roots, as well as the childhood experience of building anything in a backyard sandpit. Under this format, players made their choices about where to travel and what to investigate, often with minimal overarching narrative direction.
(Peterson, John (2012). Playing at the World: A History of Simulating Wars, People and Fantastic Adventures, from Chess to Role-Playing Games, p. 14. Unreason Press.)
To organize such roving gameplay, many designers adopted the hexcrawl, open maps typically using a hexagonal grid in which each hex represents a distinct area for the players to explore. The game master could then prepare a variety of encounters, locations, and events, many of which were procedural or modular, allowing for dynamic and unpredictable gameplay. This flexibility, however, requires a balance of preparation and improvisation from the designer, as the lack of a predefined plot demands responsiveness to the players' exploration choices.
This project aims to create an easy-to-edit framework for game designers to set up hexcrawl scenarios, even going so far as to enable such maps to be run online without a game master adjudicating descriptions and gameplay outcomes. Two hexcrawl proof-of-concepts, WANDER and REUNION MISSION, are used here as working examples. Base files can be found at:
Code base (no IMG directory files) (178k):
https://pingstanton.com/hexcrawl/hexcrawl_noimg.zip
Via Github:
https://github.com/pingstanton/hexcrawl/

Essential elements of a hexcrawl game include the following:
A. THE HEX MAP: A play space for this style of design traditionally divides into hexagonal tiles, with each hex representing a specific area. Distinctions between hexes could be geographic (different nations and seas), terrains (plains, forests, mountains, deserts), or concepts (points of debate). Numbering systems set a unique ID for each hex, making it easier for players to orient their location and progress.
B. KEY LOCATIONS: Unique points of interest within these map hexes must include narratives, challenges, and rewards for players to pursue. Following the previous examples, these could be significant cities and ports (in nations), ruins and natural landmarks (within terrains), or answers to controversial questions (in debate). These locations serve as focal points for player interaction, offering opportunities for problem-solving and story progression while broadening the thematic or conceptual framework of the hexcrawl.
C. RANDOM ENCOUNTERS: As an open world, using procedural methods of filling hexes with narrative challenges (creatures, events, hazards) randomly determined from tables of options provides game masters with a flexible alternative to exhaustive preparation. As players have agency to go in any direction, the problem of "missing" material designers intended to showcase is eliminated.
D. TRAVEL RULES: Among the resource management game aspects given to players, there must be guidelines for movement across the hexcrawl map. Typically, this might simply be time and opportunity costs based on the scale of hexes and travel speeds, but adding costs of fuel, survival supplies, or other resources can deepen the immersion into players' decisions.
E. CHALLENGES AND REWARDS: Each hex should present at least one opportunity for players to make risk-and-reward choices under the hexcrawl's thematic framework. When presented with a narrative situation, a player may choose to respond by option #1, #2, or #3, each matched to a possible outcome. In even more open systems such as role-playing games, game masters will have rules and tools for almost any reaction players devise: Fight, flee, parley, sneak, trade, or so forth. Rewards for success may include increased resources, new story information, or points toward the game's victory conditions. Costs for failure may range from lost resources to elimination from the game.
F. TRACKING TOOLS: A system for recording players' travels in distances and time serves both as a resource clock and a record of exploration progress. The hexcrawl may make use of such tracking to change encounters based on weather, seasons, world events, or other narrative factors.
The code for this project is written in PHP, a widely used open-source scripting language designed primarily for web development. This section provides a brief introduction to the code. Readers already familiar with PHP may wish to skip ahead to Part 3: The Hex Map.
PHP code can be edited using any text or code editor on operating systems such as Linux, Windows, or macOS. It integrates seamlessly with popular web servers like Apache and Nginx. Unlike compiled languages, PHP scripts are executed directly on the server, dynamically generating interactive web pages. This is achieved by processing the script's logic and outputting the final content, often using an HTML template, as specified in the "echo" command.
Example: Write and save a file named "helloworld.php," upload it to a web server running PHP, and call the page from its web address:
File content:
Web address: http://(your domain name)/helloworld.php
The script should display the worlds "Hello, World!" in a web browser.
A game designer can customize the script from this project by filling in variables noted by a dollar sign or sometimes formatting in an array of variables to save space in the script...
Another function commonly used in these PHP scripts generates a random number to assign a value to a variable. For instance, in the example below the variable $oath does not have a value until the script generates a random number to determine which text should be assigned to it. While this approach is less compact and efficient compared to other methods, it can be easier to read and review when examining the response options. Additionally, previously defined variables can be incorporated into the text of an option. For example, the variable $name, representing the player's chosen name, is dynamically inserted into the string. This makes the script both flexible and customizable.
Random choices may also be based off range bands, such as 1 to 3 out of 6 means "option A," 4 or 5 means "option B," and 6 means "option C."
In order to track hexes' relative positions and unique content, an ID number has been assigned to each hex. For simplicity, both examples in this project use Hex #1000000 ("the one million hex") as the starting point, theoretically allowing a player to travel thousands of hexes in any direction before reaching the virtual "edge" of the play space. In actual practice, both project examples only use about a five-hex radius before using blank "default" options for non-utilized spaces.
The WANDER script is a simple demonstration of navigating such a hexcrawl. Placeholder names and one-sentence descriptions have been assigned to 90 hexes radiating out around Hex #100000 (see above illustration). Editing wander.php allows designers to replace this text with custom content following this format:
For the purposes of demonstrating this script, the content for each variable has been hard-coded into the wander.php, but it would be a simple matter to import such data from an external source, such as a text file or this sample .csv file, depending on whichever method was easiest for the designer.
While WANDER was only an introductory exercise in "wandering" around a hexcrawl layout, a game experience needs to add the missing elements of key locations, random encounters, travel rules, challenges, and rewards. The example game REUNION MISSION, a short demo hexcrawl using science-fiction themes inspired by Cixin Liu's The Dark Forest, illustrates these possibilities.
There are two script files for REUNION MISSION: intro.php, which walks the user through four instruction slides that include two "character creation" decisions, and play.php, which loops through random encounters linked to hex spaces.

In intro.php, the player is asked to provide a name for their imaginary starship. (If the user enters the name DEBUG here, a debugging panel of variables will display in the play.php part of the game.) Choosing skill specialties for both android crew members will affect the attrition rate of the player's starship resources in future game turns. If no selections are made at this stage, the ship is simply named Reunion Ship I by default.

In play.php, the script's available interactions with the player alternate between an encounter state where text is presented and two to five response choices are given, and a move state which displays text reflecting the consequences of the player's decision and the choice of which neighboring hex to visit next.
A full version of this game would include 30 or more encounters randomly assigned to core hexes, plus procedurally-generated encounters for "off the map" hexes. For this demo, the game is limited to five to six scripted encounters. A number of global variables are selected from predesigned arrays either at random on every page load or based on hex-specific key variables. These options include images, character titles and names, technobabble terms, and lines of non-player character dialog.
Throughout the game, and hidden from the player, there are five victory conditions being tracked: Empathy ($faction01score), Pragmatism ($faction02score), Individualism ($faction03score), Collectivism ($faction04score), and Entropy ($faction05score.) A simple number score is associated with different options chosen or not chosen by the player in each encounter.
Encounter 0: Into the Unknown. The first encounter in Hex #1000000 continues the introduction text while showing the player to the main game interface. On the left is locator, hex-linked image, and description of the player's current location on the hexcrawl, along with a link to open a broader hexcrawl map in a new web browser window.
Below this locator is a tracker of starship resources. Travel attrition will reduce any resource that is not a specialty of either android, per the skill selections the player made in intro.php. In later encounters, if a specific option is keyed to the availability of a resource whose value has dropped to zero, that option will not be displayed to the player.
On the right is the encounter's text and an illustrative image. The text itself in this encounter only contains a few procedural elements - the leader's title, name, minor variations in dialog - and the initial game decision for the player is only to select the next adjoining hex to visit.
Encounter 1: The Trouble With Drones. This encounter introduces the concept of player choices affecting the ship's resources. If the player willingly gives up a quantity of drones, the problem reported by the encounter text is easily solved. If the player refuses the dialog request, the hidden tracking scores will reflect this decision at the end of the game demo.
Encounter 2: The Belligerent Colony. This encounter ramps up the risk-versus-reward opportunity of encounters by offering five response options, each with different resource costs not clearly revealed to the player before making a decision. Three of the options will deduct random amounts from all of the starship's resources, while others cause minimal risk.
Encounter 3: Mad Science. This encounter has many different pieces of procedurally generated dialog, but the aim of the text remains largely the same: Confront the player with an ethical dilemma and choose branching options down different resolution paths.
Encounter 4: The Android's Garden. Similar to Mad Science, this encounter features branching and follow-up text prompts triggered by the player's decisions. Unlike previous more action-based responses, resource costs are made further unclear by focusing only on choosing dialog as a response.
Encounter 5: Close Encounter. Another branching text encounter, this one is designed to set up some backstory for the final encounter.
Encounter 6: The Vault. Unlike previous encounters, the player is shown a visual puzzle to solve by selecting from among four possible images. Picking any of the three incorrect options from this encounter forces the player to repeat this same scenario at the next visited hex until the correct response is chosen. The correct answer immediately moves the player to the game demo's conclusion and reveals the hidden victory condition scores that have been secretly tallied during the game. The player is also given the option to restart the game.
Encounter X: The Unknown. Moving into a hex without associated details does not cost the player resources, but neither does it advance the game state. Should a player begin to move away from the hexes designed to be visited without keeping careful track of how to return to known star systems, the player risks getting lost in uncharted space. This "soft railroad" could be addressed in a version of this game beyond the scope of the demo at a later time.
Novels
Clarke, Arthur C. (1968). 2001: A Space Odyssey. Hutchinson (UK), New American Library (US).
Clarke, Arthur C. (1982). 2010: Odyssey Two. Ballantine Books.
Liu, Cixin (2016). The Dark Forest (Book 2 of the 3-Body Problem Series). Tor Books.
VanderMeer, Jeff (2014). Annihilation. Farrar, Straus and Giroux.
Films
Garland, Alex (2014). Ex Machina. A24.
Garland, Alex (2018). Annihilation. Paramount Pictures.
O'Bannon, Dan (screenwriter) (1979). Alien. 20th Century Fox.
Villeneuve, Denis (2016). Arrival. Paramount Pictures.
Television
Brooker, Charlie (2011-2023). Black Mirror (series). Channel 4.
Guzikowski, Aaron (2022-2023). Raised by Wolves. HBO Max.
Roddenberry, Gene et. al. (1966-2024). Star Trek (various series). Paramount Global.
Games
McCoy, Sean (2018, 2023). Mothership. Tuesday Night Games.
Nogueira, Diogo (2020). Screams Amongst The Stars. Old Skull Publishing.
Niblaeus, Carl and Plogfors, Christian (2022). Death In Space. Free League Publishing.
Boyle, Rob and Cross, Brian (2009). Eclipse Phase. Catalyst Game Labs and Posthuman Studios.