ARC-71: Space Station Construction & Management

This book serves as the game design document, and a high-level developer reference (as a supplement to the rustdoc documentation).

This book is a work in progress.

Overview

Once belonging to the Aeon Resources Conglomerate, you have just acquired ARC-71, currently operating as a refueling depot in a quiet little corner of the galaxy. You are tasked with expanding the station as you see fit, managing resources to keep your workers happy and attract new industry, business opportunities, and even bring tourism to your sector.

You will build your station by issuing orders to alien workers, who will carry them out by building additional areas, installing furniture, etc.

Gameplay

Players will begin the game with a small station and a few Workers. The station will have adequate systems to support these Workers, with leftover resources to support an additional 2-3. The station will also have systems to enable it to function as a refueling station, with ships arriving to buy fuel and haulers arriving to sell fuel, giving a small but steady income to the player; a small amount of money will already be available.

The station itself consists of tiles on the game grid (the grid itself is not visible). Players can spend money to "purchase" additional tiles, which must be adjacent either to existing or "pending" tiles. Once purchased, the new tiles are initially in a "pending" state and a task is created to actually construct it. Workers will periodically check for tasks and take an available one, and they will then move toward the tile location and construct the tile; in addition to the time for the task to be picked up and the time for the Worker to walk to the location, the construction itself also takes time to complete.

Walls, doors, and similar constructions are built on tile edges. Since edges are in effect shared by adjacent tiles, tiles on both sides of an edge will present the edge's feature. While the initial station will begin fully enclosed (TBD: what about facilities for ships to dock?), newly-built tiles will not automatically gain enclosing walls; additional tasks must be ordered to build them. Workers cannot move through walls, even to construct tiles on the other side, so players must provide a means by which workers can reach such new construction, by either building a door to serve as an airlock into space, or removing a wall.

Players will also construct new systems, such as fusion reactors and hydroponic farms, which again cost money and create tasks for Workers to execute. Similarly, systems, doors, walls, and even tiles can be deconstructed; while this generally does not cost money, it does require an available Worker to take the task and time.

Through expanding their station and building new systems, players will develop their station and manage the various resources. As their station grows they will attract new business and even tourism, and will need to plan further growth to capitalize on new opportunities.

Secondary platforms

Players will be able to construct "umbilicals", systems that can extend into space. Workers can move along them (provided they have sufficient protection for the vacuum of space), and build tiles on the other end, allowing players to construct a network of separate platforms. Umbilicals provide two-way conduits for power, life support, etc., provided those systems are able to reach them.

Should an umbilical become severed, resources can no longer flow across them; if the platforms on either side are adequately staffed and self sufficient, however, players need not be in any rush to repair them.

Players will also have the ability to construct the necessary infrastructure and vehicles to create a transportation network allowing aliens to more freely move between platforms; only workers are able to use the umbilicals directly to move from one to another, and again only if they are able to bring their own life support with them.

Specifications

Game World

The game's world will consist of a grid of tiles, rendered in a top-down 2D environment. The world storage will be "sparse", eschewing the storage of any "empty" tiles, allowing for station sizes limited only by the precision of the internal coordinate representation (single-precision floating point limits us to ~1 million tiles on each axis).

Aliens will enter and exit the world via spaceships that spawn into the game and then dock to appropriate locations around the station. The game will need to support these ships spawning and moving outside of the limits of the tile map.

NB: We will try to structure the code in such a way that converting to rendering this 2D world using 3D models will be doable, however this is not a strict goal and it's okay if we wind up "stuck" with 2D sprites.

Tasks

When the player wishes to construct something - e.g. a tile, a wall, a fusion reactor - a new Task will be created and queued for completion. Idle Workers will periodically check for available Tasks, determine whether they are capable of completing it (e.g. an Oxygen-breathing Worker cannot perform work within a Hydrogen atmosphere unless there is an available pressure suit) and, if so, assign themselves to the Job. They'll walk to the work location and execute the Task there.

Tasks will take time to complete, which is based on what is being built.

Workers will rely on a user-configurable priority list of "Jobs", with every Task belonging to a particular Job: Workers check higher-priority Jobs for any available Tasks before continuing down the list; when multiple available Tasks have the same priority, Workers should prefer those that require the least amount of walking.

Actors

"Actor" is the catch-all term for the NPCs that live, work, or simply visit aboard the station - including humans, aliens, and androids. While in-game descriptions may name and describe different alien races, the game itself only needs to differentiate between the 3 different types. Actors are all controlled by the game itself (i.e. they are NPCs).

All actors have a set of statistics that influence their behaviors in different ways:

• Happiness: Typical values are in the range [-10, 10], but can go higher or lower, where positive values are happy while negative values are unhappy. The game will display a bar covering the [-10, 10] range, with an arrow pointing off the appropriate end for values outside that range. Happiness defaults to 5 and can go up or down based on a variety of factors.
• Breath: Usually max, but decreases if inadequate life support is available; actors die when it reaches 0.
• Hydration: Usually max, but decreases if inadequate Water is available; actors die when it reaches 0. Decreases slower than Breath.
• Satiety: Usually max, but decreases if inadequate Food is available; actors die when it reaches 0. Decreases slower than Hydration.

Air, Water, and Food stats are on the range [0, 10]. All stats are tracked internally as floating point values, but displayed to the player on a bar rather than as a number.

Happiness decreases if any of Breath, Hydration, or Satiety are below a threshold unique to each; Breath decreases Happiness immediately, while Hydration takes a little longer to begin decreasing it and Satiety takes longer still. Happiness continues to decrease as each of these stats remain below their threshold, and the rate increases as the stats fall further below it. This decrease is cumulative if more than one stat is below its threshold.

Happiness resists change as it approaches ±10, but does not when it is near 0. This resistance can never eliminate a change, only reduce it.

Workers

Workers are responsible for performing tasks such as building new tiles and constructing new systems. The player will determine how many Workers they need, and Workers will arrive to fill those roles; how quickly will be based on how happy the current set of Workers are. Worker Happiness is based on salary in addition to the other factors, with higher salaries increasing Worker Happiness.

If a Worker's Happiness falls below -5, they will quit and attempt to leave the station.

If a player lays off at least 10% of their work force or at least 4 Workers (whichever is greater), all remaining Workers will immediately lose some amount of Happiness based on what percentage is laid off. In other words, if a player changes their desired number of Workers to a number below their currently-employed Workers, the "excess" Workers (chosen at random) are considered laid off. This penalty cannot be erased by hiring more Workers, but other factors can restore the lost Happiness over time.

Hiring Workers

The player has 3 options when it comes to hiring workers, and they have to balance the pros and the cons of each as they play.

1) Using a Placement Agency

Placement agencies typically have a number of applicants available immediately, but hiring one requires paying the agency a fee. Applicants are pre-screened, so the worst are not in the pool, but the best applicants know they don't need an agency, so they aren't in the pool either; the result is that while using a placement agency will let you hiring someone quick, you'll get a middle-of-the-road worker rather than potentially finding the cream-of-the-crop.

Once hired, workers typically need a day or two to travel to your station before they can begin work.

2) Hiring Directly

You can post a want ad yourself to avoid the placement agency's fees. This however requires several days before you have a pool of applicants to choose from, and the range of quality runs the full gamut from the virtually unhirable to the absolute best worker you could have dreamed of. Additionally, once hired, workers typically need a few days before they show up at your station.

Should you leave the ad open instead of hiring someone, the pool will change over time as applicants withdraw or apply, so it you don't like what you've got you can always just keep waiting. You can also give your pool a slight quality boost by promoting it for a variable fee.

3) Using a Recruiter

If you have both time and money to spare, you can find the perfect fit for your needs by using a recruiter. This allows you to specify the skills you want, and your recruiter will go out and find the perfect fit. This takes longer the more skills you require and the higher your require them, and when the recruiter returns you only have a single applicant to look at.

Should you decline to hire the recruiter's applicant, you can continue the search for a smaller fee, or terminate the contract.

Visitors

Life Support

Life support is a general term that, logically, encompasses not only those systems that produce needed resources (e.g. Oxygen, Water), but also those that remove wasteful byproducts (e.g. CO2, Heat); for game purposes, however, it describes the unique sets of systems used to sustain different types of aliens (e.g. Oxygen/CO2), and generally not those that are common to all (known) life (e.g. Food, Water).

There are 3 types of life support in the game:

• Oxygen Atmosphere: For human-like aliens (including humans), Oxygen needs to be produced and CO2 removed¹.
• Hydrogen Atmosphere: For Methanogen aliens, Hydrogen needs to be produced and Methane removed². Hydrogen atmospheres are toxic to Oxygen-breathing aliens, and vice-versa.
• Aquatic: Aquatic aliens live submerged or mostly submerged in Water. Their rooms therefore need additional reinforcement to contain the additional mass and pressure, though these reinforced rooms can be "re-zoned" to either Oxygen or Hydrogen, albeit slower to fill/drain the water.

Insufficient resources

When life support resources (e.g. Oxygen) are insufficient to meet the needs of the station, the game will use a "breadth first" approach to determining exactly where the shortfall lands.

Specifically, beginning in rooms with life support systems, the game will attempt to meet the needs of any occupants in the room first, then the overhead of the space of the room; if there's sufficient resources, the game will then check all rooms connected to the room, and then all rooms connected to those, until it finds rooms where occupants or space needs cannot be met. If a room has sufficient resources for occupants, but not for its space, occupants will suffer minor symptoms (i.e. become unhappy) but otherwise be uninjured; if there are insufficient resources for occupants, they will begin to e.g. suffocate.

Environment suits

Workers are able to equip environment suits to enable them to enter environments otherwise hostile to their own life support needs, e.g. a human Worker who breaths Oxygen can equip such a suit to enter a Hydrogen atmosphere or Aquatic environment; this enables Workers to perform work regardless of where they are, and prevents the game from becoming unplayable if work must be done in one or more environments where the player has no "compatible" Workers.

It takes time to equip or unequip an environment suit, which takes place when the Worker reaches the door between the environments. Movement is slowed while wearing the environment suit; if the Worker is Aquatic, or is non-Aquatic in an Aquatic environment, this movement penalty is doubled. It also takes more time to enter or exit an Aquatic environment.

Resources

The UI will display Resources in a simple "demand/supply" format, e.g. 8/10, which means 8 of the resource are needed and 10 are available. Hovering the cursor over this will give a more detailed breakdown of both supply and demand.

Money

Money is used to purchase everything the player builds, from simple space to walls to systems within the station.

Workers will also require Money in the form of salaries; inadequate funds will make for unhappy workers, who will leave or even lash out and sabotage station systems.

Money will be produced via trade, providing services (e.g. refueling spaceships), and visitors.

Power

Most systems will require Power to function, as well as general overhead for the size of the station itself (e.g. every 10 tiles of the station, rounded up, requires 1 Power). Power will be available through a variety of systems such as cheap and passive (but low-yield) solar panels, or fusion reactors that generate a lot of Power but are expensive to build, generate a lot of excess Heat, and require fuel to be purchased.

Inadequate Power supplies will cause Power-dependent systems to fail at random, remaining offline until manually repaired. This could easily worsen a situation if, for example, crucial life support systems fail, killing or driving out the NPCs needed to install additional Power systems.

Oxygen & Hydrogen

Humans and similar aliens require Oxygen to breath - and, therefore, to live. Additionally, areas zoned for Oxygen atmospheres will require some overhead just to ensure proper pressurization (e.g. every 20 tiles, rounded up, requires 1 Oxygen). (Note that this ratio is not meant to represent any particular atmospheric ratio, as units are deliberately unspecified and meant to vary from one resource to another, it is merely a gameplay element.)

Areas that become isolated from Oxygen producing systems will slowly lose Oxygen, leading to anyone within them dying.

Hydrogen-breathing aliens have similar needs for Hydrogen, as do areas zoned for Hydrogen atmospheres.

User Story

An Event occurs that results in a hull breach in a room. The station will automatically seal the adjoining doors to isolate the breach, immediately robbing the breached room of Oxygen. Anyone inside suffocates and dies. Due to the layout of the station, this breach has isolated 3 rooms that no longer can draw a path to any system that produce Oxygen, and as a result Oxygen levels in those rooms gradually decrease, eventually suffocating anyone within them unless Oxygen is restored to these rooms (e.g. by creating a new path for Oxygen to reach them, building a new system that produces Oxygen, or fixing the breach and reopening that path).

Food

Most beings need Food to live.

Besides a simple quantity, Food will also have a Quality ranging from 1 (Poor) to 10 (Exquisite). All Food producing systems will produce a certain Quality of Food, and the overall Quality the station has is calculated by a weighted average and then rounded to the nearest whole number.

Example: 2 systems produce a combined 8 Food of Quality 2, while a third system produces 3 Food of Quality 5. The station has a total supply of 11 Food (8 + 3). The station's Food Quality is 3 ((2×8 + 3×5) ÷ 11 = 2.8182 ⇒ 3).

Inadequate Food supplies will make aliens unhappy, and eventually leave. Starvation is possible but takes a long time.

Water

All life as we know it depends on water, so it is essential for all life support. It is also very commonly used in the production of Food, and even in some Power systems. Unlike e.g. Oxygen, however, there is no "overhead" for the size of the station. Also unlike Oxygen, should Water demand ever exceed supply (e.g. due to an area becoming isolated from Water systems), aliens will slowly dehydrate over time, becoming very unhappy as they do, before either leaving or dying.

The exception to the latter is supporting aquatic aliens: Their zones need to be filled with Water. While the game will abstract away the "filling" process as part of the construction costs, these areas do require a supply of water (e.g. 1 Water per 10 tiles, rounded up). In this context, Water supply represents filtering out waste, managing pH and salinization levels, etc.; as a result, while aquatic aliens will still dehydrate if supply is outstripped by demand, they will do so a lot slower than others.

Additionally, zones designated for aquatic life support need to be reinforced to handle the additional pressure and mass of the contained water.

Heat

Heat is a waste byproduct of nearly everything aboard a space station. As such, it needs to be managed carefully to avoid overheating the station and its occupants.

Heat "supply" actually represents the station's ability to remove excess heat, while "demand" represents the Heat that is actually generated in the station; in this sense it is "backwards" from other resources, though aside from this logical discongruity it is still treated identically. Excess Heat will make aliens unhappy, and can lead to systems failing; aquatic aliens are most adversely affected by excess Heat.

Heat is generally managed by radiators, which unlike other systems must be built on the outside of the station; they can, however, extend beyond the extents of the game world. Radiators will have 1 or more "root" tiles that must be within the game's grid and adjacent to station tiles, and multiple tiles visually representing the radiator itself which may extend into areas otherwise inaccessible for building.

Some radiators may be expandable, in which case adding additional Heat capacity is a simple matter of interacting with a UI attached to the "root" tile(s), which will further extend the visuals.

Carbon Dioxide & Methane

Carbon Dioxide (CO2) is a byproduct of respiration for both human-like and aquatic aliens, and must be managed by systems to remove it from the environment before it poisons the aliens aboard the station. CO2 is also produced by fires.

In Hydrogen atmospheres, the byproduct of respiration is instead Methane, which likewise needs to be removed before it poisons the aliens in those areas.

Similar to Heat, "supply" represents how much of the gas the station can remove, while "demand" is how much is generated. And similar to Water, excess takes more time to kill NPCs; unlike Water, they remain unaware for some time, until symptoms (and thus unhappiness) appear suddenly shortly before death. Excess CO2/Methane also rapidly accelerates suffocation if Oxygen/Hydrogen supplies are short.

Biowaste

"Everybody poops," and the aliens aboard the player's station are no exception.

As with Heat and CO2, "supply" represents the station's capacity for handling waste, while "demand" represents how much is produced.

Excess Biowaste will very rapidly increase alien unhappiness, and will generally lead to aliens fleeing your station. Any that are unable to, however, will eventually become sick and die.

Hazards

The player will need to address certain hazards in addition to generally managing their station. Hazards are often the results of certain events.

Fire

Fires are extremely hazardous, however they can only occur with Oxygen atmospheres. When a fire does break out, it will rapidly consume Oxygen from the room(s) it's within while increasing CO2. Fires will spread until they are extinguished.

While fires cannot occur within Hydrogen atmospheres, the presence of both Hydrogen and Methane means that there is a severe risk of explosion if a fire manages to breach a wall or door into a Hydrogen atmosphere. Fires can also cause explosions if they ignite certain Oxygen-producing systems.

Doors immediately close and lock to contain a fire. While fires can breach doors, they do so much slower than they spread within rooms; they can also breach walls, but are even slower to do so.

Explosion

Explosions are extremely destructive events that will destroy systems, doors, walls, and breach exterior hulls, as well as instantly kill any aliens caught within them. Explosions are dampened by water.

If an explosion breaches doors/walls and results in an Oxygen atmosphere and Hydrogen atmosphere meeting, it will set off a secondary explosion, potentially resulting in a chain reaction. This is only possible if the breach is between two rooms that have otherwise not already been breached.

Explosions have a chance of extinguishing fires they touch, with that chance decreasing the further away from the point of ignition.

Flooding

Should a door or wall fail for any reason between an Aquatic environment and either a Hydrogen or Oxygen atmosphere, the latter room will become flooded, while the water in the former will drop below necessary levels. Flooding can damage or destroy systems (Power systems and many Food systems are especially vulnerable).

Flooding extinguishing fires and suppresses many sources of explosions.

Hull breach

Hull breaches can be caused by fires, explosions, or other events. A room containing a hull breach immediately loses its atmosphere. Doors into the room close and lock automatically to contain the breach. Rooms cannot receive life support if the breached room is their only connection to life support systems.

Events

Random events will occur periodically. To ease the player into the game, there will be a "warm-up" period at the start of a new game during which no events can occur. The interval between events will vary between a minimum and maximum duration, which will be based on real time; time will not be counted while the game is paused or closed, but should resume when a saved game is loaded¹.

Events will have preconditions that need to be met when they are selected; if this check fails, the event is ignored and gameplay continues. This will provide the impression that events become more frequent -- and somewhat more regular -- as the game progresses without the need for complex logic to regulate that.

Events can be re-selected, but only after a number of other events have occurred (excluding any events that fail their preconditions). This will be implemented by removing selected events from the pool and inserting them into a queue; after resolving an event, the first event in the queue will be removed and returned to the pool. Due to the nature of preconditions making early-game events less likely to occur, there may not be any need to pre-populate the queue at all, instead relying on these "failed" events to naturally add to the queue's length; if, however, this does not seem to work in practice, the queue can be pre-populated with random events drawn from the pool.

Examples

These examples are intended to help convey the kind of events desired, not necessarily to be implemented into the game verbatim.

• Meteor Strike: A random tile location is struck by a meteor, causing a hull breach in that room. If the random tile is empty, this event has no effect.
• VIP Visit: A VIP will visit the station in {duration}. Certain amenities must be in place by then or the visit will be canceled. These may include a minimum Food Quality, a hotel room meeting certain criteria, etc. This event can only occur if the station has already reached a minimum level of prestige.

Getting Started

You must of course have Rust installed; this guide assumes you will be using the default toolchain, including rustup and cargo. Ensure your locally installed Rust keeps pace with the MSRV.

Configure Githooks

Before committing any changes, you should first run git config core.hooksPath .githooks in your copy of the repo. This ensures the pre-commit hook to validate Rust formatting is installed.

Clang and Mold

For faster builds, this project is configured to use mold with clang as the linker under Linux.

1. Install clang: sudo apt install clang
2. Install mold: Read the docs

Building ARC-71

Assuming you've set up clang and mold, there's no trick to building the game: Just run cargo build (or cargo run to build and run it). If you are using VS Code, a build task is provided in the .vscode directory; simply hit Ctrl-Shift-B to build and run the game from within VS Code.

MSRV

The Minimum Supported Rust Version is the current stable release, and is enforced in Cargo.toml via the rust-version key.

Note that even when updates to rust-version lag behind releases, the policy remains that the official supported version is the latest one.

Code Style (WIP)

Code committed to the main branch is expected to be free of syntax errors, warnings, and fully linted - meaning all code flagged by a lint is either fixed to conform to said lint, or is appropriately annotated to allow the lint to fail on it. Code committed to an individual dev's working branch can be in any state (but must meet the above criteria before a PR is opened), while code in shared working branches should be error-free but may contain warnings.

When overriding a lint in code, the #[allow(..)] attribute MUST be accompanied by a comment justifying why this lint is being permitted here; when (if) the lint_reasons feature is stabilized, these should be converted to #[expect(.., reason = "..")] attributes, where the reason will be required in lieu of a comment to justify its presence.

Non-default lints are defined in the [lints.rust] and [lints.clippy] tables in Cargo.toml. While conforming to the chosen lints will make the code objectively better¹, the choice of which lints to use is inherently a subjective matter and is always open to discussion; feel free to bring it up through your preferred medium, or simply open a PR with your proposed changes to the lints tables to be discussed there.

Commit Messages

Inspired by the Conventional Commits specification and the Angular convention, ARC-71 uses a commit message structure that consists of a header, a body, and a footer:

<header>

<body>

<footer>

The header is mandatory, while the rest is optional.

Adhering to this convention allows for the possibility of automatically generating changelogs. Note that this project began prior to adopting this specification, so early commits do not adhere to them.

Header

The header line takes the following format:

<type>(<scope>): <description>

The header line should be no more than 72 characters in total. This includes type, scope, description, and relevant delimiter characters. This is to make the commit history easier to read in common tools including git and GitHub.

Type

Type must be one of the following:

• fix: Issues and bug fixes
• feat: A new feature
• docs: Documentation only changes
• assets: Assets only changes
• perf: Code changes that improve performance
• refactor: Restructuring code without introducing new features or fixing bugs
• style: Changes to code style (e.g. running rustfmt, renaming functions/variables)
• test: Adding or changing tests
• chore: Other tasks that don't directly change code, e.g. CI configuration, modifying the build process

Scope

The scope is optional, but strongly encouraged. If the scope is omitted, also omit the parentheses surrounding it, i.e. fix: no longer broken instead of fix(): no longer broken.

Changes to this book (the Game Design Document aka GDD) should have the scope "gdd", and thus all changes to it should be prefixed by docs(gdd): .

chore commits should use the following scopes when appropriate:

• build: changes to the build process
• ci: changing the CI/CD process
• deps: dependencies-only changes (e.g. updating or removing dependencies)

Other scopes are still TBD; for now use best judgment (crate name ­— sans arc71_ prefix — may be a good default) or omit it.

Description

The description is a short summary of the change, using the present imperative, e.g. "change star generation", not "changed" or "changes". It reads as a complete sentence, however it does not start with a capital letter (unless the initial letter would be capitalized otherwise, e.g. proper nouns or initialisms) and does not end with a period.

docs(gdd): add commit message specification

Body

Just like the description, the body uses the present imperative. It is separated from the header by a blank line, and consists of one or more free-form paragraphs separated by blank lines. Use complete sentences and proper grammar.

fix: prevent workers stealing tasks

Introduce a worker ID and apply to tasks as workers take them. Prevent workers
from taking tasks with an ID.

If the body is provided, it should describe more context about the code changes.

Footer

If present, the footer contains references to GitHub issues that this commit addresses; it may or may not close the issue, especially for larger issues.

• On commits that do not close the issue, use Refs, e.g. Refs: #42
• If the commit closes an issue and is not a fix commit, use Closes, e.g. Closes: #42
• If the commit closes an issue and is a fix, use Fixes, e.g. Fixes: #42

Commits should address only one issue, however if for any reason a commit does address multiple issues, separate them with commas, e.g. Refs: #42, #56, Refs: #42, Fixes: #78.

Reverting Commits

When reverting previous commits, use revert as the type. The description should summarize what is being reverted, and the body may describe the reason. The footer must contain Refs: followed by the short hashes of the reverted commits. GitHub issue(s) may also be referenced on a separate line.

revert: remove changes to room detection

Turns out these changes are hugely detrimental to performance, so we need to
pull them out for now until those issues can be resolved.

Refs: 676104e, a215868
Refs: #43

Breaking Changes

Generally speaking, a breaking change is any change that would prevent a player from downgrading to the previous version of the code and still keep their current save file.

Breaking changes must be indicated by either a ! immediately before the colon in the header (e.g. feat!: change save file serialization to CBOR) or a footer prefixed with BREAKING CHANGE: followed by a description of the breakage. Both indicators may be present.

Breaking changes need not be indicated prior to the first publicly available build.

mdBook (Markdown Book)

mdBook is a command line tool to create books with Markdown. It is ideal for creating product or API documentation, tutorials, course materials or anything that requires a clean, easily navigable and customizable presentation.

You can find the mdBook repository here: https://github.com/rust-lang/mdBook

You can find online documentation for mdBook here: https://rust-lang.github.io/mdBook/

Quickstart

Simply install mdBook from Cargo:

$ cargo install mdbook

To view a live version of the book, cd into the book directory and execute:

$ cd book
book/$ mdbook serve --open

and a web browser will open to the URL of the book. You can edit the book live and changes will be automatically detected.

To build the book for deployment to a web server, issue the following commands:

$ cd book
book/$ mdbook build

and the book will be built into the book/book/ subfolder.