diff --git a/doc/Baking-the-world.md b/doc/Baking-the-world.md index a2f3739..ab313a5 100644 --- a/doc/Baking-the-world.md +++ b/doc/Baking-the-world.md @@ -2,7 +2,9 @@ #### Wednesday, 8 May 2019 -![Devogilla's Bridge in Dumfries, early foourteenth century](https://2.bp.blogspot.com/-qxkySlJNmtY/XNKvJksmSjI/AAAAAAAAnXU/z1Zv2LmjydMmi_1q2mWdwVALmdfi9OItwCLcBGAs/s1600/Devorgillas-Bridge.jpg) +![Devorgilla's Bridge in Dumfries, early fourteenth century](https://2.bp.blogspot.com/-qxkySlJNmtY/XNKvJksmSjI/AAAAAAAAnXU/z1Zv2LmjydMmi_1q2mWdwVALmdfi9OItwCLcBGAs/s1600/Devorgillas-Bridge.jpg) + +*Devorgilla's Bridge in Dumfries, early fourteenth century. This clearly shows how a genetic buildings approach to bridges can be made to work: a single element is repeated to span the necessary distance. That element can be stretched vertically and laterally to match the location, and can be rendered in different stone finishes to match local geology.* In previous posts, I've described algorithms for dynamically [populating](Populating-a-game-world.html) and dynamically [settling](Settling-a-game-world.html) a game world. But at kilometre scale (and I think we need a higher resolution than that - something closer to hectare scale), settling the British Isles using my existing algorithms takes about 24 hours of continuous compute on an eight core, 3GHz machine. You cannot do that every time you launch a new game. diff --git a/doc/Pathmaking.md b/doc/Pathmaking.md index 216446b..67beb50 100644 --- a/doc/Pathmaking.md +++ b/doc/Pathmaking.md @@ -4,9 +4,7 @@ ## Stages in creating routes between locations -### The 'procedural' phase - -*see also [[Baking-the-world]]* +*see also [Baking the world](Baking-the-world.html)* Towards the end of the procedural phase of the build process, every agent within the game world must move through the complete range of their needs-driven repertoire. Merchants must traverse their trading routes; soldiers must patrol routes within their employers domain; primary producers and craftspeople must visit the craftspeople who supply them; every character must visit their local inn, and must move daily between their dwelling and their workplace if different; and so on. They must do this over a considerable period - say 365 simulated days. @@ -16,7 +14,11 @@ The algorithmic part of choosing a route is the same during this baking phase as Thus the 'weight' of any section of route is a function of the total number of times that route segment has been traversed by an agent during this baking phase. At the end of the baking phase, routes travelled more than `R` times are rendered as roads, `T` times as tracks, and `P` times as footpaths, where `R`, `T` and `P` are all chosen by the game designer but generally `R > T > P`. -### Algorithmic rules +### Routing + +Routing is fundamentally by [A\*](https://www.redblobgames.com/pathfinding/a-star/introduction.html), I think. + +#### Algorithmic rules 1. No route may pass through any part of a reserved holding, except the holding which is its origin, if any, and the holding which is its destination (and in any case we won't render paths or roads within holdings, although traversal information may be used to determine whether a holding, or part of it, is paved/cobbled; 2. No route may pass through any building, with the exception of a city gate; @@ -24,9 +26,43 @@ Thus the 'weight' of any section of route is a function of the total number of t 4. Any existing route segment costs only a third as much to traverse as open ground having the same gradient; 5. A more used route costs less to traverse than a less used route. +#### Step costing: + +Step cost is something like: + + (/ + (- + (+ distance + (expt height-gained height-gain-exponent) + (reduce + (map crossing-penalty watercourses-crossed))) + (reduce + (map bridge-bonus bridges-crossed))) + (or road-bonus 1)) + +**Where** + +* `distance` traversed is in metres; +* `height-gained` is in metres; +* `height-gain-exponent` is tunable; +* river `crossing-penalty` varies with a (tunable) exponent of the flow; +* `bridge-bonus` works as follows: bridge bonus for a bridge entirely cancels the river crossing penalty +for the watercourse the bridge crosses; bridge bonus for a ferry cancels a (tunable) fraction the river +crossing penalty. +* road-bonus for a road is substantial - probably about 8; for a track is less than road but greater than footpath, say 5; for a footpath has to be at least 3, to provide an incentive to +stick to paths. All these values are tunable. Road bonus ought also to increase a small amount with each traversal of the path segment, but that's still to be worked on. + +A lot of this is subject to tuning once we have prototype code running. + +Somewhere into all this I need to factor tolls charged by local aristons, +especially for bridges/ferries, and risk factors of hostile action, whether +by outlaws or by hostile factions. But actually, that is at a per actor +level, rather than at a pathmaking level: richer actors are less deterred +by tolls, better armed actors less deterred by threat of hostile action. + ### River crossings -Crossing rivers is expensive - say five times as expensive as level open ground (but this will probably need tuning). Where a river is shallow enough, (i.e. where the amount of water passing is below some threshold) then a path crossing will be rendered as stepping stones and a track crossing as a ford. Where it's deeper than that, a path crossing either isn't rendered at all or is rendered as a light footbridge. A track or road crossing is rendered as a bridge. However, the maximum length of a bridge varies with the amount of traffic on the route segment, and if the crossing exceeds that length then a ferry is used. Road bridges will be more substantial than track bridges, for example in a biome with both timber and stone available road bridges might be rendered as stone bridges while track bridges were rendered as timber. If the watercourse is marked as `navigable`, the bridge must have a lifting section. It is assumed here that bridges are genetic buildings like most other in-game buildings, and so don't need to be individually designed. +River crossings appear automatically when the number of traversals of a particular route across a watercourse passes some threshhold. The threshold probably varies with an exponent of the flow; the threshold at which a ferry will appear is lower (by half?) than the threshold for a bridge. Of course river crossings, like roads, can also be pre-designed by game designers. + +Where a river is shallow enough, (i.e. where the flow is below some threshold) then a path crossing will be rendered as stepping stones and a track crossing as a ford. Where it's deeper than that, a path crossing either isn't rendered at all or is rendered as a light footbridge. A track or road crossing is rendered as a bridge. However, the maximum length of a bridge varies with the amount of traffic on the route segment, and if the crossing exceeds that length then a ferry is used. Road bridges will be more substantial than track bridges, for example in a biome with both timber and stone available road bridges might be rendered as stone bridges while track bridges were rendered as timber. If the watercourse is marked as `navigable`, the bridge must have a lifting section. It is assumed here that bridges are genetic buildings like most other in-game buildings, and so don't need to be individually designed. ### Representation @@ -65,17 +101,7 @@ I'm working on a separate library, [walkmap](https://simon-brooke.github.io/walk ### Pathmaking and scale -Dealing with large heightmaps - doing anything at all with them - is extremely compute intensive. Just converting a 1000x1000 heightmap from STL to SVG is currently taking 8 hours and 15 minutes; and it ends up with a 46 megabyte SVG file! However, most of the time cost is in writing. Reading the STL file takes four and a quarter seconds; converting that STL to SVG in memory takes less than five seconds. So the huge cost is writing the file with Dali. - - walkmap.core=> (time (def stl (decode-binary-stl "../the-great-game/resources/maps/heightmap.stl"))) - "Elapsed time: 4285.231513 msecs" - #'walkmap.core/stl - walkmap.core=> (time (def svg (stl-to-svg stl))) - "Elapsed time: 4865.798059 msecs" - #'walkmap.core/svg - - -"Elapsed time: 2.969569560662E7 msecs" +Dealing with large heightmaps - doing anything at all with them - is extremely compute intensive. We cannot effectively do routing at metre scale - which is what we ultimately need in settlements - across the entire thousand kilometre square map in one pass. But also we don't need to because much of the continent is by design relatively unpeopled and relatively untracked. The basic concept of the Steppe is that there are two north/south routes, the one over the Midnight Pass into the Great Place and the one via Hans'hua down to the Cities of the Coast, and those can be part of the 'designed roads' map. So we can basically exclude most of the Steppe from routing altogether. We can also - for equally obvious reasons exclude the ocean. The ocean makes up roughly half of the 1000x1000 kilometre map, the steppe and plateau take up half of what's left, mountain massifs eat into the remainder and my feeling is that much of the eastern part of the continent is probably too arid to be settled. So we probably end up only having to dynamically route about 20% of the entire map. @@ -107,6 +133,10 @@ we can then collect contiguous groups of zones each having at least one holding, At least one of phases three, four, five and six is probably redundant; but without trying I'm not sure which. +#### Relevant actor classes by phase + +Craftspeople and primary producers do travel between settlements, but only exceptionally. They mainly travel within at most a few kilometres of home; so they are primarily relevant in phases four and five, and need not be activated during phase six. Similarly, merchants primarily travel between settlements, and rarely within settlements; therefore, they need not be activated in phase four, and probably not even in phase five; but they must do a lot of journeys - substantially their full repertoire - in phase six. + ### Tidying up After the full set of increasing-scale passes is complete, we should automatically cull any route segments generated in the settlement phase which have never actually been traversed. diff --git a/docs/codox/Baking-the-world.html b/docs/codox/Baking-the-world.html index 0e624ad..b54a08b 100644 --- a/docs/codox/Baking-the-world.html +++ b/docs/codox/Baking-the-world.html @@ -1,8 +1,9 @@ -Baking the world

Project

Topics

Namespaces

Baking the world

+Baking the world

Project

Topics

Namespaces

Baking the world

Wednesday, 8 May 2019

-

Devogilla’s Bridge in Dumfries, early foourteenth century

+

Devorgilla’s Bridge in Dumfries, early foourteenth century

+

Devorgilla’s Bridge in Dumfries, early foourteenth century. This clearly shows how a genetic buildings approach to bridges can be made to work: a single element is repeated to span the necessary distance. That element can be stretched vertically and laterally to match the location, and can be rendered in different stone finishes to match local geology.

In previous posts, I’ve described algorithms for dynamically populating and dynamically settling a game world. But at kilometre scale (and I think we need a higher resolution than that - something closer to hectare scale), settling the British Isles using my existing algorithms takes about 24 hours of continuous compute on an eight core, 3GHz machine. You cannot do that every time you launch a new game.

So the game development has to run in four phases: the first three phases happen during development, to create a satisfactory, already populated and settled, initial world for the game to start from. This is particularly necessary if hand-crafted buildings and environments are going to be added to the world; the designers of those buildings and environments have to be able to see the context into which their models must fit.

Phase one: proving - the procedural world

diff --git a/docs/codox/Pathmaking.html b/docs/codox/Pathmaking.html index 966e6e7..17d6c51 100644 --- a/docs/codox/Pathmaking.html +++ b/docs/codox/Pathmaking.html @@ -1,15 +1,16 @@ -Pathmaking

Project

Topics

Namespaces

Pathmaking

+Pathmaking

Project

Topics

Namespaces

Pathmaking

NOTE: this file is called ‘pathmaking’, not ‘pathfinding’, because ‘pathfinding’ has a very specific meaning/usage in game design which is only part of what I want to talk about here.

Stages in creating routes between locations

-

The ‘procedural’ phase

-

see also Baking-the-world

+

see also Baking the world

Towards the end of the procedural phase of the build process, every agent within the game world must move through the complete range of their needs-driven repertoire. Merchants must traverse their trading routes; soldiers must patrol routes within their employers domain; primary producers and craftspeople must visit the craftspeople who supply them; every character must visit their local inn, and must move daily between their dwelling and their workplace if different; and so on. They must do this over a considerable period - say 365 simulated days.

At the start of the baking phase, routes - roads, tracks and paths - designed by the game designers already exist.

The algorithmic part of choosing a route is the same during this baking phase as in actual game play except that during the baking phase the routemap is being dynamically updated, creating a new path or augmenting an existing path wherever any agent goes.

Thus the ‘weight’ of any section of route is a function of the total number of times that route segment has been traversed by an agent during this baking phase. At the end of the baking phase, routes travelled more than R times are rendered as roads, T times as tracks, and P times as footpaths, where R, T and P are all chosen by the game designer but generally R > T > P.

-

Algorithmic rules

+

Routing

+

Routing is fundamentally by A*, I think.

+

Algorithmic rules

  1. No route may pass through any part of a reserved holding, except the holding which is its origin, if any, and the holding which is its destination (and in any case we won’t render paths or roads within holdings, although traversal information may be used to determine whether a holding, or part of it, is paved/cobbled;
  2. No route may pass through any building, with the exception of a city gate;
    3. @@ -17,8 +18,30 @@
  3. Any existing route segment costs only a third as much to traverse as open ground having the same gradient;
  4. A more used route costs less to traverse than a less used route.
+

Step costing:

+

Step cost is something like:

+
(/
+  (-
+    (+ distance
+      (expt height-gained height-gain-exponent)
+      (reduce + (map crossing-penalty watercourses-crossed)))
+    (reduce + (map bridge-bonus bridges-crossed)))
+  (or road-bonus 1))
+
+

Where

+
    +
  • distance traversed is in metres;
    • +
  • height-gained is in metres;
    • +
  • height-gain-exponent is tunable;
    • +
  • river crossing-penalty varies with a (tunable) exponent of the flow;
    • +
  • bridge-bonus works as follows: bridge bonus for a bridge entirely cancels the river crossing penalty for the watercourse the bridge crosses; bridge bonus for a ferry cancels a (tunable) fraction the river crossing penalty.
    • +
  • road-bonus for a road is substantial - probably about 8; for a track is less than road but greater than footpath, say 5; for a footpath has to be at least 3, to provide an incentive to stick to paths. All these values are tunable. Road bonus ought also to increase a small amount with each traversal of the path segment, but that’s still to be worked on.
    • +
+

A lot of this is subject to tuning once we have prototype code running.

+

Somewhere into all this I need to factor tolls charged by local aristons, especially for bridges/ferries, and risk factors of hostile action, whether by outlaws or by hostile factions. But actually, that is at a per actor level, rather than at a pathmaking level: richer actors are less deterred by tolls, better armed actors less deterred by threat of hostile action.

River crossings

-

Crossing rivers is expensive - say five times as expensive as level open ground (but this will probably need tuning). Where a river is shallow enough, (i.e. where the amount of water passing is below some threshold) then a path crossing will be rendered as stepping stones and a track crossing as a ford. Where it’s deeper than that, a path crossing either isn’t rendered at all or is rendered as a light footbridge. A track or road crossing is rendered as a bridge. However, the maximum length of a bridge varies with the amount of traffic on the route segment, and if the crossing exceeds that length then a ferry is used. Road bridges will be more substantial than track bridges, for example in a biome with both timber and stone available road bridges might be rendered as stone bridges while track bridges were rendered as timber. If the watercourse is marked as navigable, the bridge must have a lifting section. It is assumed here that bridges are genetic buildings like most other in-game buildings, and so don’t need to be individually designed.

+

River crossings appear automatically when the number of traversals of a particular route across a watercourse passes some threshhold. The threshold probably varies with an exponent of the flow; the threshold at which a ferry will appear is lower (by half?) than the threshold for a bridge. Of course river crossings, like roads, can also be pre-designed by game designers.

+

Where a river is shallow enough, (i.e. where the flow is below some threshold) then a path crossing will be rendered as stepping stones and a track crossing as a ford. Where it’s deeper than that, a path crossing either isn’t rendered at all or is rendered as a light footbridge. A track or road crossing is rendered as a bridge. However, the maximum length of a bridge varies with the amount of traffic on the route segment, and if the crossing exceeds that length then a ferry is used. Road bridges will be more substantial than track bridges, for example in a biome with both timber and stone available road bridges might be rendered as stone bridges while track bridges were rendered as timber. If the watercourse is marked as navigable, the bridge must have a lifting section. It is assumed here that bridges are genetic buildings like most other in-game buildings, and so don’t need to be individually designed.

Representation

At some stage in the future I’ll have actual game models to work with and $DEITY knows what the representation of those will be like, but to get this started I need two inputs: a heightmap, from which gradients can be derived, and a route map. The heightmap can conventionally be a monochrome raster image, and that’s easy. The route map needs to be a vector representation, and SVG will be as convenient as any. So from the point of view of routing during the baking phase, a route map shall be an SVG with the following classes:

    @@ -47,15 +70,7 @@

    I shall have to write custom code for 4 and 5 above, and, looking at what’s available, probably 3 as well.

    I’m working on a separate library, walkmap, which will attempt to implement this pipeline.

    Pathmaking and scale

    -

    Dealing with large heightmaps - doing anything at all with them - is extremely compute intensive. Just converting a 1000x1000 heightmap from STL to SVG is currently taking 8 hours and 15 minutes; and it ends up with a 46 megabyte SVG file! However, most of the time cost is in writing. Reading the STL file takes four and a quarter seconds; converting that STL to SVG in memory takes less than five seconds. So the huge cost is writing the file with Dali.

    -
    walkmap.core=> (time (def stl (decode-binary-stl "../the-great-game/resources/maps/heightmap.stl")))
-"Elapsed time: 4285.231513 msecs"
-#'walkmap.core/stl
-walkmap.core=> (time (def svg (stl-to-svg stl)))
-"Elapsed time: 4865.798059 msecs"
-#'walkmap.core/svg
-
    -

    “Elapsed time: 2.969569560662E7 msecs”

    +

    Dealing with large heightmaps - doing anything at all with them - is extremely compute intensive.

    We cannot effectively do routing at metre scale - which is what we ultimately need in settlements - across the entire thousand kilometre square map in one pass. But also we don’t need to because much of the continent is by design relatively unpeopled and relatively untracked. The basic concept of the Steppe is that there are two north/south routes, the one over the Midnight Pass into the Great Place and the one via Hans’hua down to the Cities of the Coast, and those can be part of the ‘designed roads’ map. So we can basically exclude most of the Steppe from routing altogether. We can also - for equally obvious reasons exclude the ocean. The ocean makes up roughly half of the 1000x1000 kilometre map, the steppe and plateau take up half of what’s left, mountain massifs eat into the remainder and my feeling is that much of the eastern part of the continent is probably too arid to be settled. So we probably end up only having to dynamically route about 20% of the entire map.

    However, this doesn’t get round the main problem with scale, and pathmaking. If we pathmake at kilometre scale, then curves will be necessarily very long and sweeping - because each path segment will be at least a kilometre long. And, actually, that’s fine for very long distance roads in unpopulated fairly flat territory. It’s not so good for long distance roads in rugged terrain, but…

    Phase one: hand-designed routes

    @@ -74,6 +89,8 @@ walkmap.core=> (time (def svg (stl-to-svg stl)))

    we can then collect contiguous groups of zones each having at least one holding, where in phase four each zone is a kilometre square and divided into 100x100 grid so that we route at ten metre scale; in phase five we use ten kilometre by ten kilometre zones and we route at 100 metre scale; in phase six, 100 km by 100 km zones and we route at kilometre scale. This process should automatically link up all settlements on the south and west coasts, all those on the north coast, and all in the Great Place; and seeing that the posited pre-designed caravan roads already join the south coast to the north, the north to the Great Place and the Great Place to the south coast, we’re done.

    At least one of phases three, four, five and six is probably redundant; but without trying I’m not sure which.

    +

    Relevant actor classes by phase

    +

    Craftspeople and primary producers do travel between settlements, but only exceptionally. They mainly travel within at most a few kilometres of home; so they are primarily relevant in phases four and five, and need not be activated during phase six. Similarly, merchants primarily travel between settlements, and rarely within settlements; therefore, they need not be activated in phase four, and probably not even in phase five; but they must do a lot of journeys - substantially their full repertoire - in phase six.

    Tidying up

    After the full set of increasing-scale passes is complete, we should automatically cull any route segments generated in the settlement phase which have never actually been traversed.

    Following that, there may be scope for some final manual tweaking, if desired; I think this is most likely to happen where roads routed at kilometre scale cross rugged terrain.

\ No newline at end of file diff --git a/docs/codox/Populating-a-game-world.html b/docs/codox/Populating-a-game-world.html index 5ea5c9e..695ef2c 100644 --- a/docs/codox/Populating-a-game-world.html +++ b/docs/codox/Populating-a-game-world.html @@ -1,6 +1,6 @@ -Populating a game world

Project

Topics

Namespaces

Populating a game world

+Populating a game world

Project

Topics

Namespaces

Populating a game world

Saturday, 6 July 2013

(You might want to read this essay in conjunction with my older essay, Settling a game world, which covers similar ground but which this hopefully advances on)

For an economy to work people have to be able to move between occupations to fill economic niches. In steady state, non player character (NPC) males become adult as ‘vagrants’, and then move through the state transitions described in this document. The pattern for females is different.

diff --git a/docs/codox/Settling-a-game-world.html b/docs/codox/Settling-a-game-world.html index 1bdac1f..b46a745 100644 --- a/docs/codox/Settling-a-game-world.html +++ b/docs/codox/Settling-a-game-world.html @@ -1,6 +1,6 @@ -Settling a game world

Project

Topics

Namespaces

Settling a game world

+Settling a game world

Project

Topics

Namespaces

Settling a game world

Wednesday, 30 December 2009

This essay is part of a series with ‘Worlds and Flats’ and ‘The spread of knowledge in a large game world’; if you haven’t read those you may want to read them before reading this. This essay describes how a large world can come into being and can evolve. I’ve written again on this subject since - see ‘Populating a game world’)

Microworld

diff --git a/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html b/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html index 21193ca..4b8dc93 100644 --- a/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html +++ b/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html @@ -1,6 +1,6 @@ -The spread of knowledge in a large game world

Project

Topics

Namespaces

The spread of knowledge in a large game world

+The spread of knowledge in a large game world

Project

Topics

Namespaces

The spread of knowledge in a large game world

Saturday, 26 April 2008

part of the role of Dandelion, in The Witcher games, is to provide the player with news

Note

diff --git a/docs/codox/Voice-acting-considered-harmful.html b/docs/codox/Voice-acting-considered-harmful.html index 44121b1..1b1b3fe 100644 --- a/docs/codox/Voice-acting-considered-harmful.html +++ b/docs/codox/Voice-acting-considered-harmful.html @@ -1,6 +1,6 @@ -Voice acting considered harmful

Project

Topics

Namespaces

Voice acting considered harmful

+Voice acting considered harmful

Project

Topics

Namespaces

Voice acting considered harmful

Wednesday, 25 February 2015

The Witcher: Conversation with Kalkstein

Long, long, time ago, I can still remember when… we played (and wrote) adventure games where the user typed at a command line, and the system printed back at them. A Read-Eval-Print loop in the classic Lisp sense, and I wrote my adventure games in Lisp. I used the same opportunistic parser whether the developer was building the game Create a new room north of here called dungeon-3 the player was playing the game Pick up the rusty sword and go north or the player was talking to a non-player character Say to the wizard ‘can you tell me the way to the castle’ Of course, the parser didn’t ‘understand’ English. It worked on trees of words, in which terminal nodes were actions and branching nodes were key words, and it had the property that any word it didn’t recognise at that point in sentence was a noise word and could be ignored. A few special hacks (such as ‘the’, ‘a’, or ‘an’ was an indicator that what came next was probably a noun phrase, and thus that if there was more than one sword in the player’s immediate environment the one that was wanted was the one tagged with the adjective ‘rusty’), and you ended up with a parser that most of the time convincingly interpreted most of what the player threw at it.

diff --git a/docs/codox/economy.html b/docs/codox/economy.html index c4dbafb..9bd68f7 100644 --- a/docs/codox/economy.html +++ b/docs/codox/economy.html @@ -1,6 +1,6 @@ -Game world economy

Project

Topics

Namespaces

Game world economy

+Game world economy

Project

Topics

Namespaces

Game world economy

Broadly this essay extends ideas presented in Populating a game world, q.v.

Primary producers

Herdsfolk

diff --git a/docs/codox/index.html b/docs/codox/index.html index f7aab85..2d0f0d2 100644 --- a/docs/codox/index.html +++ b/docs/codox/index.html @@ -1,3 +1,3 @@ -The-great-game 0.1.1-SNAPSHOT

Project

Topics

Namespaces

The-great-game 0.1.1-SNAPSHOT

Released under the GNU General Public License,version 2.0 or (at your option) any later version

Prototype code towards the great game I've been writing about for ten years, and know I will never finish.

Installation

To install, add the following dependency to your project or build file:

[the-great-game "0.1.1-SNAPSHOT"]

Topics

Namespaces

the-great-game.agent.agent

Anything in the game world with agency

Public variables and functions:

the-great-game.gossip.gossip

Interchange of news events between gossip agents

Public variables and functions:

the-great-game.gossip.news-items

Categories of news events interesting to gossip agents

Public variables and functions:

the-great-game.merchants.markets

Adjusting quantities and prices in markets.

Public variables and functions:

the-great-game.merchants.merchant-utils

Useful functions for doing low-level things with merchants.

Public variables and functions:

the-great-game.merchants.merchants

Trade planning for merchants, primarily.

Public variables and functions:

the-great-game.merchants.planning

Trade planning for merchants, primarily. This follows a simple-minded generate-and-test strategy and currently generates plans for all possible routes from the current location. This may not scale. Also, routes do not currently have cost or risk associated with them.

Public variables and functions:

the-great-game.merchants.strategies.simple

Default trading strategy for merchants.

Public variables and functions:

the-great-game.objects.container

TODO: write docs

Public variables and functions:

the-great-game.objects.game-object

Anything at all in the game world

Public variables and functions:

the-great-game.time

TODO: write docs

Public variables and functions:

the-great-game.utils

TODO: write docs

Public variables and functions:

the-great-game.world.location

Functions dealing with location in the world.

Public variables and functions:

the-great-game.world.routes

Conceptual (plan level) routes, represented as tuples of location ids.

Public variables and functions:

the-great-game.world.run

Run the whole simulation

Public variables and functions:

the-great-game.world.world

Access to data about the world

Public variables and functions:

\ No newline at end of file +The-great-game 0.1.2-SNAPSHOT

Project

Topics

Namespaces

The-great-game 0.1.2-SNAPSHOT

Released under the GNU General Public License,version 2.0 or (at your option) any later version

Prototype code towards the great game I've been writing about for ten years, and know I will never finish.

Installation

To install, add the following dependency to your project or build file:

[journeyman-cc/the-great-game "0.1.2-SNAPSHOT"]

Topics

Namespaces

the-great-game.agent.agent

Anything in the game world with agency

Public variables and functions:

the-great-game.gossip.gossip

Interchange of news events between gossip agents

Public variables and functions:

the-great-game.gossip.news-items

Categories of news events interesting to gossip agents

Public variables and functions:

the-great-game.merchants.markets

Adjusting quantities and prices in markets.

Public variables and functions:

the-great-game.merchants.merchant-utils

Useful functions for doing low-level things with merchants.

Public variables and functions:

the-great-game.merchants.merchants

Trade planning for merchants, primarily.

Public variables and functions:

the-great-game.merchants.planning

Trade planning for merchants, primarily. This follows a simple-minded generate-and-test strategy and currently generates plans for all possible routes from the current location. This may not scale. Also, routes do not currently have cost or risk associated with them.

Public variables and functions:

the-great-game.merchants.strategies.simple

Default trading strategy for merchants.

Public variables and functions:

the-great-game.objects.container

TODO: write docs

Public variables and functions:

the-great-game.objects.game-object

Anything at all in the game world

Public variables and functions:

the-great-game.time

TODO: write docs

Public variables and functions:

the-great-game.utils

TODO: write docs

Public variables and functions:

the-great-game.world.location

Functions dealing with location in the world.

Public variables and functions:

the-great-game.world.routes

Conceptual (plan level) routes, represented as tuples of location ids.

Public variables and functions:

the-great-game.world.run

Run the whole simulation

Public variables and functions:

the-great-game.world.world

Access to data about the world

Public variables and functions:

\ No newline at end of file diff --git a/docs/codox/intro.html b/docs/codox/intro.html index a892c58..708ac64 100644 --- a/docs/codox/intro.html +++ b/docs/codox/intro.html @@ -1,6 +1,6 @@ -Introduction to the-great-game

Project

Topics

Namespaces

Introduction to the-great-game

+Introduction to the-great-game

Project

Topics

Namespaces

Introduction to the-great-game

The Great Game

In this essay I’m going to try to pull together a number of my architectural ideas about the Great Game which I know I’m never actually going to build - because it’s vastly too big for any one person to build - into one overall vision.

So, firstly, how does one characterise this game?

diff --git a/docs/codox/modelling_trading_cost_and_risk.html b/docs/codox/modelling_trading_cost_and_risk.html index 93ea97f..0e4b71a 100644 --- a/docs/codox/modelling_trading_cost_and_risk.html +++ b/docs/codox/modelling_trading_cost_and_risk.html @@ -1,6 +1,6 @@ -Modelling trading cost and risk

Project

Topics

Namespaces

Modelling trading cost and risk

+Modelling trading cost and risk

Project

Topics

Namespaces

Modelling trading cost and risk

In a dynamic pre-firearms world with many small states and contested regions, trade is not going to be straightforward. Not only will different routes have different physical characteristics - more or less mountainous, more or fewer unbridged river crossings - they will also have different political characteristics: more of less taxed, more or less effectively policed.

Raids by outlaws are expected to be part of the game economy. News of raids are the sort of things which may propagate through the gossip system. So are changes in taxation regime. Obviously, knowledge items can affect merchants’ trading strategy; in existing prototype code, individual merchants already each keep their own cache of known historical prices, and exchange historical price data with one another; and use this price data to select trades to make.

So: to what extent is it worth modelling the spread of knowledge of trade cost and risk?

diff --git a/docs/codox/naming-of-characters.html b/docs/codox/naming-of-characters.html index e0f2dea..d36f96d 100644 --- a/docs/codox/naming-of-characters.html +++ b/docs/codox/naming-of-characters.html @@ -1,6 +1,6 @@ -Naming of Characters

Project

Topics

Namespaces

Naming of Characters

+Naming of Characters

Project

Topics

Namespaces

Naming of Characters

Generally speaking, in modern RPGs, every character with any impact on the plot has a distinct name. But if we are going to give all non-player characters sufficient agency to impact on the plot, then we must have a way of naming tens or hundreds of thousands of characters, and distinct names will become problematic (even if we’re procedurally generating names, which we shall have to do. So this note is about how characters are named.

The full name of each character will be made up as follows:

[epithet] [clan] [personal-name] the [trade-or-rank] of [location], son/daughter of [parent]

diff --git a/docs/codox/on-dying.html b/docs/codox/on-dying.html index a52e81a..8b6ad91 100644 --- a/docs/codox/on-dying.html +++ b/docs/codox/on-dying.html @@ -1,6 +1,6 @@ -On Dying

Project

Topics

Namespaces

On Dying

+On Dying

Project

Topics

Namespaces

On Dying

Death is the end of your story. One of the tropes in games which, for me, most breaks immersion is when you lose a fight and are presented with a screen that says ‘you are dead. Do you want to reload your last save?’ Life is not like that. We do not have save-states. We die.

So how could this be better handled?

You lose a fight. Switch to cutscene: the battlefield, after the fight, your body is there. Probably no sound. A party of non-enemies crosses the battlefield and finds your body. We see surprise and concern. They gather around you. Cut to interior scene, you are in a bed, unconcious, being tended; cut to similar interior scene, you are in a bed, conscious, being tended; cut to exterior scene, you are sitting with some of your saviours, and the game restarts.

diff --git a/docs/codox/orgnic-quests.html b/docs/codox/orgnic-quests.html index 49b6973..ae56c9c 100644 --- a/docs/codox/orgnic-quests.html +++ b/docs/codox/orgnic-quests.html @@ -1,6 +1,6 @@ -Organic Quests

Project

Topics

Namespaces

Organic Quests

+Organic Quests

Project

Topics

Namespaces

Organic Quests

The structure of a modern Role Playing Came revolves around ‘quests’: tasks that the player character is invited to do, either by the framing narrative of the game or by some non-player character (‘the Quest Giver’). Normally there is one core quest which provides the overarching narrative for the whole game. [Wikipedia](https://en.wikipedia.org/wiki/Quest_(gaming)) offers a typology of quests as follows:

  1. Kill quests
    2. diff --git a/docs/codox/sandbox.html b/docs/codox/sandbox.html index 975e6d8..4ec0232 100644 --- a/docs/codox/sandbox.html +++ b/docs/codox/sandbox.html @@ -1,6 +1,6 @@ -Sandbox

    Project

    Topics

    Namespaces

    Sandbox

    +Sandbox

    Project

    Topics

    Namespaces

    Sandbox

    Up to now I’ve been thinking of the Great Game as essentially an RPG with some sandbox-like elements; but I think it may be better to think of it as a sandbox game with some RPG like elements.

    Why?

    The core of the game is a world in which non-player characters have enough individual knowledge of the world and their immediate surroundings that they can sensibly answer questions like

    diff --git a/docs/codox/sexual-dimorphism.html b/docs/codox/sexual-dimorphism.html index 90c7153..07f0ce8 100644 --- a/docs/codox/sexual-dimorphism.html +++ b/docs/codox/sexual-dimorphism.html @@ -1,6 +1,6 @@ -Sexual dimorphism

    Project

    Topics

    Namespaces

    Sexual dimorphism

    +Sexual dimorphism

    Project

    Topics

    Namespaces

    Sexual dimorphism

    This essay is going to upset a lot of people, so let’s start with a statement of what it is about: it is an attempt to describe the systematically different behaviours of men and women, in sufficient detail that this can be represented by agents in a game world. It’s trying to allow as broad as possible a range of cultures to be represented, so when I’m talking about what I consider to be behaviours of particular cultures, I’ll say that.

    Of course, I’m writing this from the view point of an old white male. It’s not possible to write about these things from a totally neutral viewpoint, and every one of us will have prejudices.

    OK? Let’s start.

    diff --git a/docs/codox/the-great-game.agent.agent.html b/docs/codox/the-great-game.agent.agent.html index 7e659af..efd5f84 100644 --- a/docs/codox/the-great-game.agent.agent.html +++ b/docs/codox/the-great-game.agent.agent.html @@ -1,6 +1,6 @@ -the-great-game.agent.agent documentation

    Project

    Topics

    Namespaces

    Public Vars

    the-great-game.agent.agent

    Anything in the game world with agency

    ProtoAgent

    protocol

    An object which can act in the world

    members

    act

    (act actor world circle)

    Allow actor to do something in this world, in the context of this circle; return the new state of the actor if something was done, nil if nothing was done. Circle is expected to be one of

    +the-great-game.agent.agent documentation

    Project

    Topics

    Namespaces

    Public Vars

    the-great-game.agent.agent

    Anything in the game world with agency

    ProtoAgent

    protocol

    An object which can act in the world

    members

    act

    (act actor world circle)

    Allow actor to do something in this world, in the context of this circle; return the new state of the actor if something was done, nil if nothing was done. Circle is expected to be one of