diff --git a/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html b/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html index 35fec7a..d7412d3 100644 --- a/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html +++ b/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html @@ -1,6 +1,6 @@ -A Generic Planning Algorithm for craftworker NPCs

A Generic Planning Algorithm for craftworker NPCs

+A Generic Planning Algorithm for craftworker NPCs

A Generic Planning Algorithm for craftworker NPCs

Preamble

The Great Game requires a number of different crafts to be performed, both because the economy depends on the products of those crafts and to provide verisimilitude and set dressing. Some of those crafts, the relations between them, and the progression within them are set out in Populating a game world.

For the purposes of planning work, only Master craftspeople are considered.

diff --git a/docs/codox/API_Spec.html b/docs/codox/API_Spec.html index 72e1bf8..95affa0 100644 --- a/docs/codox/API_Spec.html +++ b/docs/codox/API_Spec.html @@ -1,6 +1,6 @@ -API Spec (unfinished)

API Spec (unfinished)

+API Spec (unfinished)

API Spec (unfinished)

If the Gossip system is ever to be deployed in practice at all, it will need to be deployed as a library add-on to someone else’s game, since in practice The Great Game will never be even nearly finished. The game engine already knows many of the things the Gossip system needs to know; that we need to define is an interface which allows Gossip, considered as a subsystem, to query the game engine.

My preference is still that Gossip should be written in a Lisp-like language - and, for now, in Clojure - simply because that is most comfortable to me. It needs bidirectional socket communication with the game engine, over which it sends either extensible data notation or JavaScript Object Notation, with a preference for the former.

Tracking what happens in the world

diff --git a/docs/codox/Appraisal.html b/docs/codox/Appraisal.html index a61a0a2..fb817c8 100644 --- a/docs/codox/Appraisal.html +++ b/docs/codox/Appraisal.html @@ -1,6 +1,6 @@ -Appraisal (unfinished)

Appraisal (unfinished)

+Appraisal (unfinished)

Appraisal (unfinished)

What is Appraisal

There’s an thing that all non player characters can do, which varies greatly from person to person, and which is of particular importance to merchants, and that is appraisal.

Each category of goods has different dimensions of quality. A sword may be evaluated, for example, on

diff --git a/docs/codox/Baking-the-world.html b/docs/codox/Baking-the-world.html index 387459e..7d37618 100644 --- a/docs/codox/Baking-the-world.html +++ b/docs/codox/Baking-the-world.html @@ -1,6 +1,6 @@ -Baking the world

Baking the world

+Baking the world

Baking the world

Wednesday, 8 May 2019

Devorgilla's Bridge in Dumfries, early fourteenth century

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.

diff --git a/docs/codox/Biomes_and_ecology.html b/docs/codox/Biomes_and_ecology.html index cc2c0f1..88d04ee 100644 --- a/docs/codox/Biomes_and_ecology.html +++ b/docs/codox/Biomes_and_ecology.html @@ -1,6 +1,6 @@ -Biomes and ecology (unfinished)

Biomes and ecology (unfinished)

+Biomes and ecology (unfinished)

Biomes and ecology (unfinished)

The motivation for this document was to explain the mulberry trees in the Tcha valley, and think about why Tchahua is especially a centre for the silk trade

Broader geography

The broader geography of the world is not a matter for this document, but TODO: there isn’t yet a document which usefully describes it, and there needs to be.

diff --git a/docs/codox/Building_on_microworld.html b/docs/codox/Building_on_microworld.html index 0f886ee..d3d807e 100644 --- a/docs/codox/Building_on_microworld.html +++ b/docs/codox/Building_on_microworld.html @@ -1,6 +1,6 @@ -Building on Microworld

Building on Microworld

+Building on Microworld

Building on Microworld

In Settling a Game World I intended that a world should be populated by setting agents - settlers - to explore the map and select places to settle according to particular rules. In the meantime, I’ve built MicroWorld, a rule driven cellular automaton which makes a reasonably good job of modelling human settlement. It works, and I now plan to use it, as detailed in this note; but there are issues.

First and foremost, it’s slow, and both processor and memory hungry. That means that at continent scale, a cell of one kilometre square is the minimum size which is really possible, which isn’t small enough to create a settlement map of the density that a game will need. Even with 1 km cells, even on the most powerful machines I have access to, a continent-size map will take many days to run.

Of course it would be possible to do a run at one km scale top identify areas which would support settlement, and then to do a run on a ten metre grid on each of those areas to more precisely plot settlement. That’s an idea which I haven’t yet explored, which might prove fruitful.

diff --git a/docs/codox/Canonical-dictionary.html b/docs/codox/Canonical-dictionary.html index 55a31d0..82eff50 100644 --- a/docs/codox/Canonical-dictionary.html +++ b/docs/codox/Canonical-dictionary.html @@ -1,6 +1,6 @@ -Canonical dictionary for this documentation

Canonical dictionary for this documentation

+Canonical dictionary for this documentation

Canonical dictionary for this documentation

Where a word is used in the documentation for The Great Game and its related projects, this file describes the canonical meaning of that word. This is because a lot of the concepts in play are messy and ambiguous, so that at times even I am confused by what I mean. The presence of this file is an acknowledment of this difficulty, and an implicit admission that not all the documentation is, at this stage anyway, consistent.

Actor

An actor is a thing which performs actions within the game world. Thus a tree is (almost certainly) not an actor, and things like sheep and rabbits that run about are probably not actors, but an animal which may pro-actively interact with the player character (such as a predator, or a beast of burden, or even a prey species which may flee) is an actor. In god mode, if implemented, the player can inhabit any actor within the game world.

diff --git a/docs/codox/Division_of_tasks_between_server_and_client.html b/docs/codox/Division_of_tasks_between_server_and_client.html index 9dff384..6be9582 100644 --- a/docs/codox/Division_of_tasks_between_server_and_client.html +++ b/docs/codox/Division_of_tasks_between_server_and_client.html @@ -1,6 +1,6 @@ -Division of tasks between server and client

Division of tasks between server and client

+Division of tasks between server and client

Division of tasks between server and client

An alternative nomentclature I may use for this dichotomy would be planner and performer; it would be the same dichotomy. ‘Planner’ and ‘server’ are synonyms; ‘performer’ and ‘client’ are synonyms.

What do I mean by the ‘server’?

There is something which manages game state and things like the gossip network, merchant network, and major world events. This something is almost certainly written in some form of Lisp; I’d prefer Clojure but I don’t think it’s performant enough so probably Common Lisp. This means that it has inevitable pauses for garbage collection. Underneath this is a database which handles persistent storage of game state, which is probably an SQL database and quite likely SQLite.

diff --git a/docs/codox/Dynamic-consequences.html b/docs/codox/Dynamic-consequences.html index c3e974a..48c278d 100644 --- a/docs/codox/Dynamic-consequences.html +++ b/docs/codox/Dynamic-consequences.html @@ -1,6 +1,6 @@ -On the consequences of a dynamic game environment for storytelling

On the consequences of a dynamic game environment for storytelling

+On the consequences of a dynamic game environment for storytelling

On the consequences of a dynamic game environment for storytelling

First, a framing disclaimer: in Racundra’s First Cruise, Arthur Ransome describes coming across a half built — and by the time he saw it, already obsolete — wooden sailing ship, in a Baltic forest. An old man was building it, by himself. He had been building it since he had been a young man. It’s clear that Ransome believed the ship would never be finished. It’s not clear whether the old man believed that it would, but nevertheless he was building it.

I will never build a complete version of The Great Game; it will probably never even be a playable prototype. It is a minor side-project of someone who

    diff --git a/docs/codox/Economy.html b/docs/codox/Economy.html index bef0905..4b2dc70 100644 --- a/docs/codox/Economy.html +++ b/docs/codox/Economy.html @@ -1,6 +1,6 @@ -Game world economy

    Game world economy

    +Game world economy

    Game world economy

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

    Primary producers

    Herdsfolk

    diff --git a/docs/codox/Further-reading.html b/docs/codox/Further-reading.html index daa3914..67968f4 100644 --- a/docs/codox/Further-reading.html +++ b/docs/codox/Further-reading.html @@ -1,6 +1,6 @@ -Further Reading (and watching)

    Further Reading (and watching)

    +Further Reading (and watching)

    Further Reading (and watching)

    Work by other people which is relevant to what I’m doing, and which I should study.

    ## Modelling the natural environment

      diff --git a/docs/codox/Game-engine-integration.html b/docs/codox/Game-engine-integration.html index 243a2c2..3919841 100644 --- a/docs/codox/Game-engine-integration.html +++ b/docs/codox/Game-engine-integration.html @@ -1,6 +1,6 @@ -Game-engine integration (unfinished)

      Game-engine integration (unfinished)

      +Game-engine integration (unfinished)

      Game-engine integration (unfinished)

      To build a game using these ideas we need a lot of things that are well understood and already implemented: rendering a world, moving models of characters in a world, and so on. This collection of technologies which allow us to realise an interactive realisation of a world is typically called a game engine.

      It’s my intention that the bits that I add to the mix should be open source in the hard sense of that phrase, fully free software released under GPL. They cannot therfore be directly linked to a proprietary game engine.

      But the current state of play is that the best and easiest to work with game engines are not open source; and while I could build a demo game using, for example, the Godot engine or jMonkeyEngine the result wouldn’t be as compelling and I believe the effort would be more considerable than if I use Unreal Engine, which is my current plan.

      diff --git a/docs/codox/Game_Play.html b/docs/codox/Game_Play.html index 5678e3c..9b1c490 100644 --- a/docs/codox/Game_Play.html +++ b/docs/codox/Game_Play.html @@ -1,6 +1,6 @@ -Game Play

      Game Play

      +Game Play

      Game Play

      The principles of game play which I’m looking for are a reaction against all I see as wrong in modern video games. So let’s set out what these are:

      1. diff --git a/docs/codox/Genetic-buildings.html b/docs/codox/Genetic-buildings.html index b84d686..517998b 100644 --- a/docs/codox/Genetic-buildings.html +++ b/docs/codox/Genetic-buildings.html @@ -1,6 +1,6 @@ -Genetic Buildings

        Genetic Buildings

        +Genetic Buildings

        Genetic Buildings

        Building selection based on location

        The objective of this note is to create a landscape with varied and believable buildings, with the minimum possible data storage per instance.

        Like plants, buildings will ‘grow’ from a seed which has northing and easting attributes. These locate a position on the map. Again, like trees, some aspects of the building type selector are location based. Aspects of the location which are relevant to building type are

        diff --git a/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html b/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html index d82fe47..ad7e010 100644 --- a/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html +++ b/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html @@ -1,6 +1,6 @@ -Gossip, scripted plot, and Johnny Silverhand

        Gossip, scripted plot, and Johnny Silverhand

        +Gossip, scripted plot, and Johnny Silverhand

        Gossip, scripted plot, and Johnny Silverhand

        I’ve been writing literally for years — since Voice acting considered harmful in 2015 — about game worlds in which the player speaks to non-player characters just by speaking the words they choose in their normal voice, and the non-player character replies using a pipeline that goes, essentially,

        1. Alexa/Siri style speech interpretation;
        2. diff --git a/docs/codox/MVP-Roadmap.html b/docs/codox/MVP-Roadmap.html index 25bb614..0a7fc7e 100644 --- a/docs/codox/MVP-Roadmap.html +++ b/docs/codox/MVP-Roadmap.html @@ -1,6 +1,6 @@ -Minimum Viable Product, and a road map

          Minimum Viable Product, and a road map

          +Minimum Viable Product, and a road map

          Minimum Viable Product, and a road map

          Right, I’m bogged down thinking about the immensity of what I want to build, so I’m achieving nothing. So the first thing I need to state is what the Minimum Viable Product is, and the second is to outline a rough road map which takes us forwards a few steps from the MVP.

          The core idea here is to have a game world in which you can just say anything you like to game characters, and they can say sensible things back.

          But actually, I know that speech to text can be reasonably effectively done; and I believe with a slightly lower degree of confidence that text to convincing speech can also be done.

          diff --git a/docs/codox/Modelling_democracy_and_morale.html b/docs/codox/Modelling_democracy_and_morale.html index c06f3d3..73bfb73 100644 --- a/docs/codox/Modelling_democracy_and_morale.html +++ b/docs/codox/Modelling_democracy_and_morale.html @@ -1,6 +1,6 @@ -The Red Company: modelling democracy and morale (unfinished)

          The Red Company: modelling democracy and morale (unfinished)

          +The Red Company: modelling democracy and morale (unfinished)

          The Red Company: modelling democracy and morale (unfinished)

          Background

          The Great Game exists as a project on two levels. One one level, it’s a framework for building algorithms to build much more vibrant, and thus enjoyable game worlds; at another level, it’s about building a particular world, in which I want to tell stories.

          The world in which I want to tell stories is a world which is based roughly on late bronze age to medieval Europe. It’s a world in which the region known as ‘The Coast’ — the southern littoral of the continent — had been a mostly-peaceful matrideic dispersed agrarian tribal society, which had been invaded some hundreds of years past by a warrior tribe with substantially better military technology.

          diff --git a/docs/codox/Modelling_trading_cost_and_risk.html b/docs/codox/Modelling_trading_cost_and_risk.html index b7f266b..21860b9 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 (unfinished)

          Modelling trading cost and risk (unfinished)

          +Modelling trading cost and risk (unfinished)

          Modelling trading cost and risk (unfinished)

          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/My-setting.html b/docs/codox/My-setting.html deleted file mode 100644 index 60a7047..0000000 --- a/docs/codox/My-setting.html +++ /dev/null @@ -1,6 +0,0 @@ - -My setting for the Great Game

          My setting for the Great Game

          -

          It should be evident that all the key ideas in The Great Game project would be applicable to games set in the historic past of our world, to games set in its present, or to games set in some imagined or forecast future; the ideas are intended to be, and I believe are, largely independent of setting.

          -

          Nevertheless I feel the need for a concrete setting to ground the development of ideas. I’ve chosen deliberately not to place that setting in the real world; although it’s broadly based on cultures from the late bronze age/early iron age mediterrainian.

          -
          \ No newline at end of file diff --git a/docs/codox/Naming-of-characters.html b/docs/codox/Naming-of-characters.html index 2342e2e..7d348c9 100644 --- a/docs/codox/Naming-of-characters.html +++ b/docs/codox/Naming-of-characters.html @@ -1,6 +1,6 @@ -Naming of Characters

          Naming of Characters

          +Naming of Characters

          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/NewCh1.html b/docs/codox/NewCh1.html deleted file mode 100644 index 09abe76..0000000 --- a/docs/codox/NewCh1.html +++ /dev/null @@ -1,13 +0,0 @@ - -Axiom

          Axiom

          -

          It is at once natural and yet extraordinary; at once familiar and yet always uncanny. Strange, yet still a part of the landscape of my life since earliest childhood. Circular, about three and a half metres across, of unknown depth; filled with clear water which neither rises in time of flood nor falls in time of drought, which is never warm in summer yet rarely freezes in winter. And its level is always, always, always, about a metre higher than the level of the burn which flows around three sides of the rock through which it rises.

          -

          The well is liminal: a gateway between the world of air and the world of water, the world of men and the underworld, the world of sunlight and the world of darkness. It is the place where – my mother always claimed – I was conceived; and for too many people whom I have known, the gateway between life and death, through which none pass twice.

          -

          It is the Cauld Well: the Cauld Well of Scotland. The Well of Sorrows. According to folklore, a place of blessings and ancient magic. According to historians, the last site in Britain where the Celtic gods were regularly worshipped.

          -

          And it is mine.

          -

          Tentatively Curious

          -

          Cryptography is the science of hiding things. The modern methods of hiding things are well known; they’re based on mathematical problems which are very hard to solve unless you already have a known starting point. For now, they work very well; but the problem with mathematical problems which are very hard to solve is that computers are steadily getting better and better at solving things.

          -

          Encryption is important; it is everywhere. It secures our communications, our wealth, our identity, our secrets. Many people – people with a great deal of money to spend – are very interested in the science of hiding things: in ensuring things are hidden, or else in finding things which others have hidden.

          -

          Unfortunately, the person who I wanted to find, in the spring of 2015 – who I had wanted to find since I’d lost her in the autumn of 2012 – could not be found by solving hard sums. In that spring, in fact, lots of things were hidden from me. Things which were hidden in plain sight, which were urgently important;

          -

          Like A. A. Milne’s King John, I am not a good man. Like him, I have my little ways. And very often no one speaks to me for days and days and days; although, to be fair, these past three years I hadn’t much encourage them to.

          -

          The university mostly understood that. My research – and to some degree my name – still brought in money; my papers were still well received. I no longer taught undergraduates, but I had a select group of excellent postgrads. And my colleagues accepted that I needed time to grieve.

          \ No newline at end of file diff --git a/docs/codox/Not_my_problem.html b/docs/codox/Not_my_problem.html index 94dd37d..fec3600 100644 --- a/docs/codox/Not_my_problem.html +++ b/docs/codox/Not_my_problem.html @@ -1,6 +1,6 @@ - Not my problem

          # Not my problem

          + Not my problem

          # Not my problem

          Introduction

          This document is essentially a catalogue of side-tracks which I do not have to go down when implementing The Great Game. Solved problems; or problems which are common to many other games, so if I don’t solve them someone else will. The object of doing this is to work down to a constrained set of problems which are genuinely things I’m trying to innovate, which I should focus on; which essentially come down to

            diff --git a/docs/codox/On-dying.html b/docs/codox/On-dying.html index 59e49d6..0aee2f8 100644 --- a/docs/codox/On-dying.html +++ b/docs/codox/On-dying.html @@ -1,6 +1,6 @@ -On Dying, and Injury

            On Dying, and Injury

            +On Dying, and Injury

            On Dying, and Injury

            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/On-sex-and-sexual-violence.html b/docs/codox/On-sex-and-sexual-violence.html index aaab08d..00f8de0 100644 --- a/docs/codox/On-sex-and-sexual-violence.html +++ b/docs/codox/On-sex-and-sexual-violence.html @@ -1,6 +1,6 @@ -On Sex, and Sexual Violence, in Games

            On Sex, and Sexual Violence, in Games

            +On Sex, and Sexual Violence, in Games

            On Sex, and Sexual Violence, in Games

            For me the purpose of games is to provide worlds in which players can explore moral actions, and the consequences of moral actions. Sexual violence is something that happens in the real world, and which happens, even within the real world, more frequently in areas of poor governance and open conflict; and those are areas in which there are important moral actions, and important moral consequences, so they are areas in which it is interesting to set games.

            It would be ludicrous to argue ‘sexual violence is wrong, therefore we should not represent it in games.’ Killing people is also wrong, yet it is extremely common in games. However, sexual violence — and in particular the representation of sexual violence — does pose some specific problems that need to be addressed.

            Firstly, sexual violence is extremely gendered. Yes, male people are sometimes subjected to sexual violence, but nevertheless the overwhelming majority of victims of sexual violence are female. Yes, female people are sometimes — extraordinarily rarely, but sometimes — perpetrators of sexual violence, but nevertheless perpetrators of sexual violence are almost exclusively male.

            diff --git a/docs/codox/Organic_Quests.html b/docs/codox/Organic_Quests.html index dc5d81c..4ec1afc 100644 --- a/docs/codox/Organic_Quests.html +++ b/docs/codox/Organic_Quests.html @@ -1,6 +1,6 @@ -Organic Quests

            Organic Quests

            +Organic Quests

            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 offers a typology of quests as follows:

            1. Kill quests
            2. diff --git a/docs/codox/Pathmaking.html b/docs/codox/Pathmaking.html index 62bc5c1..53e2127 100644 --- a/docs/codox/Pathmaking.html +++ b/docs/codox/Pathmaking.html @@ -1,6 +1,6 @@ -Pathmaking

              Pathmaking

              +Pathmaking

              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.

              NOTE: Work on this is being carried on in a separate library, Walkmap, q.v.

              Stages in creating routes between locations

              diff --git a/docs/codox/Populating-a-game-world.html b/docs/codox/Populating-a-game-world.html index 95844f1..b116480 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

              Populating a game world

              +Populating a game world

              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/Roadmap.html b/docs/codox/Roadmap.html index c0558fc..d126339 100644 --- a/docs/codox/Roadmap.html +++ b/docs/codox/Roadmap.html @@ -1,6 +1,6 @@ -Roadmap (obsolete)

              Roadmap (obsolete)

              +Roadmap (obsolete)

              Roadmap (obsolete)

              This document outlines a plan to move forward from where I am in June 2021.

              NOTE: this document has been superceded.

              JMonkeyEngine

              diff --git a/docs/codox/Sandbox.html b/docs/codox/Sandbox.html index 5e8679b..0dab2d2 100644 --- a/docs/codox/Sandbox.html +++ b/docs/codox/Sandbox.html @@ -1,6 +1,6 @@ -Sandbox

              Sandbox

              +Sandbox

              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

              @@ -31,11 +31,11 @@

              Most craft skills — especially in the learning phase — are not like this, and crafts which are sophisticated enough to be actually engaging are very hard to model in a game. Learning a craft is essentially, inherently, repetitive and dull, and if you take that repetition out of it you probably don’t have enough left to yield the feeling of mastery which would reward success; so it doesn’t seem to me that making craft roles playable should be a priority.

              Cruise control

              One of the most enjoyable aspects of The Witcher 3 — still my go-to game for ideas I want to improve on — is simply travelling through the world. Although fast travel is possible I find I rarely use it, and a journey which takes fifteen minutes of real world wall clock time can be enjoyable in and of itself. This is, of course, a credit to the beautiful way the world is realised.

              -

              (It’s worth noting that Kenshi, a game I’m coming to greatly admire, does not allow fast travel at all, but has an equivalent of ‘cruise control’ — you can set a destination and then accelerate time and simply watch as your characters journey).

              But nevertheless, in The Witcher 3, a decision was made to pack incident fairly densely — because players would find just travelling boring. This leads to a situation where peaceful villages exist two minutes travel from dangerous monsters or bandit camps, and the suspension of disbelief gets a little strained. Building a world big enough that a market simulation is believable means that for the individual, the travel time to a market where a particular desired good is likely to be cheaper becomes costly in itself. Otherwise, there’s no arbitrage between markets and no ecological niche for a merchant to fill. The journey time from market to market has to be several in-game days.

              An in-game day doesn’t have to be as long as a wall clock day, and, indeed, typically isn’t. But nevertheless, doing several game days of incident-free travel, even in beautiful scenery, is not going to be engaging — which implies a fast-travel mechanic.

              I don’t like fast travel, I find it a too-obvious breaking of immersion. Also, of course, one of the interesting things about a game in a merchant/outlaw ecosystem is the risk of interception on a journey. The Dragon Age series handled interrupted travel in ‘fast travel’ by randomly interrupting the loading screen you get when moving from location to location in Dragon Age’s patchwork worlds by dumping you into a tiny arena with enemies. That’s really, really bad — there’s no other way to say this. Everything about it shouts artifice.

              So I’m thinking of a different mechanism: one I’m calling cruise control.

              You set out on a task which will take a long time — such as a journey, but also such as any routine task. You’re shown either a ‘fast forward’ of your character carrying out this task, or a series of cinematic ‘shots along the way’. This depends, of course, on there being continuous renderable landscape between your departure and your destination, but there will be. This fast-forward proceeds at a substantially higher time gearing than normal game time — ten times as fast perhaps; we need it to, because as well as doing backgound scenery loading to move from one location to another, we’re also simulating lots of non-player agents’ actions in parts of the world where the player currently isn’t. So a ‘jump cut’ from one location to another isn’t going to work anyway.

              The player can interrupt ‘fast forward’ at any time. But also, the game itself may bring you out of fast forward when it anticipates that there may be action which requires decision — for example, when there are outlaws in the vicinity. And it will do this before the player’s party is under immediate attack — the player will have time to take stock of the situation and prepare appropriately. Finally, this will take place in the full open world; the player will have the option to choose not to enter the narrow defile, for example, to ask local people (if there are any) for any news of outlaw activity, or, if they are available, to send forward scouts.

              +

              (It’s worth noting that Kenshi, a game I’m coming to greatly admire, does not allow fast travel at all, but has an equivalent of ‘cruise control’ — you can set a destination and then accelerate time and simply watch as your characters journey).

              \ No newline at end of file diff --git a/docs/codox/Selecting_Character.html b/docs/codox/Selecting_Character.html index cb5d790..365ee92 100644 --- a/docs/codox/Selecting_Character.html +++ b/docs/codox/Selecting_Character.html @@ -1,6 +1,6 @@ -Selecting the Player Character

              Selecting the Player Character

              +Selecting the Player Character

              Selecting the Player Character

              Background

              Many computer role playing games, particularly older ones such as Neverwinter Nights, allow you to ‘design’ your player character from a fairly broad canvas. Race, class, attributes, gender and appearance are all selectable.

              Choice has eroded over time. For example the Dragon Age series, where you can chose between three races, two genders, and a small number of classes. In the Mass Effect trilogy, you play as Shepard, who is human and essentially a Fighter, but can be either male or female and whose appearance you can customise. You can play as either lawful good or chaotic neutral. In Cyberpunk 2077, you play as V, who is human, either male or female, essentially a Fighter, and chaotic neutral.

              diff --git a/docs/codox/Settling-a-game-world.html b/docs/codox/Settling-a-game-world.html index 4be912d..98052f5 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

              Settling a game world

              +Settling a game world

              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/Sexual-dimorphism.html b/docs/codox/Sexual-dimorphism.html index bfd002d..59393d8 100644 --- a/docs/codox/Sexual-dimorphism.html +++ b/docs/codox/Sexual-dimorphism.html @@ -1,6 +1,6 @@ -Sexual dimorphism

              Sexual dimorphism

              +Sexual dimorphism

              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/Simulated-genetics.html b/docs/codox/Simulated-genetics.html new file mode 100644 index 0000000..d5e9f2a --- /dev/null +++ b/docs/codox/Simulated-genetics.html @@ -0,0 +1,29 @@ + +Simulated Genetics

              Simulated Genetics

              +

              If we’re going to have a world with a multi-generational population of hundreds of thousands of procedurally generated characters, and we’re to persuasively represent each character as being related to others, then we have to have a mechanism for making children look reasonably like their parents, to have family resemblances among cousins, and so on. We need to do this at reasonably low data storage and algorithmic cost, firstly because we have to store all these characters, and secondly because (especially when the player approaches an urban centre), we may need to instantiate models for a lot of them in limited time.

              +

              This note discusses how this might be done.

              +

              The pseudo-genome

              +

              Suppose we have a binary vector of memory, such that when a ‘child’ was born to two parents, bits were taken at random from the parents’ chromosomes to populate the child’s genome – which is sort of, very roughly, what happens in actual biology – how big would that genome have to be? After all, the full data size of the human genetic code is enormous. But actually, we don’t need to simulate anything like so large. After all, all our genome needs to encode is morphology, and only sufficiently to enable the player to recognise and distinguish characters.

              +

              My hunch is that a 32 bit genome is sufficient, if we code it carefully. It allows for four billion distinct appearances to be encoded, which is way more than we need. So here’s how such a genome might be structured:

              + + + + + + + + + + + + + + +
              Field Bits Interpretation
              Ethnic type 4 Ethnic type. Most significant bits both indicate dark skin, with ??11 indicating dark skin/curly hair and ??01 indicating dark skin/straight hair
              Skin tone 3 Plus second-most significant bit from ethnic type (i.e. ??1?) as most significant bit. This means sixteen distinct tones, with the darkest tone of ‘pale skinned’ ethnicities just very slightly lighter than the palest tone of ‘dark skinned’ ethnicities.
              Freckles? 2 11 means freckles, any other value means no freckles. Freckles won’t be visible on very dark skin.
              Hair colour 3 Plus second-most significant bit from ethnic type (i.e. ??1?) as most significant bit. Least significant bit does not contribute to tone but indicates red tint. Thus eight distinct degrees of darkness from pale blond to black, plus red tint which can affect any degree of darkness.
              Eye colour 2 Plus second-most significant bit from ethnic type (i.e. ??1?) as most significant bit. Thus eight values: 000 blue; 001 hazel; 010111 shades of brown lighter->darker.
              Height 3 Height when adult; children will have a scaled proportion of their adult height, and the same height value in the genome will result in female body models 95% the height of an equivalent male body model. So 000 codes for 150mm, 111 codes for 200mm, with eight distinct values
              Gracility/Robustness 3 Slenderness to stockiness of skeleton/armature build, with 000 being very slender and 111 being very broad/heavy.
              Age-related change 3 People get white haired at different ages; some men go bald and some do not. The sons of the daughter of a bald man should have a chance of inheriting age-related baldness, although their mother won’t express that gene. So I’m allowing here for eight different profiles for age related change, although I’m not yet clear what the exact values would mean.
              +

              That’s twenty-two of our thirty-two bits, leaving 10 bits (1024 values) for face models; but actually, that 2048 distinct possible face models, because the morphology of female faces is different from the morphology of male faces. Although, again, we might encode gender into the genome, which would mean only bits left for face models, but still, 1024 distinct faces is plenty, especially as each face model would need to have its own aging model, so that characters would credibly age.

              +

              What’s not included in the genome

              +

              Things which are cultural are not included in the genome; things which are lifestyle related are not included in the genome. So, for example, gracility/robustness, is not the same as skinniness/fatness, which are mostly lifestyle/diet related rather than genetic. There are some occupations (e.g., blacksmith) where you’d be unlikely to be fat (but might be very robust). Also, the same character might grow fatter (or thinner) over time.

              +

              Similarly, hairstyle and beard-wearing are cultural (and occupational) rather than genetic, and closely related to choice of clothing. So while we do need to represent these things, they’re not things which should be represented in the genome.

              +

              Injury-related change – which would especially affect soldiers and outlaws especially but could affect any character – also needs to be encoded somehow (and may cause real problems), but this is also not a problem for the genome.

              +
              \ No newline at end of file diff --git a/docs/codox/Simulation-layers.html b/docs/codox/Simulation-layers.html index f1105e4..31e0354 100644 --- a/docs/codox/Simulation-layers.html +++ b/docs/codox/Simulation-layers.html @@ -1,6 +1,6 @@ -Simulation layers

              Simulation layers

              +Simulation layers

              Simulation layers

              In essence, the environment for The Great Game is broadly descended from games like the original Elite space trading game, and Sid Meier’s Pirates!, with some elements from political simulations like for example SimCity.

              That is to say there is

              An economy simulation

              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 064fadc..f4208d9 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

              The spread of knowledge in a large game world

              +The spread of knowledge in a large game world

              The spread of knowledge in a large game world

              Saturday, 26 April 2008

              Note

              This version of this essay has been adapted to use the code in the-great-game.gossip.news-items, q.v.. The original version of the essay is still available on my blog.

              diff --git a/docs/codox/Things_Voice_Interaction_Enables.html b/docs/codox/Things_Voice_Interaction_Enables.html index c7a5549..f6d27c1 100644 --- a/docs/codox/Things_Voice_Interaction_Enables.html +++ b/docs/codox/Things_Voice_Interaction_Enables.html @@ -1,6 +1,6 @@ -Things Voice Interaction Enables

              Things Voice Interaction Enables

              +Things Voice Interaction Enables

              Things Voice Interaction Enables

              Organic quest routing

              In a world in which you can talk to non-player characters, and in which non-player characters know the directions to things which are local to their homes (and some, travellers, will be able to give you routes to things further away), when you need to get to your next waypoint you can just ask for directions. That much is easy.

              But something much richer occurred to me.

              diff --git a/docs/codox/Uncanny_dialogue.html b/docs/codox/Uncanny_dialogue.html index 496f36f..bd58062 100644 --- a/docs/codox/Uncanny_dialogue.html +++ b/docs/codox/Uncanny_dialogue.html @@ -1,6 +1,6 @@ -The Uncanny Valley, and dynamically generated dialogue

              The Uncanny Valley, and dynamically generated dialogue

              +The Uncanny Valley, and dynamically generated dialogue

              The Uncanny Valley, and dynamically generated dialogue

              If the player is allowed to just speak arbitrary dialogue, then the conversation animation of the player character cannot be designed. If non-player characters are able to engage dynamically generated dialogue, in response to events in the game which are not scripted, then their conversation animation for those dialogues cannot be designed. So conversation animation must almost always be dynamically generated, largely from an augmented text of the speech act. With non-player characters, emotional content of a speech act can be generated by exactly the same process which generates the text. Extracting emotional content information from the player character’s voice may be more challenging.

              It would be possible to avoid animating the player character’s face by using a first-person camera. However, I don’t personally find this makes for a very engaging game experience.

              These thoughts were prompted by a very interesting video and Twitter thread about the perceived failings in the character animation system of Mass Effect Andromeda.

              diff --git a/docs/codox/Voice-acting-considered-harmful.html b/docs/codox/Voice-acting-considered-harmful.html index d8711d4..01c4a4e 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

              Voice acting considered harmful

              +Voice acting considered harmful

              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

              diff --git a/docs/codox/Worlds-and-flats.html b/docs/codox/Worlds-and-flats.html new file mode 100644 index 0000000..6cc6d8e --- /dev/null +++ b/docs/codox/Worlds-and-flats.html @@ -0,0 +1,39 @@ + +Worlds and flats [obsolete]

              Worlds and flats obsolete

              +

              This essay is from 2008, and is now at least partly obsolete; but there’s useful stuff in it which is worth holding onto.

              +

              Of Compartmented Worlds

              +

              Playing The Witcher has got me thinking again about an algorithm for rendering a world which I first thought of twenty-five years ago. Then, it was a hack for dealing with the fact that the computers of the day didn’t have much memory or horsepower. Now, it’s a hack for dealing with the fact that — when considered against the complexity of a world — the computers of today still don’t have enough memory and horsepower. Mind you, today I’m contemplating photorealistic scenes, whereas then simple line and wash would have been good enough, but…

              +

              The algorithm for rendering I’ll call ‘flats’. But before we get to discussing flats, lets discuss worlds. The world of The Witcher (and other games based on the Aurora engine) is composed of areas. One area is loaded into memory at a time; when the player reaches an area boundary, the area is unloaded in toto, and the next area loaded, also in toto. The result is a noticeable interruption in game play. There’s also, normally, a noticeable visual disjunction at the boundary; the new area uses a different ‘tileset’, which is to say, set of bits of scenery. When you look across a boundary, the scenery often appears different from what you find when you cross the boundary and arrive at the other side.

              +

              Finally, you can only cross boundaries at specific gateway points. For example, Chapter Four of The Witcher takes place in a continuous rural space composed of three main areas: the lakeside, the village, and the fields. Between the lakeside and the other two regions there’s a wooded escarpment, which provides some logical justification for the fact that there are actually only two places you can actually cross it — from the lake shore, either up the road to the village or else through a series of glades to the fields. But between the village and the fields there’s no such logic. There are a pair of gateposts, and you must cross between those gateposts — but the landscape appears continuous, with no visible barrier. It’s an artifact of the game engine.

              +

              So, how to deal with this?

              +

              My interest, let’s be frank, is in story telling; and the nature of story telling is moderately constrained plots. In computer mediated story telling the reader/player can and should be able to explore the plot in his own way, make his own choices, take his own path through the environment, encounter the elements of the plot as he encounters them on that path, and it’s the job of the story teller to make that engaging whatever path the reader takes. But if the reader chooses to ignore your hints and wander out of the area you’ve populated with plot altogether, there’s two things you can do. One is put up physical barriers which stop him (although the silly field fences in Chapter One of The Witcher do not count, as it’s obvious that Geralt could simply hurdle them; they are just another artifact).

              +

              Of Finite and Infinite Worlds

              +

              But an infinite world is not required for the sort of stories I’m interested in; the sort of stories I’m interested in take place in, at best, regions of infinite worlds. Just because I don’t choose to use all of it, of course, is not a reason that a world should not be very large.

              +

              There are plenty of fractal mathematical equations which map an infinite three dimensional surface with landscape like features. If such an equation gives you land heights, then altitude, steepness and orientation will give you soil type and vegetation cover. There is no need to store a whole world in order to be able to reproduce it exactly when the player follows the same route through it for a second time; it is sufficient to start with the same seed. So a world need not take up vast amounts of disk space for pre-mapped scenery; scenery need only be mapped as it comes in sight. This is fundamentally the trick used by Elite to pack a large, reproducible universe into less than 32K of RAM, and it still works today.

              +

              Of River Systems

              +

              However, there are reasons to prefer that a world be pre-mapped, at least at coarse grain. One example of why is river systems. It’s trivial that we render a river at the bottom of a valley, but it isn’t trivial to compute how wide and deep that river should be. To calculate that we have to explore the extent of the watershed upstream of any given point, and sum the rainfall on it, which in turn is a factor of exposure to prevailing airflow and the proximity of ocean to windward. It’s computable, but it’s much more efficient to compute it once and cache the results, especially since for any given river system it’s a recursive function.

              +

              Furthermore, rivers cause erosion, changing the landscape through which they pass, cutting gorges on steep slopes (especially if soft), building up flood-plains in flatter areas downstream. Some fractals are naturally extremely landscape-like, but it seems to me — better mathematicians might prove me wrong — to realistically render river systems requires some degree of post processing, and post processing which would be expensive to do repeatedly in realtime.

              +

              Of Human Settlement

              +

              Human settlement is a separate issue. Many years ago I wrote a program which modelled the spread of human settlement over a landscape.

              +

              Human settlement is not random. Human settlement follows rules and patterns. Pioneers settle in places which have a sufficient spread of resources to meet their year round needs; they settle near to easy routes from their parent settlement. Pastoralists need grazing land and water; they spread up river systems, but avoid marshy areas. They settle where there is open grazing, but often close to a forest edge for access to timber. Second wave settlers prefer to settle close to existing settlers, for mutual protection and help. Cereal growers join these settlements where the depth of soil is optimal for crops. As the settlement grows and pressure on land increases, the forest edge is cut back both for building material and to increase the available agricultural land. If a settlement fails, the forest may reclaim this land

              +

              Road networks develop. People travel between settlements by the easiest route — but the very fact a route is travelled makes it easier. A path gets cleared; later, people fill in boggy bits and bridge streams, to make their own passage easier or to encourage trade through their lands. Because as a road grows more important, so the settlements along it grow more important, and as the settlements along it grow more important so the roads between them grow more important. The road network, then, is a dynamic fractal which interacts with another dynamic fractal, the distribution of human settlement.

              +

              The program I wrote was a cellular automaton which modelled human settlement in only thirty states. It did a remarkably good job. Settlement would spread across a landscape; settlements in strategically beneficial areas would grow faster, develop temples and markets sooner, and thus become important foci of the roads system; other settlements would wax and wane, some falling into ruin; new waves of settlers might settle in slightly different areas.

              +

              More states would be better, give a richer, more subtle model, But this demonstrates that it’s easy to design a program which will settle a landscape in a realistic way automatically. Once again, though I think it can be done more realistically if it is precomputed and cached rather than if it is generated from the landscape fractal.

              +

              In summary: yes, I think it’s possible to have a near-infinite world which is satisfying and can be reproduced at will from a seed, but the stories I want to tell do not call for infinite worlds and if the world is finite I believe it can be made still more satisfyingly realistic by pre-computing and caching things like river systems, afforestation and settlement patterns. Either way, though, the world can be very large — much larger than the worlds of current near-photo-realistic games. The world of The Witcher, for example, is a few hundred hectares; I’m envisaging storing hundreds or thousands of square kilometres in similar data size and with a similar expenditure of artist’s effort.

              +

              Rendering, and the Flats idea

              +

              Rendering a convincing distant view in computer-generated virtual environment is hard. There’s an enormous amount of data in a distant view, and if the viewer is moving in real time it becomes computationally unaffordable, even on machines with a great deal of horsepower. Games typically work around this problem by either angling the camera downwards, or else rendering a high degree of atmospheric haze — it’s always slightly foggy — so there is never a distant horizon.

              +

              Movies shot in studios often have wonderful, detailed backgrounds to their sets. Vistas of far mountains and great cities… of course, the far mountains and great cities don’t exist in the set. They’re painted on large canvases called ‘flats’. The flats illusion depends on the camera not moving too much, because of parallax — nearer things should appear to move relative to further things, and on a flat they don’t.

              +

              But. But.

              +

              For a player moving in a computer game the field of view is quite restricted — it’s no more than thirty degrees, typically straight ahead as he moves. Parallax movements are less significant straight ahead. A single flat still isn’t going to work, but in many animated films a system of multiple flats is used, with the nearer flat moved relative to the further flat to give an illusion of parallax. This can work very well. Suppose one projects onto the world a hexagonal grid — it doesn’t have to be hexagonal, but I think that is likely to work best — with a cell size of about 100 metres (the exact cell size depends a bit on the speed of movement of the player, for reasons which will become apparent). Cells are grouped into metacells of seven cells (if square, then metacells of nine cells). For each cell, there are six inner flats. Each inner flat consists of a rendering from the centre of the cell of everything more than one cell distant, but less than five cells distant, over a 60 degree arc of view.

              +

              For a given area of the world the distant view doesn’t change very much. We don’t, therefore, have to compute a set of outer flats for every cell, just for every metacell. The outer flats each consist of a rendering of the scenery more than one whole metacell away, from the centre of the metacell. To render a scene, then, we first paint the outer flat for the metacell the player is in, in the direction the player is looking. Over that we paint the inner flat for the cell the player is in. Over that we render the actual objects in the adjacent cells which fall within the viewing area. Over that we render the objects in the current cell. Thus we only have to render in real time certainly no more objects than can already be rendered by systems which clip for distance either by angling the camera down or by using fog, and yet still manage a realistic distant view.

              +

              Rendering the Flats

              +

              OK, so when do the flats get rendered? After all, if you’re going to pre-render six full colour full screen resolution flats for every hundred metre cell in the world, then either your data volume is going to get enormous or your world is going to get pretty constrained — which was just what we were trying to get away from. And if you’re going to multiply that with flats rendered for every time of day and every weather condition — well, it’s not feasible.

              +

              You cannot realistically pre-render the flats, in my opinion. Or if you can, you’re going to have to give them so much real time post processing that you will lose the benefit. Pre-rendering the flats is not the idea. But if they are rendered in real time, where is the benefit…?

              +

              There’s a middle way. Running straight forward at top speed a player crosses a hundred metre cell in about a minute, during which to give an illusion of continuous movement at least nine hundred full screen frames must have rendered. But the flats don’t change in a minute. The flats don’t change in five minutes. They don’t need to. Even if rain clouds are sweeping across the landscape, it’s OK for the distant view still to be sunny five minutes after the rain reaches you, or vice versa. If you can render a high proportion of the detail in a view only once every nine hundred frames, you’ve saved a lot of processing.

              +

              So there is a continuous background process running which renders flats. It does it all the time. It prioritises making sure that a flat exists for every direction the player may look in in the next minute — that is, every direction from the cells and metacells he’s currently heading towards. Having done that, it renders flats for cells to either side which he might turn to. It maintains in memory a small stock of flats from recently visited cells, so that if the player turns back they don’t have to be repainted in a hurry; and if a flat is more than about five minutes — 4,500 frames — old, it may repaint it to update time-of-day lighting or weather effects.

              +

              Obviously, quite a lot of the time the join between two adjacent flats will be in view. I don’t see this as a problem. Just naturally, the rendering of the flats should essentially form segments of a hoop, so the join between two adjacent flats should not be perceptible.

              +

              Artifacts

              +

              Inevitably, there will be undesired artifacts of this system. Significantly, mobile objects — ‘non-player characters’, the avatars of other players, monsters and computer mediated creatures in the landscape — more than two cells away will not be visible. The flat is static, so it can’t have moving characters on it. There may be some algorithmic way round this, since one hundred and fifty metres away is rather close for people to suddenly vanish; but it is not a problem I have a solution for.

              +

              Again, if the player is looking sideways as they cross a metacell boundary, there will be a jarring sudden shift in parallax. I acknowledge that and think it just can’t be helped; that the benefits in terms of quality of view for given computer power, will render it acceptable.

              +
              \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.agent.agent.html b/docs/codox/cc.journeyman.the-great-game.agent.agent.html deleted file mode 100644 index f79e82a..0000000 --- a/docs/codox/cc.journeyman.the-great-game.agent.agent.html +++ /dev/null @@ -1,24 +0,0 @@ - -cc.journeyman.the-great-game.agent.agent documentation

              cc.journeyman.the-great-game.agent.agent

              Anything in the game world with agency; primarily but not exclusively characters.

              -

              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

              -
                -
              • :active - actors within visual/audible range of the player character;
              • -
              • :pending - actors not in the active circle, but sufficiently close to it that they may enter the active circle within a short period;
              • -
              • :background - actors who are active in the background in order to handle trade, news, et cetera;
              • -
              • :other - actors who are not members of any other circle.
              • -
              -

              The act method must not have side effects; it must only return a new state. If the actor’s intention is to seek to change the state of something else in the game world, it must add a representation of that intention to the sequence which will be returned by its pending-intentions method.

              -

              hungry?

              (hungry? actor world circle)

              True if this actor is hungry and has no immediate access to food.

              -

              pending-intentions

              (pending-intentions actor)

              Returns a sequence of effects an actor intends, as a consequence of acting.

              -

              pending-scheduled-action?

              (pending-scheduled-action? actor world circle)

              True if there is a plan in this actor’s schedule which should be activated now. NOTE THAT plans in the daily schedule are NOT activated when in circles :background or :other

              -

              plan-fight-or-flight

              (plan-fight-or-flight actor world circle)

              Return a plan to resolve any active threat to this actor in this world.

              -

              plan-find-food

              (plan-find-food actor workd circle)

              Return a plan to find this actor food in this world.

              -

              plan-find-rest

              (plan-find-rest actor workd circle)

              Return a plan to find this actor a safe place to rest, or if in one, to actually rest, in this world.

              -

              plan-goal

              (plan-goal actor world circle)

              Return a plan to advance this actor towards their personal objective, in this world, or nil for default actors with no objective.

              -

              plan-scheduled-action

              (plan-scheduled-action actor workd circle)

              Return a plan taken from the schedule of this actor for the current date and time, if any, else nil.

              -

              schedule

              (schedule actor)

              Return a map of scheduled actions for this actor. TODO: work out the detailed format!

              -

              threatened?

              (threatened? actor world circle)

              True if this actor is threatened in this world.

              -

              tired?

              (tired? actor world circle)

              True if this actor needs rest.

              -
              \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.agent.schedule.html b/docs/codox/cc.journeyman.the-great-game.agent.schedule.html index 6c9d4b0..ebdd84e 100644 --- a/docs/codox/cc.journeyman.the-great-game.agent.schedule.html +++ b/docs/codox/cc.journeyman.the-great-game.agent.schedule.html @@ -1,5 +1,5 @@ -cc.journeyman.the-great-game.agent.schedule documentation

              cc.journeyman.the-great-game.agent.schedule

              Schedules of plans for actors in the game, in order that they may have daily and seasonal patterns of behaviour.

              +cc.journeyman.the-great-game.agent.schedule documentation

              cc.journeyman.the-great-game.agent.schedule

              Schedules of plans for actors in the game, in order that they may have daily and seasonal patterns of behaviour.

              plan-scheduled-action

              (plan-scheduled-action actor world circle)

              TODO: write docs

              \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.buildings.module.html b/docs/codox/cc.journeyman.the-great-game.buildings.module.html index ba1e846..cbd7288 100644 --- a/docs/codox/cc.journeyman.the-great-game.buildings.module.html +++ b/docs/codox/cc.journeyman.the-great-game.buildings.module.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.buildings.module documentation

              cc.journeyman.the-great-game.buildings.module

              A module of a building; essentially something like a portacabin, which can be assembled together with other modules to make a complete building.

              +cc.journeyman.the-great-game.buildings.module documentation

              cc.journeyman.the-great-game.buildings.module

              A module of a building; essentially something like a portacabin, which can be assembled together with other modules to make a complete building.

              Modules need to include

              1. Ground floor modules, having external doors;
              2. diff --git a/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html b/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html deleted file mode 100644 index 95c6f4c..0000000 --- a/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html +++ /dev/null @@ -1,39 +0,0 @@ - -cc.journeyman.the-great-game.buildings.rectangular documentation

                cc.journeyman.the-great-game.buildings.rectangular

                Build buildings with a generally rectangular floow plan.

                -

                Motivations

                -

                Right, the idea behind this namespace is many fold.

                -
                  -
                1. To establish the broad principle of genetic buildings, by creating a function which reproducibly creates reproducible buildings at specified locations, such that different buildings are credibly varied but a building at a specified location is always (modulo economic change) the same.
                2. -
                3. Create good rectangular buildings, and investigate whether a single function can be used to create buildings of more than one family (e.g. can it produce flat roofed, north African style, mud brick houses as well as pitch roofed, half timbered northern European houses?)
                4. -
                5. Establish whether, in my current state of fairly severe mental illness, I can actually produce any usable code at all.
                6. -
                -

                Key factors in the creation of a building

                -

                Holding

                -

                Every building is on a holding, and, indeed, what I mean by ‘building’ here may well turn out to be ’the collection of all the permanent structures on a holding. A holding is a polygonal area of the map which does not intersect with any other holding, but for the time being we’ll make the simplifying assumption that every holding is a rectangular strip, and that ‘urban’ holdings are of a reasonably standard width (see Viking-period York) and length. Rural holdings (farms, ?wood lots) may be much larger.

                -

                Terrain

                -

                A building is made of the stuff of the place. In a forest, buildings will tend to be wooden; in a terrain with rocky outcrops – normally found on steep slopes – stone. On the flat lands where there’s river mud, of brick, cob, or wattle and daub. So to build a building we need to know the terrain. Terrain can be inferred from location but in practice this will be computationally expensive, so we’ll pass terrain in as an argument to the build function.

                -

                For the time being we’ll pass it in simply as a keyword from a defined set of keywords; later it may be a more sophisticated data structure.

                -

                Culture

                -

                People of different cultures build distinctively different buildings, even when using the same materials. So, in our world, a Japanese wooden house looks quite different from an Anglo Saxon stave house which looks quite different from a Canadian log cabin, even though the materials are much the same and the tools available to build with are not much different.

                -

                Culture can affect not just the overall shape of a building but also its finish and surface detail. For example, in many places in England, stone buildings are typically left bare; in rural Scotland, typically painted white or in pastel shades; in Ireland, often quite vivid colours.

                -

                People may also show religious or cultural symbols on their buildings.

                -

                For all these reasons, we need to know the culture of the occupant when creating a building. Again, this will initially be passed in as a keyword.

                -

                Craft

                -

                People in the game world have a craft, and some crafts will require different features in the building. In the broadly late-bronze-age-to medieval period within which the game is set, residence and workplace are for most people pretty much the same.

                -

                So a baker needs an oven, a smith a forge, and so on. All crafts who do some degree retail trade will want a shop front as part of the ground floor of their dwelling. Merchants and bankers will probably have houses that are a bit more showy than others.

                -

                Whether the ‘genetic buildings’ idea will ever really produce suitable buildings for aristons I don’t know; it seems more likely that significant strongholds (of which there will be relatively few) should all be hand modelled rather than procedurally generated.

                -

                *building-families*

                dynamic

                Families of buildings.

                -

                Each family has

                -
                  -
                • terrain types to which it is appropriate;
                • -
                • crafts to which it is appropriate;
                • -
                • cultures to which it is appropriate.
                • -
                -

                Each generated building will be of one family, and will comprise modules taken only from that family.

                -

                *crafts*

                dynamic

                Crafts which affect building types in the game. See Populating a game world. TODO: placeholder

                -

                *cultures*

                dynamic

                Cultures which affect building families. TODO: placeholder

                -

                *terrain-types*

                dynamic

                Types of terrain which affect building families. TODO: This is a placeholder; a more sophisticated model will be needed.

                -

                build!

                (build! holding terrain culture craft size)

                Builds a building, and returns a data structure which represents it. In building the building, it adds a model of the building to the representation of the world, so it does have a side effect.

                -

                building-family

                (building-family terrain culture craft gene)

                A building family is essentially a collection of models of building modules which can be assembled to create buildings of a particular structural and architectural style.

                -
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.cloverage.html b/docs/codox/cc.journeyman.the-great-game.cloverage.html deleted file mode 100644 index 8f847a4..0000000 --- a/docs/codox/cc.journeyman.the-great-game.cloverage.html +++ /dev/null @@ -1,6 +0,0 @@ - -cc.journeyman.the-great-game.cloverage documentation

                cc.journeyman.the-great-game.cloverage

                TODO: write docs

                -

                documented-project-dir

                TODO: write docs

                -

                opts

                TODO: write docs

                -
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html b/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html index 050de15..9431123 100644 --- a/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html +++ b/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.gossip.gossip documentation

                cc.journeyman.the-great-game.gossip.gossip

                Interchange of news events between gossip agents.

                +cc.journeyman.the-great-game.gossip.gossip documentation

                cc.journeyman.the-great-game.gossip.gossip

                Interchange of news events between gossip agents.

                Note that habitual travellers are all gossip agents; specifically, at this stage, that means merchants. When merchants are moved we also need to update the location of the gossip with the same key.

                Innkeepers are also gossip agents but do not typically move.

                dialogue

                (dialogue enquirer respondent world)

                Dialogue between an enquirer and an agent in this world; returns a map identical to enquirer except that its :gossip collection may have additional entries.

                diff --git a/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html b/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html index 25f2550..8e65b18 100644 --- a/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html +++ b/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.gossip.news-items documentation

                cc.journeyman.the-great-game.gossip.news-items

                Using news items (propositions) to transfer knowledge between gossip agents.

                +cc.journeyman.the-great-game.gossip.news-items documentation

                cc.journeyman.the-great-game.gossip.news-items

                Using news items (propositions) to transfer knowledge between gossip agents.

                Status

                What is here is essentially working. It’s not, however, working with the rich data objects which will be needed, and it’s not yet nearly efficient enough, but it allows knowledge to propagate through the world procedurally, at a rate limited by the speed of movement of the gossip agents.

                Discussion

                diff --git a/docs/codox/cc.journeyman.the-great-game.holdings.holding.html b/docs/codox/cc.journeyman.the-great-game.holdings.holding.html deleted file mode 100644 index a661aab..0000000 --- a/docs/codox/cc.journeyman.the-great-game.holdings.holding.html +++ /dev/null @@ -1,6 +0,0 @@ - -cc.journeyman.the-great-game.holdings.holding documentation

                cc.journeyman.the-great-game.holdings.holding

                TODO: write docs

                -

                ProtoHolding

                protocol

                members

                building-origin

                (building-origin holding)

                Returns an oriented location - normally the right hand end of the frontage, for an urban holding - from which buildings on the holding should be built.

                -

                frontage

                (frontage holding)

                Returns a sequence of two locations representing the edge of the polygon which defines this holding which is considered to be the front.

                -
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.location.location.html b/docs/codox/cc.journeyman.the-great-game.location.location.html index f843370..baa26fd 100644 --- a/docs/codox/cc.journeyman.the-great-game.location.location.html +++ b/docs/codox/cc.journeyman.the-great-game.location.location.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.location.location documentation

                cc.journeyman.the-great-game.location.location

                TODO: write docs

                +cc.journeyman.the-great-game.location.location documentation

                cc.journeyman.the-great-game.location.location

                TODO: write docs

                ProtoLocation

                protocol

                members

                altitude

                (altitude location)

                Return the absolute altitude of this location, which may be different from the terrain height at this location, if, for example, the location is underground or on an upper floor.

                easting

                (easting location)

                Return the easting of this location

                northing

                (northing location)

                Return the northing of this location

                diff --git a/docs/codox/cc.journeyman.the-great-game.lore.digester.html b/docs/codox/cc.journeyman.the-great-game.lore.digester.html index acccd4e..e375cba 100644 --- a/docs/codox/cc.journeyman.the-great-game.lore.digester.html +++ b/docs/codox/cc.journeyman.the-great-game.lore.digester.html @@ -1,4 +1,4 @@ -cc.journeyman.the-great-game.lore.digester documentation

                cc.journeyman.the-great-game.lore.digester

                TODO: write docs

                +cc.journeyman.the-great-game.lore.digester documentation

                cc.journeyman.the-great-game.lore.digester

                TODO: write docs

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.markets.html b/docs/codox/cc.journeyman.the-great-game.merchants.markets.html index 7e5f4f2..e8a056e 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.markets.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.markets.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.merchants.markets documentation

                cc.journeyman.the-great-game.merchants.markets

                Adjusting quantities and prices in markets.

                +cc.journeyman.the-great-game.merchants.markets documentation

                cc.journeyman.the-great-game.merchants.markets

                Adjusting quantities and prices in markets.

                adjust-quantity-and-price

                (adjust-quantity-and-price world city commodity)

                Adjust the quantity of this commodity currently in stock in this city of this world. Return a fragmentary world which can be deep-merged into this world.

                new-price

                (new-price old stock supply demand)

                If stock is greater than the maximum of supply and demand, then there is surplus and old price is too high, so shold be reduced. If lower, then it is too low and should be increased.

                run

                (run world)

                Return a world like this world, with quantities and prices in markets updated to reflect supply and demand.

                diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html b/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html index 8b40995..b6d2926 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.merchants.merchant-utils documentation

                cc.journeyman.the-great-game.merchants.merchant-utils

                Useful functions for doing low-level things with merchants.

                +cc.journeyman.the-great-game.merchants.merchant-utils documentation

                cc.journeyman.the-great-game.merchants.merchant-utils

                Useful functions for doing low-level things with merchants.

                add-known-prices

                (add-known-prices merchant world)

                Add the current prices at this merchant’s location in the world to a new cache of known prices, and return it.

                add-stock

                (add-stock a b)

                Where a and b are both maps all of whose values are numbers, return a map whose keys are a union of the keys of a and b and whose values are the sums of their respective values.

                burden

                (burden merchant world)

                The total weight of the current cargo carried by this merchant in this world.

                diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html b/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html index a0cd389..04c53b4 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html @@ -1,5 +1,5 @@ -cc.journeyman.the-great-game.merchants.merchants documentation

                cc.journeyman.the-great-game.merchants.merchants

                Trade planning for merchants, primarily.

                +cc.journeyman.the-great-game.merchants.merchants documentation

                cc.journeyman.the-great-game.merchants.merchants

                Trade planning for merchants, primarily.

                run

                (run world)

                Return a partial world based on this world, but with each merchant moved.

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.planning.html b/docs/codox/cc.journeyman.the-great-game.merchants.planning.html index 2e78b37..d7c2427 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.planning.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.planning.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.merchants.planning documentation

                cc.journeyman.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.

                +cc.journeyman.the-great-game.merchants.planning documentation

                cc.journeyman.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.

                augment-plan

                (augment-plan merchant world plan)

                Augment this plan constructed in this world for this merchant with the :quantity of goods which should be bought and the :expected-profit of the trade.

                Returns the augmented plan.

                generate-trade-plans

                (generate-trade-plans merchant world commodity)

                Generate all possible trade plans for this merchant and this commodity in this world.

                diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html b/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html index 2e059f2..bdacf8c 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.merchants.strategies.simple documentation

                cc.journeyman.the-great-game.merchants.strategies.simple

                Default trading strategy for merchants.

                +cc.journeyman.the-great-game.merchants.strategies.simple documentation

                cc.journeyman.the-great-game.merchants.strategies.simple

                Default trading strategy for merchants.

                The simple strategy buys a single product in the local market if there is one which can be traded profitably, trades it to the chosen target market, and sells it there. If there is no commodity locally which can be traded profitably, moves towards home with no cargo. If at home and no commodity can be traded profitably, does not move.

                move-merchant

                (move-merchant merchant world)

                Handle general en route movement of this merchant in this world; return a (partial or full) world like this world but in which the merchant may have been moved ot updated.

                plan-and-buy

                (plan-and-buy merchant world)

                Return a world like this world, in which this merchant has planned a new trade, and bought appropriate stock for it. If no profitable trade can be planned, the merchant is simply moved towards their home.

                diff --git a/docs/codox/cc.journeyman.the-great-game.objects.character.html b/docs/codox/cc.journeyman.the-great-game.objects.character.html index 622eed6..5bf31d2 100644 --- a/docs/codox/cc.journeyman.the-great-game.objects.character.html +++ b/docs/codox/cc.journeyman.the-great-game.objects.character.html @@ -1,4 +1,4 @@ -cc.journeyman.the-great-game.objects.character documentation

                cc.journeyman.the-great-game.objects.character

                TODO: write docs

                +cc.journeyman.the-great-game.objects.character documentation

                cc.journeyman.the-great-game.objects.character

                TODO: write docs

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.objects.container.html b/docs/codox/cc.journeyman.the-great-game.objects.container.html index a6f8489..21b1266 100644 --- a/docs/codox/cc.journeyman.the-great-game.objects.container.html +++ b/docs/codox/cc.journeyman.the-great-game.objects.container.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.objects.container documentation

                cc.journeyman.the-great-game.objects.container

                TODO: write docs

                +cc.journeyman.the-great-game.objects.container documentation

                cc.journeyman.the-great-game.objects.container

                TODO: write docs

                ProtoContainer

                protocol

                members

                contents

                (contents container)

                Return a sequence of the contents of this container, or nil if empty.

                is-empty?

                (is-empty? container)

                Return true if this container is empty, else false.

                -
                \ No newline at end of file +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.objects.game-object.html b/docs/codox/cc.journeyman.the-great-game.objects.game-object.html index 7800e98..64ead8c 100644 --- a/docs/codox/cc.journeyman.the-great-game.objects.game-object.html +++ b/docs/codox/cc.journeyman.the-great-game.objects.game-object.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.objects.game-object documentation

                cc.journeyman.the-great-game.objects.game-object

                Anything at all in the game world

                +cc.journeyman.the-great-game.objects.game-object documentation

                cc.journeyman.the-great-game.objects.game-object

                Anything at all in the game world

                ProtoObject

                protocol

                An object in the world

                members

                id

                (id object)

                Returns the unique id of this object.

                reify-object

                (reify-object object)

                Adds this object to the global object list. If the object has a non-nil value for its id method, keys it to that id - but if the id value is already in use, throws a hard exception. Returns the id to which the object is keyed in the global object list.

                diff --git a/docs/codox/cc.journeyman.the-great-game.playroom.html b/docs/codox/cc.journeyman.the-great-game.playroom.html index b6c3abe..5e176fc 100644 --- a/docs/codox/cc.journeyman.the-great-game.playroom.html +++ b/docs/codox/cc.journeyman.the-great-game.playroom.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.playroom documentation

                cc.journeyman.the-great-game.playroom

                TODO: write docs

                +cc.journeyman.the-great-game.playroom documentation

                cc.journeyman.the-great-game.playroom

                TODO: write docs

                app

                TODO: write docs

                init

                (init)

                TODO: write docs

                simple-update

                (simple-update tpf)

                TODO: write docs

                diff --git a/docs/codox/cc.journeyman.the-great-game.proving.core.html b/docs/codox/cc.journeyman.the-great-game.proving.core.html index 3c79395..6d9d500 100644 --- a/docs/codox/cc.journeyman.the-great-game.proving.core.html +++ b/docs/codox/cc.journeyman.the-great-game.proving.core.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.proving.core documentation

                cc.journeyman.the-great-game.proving.core

                Phase one of ‘Baking the World

                +cc.journeyman.the-great-game.proving.core documentation

                cc.journeyman.the-great-game.proving.core

                Phase one of ‘Baking the World

                *life-goals*

                dynamic

                TODO: This definitely doesn’t belong here, and will be moved.

                get-biome-map

                (get-biome-map height-map)(get-biome-map height-map _rainfall-map)

                Given this height-map (a monochrome raster) and optionally this rainfall-map (also a monochrome raster), return a biome map (a microworld style world tagged with vegetation, etc, data).

                get-drainage-map

                (get-drainage-map height-map)(get-drainage-map height-map _rainfall-map)

                Given this height-map (a monochrome raster) and optionally this rainfall-map (also a monochrome raster), return a drainage map (a microworld style world tagged with drainage data).

                diff --git a/docs/codox/cc.journeyman.the-great-game.proving.sketches.html b/docs/codox/cc.journeyman.the-great-game.proving.sketches.html index 50925fc..936d86b 100644 --- a/docs/codox/cc.journeyman.the-great-game.proving.sketches.html +++ b/docs/codox/cc.journeyman.the-great-game.proving.sketches.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.proving.sketches documentation

                cc.journeyman.the-great-game.proving.sketches

                TODO: write docs

                +cc.journeyman.the-great-game.proving.sketches documentation

                cc.journeyman.the-great-game.proving.sketches

                Code that’s useful for exploring, but probably not part of the final product, and if it is, will end up somewhere else.

                couple-cell?

                (couple-cell? c)

                TODO: write docs

                -

                happy-cell?

                (happy-cell? c)

                True if all NPCs at c (assumed to be a MicroWorld-style cell) are of a happy disposition.

                -
                \ No newline at end of file +

                happy-cell?

                (happy-cell? c)

                True if all NPCs at c (assumed to be a MicroWorld-style cell) are of a happy disposition.

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.time.html b/docs/codox/cc.journeyman.the-great-game.time.html index 184bd3b..8fb540c 100644 --- a/docs/codox/cc.journeyman.the-great-game.time.html +++ b/docs/codox/cc.journeyman.the-great-game.time.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.time documentation

                cc.journeyman.the-great-game.time

                TODO: write docs

                +cc.journeyman.the-great-game.time documentation

                cc.journeyman.the-great-game.time

                TODO: write docs

                canonical-ordering-of-houses

                The canonical ordering of religious houses.

                date-string

                (date-string game-time)

                Return a correctly formatted date for this game-time in the calendar of the Great Place.

                day

                (day game-time)

                Day of the eight-day week represented by this game-time.

                diff --git a/docs/codox/cc.journeyman.the-great-game.utils.html b/docs/codox/cc.journeyman.the-great-game.utils.html index 4c3006c..e13d5bd 100644 --- a/docs/codox/cc.journeyman.the-great-game.utils.html +++ b/docs/codox/cc.journeyman.the-great-game.utils.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.utils documentation

                cc.journeyman.the-great-game.utils

                TODO: write docs

                +cc.journeyman.the-great-game.utils documentation

                cc.journeyman.the-great-game.utils

                TODO: write docs

                cyclic?

                (cyclic? route)

                True if two or more elements of route are identical

                deep-merge

                (deep-merge & maps)

                inc-or-one

                (inc-or-one val)

                If this val is a number, return that number incremented by one; otherwise, return 1. TODO: should probably be in utils.

                diff --git a/docs/codox/cc.journeyman.the-great-game.world.heightmap.html b/docs/codox/cc.journeyman.the-great-game.world.heightmap.html index 59f8889..438d843 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.heightmap.html +++ b/docs/codox/cc.journeyman.the-great-game.world.heightmap.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.world.heightmap documentation

                cc.journeyman.the-great-game.world.heightmap

                Functions dealing with the tessellated multi-layer heightmap.

                +cc.journeyman.the-great-game.world.heightmap documentation

                cc.journeyman.the-great-game.world.heightmap

                Functions dealing with the tessellated multi-layer heightmap.

                *base-map*

                dynamic

                TODO: write docs

                *noise-map*

                dynamic

                TODO: write docs

                excerpt-grid

                (excerpt-grid grid x-offset y-offset width height)

                Return that section of this grid where the :x co-ordinate of each cell is greater than or equal to this x-offset, the :y co-ordinate is greater than or equal to this y-offset, whose width is not greater than this width, and whose height is not greater than this height.

                diff --git a/docs/codox/cc.journeyman.the-great-game.world.location.html b/docs/codox/cc.journeyman.the-great-game.world.location.html index d42ed16..5a11cfb 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.location.html +++ b/docs/codox/cc.journeyman.the-great-game.world.location.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.world.location documentation

                cc.journeyman.the-great-game.world.location

                Functions dealing with location in the world.

                +cc.journeyman.the-great-game.world.location documentation

                cc.journeyman.the-great-game.world.location

                Functions dealing with location in the world.

                distance-between

                (distance-between location-1 location-2)

                TODO: write docs

                get-coords

                (get-coords location)

                Return the coordinates in the game world of location, which may be 1. A coordinate pair in the format {:x 5 :y 32}; 2. A location, as discussed above; 3. Any other gameworld object, having a :location property whose value is one of the above.

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.world.mw.html b/docs/codox/cc.journeyman.the-great-game.world.mw.html index dc056b8..c85cd92 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.mw.html +++ b/docs/codox/cc.journeyman.the-great-game.world.mw.html @@ -1,4 +1,4 @@ -cc.journeyman.the-great-game.world.mw documentation

                cc.journeyman.the-great-game.world.mw

                Functions dealing with building a great game world from a MicroWorld world.

                +cc.journeyman.the-great-game.world.mw documentation

                cc.journeyman.the-great-game.world.mw

                Functions dealing with building a great game world from a MicroWorld world.

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.world.routes.html b/docs/codox/cc.journeyman.the-great-game.world.routes.html index bb8fdab..e353b4f 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.routes.html +++ b/docs/codox/cc.journeyman.the-great-game.world.routes.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.world.routes documentation

                cc.journeyman.the-great-game.world.routes

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

                +cc.journeyman.the-great-game.world.routes documentation

                cc.journeyman.the-great-game.world.routes

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

                find-route

                (find-route world-or-routes from to)

                Find a single route from from to to in this world-or-routes, which may be either a world as defined in the-great-game.world.world or else a sequence of tuples of keywords.

                find-routes

                (find-routes routes from)(find-routes routes from to)(find-routes routes from to steps)

                Find routes from among these routes from from; if to is supplied, to to, by breadth-first search.

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.world.run.html b/docs/codox/cc.journeyman.the-great-game.world.run.html deleted file mode 100644 index 9e6bfe8..0000000 --- a/docs/codox/cc.journeyman.the-great-game.world.run.html +++ /dev/null @@ -1,3 +0,0 @@ - -cc.journeyman.the-great-game.world.run documentation

                cc.journeyman.the-great-game.world.run

                Run the whole simulation

                init

                (init)(init config)

                TODO: write docs

                run

                (run world)(run world date)

                The pipeline to run the simulation each game day. Returns a world like this world, with all the various active elements updated. The optional date argument, if supplied, is set as the :date of the returned world.

                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.world.world.html b/docs/codox/cc.journeyman.the-great-game.world.world.html index 8bac4b6..931e1b3 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.world.html +++ b/docs/codox/cc.journeyman.the-great-game.world.world.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.world.world documentation

                cc.journeyman.the-great-game.world.world

                Access to data about the world

                +cc.journeyman.the-great-game.world.world documentation

                cc.journeyman.the-great-game.world.world

                Access to data about the world

                actual-price

                (actual-price world commodity city)

                Find the actual current price of this commodity in this city given this world. NOTE that merchants can only know the actual prices in the city in which they are currently located.

                default-world

                A basic world for testing concepts

                run

                (run world)(run world date)

                Return a world like this world with only the :date to this date (or id date not supplied, the current value incremented by one). For running other aspects of the simulation, see the-great-game.world.run.

                diff --git a/docs/codox/genetic-buildings.html b/docs/codox/genetic-buildings.html deleted file mode 100644 index 4274e19..0000000 --- a/docs/codox/genetic-buildings.html +++ /dev/null @@ -1,46 +0,0 @@ - -Genetic Buildings

                Genetic Buildings

                -

                Building selection based on location

                -

                The objective of this note is to create a landscape with varied and believable buildings, with the minimum possible data storage per instance.

                -

                Like plants, buildings will ‘grow’ from a seed which has northing and easting attributes. These locate a position on the map. Again, like trees, some aspects of the building type selector are location based. Aspects of the location which are relevant to building type are

                -
                  -
                • elevation — derived from the map location by interpolation from grid. The actual interpolation algorithm is probably some form of spline, but in any case it’s the same one as for everything else.
                • -
                • orientation of slope — derived by taking altitude at four corners of a 100 metre square centred on the seed point, and then taking the highest and lowest of these. If highest is northwest, lowest is southeast, the slope is considered to be oriented southeast; if highest is northwest and lowest southwest, the orientation is considered to be south, and so on. Eight orientation values are sufficient.
                • -
                • gradient of slope — derived from the difference in altitude across the same 100 metre square
                • -
                • neighbours — number of other buildings in 500 metre square centred on seed point.
                • -
                -

                The reason orientation is relevant is exactly the same as the reason it’s relevant to trees. West facing slopes are assumed wetter (coriolis winds), so grow trees better, so better availability of better quality timber, so a higher probability of timber as a primary building material. But also, in areas of higher rainfall, rain shedding is an important consideration, so a higher value is placed on pitched roofs.

                -

                So you have the following general relationships

                -
                  -
                • west (or southwest or northwest) facing, moderate gradient, moderate altitude: high probability of timber construction; construction techniques involving large timbers (e.g. cruck frame); greater probability of shingled roofs;
                • -
                • west (or southwest or northwest) facing, moderate gradient, higher altitude or northern latitude: high probability of building styles adapted to straight-trunk conifers, e.g. log cabins, stave buildings; greater probability of shingled roofs;
                • -
                • east facing, generally: greater probability of flat roofs;
                • -
                • steeper gradients: greater probability of stone buildings (steeper gradients = shallower topsoil and greater ease of quarrying = access to stone); greater probability of slate roofs;
                • -
                • shallower gradients: greater probability of mud, cobb, brick or wattle-and-daub as building materials; greater probability of thatch or turf roofs;
                • -
                • Higher number of neighbours: higher probability of two or more stories;
                • -
                -

                These factors allow classes of building to be selected. Having got past that point, we need to consider how classes of genetic building can work.

                -

                Rectangular genetic buildings

                -

                Some genetic buildings will have cells with rectangular plan. This doesn’t mean that genetic buildings are required to have rectangular cells, but they provide a starting point for discussion. For a given class of building (for example, timber frame), a number of prototype models of cells exist. These models are fully realised three dimensional models. Possibly all cells belonging to the building class have two open ends, and end walls exist as separate models; equally possibly, some cells have only one extensible end. In any case, a building will not normally comprise a single cell. Normally it will comprise multiple cells. So the cells belonging to a particular building class will be designed to ‘plug together’. Multi story building classes will have some cells which are specifically ground floor only (flat ceiling, no roof), and such cells will always have an upper floor cell added above them. Where an upper floor cell has an outside door, an outside stair will automatically be added.

                -

                Cell mutability

                -

                Although cell models are repeatedly reused they don’t have to look the same every time they are reused. Within limits, every cell can be stretched along any of its three axes. Obviously, the degree of stretch on a given axis for every cell in a given building must be the same, otherwise they won’t line up. Another mutable area is skinning — it may be possible to have alternate skins for cells, and even if there are not alternate skins, it will be possible to mutably darken, lighten or otherwise tint the skins used, within ranges which are appropriate to the materials represented. Obviously there are limits to stretching — timber comes in only such a length, stone lintels will only support such a span.

                -

                Functional cells

                -

                Some trade functions require cells of particular kinds. Thus a smith needs a working building with one cell which is explicitly a forge. A water mill must have one cell which explicitly houses the mill gear. A forge cell or a waterwheel cell should never appear in weavers workshop. But most cells are not dedicated in this way. A bedroom cell is a bedroom cell, more or less; wealth may alter how it is furnished, but it may appear in any dwelling. Similarly, except for the very wealthy, a living cell is pretty much a living cell. And any building may incorporate a storage cell. If a given building class has twelve distinct ‘generic’ cells’ and half a dozen distinct functional cells, and if buildings in the class average four cells each, then ignoring variance caused by skin mutability, a street of fifty buildings could have every one different.

                -

                Reproducibility

                -

                It’s critical that if a player visits a location, leaves it, and then returns, the buildings should not all have changed. So it must be possible to repeatedly reproduce the building at the location (this, of course, applies to other procedural scene dressing, such as trees, roads, boundaries, bridges and so on). This is possible if a deterministic random number generator is used which is seeded from the latitude and longitude attributes of the location. Other attributes which should be cached on the seed even though they are determined procedurally when the building is first instantiated include building class, purpose, and wealth. Using these attributes and the deterministic random number generator, the same building can be reproduced on the same site each time it is visited, with a very small amount of data stored.

                -

                Buildings will normally be built at the edge of the associated land holding. If an edge of the land holding adjoins a road, then the building will be built with one long side aligned to the road. Otherwise, the building will be built at right angles to the orientation of the slope. The orientation will be ‘frozen’ once the building has been instantiated and will be cached on the seed.

                -

                So, to build a building, use the following algorithm:

                -

                Seed the random number generator with latitude and longitude

                -
                while ( building value is less than wealth) {
                -   select a cell selected from the building class using the next number from the random number generator modulo the number of generic cells in the class;
                -   if the selected cell is not inappropriate to the building's function {
                -       fit the cell to the building at the point determined by a deterministic algorithm
                -       furnish cell using the random number generator to determine
                -       furnishing types and locations from a selection appropriate to the cell
                -       if the selected cell was not a top story cell {
                -            add a requirement that the next cell selected must be an upper story cell}
                -   }
                -}
                -
                -
                \ No newline at end of file diff --git a/docs/codox/index.html b/docs/codox/index.html index af965d9..86444b9 100644 --- a/docs/codox/index.html +++ b/docs/codox/index.html @@ -1,13 +1,10 @@ -The-great-game 0.1.3-SNAPSHOT

                The-great-game 0.1.3-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.3-SNAPSHOT"]

                Topics

                Namespaces

                cc.journeyman.the-great-game.agent.agent

                Anything in the game world with agency; primarily but not exclusively characters.

                -

                Public variables and functions:

                cc.journeyman.the-great-game.agent.schedule

                Schedules of plans for actors in the game, in order that they may have daily and seasonal patterns of behaviour.

                +The-great-game 0.1.3-SNAPSHOT

                The-great-game 0.1.3-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.3-SNAPSHOT"]

                Topics

                Namespaces

                cc.journeyman.the-great-game.agent.schedule

                Schedules of plans for actors in the game, in order that they may have daily and seasonal patterns of behaviour.

                Public variables and functions:

                cc.journeyman.the-great-game.buildings.module

                A module of a building; essentially something like a portacabin, which can be assembled together with other modules to make a complete building.

                -

                Public variables and functions:

                  cc.journeyman.the-great-game.buildings.rectangular

                  Build buildings with a generally rectangular floow plan.

                  -

                  cc.journeyman.the-great-game.gossip.gossip

                  Interchange of news events between gossip agents.

                  +

                  Public variables and functions:

                    cc.journeyman.the-great-game.gossip.gossip

                    Interchange of news events between gossip agents.

                    Public variables and functions:

                    cc.journeyman.the-great-game.holdings.holding

                    TODO: write docs

                    -

                    Public variables and functions:

                    cc.journeyman.the-great-game.location.location

                    TODO: write docs

                    Public variables and functions:

                    cc.journeyman.the-great-game.lore.digester

                    TODO: write docs

                    Public variables and functions:

                      cc.journeyman.the-great-game.merchants.markets

                      Adjusting quantities and prices in markets.

                      Public variables and functions:

                      cc.journeyman.the-great-game.merchants.merchant-utils

                      Useful functions for doing low-level things with merchants.

                      @@ -19,7 +16,7 @@

                      Public variables and functions:

                      cc.journeyman.the-great-game.objects.game-object

                      Anything at all in the game world

                      Public variables and functions:

                      cc.journeyman.the-great-game.playroom

                      TODO: write docs

                      Public variables and functions:

                      cc.journeyman.the-great-game.proving.sketches

                      Code that’s useful for exploring, but probably not part of the final product, and if it is, will end up somewhere else.

                      Public variables and functions:

                      cc.journeyman.the-great-game.world.heightmap

                      Functions dealing with the tessellated multi-layer heightmap.

                      diff --git a/docs/codox/intro.html b/docs/codox/intro.html index fa5346b..c85a188 100644 --- a/docs/codox/intro.html +++ b/docs/codox/intro.html @@ -1,6 +1,6 @@ -Introduction to the-great-game

                      Introduction to the-great-game

                      +Introduction to the-great-game

                      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 deleted file mode 100644 index 82372fa..0000000 --- a/docs/codox/modelling_trading_cost_and_risk.html +++ /dev/null @@ -1,8 +0,0 @@ - -Modelling trading cost and risk

                      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?

                      -

                      Obviously the more we model, the more compute power modelling consumes. If the core objective is a Role Playing Games as currently understood, then there is no need to model very complex trade risk assessment behaviour.

                      -
                      \ No newline at end of file diff --git a/docs/codox/orgnic-quests.html b/docs/codox/orgnic-quests.html deleted file mode 100644 index ae56c9c..0000000 --- a/docs/codox/orgnic-quests.html +++ /dev/null @@ -1,34 +0,0 @@ - -Organic Quests

                      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. -
                      3. Combo quests
                      4. -
                      5. Delivery quests
                      6. -
                      7. Gather quests
                      8. -
                      9. Escort quests
                      10. -
                      11. Syntax quests
                      12. -
                      13. Hybrids
                      14. -
                      -

                      ‘Gather quests’ are more frequently referred to in the literature as ‘fetch quests’, and ‘kill quests’ are simply a specialised form of fetch quest where the item to be fetched is a trophy of the kill. A delivery quest is a sort of reverse fetch quest: instead of going to some location or NPC and getting a specific item to return to the quest giver, the player is tasked to take a specific item from the quest giver to some location or NPC.

                      -

                      Hybrids are in effect chains of quests: do this task in order to get this precondition of this other task, in order to get the overall objective; obviously such chains can be deep and involved - the ‘main quest’ of every role playing game I know of is a chain or hybrid quest.

                      -

                      My understanding is that what Wikipedia means by a ‘syntax quest’ is what one would normally call a puzzle.

                      -

                      An escort quest is typically a request to take a specified non-player character safely through a dangerous area.

                      -

                      Combo quests are not, in my opinion, particularly relevant to the sorts of game we’re discussing here.

                      -

                      So essentially quests break down into three core types

                      -
                        -
                      1. Fetch and deliver quests
                      2. -
                      3. Escort quests
                      4. -
                      5. Puzzles
                      6. -
                      -

                      which are combined together into more or less complex chains, where the simplest chain is a single quest.

                      -

                      Given that quests are as simple as this, it’s obvious that narrative sophistication is required to make them interesting; and this point is clearly made by some variants of roguelike games which procedurally generate quests: they’re generally pretty dull. By contrast, the Witcher series is full of fetch-quests which are made to really matter by being wrapped in interesting character interaction and narrative plausibility. Very often this takes the form of tragedy: as one reviewer pointed out, the missing relatives that Geralt is asked to find generally turn out to be (horribly) dead. In other words, creative scripting tends to deliver much more narratively satisfying quests than is usually delivered by procedural generation.

                      -

                      But, if we’re thinking of a game with much more intelligent non-player characters with much more conversational repertoir, as I am, can satisfying quests emerge organically? In space trading games such as Elite, a primary activity is moving goods from markets with surplus (and thus low prices) to markets with shortage (and thus high prices). This is, in effect, a game made up of deliver quests - but rather than deliver quests which are scripted, they are deliver quests which arise organically out of the structure of the game world.

                      -

                      I already have working code for non-player character merchants, who move goods from city to city based on market information available to them. For player characters to join in this trading is an organic activity emerging from the structure of the world, which provides an activity. But moving merchants provides a market opportunity for bandits, who can intercept and steal cargoes, and so for mercenaries, who can protect cargoes from bandits, and so on. And because I have an architecture that allows non-player characters to fill economic niches, there will be non-player characters in all these niches.

                      -

                      Where a non-player character can act, so can a player character: when a (non-player character) merchant seeks to hire a caravan guard and a player character responds, that’s an organic escort quest.

                      -

                      The key idea behind organic quests is that the circumstance and requirments for quests emerges as an emergent behaviour out of the mechanics of the game world. A non-player character doesn’t know that there is a player character who is different from them; rather, when a non-player character needs something they can’t readily achieve for themselves, they will ask other characters to help, and that may include the player character.

                      -

                      This means, of course, that characters need a goal-seeking planning algorithm to decide their actions, with one option in any plan being ‘ask for help’. Thus, ‘asking for help’ becomes a mechanism within the game, a normal behaviour. Ideally non-player characters will keep track of quite complex webs of loyalty and of obligation - debts of honour, duties of hospitality, collective loyalties. So that, if you do a favour for some character in the world, that character’s tribe, friends, obligation circle, whatever, are now more likely to do favours for you.

                      -

                      Obviously, this doesn’t stop you doing jobs you get directly paid/rewarded for, but I’d like the web of obligation to be at least potentially much richer than just tit for tat.

                      -

                      Related to this notion is the notion that, if you are asked to do a task by a character and you do it well, whether for pay or as a favour, your reputation for being competent in tasks of that kind will improve and the more likely it is that other characters will ask you to do similar tasks; and this will apply to virtually anything another character can ask of you in the game world, from carrying out an assassination to delivering a message to finding a quantiy of some specific commodity to having sex.

                      -

                      So quests can emerge organically from the mechanics of the world and be richly varied; I’m confident that will work. What I’m not confident of is that they can be narratively satisfying. This relates directly to the generation of speech.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.agent.agent.html b/docs/codox/the-great-game.agent.agent.html deleted file mode 100644 index efd5f84..0000000 --- a/docs/codox/the-great-game.agent.agent.html +++ /dev/null @@ -1,10 +0,0 @@ - -the-great-game.agent.agent documentation

                      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

                      -
                        -
                      • :active - actors within visual/audible range of the player character;
                      • -
                      • :pending - actors not in the active circle, but sufficiently close to it that they may enter the active circle within a short period;
                      • -
                      • :background - actors who are active in the background in order to handle trade, news, et cetera;
                      • -
                      • other - actors who are not members of any other circle, although I’m not clear whether it would ever be appropriate to invoke an act method on them.
                      • -
                      -

                      The act method must not have side effects; it must only return a new state. If the actor’s intention is to seek to change the state of something else in the game world, it must add a representation of that intention to the sequence which will be returned by its pending-intentions method.

                      pending-intentions

                      (pending-intentions actor)

                      Returns a sequence of effects an actor intends, as a consequence of acting. The encoding of these is not yet defined.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.core.html b/docs/codox/the-great-game.core.html deleted file mode 100644 index e85f03f..0000000 --- a/docs/codox/the-great-game.core.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.core documentation

                      the-great-game.core

                      TODO: write docs

                      foo

                      (foo x)

                      I don’t do a whole lot.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.gossip.gossip.html b/docs/codox/the-great-game.gossip.gossip.html deleted file mode 100644 index e731d5e..0000000 --- a/docs/codox/the-great-game.gossip.gossip.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.gossip.gossip documentation

                      the-great-game.gossip.gossip

                      Interchange of news events between gossip agents

                      dialogue

                      (dialogue enquirer respondent world)

                      Dialogue between an enquirer and an agent in this world; returns a map identical to enquirer except that its :gossip collection may have additional entries.

                      gather-news

                      (gather-news world)(gather-news world gossip)

                      TODO: write docs

                      move-gossip

                      (move-gossip gossip world new-location)

                      Return a world like this world but with this gossip moved to this new-location. Many gossips are essentially shadow-records of agents of other types, and the movement of the gossip should be controlled by the run function of the type of the record they shadow. The #run function below does NOT call this function.

                      run

                      (run world)

                      Return a world like this world, with news items exchanged between gossip agents.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.gossip.news-items.html b/docs/codox/the-great-game.gossip.news-items.html deleted file mode 100644 index acb2ade..0000000 --- a/docs/codox/the-great-game.gossip.news-items.html +++ /dev/null @@ -1,19 +0,0 @@ - -the-great-game.gossip.news-items documentation

                      the-great-game.gossip.news-items

                      Categories of news events interesting to gossip agents

                      degrade-character

                      (degrade-character gossip character)

                      Return a character specification like this character, but comprising only those properties this gossip is interested in.

                      degrade-location

                      (degrade-location gossip location)

                      Return a location specification like this location, but comprising only those elements this gossip is interested in. If none, return nil.

                      infer

                      (infer item rule)

                      Infer a new knowledge item from this item, following this rule

                      interest-in-character

                      (interest-in-character gossip character)

                      Integer representation of how interesting this character is to this gossip. TODO: this assumes that characters are passed as keywords, but, as documented above, they probably have to be maps, to allow for degradation.

                      interest-in-location

                      (interest-in-location gossip location)

                      Integer representation of how interesting this location is to this gossip.

                      interesting-character?

                      (interesting-character? gossip character)

                      Boolean representation of whether this character is interesting to this gossip.

                      interesting-item?

                      (interesting-item? gossip item)

                      True if anything about this news item is interesting to this gossip.

                      interesting-location?

                      (interesting-location? gossip item)

                      True if the location of this news item is interesting to this gossip.

                      interesting-object?

                      (interesting-object? gossip object)

                      TODO: write docs

                      interesting-topic?

                      (interesting-topic? gossip topic)

                      TODO: write docs

                      learn-news-item

                      (learn-news-item gossip item)(learn-news-item gossip item follow-inferences?)

                      Return a gossip like this gossip, which has learned this news item if it is of interest to them.

                      make-all-inferences

                      (make-all-inferences item)

                      Return a list of knowledge entries that can be inferred from this news item.

                      news-topics

                      Topics of interest to gossip agents. Topics are keyed in this map by their verbs. The keys associated with each topic are the extra pieces of information required to give context to a gossip item. Generally:

                      -
                        -
                      • actor is the id of the character who it is reported performed the action;
                      • -
                      • other is the id of the character on whom it is reported the action was performed;
                      • -
                      • location is the place at which the action was performed;
                      • -
                      • object is an object (or possibly list of objects?) relevant to the action;
                      • -
                      • price is special to buy/sell, but of significant interest to merchants.
                      • -
                      -

                      Notes:

                      -
                      Characters:
                      -

                      TODO but note that at most all the receiver can learn about a character from a news item is what the giver knows about that character, degraded by what the receiver finds interesting about them. If we just pass the id here, then either the receiver knows everything in the database about the character, or else the receiver knows nothing at all about the character. Neither is desirable. Further thought needed.

                      -

                      By implication, the character values passed should include all the information the giver knows about the character; that can then be degraded as the receiver stores only that segment which the receiver finds interesting.

                      -
                      Locations:
                      -

                      A ‘location’ value is a list comprising at most the x/y coordinate location and the ids of the settlement and region (possibly hierarchically) that contain the location. If the x/y is not local to the home of the receiving agent, they won’t remember it and won’t pass it on; if any of the ids are not interesting So location information will degrade progressively as the item is passed along.

                      -

                      It is assumed that the :home of a character is a location in this sense.

                      -
                      Inferences:
                      -

                      If an agent learns that Adam has married Betty, they can infer that Betty has married Adam; if they learn that Charles killed Dorothy, that Dorothy has died. I’m not convinced that my representation of inferences here is ideal.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.merchants.markets.html b/docs/codox/the-great-game.merchants.markets.html deleted file mode 100644 index 09b56a9..0000000 --- a/docs/codox/the-great-game.merchants.markets.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.merchants.markets documentation

                      the-great-game.merchants.markets

                      Adjusting quantities and prices in markets.

                      adjust-quantity-and-price

                      (adjust-quantity-and-price world city commodity)

                      Adjust the quantity of this commodity currently in stock in this city of this world. Return a fragmentary world which can be deep-merged into this world.

                      new-price

                      (new-price old stock supply demand)

                      If stock is greater than the maximum of supply and demand, then there is surplus and old price is too high, so shold be reduced. If lower, then it is too low and should be increased.

                      run

                      (run world)

                      Return a world like this world, with quantities and prices in markets updated to reflect supply and demand.

                      update-markets

                      (update-markets world)(update-markets world city)(update-markets world city commodity)

                      Return a world like this world, with quantities and prices in markets updated to reflect supply and demand. If city or city and commodity are specified, return a fragmentary world with only the changes for that city (and commodity if specified) populated.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.merchants.merchant-utils.html b/docs/codox/the-great-game.merchants.merchant-utils.html deleted file mode 100644 index 6479e51..0000000 --- a/docs/codox/the-great-game.merchants.merchant-utils.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.merchants.merchant-utils documentation

                      the-great-game.merchants.merchant-utils

                      Useful functions for doing low-level things with merchants.

                      add-known-prices

                      (add-known-prices merchant world)

                      Add the current prices at this merchant’s location in the world to a new cache of known prices, and return it.

                      add-stock

                      (add-stock a b)

                      Where a and b are both maps all of whose values are numbers, return a map whose keys are a union of the keys of a and b and whose values are the sums of their respective values.

                      burden

                      (burden merchant world)

                      The total weight of the current cargo carried by this merchant in this world.

                      can-afford

                      (can-afford merchant world commodity)

                      Return the number of units of this commodity which this merchant can afford to buy in this world.

                      can-carry

                      (can-carry merchant world commodity)

                      Return the number of units of this commodity which this merchant can carry in this world, given their current burden.

                      expected-price

                      (expected-price merchant commodity city)

                      Find the price anticipated, given this world, by this merchant for this commodity in this city. If no information, assume 1. merchant should be passed as a map, commodity and city should be passed as keywords.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.merchants.merchants.html b/docs/codox/the-great-game.merchants.merchants.html deleted file mode 100644 index 8000bba..0000000 --- a/docs/codox/the-great-game.merchants.merchants.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.merchants.merchants documentation

                      the-great-game.merchants.merchants

                      Trade planning for merchants, primarily.

                      run

                      (run world)

                      Return a partial world based on this world, but with each merchant moved.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.merchants.planning.html b/docs/codox/the-great-game.merchants.planning.html deleted file mode 100644 index 56eaf6a..0000000 --- a/docs/codox/the-great-game.merchants.planning.html +++ /dev/null @@ -1,26 +0,0 @@ - -the-great-game.merchants.planning documentation

                      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.

                      augment-plan

                      (augment-plan merchant world plan)

                      Augment this plan constructed in this world for this merchant with the :quantity of goods which should be bought and the :expected-profit of the trade.

                      -

                      Returns the augmented plan.

                      generate-trade-plans

                      (generate-trade-plans merchant world commodity)

                      Generate all possible trade plans for this merchant and this commodity in this world.

                      -

                      Returned plans are maps with keys:

                      -
                        -
                      • :merchant - the id of the merchant for whom the plan was created;
                      • -
                      • :origin - the city from which the trade starts;
                      • -
                      • :destination - the city to which the trade is planned;
                      • -
                      • :commodity - the commodity to be carried;
                      • -
                      • :buy-price - the price at which that commodity can be bought;
                      • -
                      • :expected-price - the price at which the merchant anticipates that commodity can be sold;
                      • -
                      • :distance - the number of stages in the planned journey
                      • -
                      • :dist-to-home - the distance from destination to the merchant’s home city.
                      • -

                      nearest-with-targets

                      (nearest-with-targets plans targets)

                      Return the distance to the nearest destination among those of these plans which match these targets. Plans are expected to be plans as returned by generate-trade-plans, q.v.; targets are expected to be as accepted by make-target-filter, q.v.

                      plan-trade

                      (plan-trade merchant world commodity)

                      Find the best destination in this world for this commodity given this merchant and this origin. If two cities are anticipated to offer the same price, the nearer should be preferred; if two are equally distant, the ones nearer to the merchant’s home should be preferred. merchant may be passed as a map or a keyword; commodity should be passed as a keyword.

                      -

                      The returned plan is a map with keys:

                      -
                        -
                      • :merchant - the id of the merchant for whom the plan was created;
                      • -
                      • :origin - the city from which the trade starts;
                      • -
                      • :destination - the city to which the trade is planned;
                      • -
                      • :commodity - the commodity to be carried;
                      • -
                      • :buy-price - the price at which that commodity can be bought;
                      • -
                      • :expected-price - the price at which the merchant anticipates that commodity can be sold;
                      • -
                      • :distance - the number of stages in the planned journey
                      • -
                      • :dist-to-home - the distance from destination to the merchant’s home city.
                      • -

                      select-cargo

                      (select-cargo merchant world)

                      A merchant, in a given location in a world, will choose to buy a cargo within the limit they are capable of carrying, which they can anticipate selling for a profit at a destination.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.merchants.strategies.simple.html b/docs/codox/the-great-game.merchants.strategies.simple.html deleted file mode 100644 index af365bd..0000000 --- a/docs/codox/the-great-game.merchants.strategies.simple.html +++ /dev/null @@ -1,4 +0,0 @@ - -the-great-game.merchants.strategies.simple documentation

                      the-great-game.merchants.strategies.simple

                      Default trading strategy for merchants.

                      -

                      The simple strategy buys a single product in the local market if there is one which can be traded profitably, trades it to the chosen target market, and sells it there. If there is no commodity locally which can be traded profitably, moves towards home with no cargo. If at home and no commodity can be traded profitably, does not move.

                      move-merchant

                      (move-merchant merchant world)

                      Handle general en route movement of this merchant in this world; return a (partial or full) world like this world but in which the merchant may have been moved ot updated.

                      plan-and-buy

                      (plan-and-buy merchant world)

                      Return a world like this world, in which this merchant has planned a new trade, and bought appropriate stock for it. If no profitable trade can be planned, the merchant is simply moved towards their home.

                      re-plan

                      (re-plan merchant world)

                      Having failed to sell a cargo at current location, re-plan a route to sell the current cargo. Returns a revised world.

                      sell-and-buy

                      (sell-and-buy merchant world)

                      Return a new world like this world, in which this merchant has sold their current stock in their current location, and planned a new trade, and bought appropriate stock for it.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.objects.container.html b/docs/codox/the-great-game.objects.container.html deleted file mode 100644 index 2a28aac..0000000 --- a/docs/codox/the-great-game.objects.container.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.objects.container documentation

                      the-great-game.objects.container

                      TODO: write docs

                      ProtoContainer

                      protocol

                      members

                      contents

                      (contents container)

                      Return a sequence of the contents of this container, or nil if empty.

                      is-empty?

                      (is-empty? container)

                      Return true if this container is empty, else false.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.objects.game-object.html b/docs/codox/the-great-game.objects.game-object.html deleted file mode 100644 index b486c1c..0000000 --- a/docs/codox/the-great-game.objects.game-object.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.objects.game-object documentation

                      the-great-game.objects.game-object

                      Anything at all in the game world

                      ProtoObject

                      protocol

                      An object in the world

                      members

                      id

                      (id object)

                      Returns the unique id of this object.

                      reify-object

                      (reify-object object)

                      Adds this object to the global object list. If the object has a non-nil value for its id method, keys it to that id - but if the id value is already in use, throws a hard exception. Returns the id to which the object is keyed in the global object list.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.time.html b/docs/codox/the-great-game.time.html deleted file mode 100644 index f9aaae2..0000000 --- a/docs/codox/the-great-game.time.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.time documentation

                      the-great-game.time

                      TODO: write docs

                      canonical-ordering-of-houses

                      The canonical ordering of religious houses.

                      date-string

                      (date-string game-time)

                      Return a correctly formatted date for this game-time in the calendar of the Great Place.

                      day

                      (day game-time)

                      Day of the eight-day week represented by this game-time.

                      day-of-year

                      macro

                      (day-of-year game-time)

                      The day of the year represented by this game-time, ignoring leap years.

                      days-in-season

                      TODO: write docs

                      days-in-week

                      This world has an eight day week.

                      days-of-week

                      The eight-day week of the game world. This differs from the canonical ordering of houses in that it omits the eye.

                      game-day-length

                      The Java clock advances in milliseconds, which is fine. But we need game-days to be shorter than real world days. A Witcher 3 game day is 1 hour 36 minutes, or 96 minutes, which is presumably researched. Round it up to 100 minutes for easier calculation.

                      game-start-time

                      The start time of this run.

                      game-time

                      (game-time)(game-time timestamp)

                      With no arguments, the current game time. If a Java timestamp value is passed (as a long), the game time represented by that value.

                      now

                      (now)

                      For now, we’ll use Java timestamp for time; ultimately, we need a concept of game-time which allows us to drive day/night cycle, seasons, et cetera, but what matters about time is that it is a value which increases.

                      season

                      (season game-time)

                      TODO: write docs

                      seasons-in-year

                      Nine seasons in a year, one for each house (although the order is different.

                      seasons-of-year

                      The ordering of seasons in the year is different from the canonical ordering of the houses, for reasons of the agricultural cycle.

                      waiting-day?

                      Does this game-time represent a waiting day?

                      week

                      (week game-time)

                      Week of season represented by this game-time.

                      weeks-in-season

                      To fit nine seasons of eight day weeks into 365 days, each must be of five weeks.

                      weeks-of-season

                      To fit nine seasons of eight day weeks into 365 days, each must be of five weeks.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.utils.html b/docs/codox/the-great-game.utils.html deleted file mode 100644 index 7a4708e..0000000 --- a/docs/codox/the-great-game.utils.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.utils documentation

                      the-great-game.utils

                      TODO: write docs

                      cyclic?

                      (cyclic? route)

                      True if two or more elements of route are identical

                      deep-merge

                      (deep-merge & maps)

                      make-target-filter

                      (make-target-filter targets)

                      Construct a filter which, when applied to a list of maps, will pass those which match these targets, where each target is a tuple [key value].

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.world.location.html b/docs/codox/the-great-game.world.location.html deleted file mode 100644 index b0418e4..0000000 --- a/docs/codox/the-great-game.world.location.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.world.location documentation

                      the-great-game.world.location

                      Functions dealing with location in the world.

                      distance-between

                      (distance-between location-1 location-2)

                      TODO: write docs

                      get-coords

                      (get-coords location)

                      Return the coordinates in the game world of location, which may be 1. A coordinate pair in the format {:x 5 :y 32}; 2. A location, as discussed above; 3. Any other gameworld object, having a :location property whose value is one of the above.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.world.routes.html b/docs/codox/the-great-game.world.routes.html deleted file mode 100644 index 0839bd6..0000000 --- a/docs/codox/the-great-game.world.routes.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.world.routes documentation

                      the-great-game.world.routes

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

                      find-route

                      (find-route world-or-routes from to)

                      Find a single route from from to to in this world-or-routes, which may be either a world as defined in the-great-game.world.world or else a sequence of tuples of keywords.

                      find-routes

                      (find-routes routes from)(find-routes routes from to)(find-routes routes from to steps)

                      Find routes from among these routes from from; if to is supplied, to to, by breadth-first search.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.world.run.html b/docs/codox/the-great-game.world.run.html deleted file mode 100644 index 6588175..0000000 --- a/docs/codox/the-great-game.world.run.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.world.run documentation

                      the-great-game.world.run

                      Run the whole simulation

                      init

                      (init)(init config)

                      TODO: write docs

                      run

                      (run world)(run world date)

                      The pipeline to run the simulation each game day. Returns a world like this world, with all the various active elements updated. The optional date argument, if supplied, is set as the :date of the returned world.

                      \ No newline at end of file diff --git a/docs/codox/the-great-game.world.world.html b/docs/codox/the-great-game.world.world.html deleted file mode 100644 index e4071ae..0000000 --- a/docs/codox/the-great-game.world.world.html +++ /dev/null @@ -1,3 +0,0 @@ - -the-great-game.world.world documentation

                      the-great-game.world.world

                      Access to data about the world

                      actual-price

                      (actual-price world commodity city)

                      Find the actual current price of this commodity in this city given this world. NOTE that merchants can only know the actual prices in the city in which they are currently located.

                      default-world

                      A basic world for testing concepts

                      run

                      (run world)(run world date)

                      Return a world like this world with only the :date to this date (or id date not supplied, the current value incremented by one). For running other aspects of the simulation, see the-great-game.world.run.

                      \ No newline at end of file