Services

Unresolved local problems can impose capped trade and disease consequences. The inn is the discovery funnel; a settlement without an available inn uses overview.

People and locations

Every seeded or imported settlement has persistent local NPC identities in addition to its service providers. The overview/public area and service locations contain multiple people; towns and larger settlements also populate a keep. A horizontal, keyboard- navigable circular portrait strip selects whom the active character addresses. It is attached just above the resizable chat panel, opposite the party portrait strip, and moves with the chat's top edge. The selected NPC's description is centered in the remaining stage between the two strips. Service pages initially select the service provider, while other locations select a deterministic local. Selecting someone else keeps the party in place and updates the visible physical description and greeting. Dialogue subjects appear as highlighted phrases in what NPCs actually say rather than in a separate topic list. Names are not globally or settlement-locally unique. When one NPC refers the player to a different local who has the same displayed name, the dialogue explicitly says that it means "the other" person and repeats the contact's profession, appearance, and usual location. When the speaker is the contact, they identify themselves in the first person and make their testimony subject clickable in that line.

The book button immediately to the right of the settlement identity and official time toggles the character's journal without leaving the current location. Journal mode replaces the settlement's left rail with a recency-sorted quest list and its right rail with the selected quest's dry log; toggling it again or pressing Escape restores the location rails.

Public squares, residential areas, and, for towns and larger settlements, the keep appear as selectable building tabs alongside services in the settlement header. Until bespoke building art is available, non-service tabs reuse neutral building art and house/castle icons. These places use the same authoritative portrait, description, and chat surface; villages and hamlets cannot enter a keep that their population does not have.

NPC presences and daily time windows are strategic database state, not tactical positions or tick state. The player view exposes physical presentation, occupation, household, observable presentation, and public local role, but never private sex, personality, motives, beliefs, quest truth, generation weights, required causal bridges, or the private explanation for an unusual presence. Generation uses one stable typed weighted evaluator for production and tests; zero weights are impossible, while any rare choice marked as bridge-dependent is rejected unless the settlement context supplies that bridge.

Settlements may have public disease outbreak facts: disease, start and end character-minute bounds, and intensity. Acquisition uses deterministic continuous overlap plus innate and acquired immunity, so dividing the same stay into smaller rest actions does not reroll exposure. Imported settlements carry a bounded strategic industry profile derived from land use, hydrology, soil, geology, historical woodland, population, and route accessibility. It describes plausible production rather than stock on hand; accessibility can reduce scale but cannot invent resources.

The map camera follows the rendered map element's measured aspect ratio and observes later layout changes. Tile selection therefore covers the world area actually visible in desktop, narrow, and resized layouts without distorting or letterboxing the map.

Raster terrain uses a visible light-brown area for open hills, green for forest, and dark green for their overlap. It does not add symbolic hill or mountain stamps to the paper map.

Settlement and quest destinations share the same strategic location shell. A settlement's base location view shows population statistics and historical alternative names on the left and a short population-based description on the right. Imported settlements may also expose a plain-text Viabundus settlement/city description in a collapsed section labeled with its source language. Its Map tab contains an accessible SVG interaction layer over detailed Paper AVIF world tiles with roads, water, generalized GLO-30 height bands and contours, and explicitly partial Copernicus forest coverage. The browser loads only cached tiles covering the current pan and zoom; current and selected settlements, locally issued available quests, the party's active quest at its issuing settlement, connectivity, settlement names, links, and the straight line from the current location to the selected destination stay in the dynamic inline SVG overlay. This keeps each response bounded rather than exposing every quest in the world. Settlements use population-class village, town, and city pictograms, while quests use diamond markers. Labels retain a consistent screen size, appear progressively by settlement importance and zoom, and avoid one another in screen space. Every canonical settlement or visible geographic quest symbol can be inspected through the same ?destination= URL used by the ordinary destination list. Selecting a destination initially fits the map to the corridor between it and the party's current location, with a close local view when both locations coincide; map symbols retain a consistent on-screen size throughout zooming, and the closest view is backed by a high-quality level-6 tile set. A directly connected settlement or active quest destination shows distance, journey time, and the existing travel action; any other settlement or available quest shows useful detail without a travel form. Dragging pans, the mouse wheel or a two-finger pinch zooms, and keyboard arrows, +, -, and Home provide accessible navigation without adding map controls, a legend, or source information to the screen. Links and server-rendered selection remain usable without JavaScript. Settlement services remain separate tabs and are available only at settlement locations.

Geographic map pins and settlement travel actions require an imported source_node_id on the current settlement. Demo or otherwise source-less settlements show an explicit map-data-not-initialized state, and source-less destinations are omitted from the geographic SVG rather than interpreting their nongeographic coordinates as longitude and latitude.

The backend classifies every materialized settlement by population as Hamlet (under 2,000), Village (2,000-3,999), Town (4,000-7,999), City (8,000-12,999), or Capital (13,000 and above), with population level as the fallback when no estimate exists. These regional bands ensure the imported 1544 playable area represents all five settlement scales. The strategic map progressively hides lower-level settlement pins as the camera zooms out while always retaining the current and selected settlements. Each service tab layers its existing service SVG over a grayscale, CSS-tinted building background. Unknown settlements, hamlets, and villages use the village set; towns use town overrides when present; and cities or capitals use city overrides when present. A missing higher-tier image falls back to that service's village building. The location header is twice the height of compact application headers so the low silhouettes and large service marks remain legible. The tabs meet the lower edge of the sky and the active building is shown by an underline. The settlement name and saved character time share one carved or engraved rectangular sign island. The active tint carries through both interface rails, whose recessed interiors, edge beams, square corner blocks, and darker interactive rows are all derived from that tint, as well as through character inspection via the validated building URL parameter. Quest destinations use green environmental framing. The location header renders a continuously interpolated sky from the active character's saved time snapshot: daylight is bright blue, dawn and dusk are warm, and nighttime plus the building surfaces are darker still. The sun or moon follows an edge-to-edge arc that peaks over the center at noon or midnight, while other header text uses protected dark labels for reliable contrast.

Weaponsmith chimneys add a subtle decorative SVG smoke layer without changing the raster building or service semantics. Quest destinations use two physical tabs: the default Map view shares the unlit tent scene used by travel camps, while the Enemy view places a skull mark over the encounter ground. The Enemy view presents combat before resolution and recovered loot afterward, so loot is not a separate tab. All effect and prop layers are noninteractive.

The wilderness props follow the ornament anatomy at styles/timber-framed/ornament/<variant>/ornament.png. Each uses a 512-by-512 transparent canvas, a bottom-center anchor on source row 487, and the shared top-bar scene scale range of 0.8473–1. The raster may overlap only the standard service-tab art bleed (0.65 rem inline, 0.45 rem above, and 0.5 rem below); animated effects may rise through its transparent upper field. These front-facing compositions must not be mirrored.

Camp and quest-location headers also carry a distant grayscale wilderness horizon behind their tabs. Forest, grassland, and hills variants use the same 2880-by-240 transparent panorama contract as settlement horizons and inherit the live sky tint and brightness. Until imported terrain selects the actual biome, a deterministic hash of the camp party or quest-location ID keeps the assigned scenery stable between visits without adding persisted state.

Each settlement offers a number of services as tabs of a unified trade page. Each service corresponds to a profession, represented by a single NPC. A greeting links the NPC's profession; asking about it explains the work and offers a second linked topic through which the active character may become an apprentice. The left side lists what the NPC offers, including training or other services where appropriate, and the right side lists what the party offers.

The general merchant teaches Command; cooks at inns teach Cooking; weaponsmiths and armourers teach Smithing; tailors teach Tailoring; herbalists divide their instruction between Physiology (one half) and Anatomy, Knife, and Tailoring (one sixth each); and the church teaches its own religious tradition through prayer and practice activities. Inns also sell cooking implements and food ingredients. Apprentices pay for instruction. At rank 2 in every associated profession skill they become journeymen who may practice independently in cities for a small wage, and at rank 4 they become masters whose practice earns a good income. Religious progression uses novice, cleric, and teacher as neutral interface terms, and religious practice earns Virtue rather than money.

This is a profession and activity system, not a guild-membership simulation. There are no persisted guild affiliations, rivalries, dues, membership limits, exclusive apprenticeships, or restrictions on where a qualified character may practice beyond the activity requiring a city. Several professions may teach the same skill without making the character a member of all of them.

The location header reflects settlement scale through architecture and its distant horizon. Unknown settlements, hamlets, and villages use the low village set; towns use moderately prosperous two- and three-story guildhouses; cities and capitals use taller masonry civic and merchant buildings. Each tier has inland, Baltic coastal, and river horizons. Until the world import supplies hydrology, a deterministic hash of the settlement ID assigns one of those three variants, so the view is stable between visits without creating persistent geographic data. The imported selector is intended to replace that temporary hash directly.

Across each architectural tier, churches and watchtowers rise above ordinary service buildings while retaining the shared ground line. Every facade keeps a common central light wall field for the separately layered white service mark; the mark stays at one height across the tier. Tall facades generally place their entrance beneath that field, with centered doors favored for churches and watchtowers and used selectively for other city buildings.

Horizon art preserves its aspect ratio and stays centered on the bottom edge. Ordinary wider screens crop its sides instead of stretching fields, buildings, bridges, ships, or towers; ultrawide-specific composition is deferred.

Services show up at the top, above the list of items in their own list. Each service has a button to expand it, which shows a custom per-service form. To rest at an inn, for example, there is a slider for how many nights you would like to pay for. Doctors may have a healing menu for different treatments (bandaging, physiology for diseases, surgery). Smiths may have a menu where you can search for a custom piece of equipment designed by another player which you can pay them to produce. Mount & Blade Bannerlord has a good reference for this menu, including the ability to trade intangibles (the barter menu with other lords kind of has this).

Weaponsmith and Armourer trade rows also offer Repair, plus a Repair all action. An action is disabled only when the item is undamaged or every damaged condition bin exceeds that smith's skill; mixed damage is accepted and repaired as far as the smith can manage. Submitted items leave the owner's inventory and appear in a bottom-anchored custody panel below the independently scrolling wares list. The panel grows only as needed up to half the list height and then scrolls internally. It shows the ETA and the residual condition the smith cannot repair. Finished items can be retrieved after leaving and returning to the settlement, with no expiry.

Halbe: Brothels may provide... other services... for a morale bonus. ||But also a risk of being afflicted by a disease||.

In the center of the screen, clients may render a 3D window of the NPC representing the service. They can have dialogue that plays, like a greeting when you open their menu, a goodbye when you leave it, and comments as you interact with their menu. But this should never interfere with the gameplay. You don't have to click through dialogue in order to buy something, it just plays in the background as you use their service. This is not important for the MVP, and later down the line this would also be a great opportunity to add voice acting and mocap to give the world some personality.

The shared chat panel floats just above the bottom of the center view with a translucent, fixed environmental background and can be resized vertically from its top edge. Its height is shared across settlement and quest-location pages and remembered by the client. Local, Party, Settlement, direct-message, Guild, and Info messages share one chronological stream rather than separate tabs. Messages are distinguished by color without a repeated channel-name prefix. A compact row of colored square toggles filters each channel: Local is white, Party blue, Settlement yellow, direct messages purple, Guild green, and Info grey. The channel name is available as the toggle's hover tooltip and accessible label rather than persistent text. Enabled channels show their full color, while disabled channels become translucent; there is no inner enablement mark. Info is reserved for game notices such as inventory and currency changes.

Halbe: The inspiration for this is the Maiden in Black from Demon's Souls, who recites an incantation while you are in the level-up menu.

Social

Each settlement has at least an inn, which serves as a social hub for chatting with other players and forming parties. Quests originate from the NPCs who run settlement services rather than from a separate notice board. A service tab uses a gold exclamation when its NPC has an available quest and red when the active completed quest is ready to report, and the quest is offered through linked lines in the shared party chat. Map destination lists mark settlements with available quests in gold and the party's active quest route in red; the current settlement is included as a non-traveling row, and completing the active objective leaves its marker red until turn-in. Parties are independent of quests, and every character is always in one: a new or departing character leads a party of one.

The crown on a portrait identifies the party leader, which is always the leftmost member. Current aggregate Physiology, Command, and Religion checks are stacked vertically as the leftmost element of the floating party strip, immediately before the party-inventory chest. Surgical capability is never aggregated: recruitment displays the character's Anatomy/Knife/Tailoring composite, while each procedure uses the applicable individual combination, so backup practitioners matter when the primary practitioner is wounded or several patients need simultaneous triage. The role-add button sits immediately to the right of the rightmost filled party member and opens the centered recruitment popup. The popup separates current roles, saved templates, role details, individual recommendation groups, and its final action into distinct sections. A leader creates a named Role with individual minimum recommendations and a quantity; each position created by that quantity is a visually grouped Slot. Current roles can be reopened in the same builder to change their name, recommendations, or total slot count. Slot count cannot fall below the number already filled. Deleting a role clears its pending applications and role association without removing party members who filled it. Saved role specifications live in a toolbar at the top of the popup. They can be loaded by selecting them, renamed or deleted through hover actions, or created immediately from the current recommendations through a separate naming prompt. Saving a template is independent of adding an active recruitment role. The Combat group contains adjacent melee, ranged, and heavy checkboxes plus weapon precision and armor tier sliders; the Mobility group contains Athletics and Endurance sliders. They are recommendations rather than hard gates, so applicants and applications that fall short receive a warning but remain actionable.

Applicant inspection uses the same icon-based character summary as a full character sheet. Its equipped-hand profile is loaded from the applicant's actual equipment, so dual-wielded duplicates collapse and hybrid weapons expose all of their weapon leaves. This presentation does not alter recruitment recommendation matching or capability checks.

Party authority is collaborative without becoming ambiguous: the leader executes party-level actions directly, while any other living member may attempt the same controls to send a persistent suggestion. The leader receives Approve/Deny notices beneath that member's portrait. Suggestions cover travel, quest acceptance/abandonment, tactical combat and autoresolve, recruitment roles and applications, member removal, party skill targets, shared inventory targets, mission cancellation, and disbanding. Turning in a completed quest is the exception: any living party member at the quest giver's settlement may report its completion and immediately claim the reward for the party. A member's newest travel suggestion replaces their older destination, and their shared-inventory edits coalesce into one notification. NPC leaders approve suggestions automatically after two seconds.

Leadership uses standing votes. At any time, a living member may use the crown control above any living member's portrait, including their own, to assign or reassign their one vote. The selected crown remains visible; a vote for the current leader is shown as a non-interactive gold crown. New solo parties receive a self-vote, and every living member joining through a party merge automatically votes for the destination's current leader. Votes survive leadership changes. A living leader is replaced only when a challenger has at least 66% of living members' votes. If the current leader is dead, the inclusive threshold is 50%; when only one member survives, normalization supplies that survivor's self-ballot so succession cannot deadlock. Dead or departed voters and invalid candidates are removed. When multiple candidates qualify, the greatest tally wins, then the lowest character ID. Re-evaluation occurs after votes, membership changes, and death, without requiring a newly elected leader to immediately retain 66%.

The leader separately configures party-level targets for Physiology, Command, and Religion from the aggregate bars above the party portraits. Each notched bar shows the current aggregate as its fill and its whole-number target from 0–5 as a movable marker; clicking anywhere on the bar moves the marker to the nearest notch, and the marker may also be dragged. Hovering reveals the aggregate to one decimal place and its target. Physiology uses the bounded geometric-support equation described in Stats: member values are sorted highest-first, then receive weights of one, one half, one quarter, and so on before being combined against the unfilled portion of the five-point scale. Religion uses each character's maximum effective tradition check as a UI-only coverage summary, while Command uses the strongest speaker, a saturating coordination allowance, and supporting members' deviations from a 2.5 baseline. These checks never filter an individual role. The same bars preview a prospective member from either side of recruitment: green shows an increase and red shows a Command decrease caused by a below-baseline recruit. Checks receiving no contribution are omitted from a projection. Candidate cards otherwise retain only their capability summary rather than repeating exact statistics.

A character applies to the role as a whole rather than an individual slot. Open slots in the same role appear as overlapping portraits, without a connector; filled positions become ordinary party-member portraits and lose their role presentation. Hovering an open slot reveals its recommended tags and applicant names. Selecting it replaces the sidebars with exact role requirements on the left and detailed applicant capability values plus Accept/Reject controls on the right. Every applicant in that right rail has a selectable portrait; selecting it shows the applicant's stats on the left and their placeholder portrait in the center without replacing the request list. Other applications stay pending while the role has capacity and are rejected only when its last slot fills. Notification badges live on the corresponding open-slot stack, while the browser window title retains the total pending count. Local development creates two randomly named bot applicants per slot: one that meets the recommendations and one that deliberately misses a requirement.

The default chat channel is Local. NPC conversations belong to the active party and service NPC; player conversations belong to both complete parties, so party members share the same history even if they open the subject later. Player conversations require both parties to occupy the same strategic location. Selecting any local player opens their stats, bio, party information, and the shared conversation; a stranger may submit a general application, while an existing member sees the relevant leave or remove control. General applications share a zero-capacity, requirement-free Unassigned role. Zero capacity stops a role from being advertised but does not discard its pending applications. Incoming players who speak to the party appear as selectable portrait shortcuts at the lower-right of the center view. Quest-giver recruitment is advertised only while the recruiting party remains in that settlement; if every role has zero open slots, the NPC mentions the helping party without inviting applications. The leader's linked name in that dialogue selects their local character profile and conversation.

Clicking any filled character portrait selects that character. The character sheet shows its automatic icon summary before biography and skills, while the opposite rail shows attributes and health. Neutral personality axes are omitted, and each shown personality tag has a tooltip stating its exact morale multiplier and any event-duration multiplier. On one's own biography, hovering or focusing the Religion entry reveals a Renounce action when the character currently professes a faith. Summary ranks deliberately use healthy aptitude-capped values: current injuries do not alter recruitment or character summary icons. The summary's tooltip still exposes the exact healthy rank, and the full skill rail separately shows injury-adjusted current performance. Recruitment recommendation matching continues to use the existing capability projection; the icon summary is presentation only.

Portrait social affordances open the normal social popup for party members and present settlement NPCs. The selected person's morale/relationship area opens the same popup. Its ordinary Chat activity has a 30-minute default and a 15-minute duration slider up to eight hours. Quest-specific confrontation approaches are not duplicated there: they appear only while the corresponding quest dialogue is active. The fallible Insight impression happens passively when the witness's quest testimony is heard.

A living active character with Physiology 2 or better sees the selected character's Physiology surface as a passive, durable notebook derived from actual shared-presence spans. It shows quantized Humour readings, recognizable symptoms, known interventions, localization appropriate to historical skill, and explicit gaps, but never diagnoses or recommends. The active character's Cooking skill icon continues to open cooking.

Herbalists sell concrete prepared interventions into personal inventory. The patient or an authorized, co-located party member may administer one with an explicit route, amount, and optional body region, and may stop an active administration. Physiology does not craft preparations; Herbalism #214 owns ingredients, lots, composition, recipes, and crafting, while Chemistry #215 owns chemical behavior. Foraging remains deferred.

Every settlement currently has one church with a fixed faith. Its priest offers conversion only to that faith through the dialogue system; changing the settlement's stored religion changes the priest's topic, profession, and the faith-specific church icon in the settlement navigation. Multiple churches in one large city are deferred until the settlement service model supports distinct church instances.

Hovering near a non-leader portrait reveals a removal action beside its inventory action. The leader may remove another member, while a non-leader sees the action only on their own portrait and may use it to leave. A player-controlled character must settle any party-inventory stake before removal; dismissing a generated companion automatically withdraws its liquid gold stake through the normal party-inventory system before it leaves. The leader disbands the party instead of removing themselves. Generated companions automatically use the normal settlement-rest system until their injuries heal whenever the party reaches a settlement; their personal strategic clocks advance independently.

Personal and shared inventories retain a desired quantity per item. Personal targets belong to the character; shared targets belong to the character who leads the party, so their preferences return whenever they lead a later party. A positive target keeps an empty row visible for restocking. Merchant trading exposes Player and Party tabs on the player's rail and uses the selected inventory and its gold.

Merchant, party-member, party-chest, and loot panels share staged transfer controls. One chevron stages one item, two stage only the quantity needed to reach or preserve the destination target, and three stage everything movable. Footer controls apply the same action to every row from top to bottom. Equipped items are excluded until unequipped.

Moving near a filled portrait reveals its backpack action. A party member's backpack opens the two-character item offer view. The active character's backpack opens a discard view: items are first staged into a left-side Discard list, can be removed from the draft, and are deleted only after confirming Discard. Equipped items cannot be staged.

Armor is summarized from the equipped pieces covering each body region, not item names or an average armor score. 1/4 armor means either a shield or a helmet worn with a cuirass; 1/2 armor requires a helmet and cuirass plus either tasset/leg protection or a shield; 3/4 armor adds both arms and thigh/knee protection; full armor requires high coverage on every modeled region. This follows the broad historical silhouettes: a pikeman's half armor consisted of helmet, cuirass, gorget, and tassets (Art Institute of Chicago), while cuirassier three-quarter armor ended around the knee and omitted lower-leg defenses (Metropolitan Museum of Art). The current body model has one slot per arm and leg, so high regional coverage is temporarily used to distinguish full harness from three-quarter armor until upper/lower limb slots exist.

All of this is done in hypertext, but what's ostensibly physically going on in the world is that NPCs explain their own problems and rumors spread once a party takes the work: "a couple of adventurers are planning on slaying those goblins that have been ambushing the merchant caravans, I hear they're looking for an archer. You should seek them out at Grub's Tavern if you're interested". When you show up in their group chat, you're approaching them at their table.

Off-Topic

Not all socialization in settlements is relevant to quests. The tavern is also effectively a public chatroom. Later, after the MVP, we can also give players the ability to purchase a building and make factions which may serve as faction-exclusive chatrooms.

Halbe: Or they could freely discriminate in other ways. In-world racism between Elves, Dwarves, and Humans would be very appropriate. Even the kind of discrimination that would be considered objectionable in the modern day would be fine, like sexism or intra-human racism, due to the system described in the next section

Moderation

We don't want to be the speech police, but there is inevitably going to be spam or links to pornography and other objectionable content that we will have to deal with. However, it would be great if we could give players the tools to enforce speech themselves and opt-in to more strict moderation than the bare minimum needed to stop spam and illegal content. Essentially, a player-run faction could own a place like a tavern and would be responsible for handling the moderation. There can be multiple taverns in a settlement, so if one of them has an overzealous moderator then you could simply go to one of the other ones. If they are all overzealous, especially if its that a particularly obstinate group of players are trying to establish a monopoly to enforce their annoying speech rules, then we can leverage the fact that this is a game not just a forum. Steal their stuff, assassinate their characters, burn their building down. Normally, these things would be hard to get away with. But players might have the ability to rate the moderators, and if enough people complain then we can increase the likelihood of success when attempting these "faction warfare" actions (when you do not have the will of the people, player establishments are protected by favor.

None of these player-run social hub features should be in the MVP, we will just be very selective about who we invite for testing until we add support for this stuff.

Languages

Each imported settlement has an inferred East-central, West-central, and Low vernacular distribution totaling 100%. Low rises northward; longitude divides the central dialects, with southern Thuringia favoring East-central. Yiddish is a small per-person incidence, never a town-exclusive language. Deterministically selected Yiddish NPCs are fluent in Yiddish and have a 0.8 best-shared-language coefficient with a fluent local German; direct German hours account for the Yiddish/German correlation. Demo settlements use explicit fallback profiles. Books, libraries, and tavern/priest translators require future item and service systems.

Each settlement also has a deterministic, versioned economy profile. Population, prosperity, road access, and nearby production jointly decide which services exist and which stock categories are common. A tiny settlement may expose only an inn and general store; a village uses a general blacksmith; prosperous towns split weaponsmith and armorer services. Generalists carry broader categories where specialists are absent. The server enforces service availability for trade, herbalist care, and repairs. The overview exposes prosperity, specializations, and every religion represented by the canonical legal status, not merely the faith selected for the single church/priest presentation.

Authored organization chapters add distinct Place Facades alongside ordinary settlement services. Each opens a real organization building with one deterministic persistent representative. Visitors may enter and speak to the representative; nonmembers may ask to join, while members conduct dues, reactivation, promotion, and presentation business through the compiled dialogue. A service-linked guild keeps its ordinary merchant or craft service and dialogue in addition to its separate chapter building.