diff --git a/LICENSE b/LICENSE.md similarity index 100% rename from LICENSE rename to LICENSE.md diff --git a/doc/Further-reading.md b/doc/Further-reading.md index 8832dd1..033f8c5 100644 --- a/doc/Further-reading.md +++ b/doc/Further-reading.md @@ -9,3 +9,7 @@ Work by other people which is relevant to what I'm doing, and which I should stu ## Systemic games 1. [This video](https://youtu.be/SnpAAX9CkIc) is thought provoking with excellent examples. + +## Procedural animation + +1. [This video](https://youtu.be/LNidsMesxSE) builds really impressive character animation on extremely simple foundations. I'm not saying this is easy, but it looks doable. \ No newline at end of file diff --git a/doc/Towards-a-procedural-animation-api.md b/doc/Towards-a-procedural-animation-api.md new file mode 100644 index 0000000..96620a7 --- /dev/null +++ b/doc/Towards-a-procedural-animation-api.md @@ -0,0 +1,76 @@ +# Towards a procedural animation API + +I've been watching this animation tutorial, and I'm impressed with its simplicity. This seems to be to be something it would be possible to do, and it started me thinking about what I wanted from a procedural animation API. + + + +The game is now open source, with the source available [here](https://github.com/WolfireGames/overgrowth/). It's available on [Steam, here](https://store.steampowered.com/app/25000/Overgrowth/). + +So: what have we here? + +A simple character rig with a small number of key frames which can adaptively negotiate a moderately complex terrain. Inverse kinematics is used, but the core of the animation is key-frame animation with well thought out interpolation, and it all looks remarkably persuasive. This looks buildable. + +So: what do I actually need? + +## Smooth continuous movement on complex terrain + +Characters need to transition from one movement to another movement smoothly, without sudden jums or jerks. Turning needs to look physically plausible. + +## Animation for several skeleton types + +Creatures I need to animate include + +1. People: upright bipedal motion; +2. Horses: even-length-legged quadripedal motion; +3. Camels: also even length legged quadripeds, but their gait is different from horses, although the skeleton might be similar. So: different key frames? Or something more elaborate than that? +4. Seals: primarily aquatic quadrupeds, with forelimbs considerably longer than back limbs, and all limbs much shorter than the other quadripeds under consideration. But I'm not sure how much I need to actually animate them. +5. Dragons: exist in the world, but aren't necessarily going to appear in version one of the game. A much more complicated problem. +6. Birds: but don't need to animate them close up or landed. However, not all birds fly using the same 'gait', so, again this may be complex. +7. Other quadrupeds, such as dogs and cats; but these are a long way down the priority scale. + +At the proof of concept stage, I only need animated people; and the only reason for cataloguing the other things I need to animate is that the animation framework needs to be able to handle multiple skeleton types. + +It's also worth pointing out that in Cyberpunk 2077, it's very noticable that several different gaits are implemented for people: there is a noticably distinct 'fat person' gait, and several different gaits that are used, for example one extremely sexualised female gait, used mainly for characters who are sex workers, but for a small number of other female characters. The point here is that not all characters walk the same, and having distinctive gaits for some characters or classes of characters decidedly adds to a game's persuasiveness. + +## The API + +### (move-to model terrain target) + +Plans a route across the terrain from where the model is to the target (which can be either a location or an object, including another potentially moving character), avoiding obstacles and choosing the easiest path across slopes, and produces a route; animates the model along that route, using the keyframe-based system described in the video, with inverse kinematics to ensure feet touch the ground. + +### (look-at model terrain target) + +Turns the model's gaze, and, if necessary, head and body, to face towards the target. + +### (sit-on model terrain target) + +Causes the model to sit on the target, moving to it first if necessary. If the target is approximately chair-height, sit on it as if on a chair; if it's a horse or camel, sit on it as though to ride; otherwise, sit cross legged. If the target is just a location, sit cross legged on the terrain surface at that location. + +Obviously, what I've described there is partially specific to upright bipedal models; horses and camels don't sit on chairs! + +### (lie-on model terrain target) + +As above, but lie down. + +### (drink-from model terrain target) + +As above, but drink. Target is expected to be a drinkable container, such as a mug, flask or bottle, or else a point in the terrain which is flooded. + +### (eat-from model terrain target) + +### (strike model terrain target implement vector) +### (thrust model terrain target implement vector) + +Two closely related animation calls, both of which might be used both in combat animation and in craft activity animation. **BUT** both combat animation and craft activity animation are much more complex problems which this not does not address. + +## Other things which need to be animated + +### Conversation + +In conversation, people move to a convenient distance from one another, typically face one another, typically take turns to say things, frequently use hand gestures when speaking. The intensity of gestures will vary with the emotion being expressed. The animation of NPC-to-NPC conversation is if possible more complex to get right than of player character to NPC. + +### Combat animation + +### Craft activity animation + +Both of these will be very complicated to get right. \ No newline at end of file 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 d7412d3..a807c3c 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 95affa0..551b7e1 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 fb817c8..dd7c6d4 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/Architecture.html b/docs/codox/Architecture.html new file mode 100644 index 0000000..66a7cdd --- /dev/null +++ b/docs/codox/Architecture.html @@ -0,0 +1,33 @@ + +Architecture

Architecture

+

OK, the basic idea is this

+

Everything (every game object, including the world) is a map.

+

Every object as an :id property; every :id property is distinct.

+

There is a master map - the oblist which contains every object, keyed by its :id. (Actually, there probably can’t be such a map in working memory, because there will be too many objects. There will be such a map in the database – but still keyed by :id).

+

Every object has a :run function, which returns either a new copy of itself or nil, and does not have side effects.

+

Every object has a :location function, which takes one argument, the object, and returns its location as a coordinate pair (or coordinate triple, probably) (this may involve fetching the location from the container in which it is contained, which implies that a contained object must hold a handle to its container).

+

Every collection of things in the world is represented as a list of :id values, by which the actual objects can be fetched from the oblist.

+

Circles

+

Among those collections are the circles. The circles include, at minimum

+
    +
  1. Those objects in audible/visual range of the player; these have their run method invoked avery game loop. Weather, is always in this circle. The sun and moon are in this circle from shortly becore they rise to shortly after they set.
  2. +
  3. Those objects which might come into audible/visual range within a short period; these have their run method invoked every N game loops, where N is probably variable depending on overall system load
  4. +
  5. Those objects (actors) which are necessary to maintain the gossip system, etc. These should each have their run method invoked once per game day, but that is done by invoking the run method of a share of them each game loop.
  6. +
+

So run takes three arguments - the object, the world and the circle; and returns nil if it makes no change, or a new copy of itself; and probably each of the main functions that run calls have the same behaviour. So, for example, a hierarchy of needs can be represented by

+
(defn run [character world circle]
+  (first
+    (handle-immediate-threat character world circle) ;; if being attacked, deal with it
+    (complete-current-action character world circle) ;; otherwise, continue the current
+                                                     ;; short-term unless completed
+    (handle-thirst character world circle)           ;; perhaps adjust tactical plan to find water
+    (handle-hunger character world circle)           ;; perhaps adjust tactical plan to find food
+    (handle-fatigue character world circle)          ;; perhaps rest if safe to do so
+    (advance-current-plan character world circle)    ;; select next step of current strategic plan
+    (select-next-plan character world circle)        ;; plan new strategic objective
+    (return-home character world circle)))           ;; if no other strategic objective, return
+                                                     ;; to home location
+
+

Atoms? Background threads?

+
\ No newline at end of file diff --git a/docs/codox/Baking-the-world.html b/docs/codox/Baking-the-world.html index 7d37618..08ae24e 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 88d04ee..dd9304f 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 d3d807e..3cd4c9b 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 82eff50..b127fe6 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 6be9582..36e4774 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 48c278d..950640a 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 4b2dc70..6333526 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 67968f4..52d891c 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_Play.html b/docs/codox/Game_Play.html index 9b1c490..292aa0e 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 517998b..b2b5bed 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 ad7e010..b911c5a 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 0a7fc7e..9b9f009 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 73bfb73..200186f 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 21860b9..4e9f110 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/Naming-of-characters.html b/docs/codox/Naming-of-characters.html index 7d348c9..769216d 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/Not_my_problem.html b/docs/codox/Not_my_problem.html index fec3600..59b8dc0 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 0aee2f8..beb620a 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 00f8de0..f37a03d 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 4ec1afc..9e5ec68 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 53e2127..19f4c87 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 b116480..82f31ee 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/Pseudo-object-inheritance.html b/docs/codox/Pseudo-object-inheritance.html new file mode 100644 index 0000000..229f55a --- /dev/null +++ b/docs/codox/Pseudo-object-inheritance.html @@ -0,0 +1,6 @@ + +Pseudo object inheritance

              Pseudo object inheritance

              +

              This is simply to document how I’m doing type inheritance for game objects, since Clojure does not provide type inheritance for records and I’m currently building game objects on Clojure records.

              +

              It’s possible that I should instead build game objects on Java beans, which do have type (class) inheritance, and would work transparently; however, that isn’t my current approach.

              +
              \ No newline at end of file diff --git a/docs/codox/Roadmap.html b/docs/codox/Roadmap.html index d126339..8a360e6 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 0dab2d2..6d3d507 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

              diff --git a/docs/codox/Selecting_Character.html b/docs/codox/Selecting_Character.html index 365ee92..0b2519c 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 98052f5..a2af51f 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 59393d8..d443b22 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 index d5e9f2a..174679b 100644 --- a/docs/codox/Simulated-genetics.html +++ b/docs/codox/Simulated-genetics.html @@ -1,6 +1,6 @@ -Simulated Genetics

              Simulated Genetics

              +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

              diff --git a/docs/codox/Simulation-layers.html b/docs/codox/Simulation-layers.html index 31e0354..3fc967e 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 f4208d9..5d935da 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 f6d27c1..7ae6a8e 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/Towards-a-procedural-animation-api.html b/docs/codox/Towards-a-procedural-animation-api.html new file mode 100644 index 0000000..88606eb --- /dev/null +++ b/docs/codox/Towards-a-procedural-animation-api.html @@ -0,0 +1,47 @@ + +Towards a procedural animation API

              Towards a procedural animation API

              +

              I’ve been watching this animation tutorial, and I’m impressed with its simplicity. This seems to be to be something it would be possible to do, and it started me thinking about what I wanted from a procedural animation API.

              + +

              The game is now open source, with the source available here. It’s available on Steam, here.

              +

              So: what have we here?

              +

              A simple character rig with a small number of key frames which can adaptively negotiate a moderately complex terrain. Inverse kinematics is used, but the core of the animation is key-frame animation with well thought out interpolation, and it all looks remarkably persuasive. This looks buildable.

              +

              So: what do I actually need?

              +

              Smooth continuous movement on complex terrain

              +

              Characters need to transition from one movement to another movement smoothly, without sudden jums or jerks. Turning needs to look physically plausible.

              +

              Animation for several skeleton types

              +

              Creatures I need to animate include

              +
                +
              1. People: upright bipedal motion;
              2. +
              3. Horses: even-length-legged quadripedal motion;
              4. +
              5. Camels: also even length legged quadripeds, but their gait is different from horses, although the skeleton might be similar. So: different key frames? Or something more elaborate than that?
              6. +
              7. Seals: primarily aquatic quadrupeds, with forelimbs considerably longer than back limbs, and all limbs much shorter than the other quadripeds under consideration. But I’m not sure how much I need to actually animate them.
              8. +
              9. Dragons: exist in the world, but aren’t necessarily going to appear in version one of the game. A much more complicated problem.
              10. +
              11. Birds: but don’t need to animate them close up or landed. However, not all birds fly using the same ‘gait’, so, again this may be complex.
              12. +
              13. Other quadrupeds, such as dogs and cats; but these are a long way down the priority scale.
              14. +
              +

              At the proof of concept stage, I only need animated people; and the only reason for cataloguing the other things I need to animate is that the animation framework needs to be able to handle multiple skeleton types.

              +

              It’s also worth pointing out that in Cyberpunk 2077, it’s very noticable that several different gaits are implemented for people: there is a noticably distinct ‘fat person’ gait, and several different gaits that are used, for example one extremely sexualised female gait, used mainly for characters who are sex workers, but for a small number of other female characters. The point here is that not all characters walk the same, and having distinctive gaits for some characters or classes of characters decidedly adds to a game’s persuasiveness.

              +

              The API

              +

              (move-to model terrain target)

              +

              Plans a route across the terrain from where the model is to the target (which can be either a location or an object, including another potentially moving character), avoiding obstacles and choosing the easiest path across slopes, and produces a route; animates the model along that route, using the keyframe-based system described in the video, with inverse kinematics to ensure feet touch the ground.

              +

              (look-at model terrain target)

              +

              Turns the model’s gaze, and, if necessary, head and body, to face towards the target.

              +

              (sit-on model terrain target)

              +

              Causes the model to sit on the target, moving to it first if necessary. If the target is approximately chair-height, sit on it as if on a chair; if it’s a horse or camel, sit on it as though to ride; otherwise, sit cross legged. If the target is just a location, sit cross legged on the terrain surface at that location.

              +

              Obviously, what I’ve described there is partially specific to upright bipedal models; horses and camels don’t sit on chairs!

              +

              (lie-on model terrain target)

              +

              As above, but lie down.

              +

              (drink-from model terrain target)

              +

              As above, but drink. Target is expected to be a drinkable container, such as a mug, flask or bottle, or else a point in the terrain which is flooded.

              +

              (eat-from model terrain target)

              +

              (strike model terrain target implement vector)

              +

              (thrust model terrain target implement vector)

              +

              Two closely related animation calls, both of which might be used both in combat animation and in craft activity animation. BUT both combat animation and craft activity animation are much more complex problems which this not does not address.

              +

              Other things which need to be animated

              +

              Conversation

              +

              In conversation, people move to a convenient distance from one another, typically face one another, typically take turns to say things, frequently use hand gestures when speaking. The intensity of gestures will vary with the emotion being expressed. The animation of NPC-to-NPC conversation is if possible more complex to get right than of player character to NPC.

              +

              Combat animation

              +

              Craft activity animation

              +

              Both of these will be very complicated to get right.

              +
              \ No newline at end of file diff --git a/docs/codox/Tree-library-evaluation.html b/docs/codox/Tree-library-evaluation.html new file mode 100644 index 0000000..4893a77 --- /dev/null +++ b/docs/codox/Tree-library-evaluation.html @@ -0,0 +1,52 @@ + +Tree library evaluation

              Tree library evaluation

              +

              This is a comparative evaluation of open source tree libraries that I have found that I could make use of. It’s entirely personal and subjective!

              +

              SimArboreal

              +

              Overview

              +

              Library by Paul Speed, who’s a senior and prolific developer in the jMonkeyEngine community; designed to work with jMonkeyEngine, and consequently integrates well with it.

              +

              Licence

              +

              BSD-style licence.

              +

              Assessment

              +

              Produces trees which are quite realistic but only for a limited range of broad-leaved species. The trees do have modelled roots, which is relatively unusual. The trees sway in virtual winds, although to my eye trunks sway too much and thinner twigs too little. A limited number of textures are supplied, but new textures can easily be added so this isn’t an issue. Handles Level of Detail automatically within the context of the jME3 libraries, which is a real bonus.

              +

              Does not provide the range of species, or of stages of growth, I want. To add convincing coniferous trees, or trees with more than one primary branching point on the main trunk, would require extra coding. The way leaves are handled is crude, but looks surprisingly persuasive. The codebase is reasonably well written and understandable, but there is virtually no documentation. If I have to build on someone else’s library, this wouldn’t be a bad choice. The one to beat.

              +

              Tree3D

              +

              Overview

              +

              Looks like a student project, or something done fairly quickly as an exercise.

              +

              Licence

              +

              None specified, not even ‘public domain’. So might be a bit sketchy to copy from.

              +

              Assessment

              +

              This is definitely not as complete or ready to use as SimArboreal; although it does build, the user interface doesn’t work with modern Java. Whether it ever worked I don’t know, but I wouldn’t be confident. Code is reasonably well written, but almost completely undocumented. There is no rendering of bark or of leaves; although the branching structure is excellent and the variety of morphologies available is good, boughs do not bend.

              +

              However, algorithmically, this has a much better understanding of how trees grow, and of tree morphology, than SimArboreal. A hybrid taking growth algorithms from this and texture, wind, level of detail and jME3 integration from SimArboreal might be relatively to do.

              +

              Proctree.js

              +

              Very polished demo project by Paul Brunt, author of a key JavaScript WebGL 3D library; but in JavaScript, so not directly usable.

              +

              Licence

              +

              None specified, not even ‘public domain’. So might be a bit sketchy to copy from.

              +

              Assessment

              +

              Very beautiful, algorithmically elegant, excellent variety of morphology. But

              +
                +
              1. No textures;
              2. +
              3. No wind sway;
              4. +
              5. No roots;
              6. +
              7. No level of detail handler;
              8. +
              9. No leaves;
              10. +
              11. No modelling of bough curvature;
              12. +
              13. Wrong language;
              14. +
              15. Relatively poorly structured code;
              16. +
              17. No documentation.
              18. +
              +

              This would be great to steal inspiration from for a new library of my own, and could possibly be used to inspire a significant extension to SimArboreal, but in its current state it isn’t usable.

              +

              What none of the candidates offer

              +

              None of the candidates have

              +
                +
              1. Seasonal change;
              2. +
              3. Species prototypes;
              4. +
              5. Broken boughs;
              6. +
              7. Leaning or nonstraight primary trunks;
              8. +
              +

              These are all features I want. The same cherry tree encountered in spring should be bedecked with blossom; in summer, green leaved; in autumn, red leaved and heavy with berries; in winter, bare. As seasons change as the player explores the game world, the trees need to change with them.

              +

              Cherries need to have green leaves tapering to a point at both ends, pink flowers in late spring, large red berries (and flocks of birds) in autumn. They need to have moderately tall trunks with upward pointing, quite stiff boughs. Pines need to have the same dark green needles all the way through the year, and, typically, tall straight trunks with a few irregular coronets of living branches near the top and occasional dead and probcably broken boughs lower down. And so on. I need the same procedural code to be able to generate thousands to millions of recognisably distinct individual trees of a biome-appropriate variety of recognisable species across the map.

              +

              They need to be individual and distinct at least partly because users are likely to recognise some of them as landmarks. And they need to be reproducably generatable from mininal seeds, because there’s no way you can store that many models at anything like the level of detail I need.

              +

              Conclusion

              +

              At this point it’s a choice between rolling my own, or using Paul Speed’s SimArboreal and enhancing it (hopefully with his approval and co-operation). In the short term, if I finalise the engine decision on jME3 (and I think I’m fairly close to doing that), SimArboreal will do as a placeholder. However, I will continue to look for other possibilities, because I have so many other things to build, and although I do want good quality forests I don’t have that much time to invest in them just now.

              +
              \ No newline at end of file diff --git a/docs/codox/Uncanny_dialogue.html b/docs/codox/Uncanny_dialogue.html index bd58062..7d3bc69 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 01c4a4e..eb5386a 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 index 6cc6d8e..fd544fd 100644 --- a/docs/codox/Worlds-and-flats.html +++ b/docs/codox/Worlds-and-flats.html @@ -1,6 +1,6 @@ -Worlds and flats [obsolete]

              Worlds and flats obsolete

              +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…

              diff --git a/docs/codox/cc.journeyman.the-great-game.agent.agent.html b/docs/codox/cc.journeyman.the-great-game.agent.agent.html new file mode 100644 index 0000000..d0abdca --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.agent.agent.html @@ -0,0 +1,24 @@ + +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 ebdd84e..a1d6bc4 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 +
              \ 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 cbd7288..cb3556f 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 new file mode 100644 index 0000000..044f4a1 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html @@ -0,0 +1,39 @@ + +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.character.sex.html b/docs/codox/cc.journeyman.the-great-game.character.sex.html new file mode 100644 index 0000000..b5e3119 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.character.sex.html @@ -0,0 +1,4 @@ + +cc.journeyman.the-great-game.character.sex documentation

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

                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 9431123..c361b01 100644 --- a/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html +++ b/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html @@ -1,10 +1,10 @@ -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.

                -

                gather-news

                (gather-news world gossip)

                Gather news for the specified gossip in this world.

                -

                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 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 +

                gather-news

                (gather-news world gossip)

                Gather news for the specified gossip in this world.

                +

                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 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/cc.journeyman.the-great-game.gossip.news-items.html b/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html index 8e65b18..05f02e1 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

              @@ -16,26 +16,26 @@

              TODO
              This namespace at present considers the :knowledge of a gossip to be a flat list of propositions, each of which must be checked every time any new proposition is offered. This is woefully inefficient.

              all-known-verbs

              All verbs currently known to the gossip system.

              -

              compatible-item?

              (compatible-item? new-item known-item)

              True if new-item is identical with, or less specific than, known-item.

              +

              compatible-item?

              (compatible-item? new-item known-item)

              True if new-item is identical with, or less specific than, known-item.

              If we already know ‘Bad Joe killed Sweet Daisy’, there’s no point in learning that ‘someone killed Sweet Daisy’, but there is point in learning ‘someone killed Sweet Daisy with poison’.

              -

              compatible-value?

              (compatible-value? new-value known-value)

              True if known-value is the same as new-value, or, for each key present in new-value, has the same value for that key.

              +

              compatible-value?

              (compatible-value? new-value known-value)

              True if known-value is the same as new-value, or, for each key present in new-value, has the same value for that key.

              The rationale here is that if new-value contains new or different information, it’s worth learning; otherwise, not.

              -

              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.

              -

              degrade-news-item

              (degrade-news-item gossip item)

              TODO: write docs

              -

              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 location)

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

              -

              interesting-object?

              (interesting-object? gossip object)

              TODO: write docs

              -

              interesting-verb?

              (interesting-verb? gossip verb)

              Is this verb interesting to this gossip?

              -

              known-item?

              (known-item? gossip item)

              True if this news item is already known to this gossip.

              +

              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.

              +

              degrade-news-item

              (degrade-news-item gossip item)

              TODO: write docs

              +

              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 location)

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

              +

              interesting-object?

              (interesting-object? gossip object)

              TODO: write docs

              +

              interesting-verb?

              (interesting-verb? gossip verb)

              Is this verb interesting to this gossip?

              +

              known-item?

              (known-item? gossip item)

              True if this news item is already known to this gossip.

              This means that the gossip already knows an item which identifiably has the same or more specific values for all the keys of this item except :nth-hand, :confidence and :learned-from.

              -

              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 set 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:

              +

              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 set 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;
              • @@ -51,4 +51,4 @@ This namespace at present considers the :knowledge of a gossip to b

                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 +
              \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.holdings.holding.html b/docs/codox/cc.journeyman.the-great-game.holdings.holding.html new file mode 100644 index 0000000..6e9868c --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.holdings.holding.html @@ -0,0 +1,6 @@ + +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.launcher.html b/docs/codox/cc.journeyman.the-great-game.launcher.html new file mode 100644 index 0000000..642e423 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.launcher.html @@ -0,0 +1,8 @@ + +cc.journeyman.the-great-game.launcher documentation

              cc.journeyman.the-great-game.launcher

              Launcher for the game

              +

              -main

              (-main & args)

              Launch the game.

              +

              cli-options

              I haven’t yet thought out what command line arguments (if any) I need. This is a placeholder.

              +

              game

              TODO: write docs

              +

              init

              (init)

              Again, placeholder. This initialises a bit of standard jMonkeyEngine terrain, just to check I have things wired up correctly.

              +
              \ 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 baa26fd..58f9862 100644 --- a/docs/codox/cc.journeyman.the-great-game.location.location.html +++ b/docs/codox/cc.journeyman.the-great-game.location.location.html @@ -1,9 +1,9 @@ -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

              settlement

              (settlement location)

              Return the settlement record of the settlement in this world within whose parish polygon this location exists, or if none whose centre (inn location) is closest to this location

              terrain-altitude

              (terrain-altitude location)

              Return the ‘ground level’ (altitude of the terrain) at this location given this world. TODO: possibly terrain-altitude should be a method of the world.

              -
              \ No newline at end of file +
              \ No newline at end of file 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 e375cba..41543d0 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 e8a056e..218b1b4 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.markets.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.markets.html @@ -1,8 +1,8 @@ -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.

              -

              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 +

              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/cc.journeyman.the-great-game.merchants.merchant-utils.html b/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html index b6d2926..396df8e 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,10 +1,10 @@ -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.

              -

              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 +

              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/cc.journeyman.the-great-game.merchants.planning.html b/docs/codox/cc.journeyman.the-great-game.merchants.planning.html index d7c2427..c0baaf3 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.planning.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.planning.html @@ -1,9 +1,9 @@ -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.

              +

              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;
              • @@ -15,8 +15,8 @@
              • :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.

              +

              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;
              • @@ -28,5 +28,5 @@
              • :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 +

              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/cc.journeyman.the-great-game.objects.character.html b/docs/codox/cc.journeyman.the-great-game.objects.character.html index 5bf31d2..8281b8d 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 21b1266..084edf1 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 64ead8c..f69bdf0 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,7 +1,7 @@ -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.

              -
              \ No newline at end of file +
              \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.playroom.html b/docs/codox/cc.journeyman.the-great-game.playroom.html index 5e176fc..e79a5f0 100644 --- a/docs/codox/cc.journeyman.the-great-game.playroom.html +++ b/docs/codox/cc.journeyman.the-great-game.playroom.html @@ -1,7 +1,7 @@ -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

              -
              \ No newline at end of file +

              init

              (init)

              TODO: write docs

              +

              simple-update

              (simple-update tpf)

              TODO: write docs

              +
              \ No newline at end of file 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 6d9d500..77dae36 100644 --- a/docs/codox/cc.journeyman.the-great-game.proving.core.html +++ b/docs/codox/cc.journeyman.the-great-game.proving.core.html @@ -1,11 +1,11 @@ -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).

              -

              get-road-map

              (get-road-map populated-world)

              TODO: write docs

              -

              populate-cell

              (populate-cell world cell)

              TODO: write docs

              -

              populate-world

              (populate-world biome-map)

              Given this biome-map (as returned by get-biome-map), populate a world (probably some form of database) and return a structure which allows that database o be interrogated.

              -

              prove

              (prove height-map rainfall-map)

              Given this height-map (a monochrome raster) and optionally this rainfall-map (also a monochrome raster), return a populated world.

              -
              \ No newline at end of file +

              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).

              +

              get-road-map

              (get-road-map _populated-world)

              TODO: write docs

              +

              populate-cell

              (populate-cell world cell)

              TODO: write docs

              +

              populate-world

              (populate-world biome-map)

              Given this biome-map (as returned by get-biome-map), populate a world (probably some form of database) and return a structure which allows that database o be interrogated.

              +

              prove

              (prove height-map rainfall-map)

              Given this height-map (a monochrome raster) and optionally this rainfall-map (also a monochrome raster), return a populated world.

              +
              \ No newline at end of file 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 936d86b..7bdcba6 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

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

              +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 8fb540c..e7e7a22 100644 --- a/docs/codox/cc.journeyman.the-great-game.time.html +++ b/docs/codox/cc.journeyman.the-great-game.time.html @@ -1,22 +1,22 @@ -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.

              -

              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 +

              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/cc.journeyman.the-great-game.utils.html b/docs/codox/cc.journeyman.the-great-game.utils.html index e13d5bd..d9b9a36 100644 --- a/docs/codox/cc.journeyman.the-great-game.utils.html +++ b/docs/codox/cc.journeyman.the-great-game.utils.html @@ -1,10 +1,10 @@ -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.

              -

              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.

              -

              truthy?

              (truthy? val)

              Returns true unless val is nil, false or an empty sequence. Otherwise always ‘false’; never any other value.

              -

              value-or-default

              (value-or-default m k dflt)

              Return the value of this key k in this map m, or this dflt value if there is none.

              -
              \ No newline at end of file +

              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.

              +

              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.

              +

              truthy?

              (truthy? val)

              Returns true unless val is nil, false or an empty sequence. Otherwise always ‘false’; never any other value.

              +

              value-or-default

              (value-or-default m k dflt)

              Return the value of this key k in this map m, or this dflt value if there is none.

              +
              \ No newline at end of file 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 438d843..a9afcff 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.heightmap.html +++ b/docs/codox/cc.journeyman.the-great-game.world.heightmap.html @@ -1,14 +1,14 @@ -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.

              -

              get-surface

              (get-surface cell-size x-offset y-offset width height)(get-surface base-map noise-map cell-size x-offset y-offset width height)

              Return, as a vector of vectors of cells represented as Clojure maps, a segment of surface from this base-map as modified by this noise-map at this cell-size starting at this x-offset and y-offset and having this width and height.

              +

              *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.

              +

              get-surface

              (get-surface cell-size x-offset y-offset width height)(get-surface base-map noise-map cell-size x-offset y-offset width height)

              Return, as a vector of vectors of cells represented as Clojure maps, a segment of surface from this base-map as modified by this noise-map at this cell-size starting at this x-offset and y-offset and having this width and height.

              If base-map and noise-map are not supplied, the bindings of *base-map* and *noise-map* will be used, respectively.

              base-map and noise-map may be passed either as strings, assumed to be file paths of PNG files, or as MicroWorld style world arrays. It is assumed that one pixel in base-map represents one square kilometre in the game world. It is assumed that cell-size, x-offset, y-offset, width and height are integer numbers of metres.

              -

              interpolate-altitude

              (interpolate-altitude cell grid src-width x-offset y-offset)

              Return the altitude of the point at x-offset, y-offset within this cell having this src-width, taken from this grid.

              -

              interpolate-cell

              (interpolate-cell cell grid src-width target-width)

              Construct a grid (array of arrays) of cells each of width target-width from this cell, of width src-width, taken from this grid

              -

              interpolate-grid

              (interpolate-grid grid src-width target-width)

              Return a grid interpolated from this grid of rows, cols given scaling from this src-width to this target-width

              -

              scale-grid

              (scale-grid grid n)

              multiply all :x and :y values in this grid by this n.

              -
              \ No newline at end of file +

              interpolate-altitude

              (interpolate-altitude cell grid src-width x-offset y-offset)

              Return the altitude of the point at x-offset, y-offset within this cell having this src-width, taken from this grid.

              +

              interpolate-cell

              (interpolate-cell cell grid src-width target-width)

              Construct a grid (array of arrays) of cells each of width target-width from this cell, of width src-width, taken from this grid

              +

              interpolate-grid

              (interpolate-grid grid src-width target-width)

              Return a grid interpolated from this grid of rows, cols given scaling from this src-width to this target-width

              +

              scale-grid

              (scale-grid grid n)

              multiply all :x and :y values in this grid by this n.

              +
              \ No newline at end of file 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 5a11cfb..6337bce 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 +

              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 c85cd92..d18ed77 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 e353b4f..91eef2e 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 +

              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.world.html b/docs/codox/cc.journeyman.the-great-game.world.world.html index 931e1b3..8fc8010 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.world.html +++ b/docs/codox/cc.journeyman.the-great-game.world.world.html @@ -1,7 +1,7 @@ -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.

              -
              \ No newline at end of file +

              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 diff --git a/docs/codox/index.html b/docs/codox/index.html index 86444b9..0ff7994 100644 --- a/docs/codox/index.html +++ b/docs/codox/index.html @@ -1,17 +1,20 @@ -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.

              +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.

              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.character.sex

                TODO: write docs

                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.launcher

                  Launcher for the game

                  +

                  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.

                    -

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

                    Trade planning for merchants, primarily.

                    -

                    Public variables and functions:

                    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.strategies.simple

                    Default trading strategy for merchants.

                    -

                    Public variables and functions:

                    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.objects.character

                    TODO: write docs

                    Public variables and functions:

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

                      TODO: write docs

                      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

                      diff --git a/docs/codox/intro.html b/docs/codox/intro.html index c85a188..bb68b07 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/project.clj b/project.clj index df18295..4b3536a 100644 --- a/project.clj +++ b/project.clj @@ -18,7 +18,8 @@ [com.github.seancorfield/next.jdbc "1.3.925"] [com.simsilica/lemur "1.16.1-SNAPSHOT"] [com.simsilica/sim-arboreal "1.0.1-SNAPSHOT"] - [com.taoensso/timbre "6.5.0"] + ;; [com.taoensso/timbre "6.5.0"] + [com.taoensso/telemere "1.0.0-beta3"] ;; Peter Taoussanis' new replacement for Timbre [environ "1.2.0"] [hiccup "2.0.0-RC3"] [jme-clj "0.1.13"] diff --git a/src/clj/cc/journeyman/the_great_game/gossip/news_items.clj b/src/clj/cc/journeyman/the_great_game/gossip/news_items.clj index ce97716..95fce1f 100644 --- a/src/clj/cc/journeyman/the_great_game/gossip/news_items.clj +++ b/src/clj/cc/journeyman/the_great_game/gossip/news_items.clj @@ -34,7 +34,7 @@ [cc.journeyman.the-great-game.world.location :refer [distance-between]] [cc.journeyman.the-great-game.time :refer [game-time]] [cc.journeyman.the-great-game.utils :refer [inc-or-one truthy?]] - [taoensso.timbre :as l])) + [taoensso.telemere.timbre :as l])) (declare interesting-location?) diff --git a/src/clj/cc/journeyman/the_great_game/merchants/markets.clj b/src/clj/cc/journeyman/the_great_game/merchants/markets.clj index 09bce1a..fea7916 100644 --- a/src/clj/cc/journeyman/the_great_game/merchants/markets.clj +++ b/src/clj/cc/journeyman/the_great_game/merchants/markets.clj @@ -1,6 +1,6 @@ (ns cc.journeyman.the-great-game.merchants.markets "Adjusting quantities and prices in markets." - (:require [taoensso.timbre :as l :refer [info error]] + (:require [taoensso.telemere.timbre :as l :refer [info error]] [cc.journeyman.the-great-game.utils :refer [deep-merge]])) (defn new-price diff --git a/src/clj/cc/journeyman/the_great_game/merchants/merchants.clj b/src/clj/cc/journeyman/the_great_game/merchants/merchants.clj index a4124b4..d29aa82 100644 --- a/src/clj/cc/journeyman/the_great_game/merchants/merchants.clj +++ b/src/clj/cc/journeyman/the_great_game/merchants/merchants.clj @@ -2,7 +2,7 @@ "Trade planning for merchants, primarily." (:require [cc.journeyman.the-great-game.utils :refer [deep-merge]] [cc.journeyman.the-great-game.merchants.strategies.simple :refer [move-merchant]] - [taoensso.timbre :as l])) + [taoensso.telemere.timbre :as l])) (defn run diff --git a/src/clj/cc/journeyman/the_great_game/merchants/strategies/simple.clj b/src/clj/cc/journeyman/the_great_game/merchants/strategies/simple.clj index b8062f7..1a6ddb7 100644 --- a/src/clj/cc/journeyman/the_great_game/merchants/strategies/simple.clj +++ b/src/clj/cc/journeyman/the_great_game/merchants/strategies/simple.clj @@ -6,7 +6,7 @@ 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." - (:require [taoensso.timbre :as l :refer [info error spy]] + (:require [taoensso.telemere.timbre :as l :refer [info error spy]] [cc.journeyman.the-great-game.utils :refer [deep-merge]] [cc.journeyman.the-great-game.gossip.gossip :refer [move-gossip]] [cc.journeyman.the-great-game.merchants.planning :refer [augment-plan plan-trade select-cargo]] @@ -72,7 +72,6 @@ (map? merchant) merchant) id (:id m) - location (:location m) plan (augment-plan m world (plan-trade m world (-> m :plan :commodity)))] (l/debug "re-plan: merchant" id) (deep-merge diff --git a/src/clj/cc/journeyman/the_great_game/proving/core.clj b/src/clj/cc/journeyman/the_great_game/proving/core.clj index ce3fe76..9a40823 100644 --- a/src/clj/cc/journeyman/the_great_game/proving/core.clj +++ b/src/clj/cc/journeyman/the_great_game/proving/core.clj @@ -6,7 +6,7 @@ [mw-engine.heightmap :refer [apply-heightmap]] [mw-engine.utils :refer [map-world]] [mw-parser.declarative :refer [compile]] - [taoensso.timbre :refer [info]] + [taoensso.telemere.timbre :refer [info]] [wherefore-art-thou.core :refer [*genders* generate]])) (defn get-drainage-map @@ -45,17 +45,19 @@ ;; persist them in the database being built. This is just a sketch. [prototype] (let [g (or (:gender prototype) (rand-nth (keys *genders*))) - p (generate g)] - (dissoc (merge {:age (+ 18 (rand-int 18)) - :disposition (- (rand-int 9) 4) ;; -4: surly to +4 sunny - :gender g - :goal (rand-nth *life-goals*) - :family-name (generate) - :occupation :vagrant - :personal-name p} prototype) - ;; it's useful to have the world available to the create function, - ;; but we don't want to return it in the results because clutter. - :world))) + p (generate g) + npc (dissoc (merge {:age (+ 18 (rand-int 18)) + :disposition (- (rand-int 9) 4) ;; -4: surly to +4 sunny + :gender g + :goal (rand-nth *life-goals*) + :family-name (generate) + :occupation :vagrant + :personal-name p} prototype) + ;; it's useful to have the world available to the create function, + ;; but we don't want to return it in the results because clutter. + :world)] + (info (format "Created NPC %s" (select-keys npc [:id :family-name :personal-name :age :gender :occupation :goal]))) + )) (defn- populate-npcs [prototype] @@ -65,7 +67,7 @@ (defn populate-cell [world cell] - ;; (info (format "populate-cell: w is %s; cell is %s" (type world) cell)) + (info (format "populate-cell: w is %s; cell is %s" (type world) cell)) (let [npcs (case (:state cell) :camp (populate-npcs {:world world :cell cell :occupation :nomad}) :house (populate-npcs {:world world :cell cell :occupation :peasant}) diff --git a/src/clj/cc/journeyman/the_great_game/world/run.clj b/src/clj/cc/journeyman/the_great_game/world/run.clj index 081d247..3b52d42 100644 --- a/src/clj/cc/journeyman/the_great_game/world/run.clj +++ b/src/clj/cc/journeyman/the_great_game/world/run.clj @@ -1,7 +1,7 @@ (ns cc.journeyman.the-great-game.world.run "Run the whole simulation" (:require [environ.core :refer [env]] - [taoensso.timbre :as timbre] + [taoensso.telemere.timbre :as timbre] [taoensso.timbre.appenders.3rd-party.rotor :as rotor] [cc.journeyman.the-great-game.gossip.gossip :as g] [cc.journeyman.the-great-game.merchants.merchants :as m] diff --git a/workspace.code-workspace b/workspace.code-workspace index 8113fcd..1b0e3d9 100644 --- a/workspace.code-workspace +++ b/workspace.code-workspace @@ -29,6 +29,9 @@ }, { "path": "../../Documents/fiction/merchants-war-game" + }, + { + "path": "../simulated-genetics" } ], "settings": {