From 0ba575c2f98e65e690cd45346c8a4427da4ceefe Mon Sep 17 00:00:00 2001 From: Simon Brooke Date: Wed, 3 Apr 2024 17:36:39 +0100 Subject: [PATCH] Much work on tidying documentation, uncompleted. --- doc/{API Spec.md => API_Spec.md} | 4 +- doc/Appraisal.md | 2 +- ...s and ecology.md => Biomes_and_ecology.md} | 4 +- ...ion_of_tasks_between_server_and_client.md} | 2 +- doc/{economy.md => Economy.md} | 8 +- doc/Game-engine-integration.md | 2 +- doc/Game_Play.md | 16 +- ...sip_scripted_plot_and_Johnny_Silverhand.md | 2 +- doc/MVP-Roadmap.md | 6 +- ...e.md => Modelling_democracy_and_morale.md} | 4 +- ....md => Modelling_trading_cost_and_risk.md} | 2 +- doc/My-setting.md | 5 - ...-characters.md => Naming-of-characters.md} | 0 doc/{Not my problem.md => Not_my_problem.md} | 0 doc/{on-dying.md => On-dying.md} | 0 doc/On-sex-and-sexual-violence.md | 23 +- ...ng Character.md => Selecting_Character.md} | 0 ...md => Things_Voice_Interaction_Enables.md} | 0 doc/genetic-buildings.md | 62 ++- docs/codox/API_Spec.html | 20 + docs/codox/Appraisal.html | 29 ++ docs/codox/Baking-the-world.html | 43 ++- docs/codox/Biomes_and_ecology.html | 66 ++++ docs/codox/Canonical-dictionary.html | 35 +- ...on_of_tasks_between_server_and_client.html | 19 + docs/codox/Dynamic-consequences.html | 47 +-- docs/codox/Economy.html | 36 ++ docs/codox/Further-reading.html | 13 + docs/codox/Game-engine-integration.html | 7 + docs/codox/Game_Play.html | 50 ++- ...p_scripted_plot_and_Johnny_Silverhand.html | 41 +- docs/codox/MVP-Roadmap.html | 42 ++ .../codox/Modelling_democracy_and_morale.html | 18 + .../Modelling_trading_cost_and_risk.html | 8 + docs/codox/My-setting.html | 6 + docs/codox/Naming-of-characters.html | 32 ++ docs/codox/Not_my_problem.html | 21 + docs/codox/On-dying.html | 17 + docs/codox/On-sex-and-sexual-violence.html | 36 ++ docs/codox/Organic_Quests.html | 37 +- docs/codox/Pathmaking.html | 91 ++--- docs/codox/Populating-a-game-world.html | 360 +++++------------- docs/codox/Roadmap.html | 27 +- docs/codox/Selecting_Character.html | 52 +++ docs/codox/Settling-a-game-world.html | 85 +++-- docs/codox/Simulation-layers.html | 11 +- ...ad-of-knowledge-in-a-large-game-world.html | 27 +- .../Things_Voice_Interaction_Enables.html | 42 ++ docs/codox/Uncanny_dialogue.html | 5 +- .../Voice-acting-considered-harmful.html | 37 +- ...anning-algorithm-for-craftworker-npcs.html | 69 ++++ docs/codox/building_on_microworld.html | 5 +- ...journeyman.the-great-game.agent.agent.html | 26 +- ...rneyman.the-great-game.agent.schedule.html | 5 + ...eyman.the-great-game.buildings.module.html | 43 ++- ....the-great-game.buildings.rectangular.html | 39 +- ...c.journeyman.the-great-game.cloverage.html | 6 + ...urneyman.the-great-game.gossip.gossip.html | 9 +- ...yman.the-great-game.gossip.news-items.html | 60 ++- ...eyman.the-great-game.holdings.holding.html | 5 +- ...yman.the-great-game.location.location.html | 8 +- ...urneyman.the-great-game.lore.digester.html | 4 + ...yman.the-great-game.merchants.markets.html | 7 +- ...e-great-game.merchants.merchant-utils.html | 9 +- ...an.the-great-game.merchants.merchants.html | 4 +- ...man.the-great-game.merchants.planning.html | 46 ++- ...reat-game.merchants.strategies.simple.html | 9 +- ...yman.the-great-game.objects.character.html | 4 + ...yman.the-great-game.objects.container.html | 5 +- ...an.the-great-game.objects.game-object.html | 6 +- ...cc.journeyman.the-great-game.playroom.html | 6 +- .../cc.journeyman.the-great-game.time.html | 21 +- .../cc.journeyman.the-great-game.utils.html | 9 +- ...neyman.the-great-game.world.heightmap.html | 13 +- ...rneyman.the-great-game.world.location.html | 5 +- ...cc.journeyman.the-great-game.world.mw.html | 3 +- ...ourneyman.the-great-game.world.routes.html | 5 +- ...journeyman.the-great-game.world.world.html | 6 +- docs/codox/economy.html | 45 ++- docs/codox/genetic-buildings.html | 46 +++ docs/codox/index.html | 28 +- docs/codox/intro.html | 134 +++---- .../modelling_trading_cost_and_risk.html | 5 +- docs/codox/naming-of-characters.html | 32 +- docs/codox/on-dying.html | 12 +- docs/codox/sandbox.html | 46 +-- docs/codox/sexual-dimorphism.html | 25 +- project.clj | 2 +- .../journeyman/the_great_game/agent/agent.clj | 82 ++-- .../the_great_game/lore/digester.clj | 7 +- 90 files changed, 1565 insertions(+), 838 deletions(-) rename doc/{API Spec.md => API_Spec.md} (96%) rename doc/{Biomes and ecology.md => Biomes_and_ecology.md} (99%) rename doc/{Division of tasks between server and client.md => Division_of_tasks_between_server_and_client.md} (97%) rename doc/{economy.md => Economy.md} (75%) rename doc/{Modelling democracy and morale.md => Modelling_democracy_and_morale.md} (92%) rename doc/{modelling_trading_cost_and_risk.md => Modelling_trading_cost_and_risk.md} (96%) delete mode 100644 doc/My-setting.md rename doc/{naming-of-characters.md => Naming-of-characters.md} (100%) rename doc/{Not my problem.md => Not_my_problem.md} (100%) rename doc/{on-dying.md => On-dying.md} (100%) rename doc/{Selecting Character.md => Selecting_Character.md} (100%) rename doc/{Things Voice Interaction Enables.md => Things_Voice_Interaction_Enables.md} (100%) mode change 120000 => 100644 doc/genetic-buildings.md create mode 100644 docs/codox/API_Spec.html create mode 100644 docs/codox/Appraisal.html create mode 100644 docs/codox/Biomes_and_ecology.html create mode 100644 docs/codox/Division_of_tasks_between_server_and_client.html create mode 100644 docs/codox/Economy.html create mode 100644 docs/codox/Further-reading.html create mode 100644 docs/codox/Game-engine-integration.html create mode 100644 docs/codox/MVP-Roadmap.html create mode 100644 docs/codox/Modelling_democracy_and_morale.html create mode 100644 docs/codox/Modelling_trading_cost_and_risk.html create mode 100644 docs/codox/My-setting.html create mode 100644 docs/codox/Naming-of-characters.html create mode 100644 docs/codox/Not_my_problem.html create mode 100644 docs/codox/On-dying.html create mode 100644 docs/codox/On-sex-and-sexual-violence.html create mode 100644 docs/codox/Selecting_Character.html create mode 100644 docs/codox/Things_Voice_Interaction_Enables.html create mode 100644 docs/codox/a-generic-planning-algorithm-for-craftworker-npcs.html create mode 100644 docs/codox/cc.journeyman.the-great-game.agent.schedule.html create mode 100644 docs/codox/cc.journeyman.the-great-game.cloverage.html create mode 100644 docs/codox/cc.journeyman.the-great-game.lore.digester.html create mode 100644 docs/codox/cc.journeyman.the-great-game.objects.character.html create mode 100644 docs/codox/genetic-buildings.html diff --git a/doc/API Spec.md b/doc/API_Spec.md similarity index 96% rename from doc/API Spec.md rename to doc/API_Spec.md index ed84b98..2070d99 100644 --- a/doc/API Spec.md +++ b/doc/API_Spec.md @@ -1,4 +1,4 @@ -# API Spec +# 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. @@ -8,7 +8,7 @@ My preference is still that Gossip should be written in a Lisp-like language - a Existing game engines don't tend to track in convenient form things which have happened off-camera - indeed, mostly, things don't happen at all when the player isn't present. They don't even track much that happens when the player is present, and they usually track what they do track in fairly ad-hoc ways. So generally Gossip-as-library will have to maintain its own history of what has happened, and who knows what about what has happened; and will have to model the major life events of non-player characters happening off-camera (if this is done at all) itself. -## Interrogating lore +## Interrogating lore Many games have a great deal of lore and many lore texts. It's reasonable to expect each non-player character to know a certain amount of lore, certainly lore which is local to their home location, or relevant to their trade. In order to make that available to Gossip, you probably need to construct a searchable corpus of all the lore, which can be simply queried. diff --git a/doc/Appraisal.md b/doc/Appraisal.md index 3ba7b1a..182a703 100644 --- a/doc/Appraisal.md +++ b/doc/Appraisal.md @@ -1,4 +1,4 @@ -# Appraisal +# Appraisal (unfinished) ## What is Appraisal diff --git a/doc/Biomes and ecology.md b/doc/Biomes_and_ecology.md similarity index 99% rename from doc/Biomes and ecology.md rename to doc/Biomes_and_ecology.md index 1d4dab6..2dd83d8 100644 --- a/doc/Biomes and ecology.md +++ b/doc/Biomes_and_ecology.md @@ -1,4 +1,4 @@ -# Biomes and ecology +# 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 @@ -108,7 +108,7 @@ The Tcha is the westernmost — and largest — river of the coast. It e A road branches off from the main Caravan Road at the South Inn and runs down the eastern side of the valley, to a ferry across the Sind river, where it joins the Tcha as a tributary, at the village helpfully known as Sind Ferry, and thence to Tchahua. -Mulberries, by products of the silk industry, are used in the production of brandy. Mulberry wine is produced in villages in the forest, and transported down river to a distillery at Sind Ferry, where it is distilled. Some mulberry wine may be sold in Tchahua for drinking as wine (and it is certainly drunk in the villages), but it is generally considered inferior to grape wine. +Mulberries, by-products of the silk industry, are used in the production of brandy. Mulberry wine is produced in villages in the forest, and transported down river to a distillery at Sind Ferry, where it is distilled. Some mulberry wine may be sold in Tchahua for drinking as wine (and it is certainly drunk in the villages), but it is generally considered inferior to grape wine. There is some arable and mixed agriculture, mainly towards the southern end of the valley on the western (less steep) side, although this side is also largely forested. diff --git a/doc/Division of tasks between server and client.md b/doc/Division_of_tasks_between_server_and_client.md similarity index 97% rename from doc/Division of tasks between server and client.md rename to doc/Division_of_tasks_between_server_and_client.md index c27d3f3..5aec649 100644 --- a/doc/Division of tasks between server and client.md +++ b/doc/Division_of_tasks_between_server_and_client.md @@ -8,7 +8,7 @@ There is something which manages game state and things like the gossip network, The initial idea of The Great Game is that it is a single player game, but it actually doesn't need to be and it would be quite possible for one server to support multiple clients, each being used by a different player. -The server/planner decides what each actor does, models what each character knows, plans and records all actions and transactions. It plans speach acts, and handles conversations which happen off screen, but hands speech texts over to the client/performer layer for actual performance. It also plans journeys as described in [[Pathmaking]], but it doesn't deal with movement within a polygon or with collision avoidance. It deals with fights which happen off screen, but not those that happen on screen. +The server/planner decides what each actor does, models what each character knows, plans and records all actions and transactions. It plans speech acts, and handles conversations which happen off screen, but hands speech texts over to the client/performer layer for actual performance. It also plans journeys as described in [[Pathmaking]], but it doesn't deal with movement within a polygon or with collision avoidance. It deals with fights which happen off screen, but not those that happen on screen. ## What do I mean by the client? diff --git a/doc/economy.md b/doc/Economy.md similarity index 75% rename from doc/economy.md rename to doc/Economy.md index 15111dc..a2882d1 100644 --- a/doc/economy.md +++ b/doc/Economy.md @@ -6,7 +6,7 @@ Broadly this essay extends ideas presented in [Populating a game world](Populati ### Herdsfolk -Herdsfolk are nomadic; it's reasonable to think they'll bring their herds to market, rather than selling it lots of tiny markets. So in the spring, shepherds will visit specific towns at the edge of open land, to hold a shearing festival/carnevale; and that both shepherds and cattle herders will visit towns on the edge of open land to sell fatstock in the autumn. +Herdsfolk are nomadic; it's reasonable to think they'll bring their herds to market, rather than selling at lots of tiny markets. So in the spring, shepherds will visit specific towns at the edge of open land, to hold a shearing festival/carnevale; and that both shepherds and cattle herders will visit towns on the edge of open land to sell fatstock in the autumn. ### Miners @@ -38,7 +38,11 @@ Farmers are all basically subsistence farmers, farming first to feed their own h Crafts generally process primary goods into secondary goods - whether intermediate stages or final consumer items. Some elite 'crafts' deal with abstract primary goods like law and knowledge, and they may be seen as somewhat separate. -A master craftsperson occupies a standard runrig plot, much like a farmer's plot. Like a farmer, a poor master crafter household will cultivate part of the plot to produce food for the house - at least grow vegetables and keep hens. However, as the crafter takes on apprentices and journeymen - and gets richer - more buildings will be required as accommodation, workshop space and materials stores. +A master craftsperson may occupy a standard runrig plot, much like a farmer's plot. Like a farmer, a poor master crafter household will cultivate part of the plot to produce food for the house - at least grow vegetables and keep hens. However, as the crafter takes on apprentices and journeymen - and gets richer - more buildings will be required as accommodation, workshop space and materials stores. + +Also, Tchahua is much more a gold-rush town than an organic, grew over hundreds of years sort of town, so it is not ex-runrig; and additionally the original settlement was probably along the river bank, land which has now been redeveloped as warehouses and as rich merchant residences. Generally, town house plots are small from the get go. + +Hans'hua is again an exception from normal organic development, as it has no agricultural land close to the city at all. Generally, primary goods aren't transported over land - because overland transport is expensive, by the time they've been transported they're no longer low cost goods. So often the craftspeople who process primary produce into at least commodity intermediate forms will live close to the source of the primary goods. diff --git a/doc/Game-engine-integration.md b/doc/Game-engine-integration.md index 32fa0a9..e6f8fa4 100644 --- a/doc/Game-engine-integration.md +++ b/doc/Game-engine-integration.md @@ -1,4 +1,4 @@ -# Game-engine integration +# Game-engine integration (unfinished) To build a game using these ideas we need a lot of things that are well understood and already implemented: rendering a world, moving models of characters in a world, and so on. This collection of technologies which allow us to realise an interactive realisation of a world is typically called a game engine. diff --git a/doc/Game_Play.md b/doc/Game_Play.md index 58c10c6..8071090 100644 --- a/doc/Game_Play.md +++ b/doc/Game_Play.md @@ -2,19 +2,19 @@ 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. Superpower: the player character has some special powers or skills that other characters in the game fo not have. +1. **Superpower**: the player character has some special powers or skills that other characters in the game fo not have. -2. Special status: the player character is 'the chosen one', 'the hero', or even just 'the Witcher' from the very beginning, without having done anything to earn those titles. +2. **Special status**: the player character is 'the chosen one', 'the hero', or even just 'the Witcher' from the very beginning, without having done anything to earn those titles. -3. Boss fights: some non-player characters have special, and specially strong, combat repertoire, and block progress in the game until you overcome them. +3. **Boss fights**: some non-player characters have special, and specially strong, combat repertoire, and block progress in the game until you overcome them. -4. Psychokiller: completing the game necessarily involves beating many, many other characters in combat. +4. **Psychokiller**: completing the game necessarily involves beating many, many other characters in combat. -5. Slaughterhouse: the main way to interact with other characters is to kill them. +5. **Slaughterhouse**: the main way to interact with other characters is to kill them. -7. The Script is King: everything is scripted. The player either can't diverge from the script, or if they do, will find no interesting content. +7. **The Script is King**: everything is scripted. The player either can't diverge from the script, or if they do, will find no interesting content. -6. Dumb and dumber: non-player characters, even important ones, have extremely limited vocal repertoire. +6. **Dumb and dumber**: non-player characters, even important ones, have extremely limited vocal repertoire. Of these, the last two, I think, are key: they are the root cause of the other problems. In fact, to take it further, the real key is the last. We talk a lot about 'Game AI', but really there's nothing remotely approaching artificial intelligence in modern games. Non-player characters do not think; they do not learn; they do not reason; they do not know. They speak only from the script. And they speak only from the script because of the fetish for voice acting. @@ -28,7 +28,7 @@ Suddenly, they can have attitudes about things that happen in the world, opinion And with the emergence of intelligent behaviour comes the emergence of possibilities for negotiation, for diplomacy, for dynamic, unscripted, friendships and romances. Which means, there are things you can do to interact with every non-player character, even ones who are not 'plot' characters, other than just kill them. -And as now gameplay possibilities emerge, as new stories emerge organically out of the dynamically changing relationships between non-player characters in the world, the need for scripting decreases. +And as new gameplay possibilities emerge, as new stories emerge organically out of the dynamically changing relationships between non-player characters in the world, the need for scripting decreases. The problem with scripting is that it greatly limits player agency. The story can only have one of a few predetermined -- literally, scripted -- endings. This is clearly expressed in [a review of Red Dead Redemption 2](https://youtu.be/_JRikiQyzLA) which I recomment to you; but is equally true of almost all other games. diff --git a/doc/Gossip_scripted_plot_and_Johnny_Silverhand.md b/doc/Gossip_scripted_plot_and_Johnny_Silverhand.md index ef2d9b7..8d6d82c 100644 --- a/doc/Gossip_scripted_plot_and_Johnny_Silverhand.md +++ b/doc/Gossip_scripted_plot_and_Johnny_Silverhand.md @@ -15,7 +15,7 @@ What individual characters know should, of course, be more limited. People who l Again, the generation of distinct voices for hundreds of non-player characters isn't any longer a big deal. Distinct social groups -- the corpos, and the different gangs such as Maelstrom or the Mox, will have their own argot, their own slang, their own habitual figures of speech which can be encoded into template libraries, while technologies like Lyrebird can produce an infinite range of realistic-sounding voices. -In particular, they can mimic real voices. They can mimic the voices of real actors. They can mimic [Keanu Reeves](https://cyberpunk.fandom.com/wiki/Keanu_Reeves). +In particular, they can mimic real voices. They can mimic the voices of real actors. They can mimic [Keanu Reeves](https://cyberpunk.fandom.com/wiki/Keanu_Reeves). (Interestingly, since I first wrote this note, CD Projekt Red have used Lyrebird-like technology to [resurrect a voice actor](https://www.theverge.com/2023/10/13/23915535/cyberpunk-2077-phantom-liberty-polish-voice-actor-ai-ripperdock-viktor-vektor) in Phantom Liberty, proving that the technology is good enough). So: how do you integrate this free form 'you can say anything to any character' style of play with scripted plot? diff --git a/doc/MVP-Roadmap.md b/doc/MVP-Roadmap.md index 59d1777..15c5435 100644 --- a/doc/MVP-Roadmap.md +++ b/doc/MVP-Roadmap.md @@ -46,7 +46,11 @@ Different characters should have different voices. ## Prototype four: performative speech -This one is hard because I'm not absolutely sure how I can do it, but I need characters' voices to convey emotion; the player needs to know from their voice whether they are angry, or frightened, or impatient, or bored. +This one is hard because I'm not absolutely sure how I can do it, but I need characters' voices to convey emotion; the player needs to know from their voice whether they are angry, or frightened, or impatient, or bored. + +There is a [W3C specification](https://www.w3.org/TR/speech-synthesis11/) for an XML markup for speech performance, and I can certainly generate that, but I'd need to find a text-to-speech library which could consume it. There's also a separate [specification](https://www.w3.org/TR/pronunciation-lexicon/) to associate pronunciations with lexical tokens, which is also potentially useful, especially for names. + +Google has a '[Cloud Text-to-Speech](https://cloud.google.com/text-to-speech/docs/ssml)' service which understands SSML and might be good enough for a demo but is more likely just embarrassingly bad. ## Prototype five traversible world diff --git a/doc/Modelling democracy and morale.md b/doc/Modelling_democracy_and_morale.md similarity index 92% rename from doc/Modelling democracy and morale.md rename to doc/Modelling_democracy_and_morale.md index a892b82..aa35d29 100644 --- a/doc/Modelling democracy and morale.md +++ b/doc/Modelling_democracy_and_morale.md @@ -1,4 +1,4 @@ -# The Red Company: modelling democracy and morale +# The Red Company: modelling democracy and morale (unfinished) ## Background @@ -25,3 +25,5 @@ One of the themes of the stories I want to tell is that this more democratic str ## Modelling democracy If each individual character has a hierarchy of needs, and plans actions based on that hierarchy of needs, then they have the mechanism in place to choose which of two options better conforms to their hierarchy of needs. + +This implies that soldiers are likely to vote for the people (or ideas presented by the people) they consider most competent and/or most trustworthy. Which comes back to modelling reputation; which comes back to the [gossip](the-great-game.gossip.gossip.html). \ No newline at end of file diff --git a/doc/modelling_trading_cost_and_risk.md b/doc/Modelling_trading_cost_and_risk.md similarity index 96% rename from doc/modelling_trading_cost_and_risk.md rename to doc/Modelling_trading_cost_and_risk.md index 78ae9dd..a62daeb 100644 --- a/doc/modelling_trading_cost_and_risk.md +++ b/doc/Modelling_trading_cost_and_risk.md @@ -1,4 +1,4 @@ -# Modelling trading cost and risk +# 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. diff --git a/doc/My-setting.md b/doc/My-setting.md deleted file mode 100644 index 6dc7020..0000000 --- a/doc/My-setting.md +++ /dev/null @@ -1,5 +0,0 @@ -# My setting for the Great Game - -It should be evident that all the key ideas in The Great Game project would be applicable to games set in the historic past of our world, to games set in its present, or to games set in some imagined or forecast future; the ideas are intended to be, and I believe are, largely independent of setting. - -Nevertheless I feel the need for a concrete setting to ground the development of ideas. I've chosen deliberately not to place that setting in the real world; although it's broadly based on cultures from the late bronze age/early iron age mediterrainian. diff --git a/doc/naming-of-characters.md b/doc/Naming-of-characters.md similarity index 100% rename from doc/naming-of-characters.md rename to doc/Naming-of-characters.md diff --git a/doc/Not my problem.md b/doc/Not_my_problem.md similarity index 100% rename from doc/Not my problem.md rename to doc/Not_my_problem.md diff --git a/doc/on-dying.md b/doc/On-dying.md similarity index 100% rename from doc/on-dying.md rename to doc/On-dying.md diff --git a/doc/On-sex-and-sexual-violence.md b/doc/On-sex-and-sexual-violence.md index e654307..3bdaaca 100644 --- a/doc/On-sex-and-sexual-violence.md +++ b/doc/On-sex-and-sexual-violence.md @@ -6,7 +6,7 @@ It would be ludicrous to argue 'sexual violence is wrong, therefore we should no 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. -Secondly, it is extremely tricky to represent sexual violence in visual media without eroticising it. There's a [very famous scene in Last Tango in Paris](https://www.independent.co.uk/arts-entertainment/films/news/last-tango-in-paris-butter-scene-b2270513.html) which the director might claim is consented in context, but which appears to me to be a clear case of anal rape, which is nevertheless highly erotic. There's a scene in [High Plains Drifter](https://en.wikipedia.org/wiki/High_Plains_Drifter#Plot) where no part of the rape is actually represented — it happens off screen — but it is nevertheless perceived by many people (including me) as eroticised. Many people — I suspect more men than women, but certainly including women — do find the idea of rape erotic. It seems to me highly undesirable that a game should be seen to be rewarding immoral action. +Secondly, it is extremely tricky to represent sexual violence in visual media without eroticising it. There's a [very famous scene in Last Tango in Paris](https://www.independent.co.uk/arts-entertainment/films/news/last-tango-in-paris-butter-scene-b2270513.html) which the director might claim is consented in context, but which appears to me to be a clear case of anal rape, which is nevertheless highly erotic. There's a scene in [High Plains Drifter](https://en.wikipedia.org/wiki/High_Plains_Drifter#Plot) where no part of the rape is actually represented — it happens off screen — but it is nevertheless perceived by many people (including me) as eroticised. Many people — I suspect more men than women, but certainly including many women — do find the idea of rape erotic. It seems to me highly undesirable that a game should be seen to be rewarding immoral action. (Yes, I know many modern games do quite explicitly reward killing, including of characters whose culpability is at best trivial, but — surely — this is something we should be seeking to move away from.) @@ -40,7 +40,7 @@ If we're going to represent a society in which public sex is normal, then we're By 'eroticised', I'm meaning deliberately intended to trigger sexual feelings in the audience — which, if the player character is present, includes the player. -## Sexual violence between non-player characters +## Sexual violence between non-player characters In a world in which there are characters who are thuggish, who seek to dominate, terrorise and subdue other characters, whether those characters are outlaws or soldiers or aristocrats, to pretend that rape would not be used as a means to dominate, terrorise or subdue is… bowdlerisation. It's unrealistic, and it's a morally indefensible choice. @@ -50,7 +50,24 @@ So there has to be a mechanism for non-player characters to decide to commit act Mutually consented sexual behaviour between the player character and (certain, scripted) non-player characters has been a feature of video games for some time, and has occasionally been portrayed with real sensitivity and eroticism. Two cases I would point to are -1. The sex scene between Geralt and Shani in [The Witcher]() +1. The sex scene between Geralt and Shani in The Witcher; +2. The sex scene between V and Judy in Cyberpunk 2077. + +Cyberpunk is a largely non-cutscene game, but the sex scenes is a cutscenes and I completely understand why, from a technical point of view: the player does not have, either with mouse and keyboard or with a game controller, nearly enough control over their character to convey the subtlety and nuance of a good sex scene. Sex scenes in most video games are also pretty rare, and that must be at least partly because of cultural prurience. + +But if a game allows a player to have a long lasting, narratively sexual relationship with a non-player character, as many games do, then sex is a behaviour which may happen repeatedly, and just playing the same cutscene over and over again is not going to be an adequate way of representing that. + +The ideal would be to have a moderately large library of brief motion captures of people authentically having sex, and to be able to select performances at random from that library to apply to the body models of the characters who in the game are having sex, whether that be the player character with a non-player character, or two non-player characters. In the case where the player character is involved, this would happen in the location where the player chose to initiate it, so it wouldn't be a cutscene in the normal sense; but I think that the controller should be disabled for the duration of the performance. + +## Sexual violence by one non-player character towards another + +This is at least implicitly represented in existing video games, and while caution about eroticising it should be maintained, I think it's something which should be narratively possible. ## Sexual violence from the player character towards non-player characters +This would be extremely tricky (and controversial!) to handle; I *think* it ought to be in the narrative toolkit, but I have no specification to offer just now. + +## Sexual violence from a non-player character towards the player character + +Even trickier! + diff --git a/doc/Selecting Character.md b/doc/Selecting_Character.md similarity index 100% rename from doc/Selecting Character.md rename to doc/Selecting_Character.md diff --git a/doc/Things Voice Interaction Enables.md b/doc/Things_Voice_Interaction_Enables.md similarity index 100% rename from doc/Things Voice Interaction Enables.md rename to doc/Things_Voice_Interaction_Enables.md diff --git a/doc/genetic-buildings.md b/doc/genetic-buildings.md deleted file mode 120000 index 7c86ff4..0000000 --- a/doc/genetic-buildings.md +++ /dev/null @@ -1 +0,0 @@ -workspace/blogiv/content/md/posts/2013-07-04-genetic-buildings.md \ No newline at end of file diff --git a/doc/genetic-buildings.md b/doc/genetic-buildings.md new file mode 100644 index 0000000..59f1edb --- /dev/null +++ b/doc/genetic-buildings.md @@ -0,0 +1,61 @@ +# Genetic Buildings + +### Building selection based on location + + The objective of this note is to create a landscape with varied and believable buildings, with the minimum possible data storage per instance. + + Like plants, buildings will 'grow' from a seed which has northing and easting attributes. These locate a position on the map. Again, like trees, some aspects of the building type selector are location based. Aspects of the location which are relevant to building type are + +* **elevation** — derived from the map location by interpolation from grid. The actual interpolation algorithm is probably some form of spline, but in any case it's the same one as for everything else. +* **orientation of slope** — derived by taking altitude at four corners of a 100 metre square centred on the seed point, and then taking the highest and lowest of these. If highest is northwest, lowest is southeast, the slope is considered to be oriented southeast; if highest is northwest and lowest southwest, the orientation is considered to be south, and so on. Eight orientation values are sufficient. +* **gradient of slope** — derived from the difference in altitude across the same 100 metre square +* **neighbours** — number of other buildings in 500 metre square centred on seed point. + + The reason orientation is relevant is exactly the same as the reason it's relevant to trees. West facing slopes are assumed wetter (coriolis winds), so grow trees better, so better availability of better quality timber, so a higher probability of timber as a primary building material. But also, in areas of higher rainfall, rain shedding is an important consideration, so a higher value is placed on pitched roofs. + + So you have the following general relationships + +* west (or southwest or northwest) facing, moderate gradient, moderate altitude: high probability of timber construction; construction techniques involving large timbers (e.g. cruck frame); greater probability of shingled roofs; +* west (or southwest or northwest) facing, moderate gradient, higher altitude or northern latitude: high probability of building styles adapted to straight-trunk conifers, e.g. log cabins, stave buildings; greater probability of shingled roofs; +* east facing, generally: greater probability of flat roofs; +* steeper gradients: greater probability of stone buildings (steeper gradients = shallower topsoil and greater ease of quarrying = access to stone); greater probability of slate roofs; +* shallower gradients: greater probability of mud, cobb, brick or wattle-and-daub as building materials; greater probability of thatch or turf roofs; +* Higher number of neighbours: higher probability of two or more stories; + + These factors allow classes of building to be selected. Having got past that point, we need to consider how classes of genetic building can work. + +### Rectangular genetic buildings + + Some genetic buildings will have cells with rectangular plan. This doesn't mean that genetic buildings are required to have rectangular cells, but they provide a starting point for discussion. For a given class of building (for example, timber frame), a number of prototype models of cells exist. These models are fully realised three dimensional models. Possibly all cells belonging to the building class have two open ends, and end walls exist as separate models; equally possibly, some cells have only one extensible end. In any case, a building will not normally comprise a single cell. Normally it will comprise multiple cells. So the cells belonging to a particular building class will be designed to 'plug together'. Multi story building classes will have some cells which are specifically ground floor only (flat ceiling, no roof), and such cells will always have an upper floor cell added above them. Where an upper floor cell has an outside door, an outside stair will automatically be added. + +### Cell mutability + + Although cell models are repeatedly reused they don't have to look the same every time they are reused. Within limits, every cell can be stretched along any of its three axes. Obviously, the degree of stretch on a given axis for every cell in a given building must be the same, otherwise they won't line up. Another mutable area is skinning — it may be possible to have alternate skins for cells, and even if there are not alternate skins, it will be possible to mutably darken, lighten or otherwise tint the skins used, within ranges which are appropriate to the materials represented. Obviously there are limits to stretching — timber comes in only such a length, stone lintels will only support such a span. + +### Functional cells + + Some trade functions require cells of particular kinds. Thus a smith needs a working building with one cell which is explicitly a forge. A water mill must have one cell which explicitly houses the mill gear. A forge cell or a waterwheel cell should never appear in weavers workshop. But most cells are not dedicated in this way. A bedroom cell is a bedroom cell, more or less; wealth may alter how it is furnished, but it may appear in any dwelling. Similarly, except for the very wealthy, a living cell is pretty much a living cell. And any building may incorporate a storage cell. If a given building class has twelve distinct 'generic' cells' and half a dozen distinct functional cells, and if buildings in the class average four cells each, then ignoring variance caused by skin mutability, a street of fifty buildings could have every one different. + +### Reproducibility + + It's critical that if a player visits a location, leaves it, and then returns, the buildings should not all have changed. So it must be possible to repeatedly reproduce the building at the location (this, of course, applies to other procedural scene dressing, such as trees, roads, boundaries, bridges and so on). This is possible if a deterministic random number generator is used which is seeded from the latitude and longitude attributes of the location. Other attributes which should be cached on the seed even though they are determined procedurally when the building is first instantiated include building class, purpose, and wealth. Using these attributes and the deterministic random number generator, the same building can be reproduced on the same site each time it is visited, with a very small amount of data stored. + + Buildings will normally be built at the edge of the associated land holding. If an edge of the land holding adjoins a road, then the building will be built with one long side aligned to the road. Otherwise, the building will be built at right angles to the orientation of the slope. The orientation will be 'frozen' once the building has been instantiated and will be cached on the seed. + + So, to build a building, use the following algorithm: + + Seed the random number generator with latitude and longitude + + ``` + while ( building value is less than wealth) { + select a cell selected from the building class using the next number from the random number generator modulo the number of generic cells in the class; + if the selected cell is not inappropriate to the building's function { + fit the cell to the building at the point determined by a deterministic algorithm + furnish cell using the random number generator to determine + furnishing types and locations from a selection appropriate to the cell + if the selected cell was not a top story cell { +          add a requirement that the next cell selected must be an upper story cell} + } + } + ``` + diff --git a/docs/codox/API_Spec.html b/docs/codox/API_Spec.html new file mode 100644 index 0000000..e6a6465 --- /dev/null +++ b/docs/codox/API_Spec.html @@ -0,0 +1,20 @@ + +API Spec (unfinished)

Project

Topics

Namespaces

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

+

Existing game engines don’t tend to track in convenient form things which have happened off-camera - indeed, mostly, things don’t happen at all when the player isn’t present. They don’t even track much that happens when the player is present, and they usually track what they do track in fairly ad-hoc ways. So generally Gossip-as-library will have to maintain its own history of what has happened, and who knows what about what has happened; and will have to model the major life events of non-player characters happening off-camera (if this is done at all) itself.

+

Interrogating lore

+

Many games have a great deal of lore and many lore texts. It’s reasonable to expect each non-player character to know a certain amount of lore, certainly lore which is local to their home location, or relevant to their trade. In order to make that available to Gossip, you probably need to construct a searchable corpus of all the lore, which can be simply queried.

+

That obviously then needs to be filtered by what the respondent can be expected to know, but that’s a problem Gossip has to handle anyway.

+

Interrogating the map

+

get-character-location id

+

Returns the player location in the world of the character with the specified id, as at minimum a three dimensional coordinate tuple, with heading; optionally with hierarchical region ids.

+

get-potential-auditors id

+

get-potential-auditors id, volume

+

Return an ordered list of ids of characters spatially close to the character with the specified id, ordered by their likelihood of being the character addressed (i.e. preferring characters in front of the character with the specified id to those off to the side or behind, on a sort of cardioid pattern). The set is bounded by the distance at which speech is deemed to be intelligible, which may be a constant, or maybe modified by some modelling of ambient noise, or the volume of the character’s speech act.

+

get-potentially-aware id

+

get-potentially-aware id, volume

+

As above, but return a list of ids of characters within a distance in which speech may be heard but not intelligibly.

+
\ No newline at end of file diff --git a/docs/codox/Appraisal.html b/docs/codox/Appraisal.html new file mode 100644 index 0000000..93dd8b6 --- /dev/null +++ b/docs/codox/Appraisal.html @@ -0,0 +1,29 @@ + +Appraisal (unfinished)

Project

Topics

Namespaces

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

+ + + + + + + + + + + + + +
Dimension Better is Ease of appraisal
Hardness More Difficult
Toughness More Difficult
Wear Less Intermediate
Weight There’s a sweet spot, but it’s low Easy
Length Judgement call Easy
Decoration/Showiness Judgement call Intermediate
Workmanship Better Intermediate
+

A person learns to appraise the qualities of a sword by having direct experience of swords with a range of values for the particular quality. A person who’s only ever handled one sword does not know whether that sword heavy or light, pristine or worn. However, once a person has handled a dozen swords of different weights, they’ll have some idea of what weight an average sword is, even if their idea may actually be a little off. Weight and length are easy to assess.

+

Similarly, once someone has handled a few dozen swords with different degrees of wear, will have an idea of how many chips, how much corrosion or pitting, is normal. Wear is harder to assess, but it doesn’t need particular techniques or skills to assess, just observation. To assess hardness, you really need to have sharpened the blade and then used it to the extent that it needs sharpening again, but if you’ve handled a lot of blades of varying qualities you may associate patterns in the steel, such as pattern welding, damascus steel, or a hamun, or particular markers’ marks, with varying hardnesses. Toughness is even harder to assess (without actually chipping or breaking the blade) and is really going to come down to recognising either high quality steels or particular makers’ marks.

+

Developing appraisal skill

+

So: how does one gain experience? I’m going to assume that anyone who’s bought a sword has handled it before making the choice. That anyone who’s survived on the winning side f a battle unwounded will also have handled eight of each type of weapon used, for each such battle (the victors will have the pick of the spoils on the battlefield). That a weapon smith has handled sixteen for each year they’ve been working. And possibly that a master weapon smith will at least examine more weapons in a year than a journeyman, who will at least examing more than an apprentice. But, essentially, appraisal skill develops with exposure to items in the particular category. The exact mechanism for tracking this I’m unsure of, because there is a tradeoff between richness of records and data compactness, and this game looks like getting rather big.

+

Of course, some people may be more observant than others, so it’s possible that some people may gain appraisal skill on the basis of less exposure than others. But at this moment that’s not a thing I’m planning to model.

+

What does appraisal skill buy you?

+

In any category of goods, some individual items are better than others, and this difference may be significant. A person with good appraisal skill will recognise this difference. So a person with good skills, offered two items at the same price, will be able to select the better one; if bargaining for an item, will be prepared to offer a higher price for the better one; if selling items, will be prepared to sell the better one only for a higher price.

+

Price arbitrage is how a static merchant makes money.

+
\ No newline at end of file diff --git a/docs/codox/Baking-the-world.html b/docs/codox/Baking-the-world.html index 1d46de3..6b8fbf3 100644 --- a/docs/codox/Baking-the-world.html +++ b/docs/codox/Baking-the-world.html @@ -1,41 +1,41 @@ -Baking the world

Project

Topics

Namespaces

Baking the world

-

Wednesday, 8 May 2019

-

Devorgilla’s Bridge in Dumfries, early fourteenth century

+Baking the world

Project

Topics

Namespaces

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.

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

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

-

Phase one: proving - the procedural world

+

Phase one: proving - the procedural world

I’m going to call the initial phase of the game run - the phase which takes place before the quest team write their quests and the art department adds their hand-crafted models - ‘proving’, as when dough has been been made and set aside to rise.

Then, when the landscape has developed - the areas of forest, scrub, open meadow, moorland, savanah and desert are determined, the rivers plotted, the settlers moved in, their trades determined and their settlements allocated, the roadways which link settlements routed, river crossings and ports defined - the proving process ends, and the world is turned over to the plot-writers, quest builders and designers, for a process we can see as analogous to kneading.

But, before going there, to summarise the proving stage. The inputs are:

    -
  1. A raster height map (although this could be randomly generated using any one of many fractal algorithms) - this probably uses ideas from tessellated multi-layer height map;
    2. -
  2. Optionally, a raster rainfall map at 1km resolution (although my personal preference is that this should be generated procedurally from the height map).
    3. +
  3. A raster height map (although this could be randomly generated using any one of many fractal algorithms) - this probably uses ideas from tessellated multi-layer height map;
    4. +
  4. Optionally, a raster rainfall map at 1km resolution (although my personal preference is that this should be generated procedurally from the height map).

The outputs are

    -
  1. A vector drainage map (rivers);
    2. -
  2. A raster biome map at roughly 1 km resolution (it might be anything between hectare resolution and 1Km resolution,  but obviously higher resolution takes more storage);
    3. -
  3. A database of settlers and their settlements, such that the settlements have x,y co-ordinates;
    4. -
  4. A vector road map.
    5. +
  5. A vector drainage map (rivers);
    6. +
  6. A raster biome map at roughly 1 km resolution (it might be anything between hectare resolution and 1Km resolution,  but obviously higher resolution takes more storage);
    7. +
  7. A database of settlers and their settlements, such that the settlements have x,y co-ordinates;
    8. +
  8. A vector road map.

In this sense, the ‘biome map’ is just the end state of a Microworld run. The ‘biomes’ include things like ‘forest’, ‘scrub’, ‘heath’, ‘pasture’, but they may also include human settlement, and even settlement by different cultural groups.

This gives us all we need to vegetate and furnish the world. When rendering each square metre we have

    -
  1. The x,y coordinates, obviously;
    2. -
  2. The altitude, taken from the height map;
    3. -
  3. The biome, taken from the biome map;
    4. -
  4. The biomes of adjacent cells in the biome map;
    5. -
  5. The proximity of the nearest watercourse;
    6. -
  6. The proximity of the nearest road or pathway;
    7. -
  7. Whether we are inside, or outside, a settlement (where for these purposes, ‘settlement’ includes enclosed field), and if inside, what type of settlement it is.
    8. +
  8. The x,y coordinates, obviously;
    9. +
  9. The altitude, taken from the height map;
    10. +
  10. The biome, taken from the biome map;
    11. +
  11. The biomes of adjacent cells in the biome map;
    12. +
  12. The proximity of the nearest watercourse;
    13. +
  13. The proximity of the nearest road or pathway;
    14. +
  14. Whether we are inside, or outside, a settlement (where for these purposes, ‘settlement’ includes enclosed field), and if inside, what type of settlement it is.

Given these parameters, and using the x, y coordinates as seed of a deterministic pseudo-random number generator, we can generate appropriate vegetation and buildings to render a believable world. The reason for pulling adjacent biomes into the renderer is that sharp transitions from one biome to another - especially ones which align to a rectangular grid - rarely exist in nature, and that consequently most transitions from one biome to another should be gradual.

Note that proving, although extremely compute intensive, is not necessarily a one-time job. If the designers aren’t satisfied with the first world to emerge from this process, they can run it again, and again, to generate a world with which they are satisfied. It’s also possible to hand-edit the output of proving, if needed.

But now, designers and story-writers can see the world in which their creations will be set.

-

Phase two: kneading - making the world fit our needs

+

Phase two: kneading - making the world fit our needs

Enough of proving, let’s get on to kneading.

Hand-designed buildings and environments are likely to be needed, or at least useful, for plot; also, particularly, very high status buildings are probably better hand designed. I’m inclined to think that less is more here, for two reasons:

You cannot hand design a very large world, it’s just impossible. How CD Project Red managed with Witcher 3 I don’t know, since I understand that is largely hand designed; but that was a very large team, and even so it isn’t a world on the scale I’m envisaging.

@@ -46,10 +46,11 @@

However, in some places the designers and story writers will want, for plot reasons and to create iconic environments, to add models. I’m inclined not to over do this, both for reasons of development effort and for reasons of storage cost, but they will. Very high status buildings may need to be unique and distinctive, for example. These need to be designed and their locations and spatial dimensions added to the database, so that the models can be rendered in the right positions (and, critically, procedurally generated models can be omitted in those positions!)

Story and quest writers will also want characters for their plots. While there’s no reason why writers cannot add entirely new characters to the database, there’s no reason why they cannot incorporate characters generated in the settlement phase into the story; for this reason, characters need to be able to be tagged in the database as plot characters, and with what quests/elements of the plot they’re associated.

This allows a mechanism to prevent a plot character from being killed by another non-player character, or dying of disease or starvation, before the plot elements in which they feature have been completed.

-

Phase three: baking - making it delicious

+

Phase three: baking - making it delicious

Once the world has been populated, settled, vegetated, the story has been written, the models built, the quests designed, there is probably a process of optimisation - stripping out things which aren’t needed at play time, streamlining things that are - before you have a game ready to ship; but really I haven’t yet given that much thought.

-

Phase four: eating!

+

Phase four: eating!

At the end, though, you have a game, and a player plays it. How much of the dynamic, organic life that brought the game through proving continues on into the playing phase? If the gossip ideas are to work, if unscripted, non-plot-related events (as well as scripted, plot related events) are to happen while the player plays, if news of these events is to percolate through the world and reach the player in organic, unscripted ways, if a lot of the emergent gameplay I’m imagining is to work, then quite a lot of the dynamic things must be happening.

Of course, part of this depends on the length of ‘game world time’ is expected to elapse in the course of one play through of the game. If it’s less than a year, then you don’t need children dynamically being born, and characters dynamically growing older; but if more, then you do. Similarly, you don’t need a real simulation of trading to dynamically drive prices in markets, but for a fun trading sub-game to emerge, you probably do, and if you are using merchants as news spreading agents the additional compute cost is not high.

And I understand that many game writers will shudder at the thought that a war might (or might not) start in the middle of their plot, that a battle might, one time in a thousand, take place right where they’ve plotted some significant encounter. Most modern video games are essentially just very complicated state machines: if you make this sequence of choices, this outcome will happen, guaranteed. Or else they’re puddles of random soup, where everything that happens is more or less driven by a random number generator. What I’m envisaging is something quite different: a world in which traders gonna trade, robbers gonna rob, lovers gonna love, scandal-mongers gonna make scandal, organically and dynamically whether the player is there or not, and news of these events will filter through to the player through the gossip network also organically and dynamically.

-

A world, in short, through which no two runs will ever be the same, in which interesting bits of story will happen with no-one directing or scripting them. And for that to work, some of the same dynamic processes that drove the proving phase have to continue into the eating phase.

\ No newline at end of file +

A world, in short, through which no two runs will ever be the same, in which interesting bits of story will happen with no-one directing or scripting them. And for that to work, some of the same dynamic processes that drove the proving phase have to continue into the eating phase.

+
\ No newline at end of file diff --git a/docs/codox/Biomes_and_ecology.html b/docs/codox/Biomes_and_ecology.html new file mode 100644 index 0000000..6a6b0e5 --- /dev/null +++ b/docs/codox/Biomes_and_ecology.html @@ -0,0 +1,66 @@ + +Biomes and ecology (unfinished)

Project

Topics

Namespaces

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.

+

Biomes relevant at this stage

+

1. Steppe

+

The centre of the continent is the steppe; it is generally too arid for forest growth, and is therefore scrub and grassland. There is one principal river system, which feeds into a marshland in the south, from which the water then goes underground beneath the limestone plateau to become the Tcha and Sind rivers. In late summer there’s little water in the river, and few other waterholes. Antelope, camels, horses, goats, possibly sheep are native to the steppe, and there are probably something like leopards which predate on them, but I haven’t fleshed it out.

+

Big dragons don’t hunt on the steppe because they can’t take off from flat ground, but smaller dragons may do so.

+

Settled by the steppe tribes, who are nomadic herders, extremely warlike but not technically highly developed. They are the game world’s principle horse breeders. Basically in the game as I’m working on it at present, the player cannot go north across the steppe because the steppe tribes are too hostile.

+

A single major road, the Caravan Road, runs north to south across the steppe. There were in the past fortified caravanserrais along the length of the road, established and protected by Hans’hua, but they have been progressively overrun and destroyed by the steppe tribes and are now ruinous. Only one remains: the North Inn, just below the northern slope of the plateau. There is some limited horticulture on land close to the South Inn, supplying markets in Hans’hua.

+

2. Plateau

+

The limestone plateau runs along the whole of the southern edge of the steppe, from the western massif to the rim of the crater which forms The Great Place. It is a landscape of clints and grykes, on which nothing grows, and on which there is no water. It is about four day’s journey by fast horse from north to south. The caravan road crosses the plateau from the North Inn to another caravanserrai, the South Inn, located in the north end of the Tcha valley. Because of the dense chaotic pattern of clints and grykes and the lack of accessible water, it is effectively impossible to cross the plateau other than by the caravan road, or by another path to the extreme east of the plateau, where it abuts the mountains of the Rim.

+

2.1 Hans’hua

+

There is one city, Hans’hua, on the caravan road about half way across the plateau, where wind-pumps lift water from the underground river. Apart from this one city, nothing lives on the plateau. Migrating birds cross it, and that is all.

+

The city is small, walled, and run as an extreme neoliberal oligarchy; the city’s main industry is maintaining the wind pumps, and its entire income is from tolls on caravans passing along the caravan road. This has been, and is still, extremely lucrative, but it is obvious both to the long distance merchants and to the oligarchs that the new ships are going to make the caravans too slow, too risky and too expensive to compete, and that as more ships are built, traffic on the caravan road will dwindle.

+

3. Massif

+

There’s a granite intrusion which forms the entire western coast of the continent. It’s geologically old and consequently the hills, though high, are rounded rather than jagged; at the southern end of the range (which is the only part that’s in the least fleshed out yet) they’re not snow covered in summer. As the prevailing winds are westerly, this massif intercepts most of the rain, which is why the steppe is arid.

+

Consequently it’s pretty thoroughly forested, and the southern parts of it are mainly broadleaf forests including high quality hardwoods and many fruiting trees. Understory typical of mediterranean littoral forests, about which I don’t really know enough.

+

Deer, cattle, pigs, wolves, leopards, badgers, squirrels… masses of birds of all appropriate types.

+

Because it’s an old granite intrusion, the soil in the valleys is largely clay. There are mineral rich veins with a considerable range of minerals, but, obviously, not all in the same place.

+

Settled by the Western Clans, a negroid people living mainly in small isolated villages in the forest, with mostly limited agriculture.

+

3.1 Northern massif

+

I haven’t yet fleshed this out, but there are probably permanent snows and the forests are probably coniferous. It’s my current working assumption that the new great ships are built from old growth conifers, taken from forests in the northern massif; but as I say this is not yet fleshed out.

+

The northern culture have developed very high quality ceramics using clay from the massif, including stonewares and porcelaines. I think the same clays also exist in the south of the massif, but the technology for producing high quality ceramics does not exist there. The northerners are also making high quality steels from magnetite and haematite from the massif. Whether these ores exist in the south I don’t yet know.

+

3.2 Dor

+

The northernmost of the western clans, the Dor, live in the central massif north of Andale, but apart from the fact that they exist and they’re there, I don’t yet really know much.

+

3.3 Andale

+

The river An rises in the east of the massif near the south-west corner of the steppe, west of where the village and market of Dawnhold now stand, and flows more or less due westward. There are two major drops in the river’s course, the upper a day’s travel east of Silverhold, which is an actual fall of at least six metres, and the lower at Anghold. Between Anghold and Silverhold the river is navigable by small shallow draught boats; west of Anghold it is navigable down to the sea at Anmouth.

+

There are freshwater and migratory fish in the river, and fishing is a source of protein and livelihood the whole length of the valley.

+

The valley is largely forested. Apart from wild animals, domestic cattle and pigs are herded in the forest. Trees include alder, almond, apple, apricot, ash, beech, birch, cherry, chestnut, hazel, holly, lime, maple, mulberry, oak, orange, pear, walnut, yew.

+
3.3.1 Dawnhold
+

Dawnhold isn’t strictly geographically in Andale — it’s east of, on the steppe side of, the watershead, but it marks the eastern border of the lands settled by clan An. There’s an annual market, a village, and a garrisoned fortification to deter raids by the steppe tribes.

+
3.3.2 Silverhold
+

Small town serving the only significant silver mine in the world. A tributary flows in from the north here, but I know nothing about it yet. There is a major fortification/refinery/treasury. All around Silverhold, right up to the headwaters of the An and right down to Anghold, the valley is forested with only small clearings round villages, which are mainly close to the river.

+

Many other metals — certainly inluding lead, tin, and small quantities of gold, probably not copper — come out of the mines at Silverhold.

+

The An produce enough ferrous metals for their own tools and weapons, but their iron smelting technology is not advanced and they don’t export iron or iron products. They produce eathernware ceramics for domestic consumption. They produce leather and linen, and textiles from nettle fibres. They produce timber, which is their principal building material, but they don’t export it. In practice their major export is silver coinage.

+
3.3.3 Longwater
+

Longwater is a long, narrow lake, like Loch Lomond, on a tributary which flows into the An from the south, joining upstream from Anghold. There is no major nucleated settlement on Longwater, but there are sufficient small villages and hamlets on its banks to form an identifiable settlement cluster. Small boats can make it downstream from Longwater from the An and back, probably with some degree of portage around rapids. There’s a pass over from the south of the Longwater valley to Gor territory, but it’s high, difficult, and not much used. The whole of the Longwater valley is broadleaf forest.

+
3.3.4 Anghold
+

There’s a small town, market and fortification — Anghold — on the south bank of the An, just above first cataract, where boats are portaged up from the lower river to the middle reach. Downstream from Anghold the river is wider, slower and more meandering, with marshy banks. The valley west of Anghold, especially on the southern side, is also more populated, with more of the forest cleared and more arable agriculture.

+
3.3.5 Anmouth
+

The An meets the sea at Anmouth, where there is a deep harbour at a bend in the river just east of a long estuary, There is a bar, making it dangerous to enter the harbour in bad weather, and the whole estuary is pretty exposed to western storms, although there may be some islands providing some shelter for emergency anchorages — I don’t have that level of detail yet. Certainly the big new ships do not yet call in here, but could.

+

There are farming and sea-fishing villages down both sides of the estuary. There is no tradition of ship building, however.

+

3.4 Gor

+

Clan Gor occupy the south-western peninsula of the continent, and the south slope of the massif, east almost as far as the Tcha valley. Their land is forested with a similar mix of trees to Andale. They have no major rivers, but several minor ones. They live mainly in coastal villages, and sea fishing is a major economic activity. They have no deep water ports.

+

In addition they do mine iron, and they have exported swords, but the market for their swords is being undercut by better crucible steel swords from the north now being imported into the Cities of the Coast by the new ships. Similarly, the Gor used to export earthenware, but that too is now being undercut by stonewares and porcelaines from the north.

+

Because of a history of being victims of raiding from the Cities of the Coast, the Gor maintain a fortified eastern border along the line of hills to the west of the Tcha valley. Nevertheless they have mostly good trading relationships with Tchahua. In particular they export large quantities of raw and spun silk, and some woven silk cloth, to Tchahua.

+

I don’t yet have nearly a clear enough picture of the organisation and layout of the Gor lands, but their major stronghold and administrative centre must be to the east. While they traditionally had the communist and democratic culture of the other Western Clans, one family have become dominant and have become effectively hereditary leaders, influenced by the cultures to their east. However the leading family do not self-identify as aristons.

+

4. Coast

+

“The Coast” is the name given to the southern littoral of the continent, west of the Great Place and east of the Massif. It’s limestone, with deeply cut, steep sided valleys separated by high, arid uplands, with scrubby vegetation, grazed by domestic sheep and both domestic and wild goats.

+

The native culture were peaceable, communistic agriculturalists, not greatly different from the Western Clans. However some several hundred years ago they were invaded by a warrior group from the steppe tribes, who established themselves as a military aristocracy — the Aristae — and started to build cities — and impose taxes onto the peasantry, forcing them into a more or less cash oriented economy.

+

The valleys were once forested, but the central valleys, which were in any case rather dryer and where the Aristae first settled and established cities, are now mostly cleared, and are a mix of pastoral and arable, with considerable viticulture.

+

4.1 Tcha valley

+

The Tcha is the westernmost — and largest — river of the coast. It emerges from under the plateau at a pool under the South Tower marking the southern limit of Hans’hua territory and runs south more or less along the divide between the granite to the west and the limestone to the east. It is still largely forested, partly because it is relatively recently occupied by the Aristae, but partly because of the growth of the silk industry. This has led to some forested areas, especially near the navigable reaches of the river, being converted into mulberry orchards. However, there’s still a great deal of mixed forest, and the majority of mulberry leaves for feeding to silk worms are gathered from natural forest.

+

A road branches off from the main Caravan Road at the South Inn and runs down the eastern side of the valley, to a ferry across the Sind river, where it joins the Tcha as a tributary, at the village helpfully known as Sind Ferry, and thence to Tchahua.

+

Mulberries, by-products of the silk industry, are used in the production of brandy. Mulberry wine is produced in villages in the forest, and transported down river to a distillery at Sind Ferry, where it is distilled. Some mulberry wine may be sold in Tchahua for drinking as wine (and it is certainly drunk in the villages), but it is generally considered inferior to grape wine.

+

There is some arable and mixed agriculture, mainly towards the southern end of the valley on the western (less steep) side, although this side is also largely forested.

+
4.1.1 Tchahua
+

The city of Tchahua lies on the east bank of the river at the head of its estuary, and has deep water — the only really usable deep water port on the coast, being not only the largest river but also the least silted. Until quite recently it had been a small provincial silk weaving city, nominally independent but in fact paying tribute to both Sinhua to its east and the Gor to its west, in order to avoid being formally conquered by either.

+

There’s a multi-span bridge here — I think a pontoon bridge — of which the eastern most span is a drawbridge which can be lifted into a fortified gateway on the eastern (Tchahua) shore. There is a fishing industry, but as the eastern side

+

Industries are silk weaving and dying, and fishing. Very recently, a new deep water quay has been constructed and the first large ships have begun to call. It is obvious that the city is going to become much more important as a strategic market and transport hub, but that has only just begun to have effect.

+

4.2 Sind valley

+

4.2.1 Sinhua

+
\ No newline at end of file diff --git a/docs/codox/Canonical-dictionary.html b/docs/codox/Canonical-dictionary.html index a756c85..f4099eb 100644 --- a/docs/codox/Canonical-dictionary.html +++ b/docs/codox/Canonical-dictionary.html @@ -1,35 +1,36 @@ -A Canonical dictionary for this documentation

Project

Topics

Namespaces

A Canonical dictionary for this documentation

+A Canonical dictionary for this documentation

Project

Topics

Namespaces

A 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

+

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.

-

Agent

+

Agent

Agent is probably just a synonym for actor. If it is different in any way, that way has not yet been determined.

-

Gossip

+

Gossip

A gossip is an actor who exchanges news with other actors, even when the player character is not nearby. Thus gossips are the mechanism by which news propagates through the game world, and also the mechanism by which information degrades. Broadly:

    -
  1. innkeepers (and possibly some others) are gossips who do not move; rather, they gather information from gossips who do move, and all non-player characters local to the are deemed to know everything that their local innkeeper knows;
    2. -
  2. merchants (and possibly some others) are gossips who do move from place to place, and thus transfer news.
    3. +
  3. innkeepers (and possibly some others) are gossips who do not move; rather, they gather information from gossips who do move, and all non-player characters local to the are deemed to know everything that their local innkeeper knows;
    4. +
  4. merchants (and possibly some others) are gossips who do move from place to place, and thus transfer news.

See the spread of knowledge in a large game world.

-

Heightmap

+

Heightmap

A heightmap is a raster image of the world, such that the intensity in which an area is coloured represents the value of some variable, by default height, of that area.

-

Holding

+

Holding

A holding is a polygon ‘owned’ by an actor on which are built appropriate building units representing the actors craft and status.

-

Location

+

Location

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

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

Examples

    -
  1. [{:x 5445678 :y 9684351}]
    2. -
  2. [{:x 5445678 :y 9684351} :karalin-palace :hanshua]
    3. +
  3. {:x 5445678 :y 9684351}
    4. +
  4. {:x 5445678 :y 9684351} :karalin-palace :hanshua
-

Merchant

+

Merchant

A merchant is an actor and gossip who trades goods, and incidentally conveys news, between markets.

-

Non-player character

+

Non-player character

A non-player character is, for our purposes, an actor capable of engaging in conversation with the player character. Note, however, that, from a software point of view, the player character is just a special case of a non-player character.

-

Player character

-

The player character is the unique actor within the game currently controlled and inhabited by the player.

-

Route

-

A route is a pre-prepared path through the game world that an actor may take. Most actors are not constrained to follow routes, but in general routes have lower traversal cost than other terrain.

\ No newline at end of file +

Player character

+

The player character is the unique actor within the game currently controlled and inhabited by the player.

+

Route

+

A route is a pre-prepared path through the game world that an actor may take. Most actors are not constrained to follow routes, but in general routes have lower traversal cost than other terrain.

+
\ No newline at end of file diff --git a/docs/codox/Division_of_tasks_between_server_and_client.html b/docs/codox/Division_of_tasks_between_server_and_client.html new file mode 100644 index 0000000..a6e2297 --- /dev/null +++ b/docs/codox/Division_of_tasks_between_server_and_client.html @@ -0,0 +1,19 @@ + +Division of tasks between server and client

Project

Topics

Namespaces

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.

+

The initial idea of The Great Game is that it is a single player game, but it actually doesn’t need to be and it would be quite possible for one server to support multiple clients, each being used by a different player.

+

The server/planner decides what each actor does, models what each character knows, plans and records all actions and transactions. It plans speech acts, and handles conversations which happen off screen, but hands speech texts over to the client/performer layer for actual performance. It also plans journeys as described in Pathmaking, but it doesn’t deal with movement within a polygon or with collision avoidance. It deals with fights which happen off screen, but not those that happen on screen.

+

What do I mean by the client?

+

There is something that renders an interesting and lively display of the part of the game world that the player can see from their current position. This display has to run without significant pauses — it’s not OK, for example, for all conversation to stop suddenly in a market place just because the server is garbage collecting.

+

The client is written in some high level game engine system, possibly Unreal Engine (although for ideological reasons I’d prefer an open source one).

+

The client/performer renders and animates everything the player character can see, and performs every sound the player character can hear. In doing this it is responsible for

+
    +
  1. The rendering of landscape, vegetation, buildings, furniture, and everything else that is fixed within the visible scene;
    2. +
  2. The animation of everything which moves within the visible scene, and, to facilitate this, detailed route planning and collision avoidance;
    3. +
  3. The performance of all speech acts and gestures, all musical performance, and the playing of all foley sounds;
    4. +
  4. Combat which happens in the field of view, including specifically all combat (including sparring) involving the player character. This means that the client/performer is the bit of the system which decides what blows are struck and whether they hit their targets, and consequently which character wins each fight. It reports this information back to the server.
    5. +
+
\ No newline at end of file diff --git a/docs/codox/Dynamic-consequences.html b/docs/codox/Dynamic-consequences.html index 595965e..1a7382a 100644 --- a/docs/codox/Dynamic-consequences.html +++ b/docs/codox/Dynamic-consequences.html @@ -1,41 +1,44 @@ -On the consequences of a dynamic game environment for storytelling

Project

Topics

Namespaces

On the consequences of a dynamic game environment for storytelling

+On the consequences of a dynamic game environment for storytelling

Project

Topics

Namespaces

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

    -
  1. Is ill, and consequently has inconsistent levels of energy and concentration;
    2. -
  2. Has other things to do in the real world which necessarily take precedence.
    3. +
  3. Is old and ill, and consequently has inconsistent levels of energy and concentration;
    4. +
  4. Has other things to do in the real world which necessarily take precedence.

Nevertheless, in making design choices I want to specify something which could be built, which could, except for the technical innovations I’m trying myself to build, be built with the existing state of the art, and which if built, would be engaging and interesting to play.

The defining characteristic of Role Playing Games - the subcategory of games in which I am interested - is that the actions, decisions and choices of the player make a significant difference to the outcome of the plot, significantly affect change in the world. This already raises challenges for the cinematic elements in telling the game story, and those cinematic elements are one of the key rewards to the player, one of the elements of the game’s presentation which most build, and hold, player engagement. These challenges are clearly expressed in two very good videos I’ve watched recently: Who’s Commanding Shepard in Mass Effect?, which discusses how much control the player actually has/should have over the decisions of the character they play as; and What Happened with Mass Effect Andromeda’s Animation?, which discusses how the more control the player has, the bigger the task of authoring animation of all conversations and plot events becomes.

There are two key innovations I want to make in The Great Game which set it apart from existing Role Playing Games, both of which make the production of engaging cinematic presentation of conversation more difficult, nd I’ll handle each in turn. But before I do, there’s something I need to make clear about the nature of video games themselves: what they are for. Video games are a vehicle to tell stories, to convey narrative. They’re a rich vehicle, because the narrative is not fixed: it is at least to some degree mutable, responsive to the input of the audience: the player.

Clear? Let’s move on.

The innovations I am interested in are

-

Unconstrained natural speech input/output

+

Unconstrained natural speech input/output

I want the player to be able to interact with non-player characters (and, indeed, potentially with other player characters, in a multi-player context) simply by speaking to them. This means that the things the player character says cannot be scripted: there is no way for the game designer to predict the full repertoire of the player’s input. It also means that the game must construct, and put into the mouth of the non-player character being addressed, an appropriate response, given

    -
  1. The speech interpretation engine’s interpretation of what it is the player said;
    2. -
  2. The immediate game and plot context;
    3. -
  3. The particular non-player character addressed’s knowledge of the game world;
    4. -
  4. The particular non-player character’s attitude towards the player;
    5. -
  5. The particular non-player character’s speech idiosyncracies, dialect, and voice
    6. +
  6. The speech interpretation engine’s interpretation of what it is the player said;
    7. +
  7. The immediate game and plot context;
    8. +
  8. The particular non-player character addressed’s knowledge of the game world;
    9. +
  9. The particular non-player character’s attitude towards the player;
    10. +
  10. The particular non-player character’s speech idiosyncracies, dialect, and voice
-

and it must be pretty clear that the full range of potential responses is extremely large. Consequently, it’s impossible that all non-player character speech acts can be voice acted; rather, this sort of generated speech must be synthesised. But a consequence of this is that the non-player character’s facial animation during the conversation also cannot be motion captured from a human actor; rather, it, too, must be synthesized.

-

This doesn’t mean that speech acts by non-player characters which make plot points or advance the narrative can’t be voice acted, but it does mean that the voice acting must be consistent with the simulated voice used for that non-player character - which is to say, probably, that the non-player character must use a synthetic voice derived from the voice of that particular voice actor.

-

Dynamic game environment

+

and it must be pretty clear that the full range of potential responses is extremely large. Consequently, it’s impossible that all non-player character speech acts can be voice acted; rather, this sort of generated speech must be synthesised. But a consequence of this is that the non-player character’s facial animation during the conversation also cannot be motion captured from a human actor; rather, it, too, must be synthesized.

+

This doesn’t mean that speech acts by non-player characters which make plot points or advance the narrative can’t be voice acted, but it does mean that the voice acting must be consistent with the simulated voice used for that non-player character - which is to say, probably, that the non-player character must use a synthetic voice derived from the voice performance of that particular voice actor in that role.

+

Dynamic game environment

Modern Role Playing Games are, in effect, extremely complex state machines: if you do the same things in the same sequence, the same outcomes will always occur. In a world full of monsters, bandits, warring armies and other dangers, the same quest givers will be in the same places at the same times. They are clockwork worlds, filled with clockwork automata. Of course, this has the advantage that is makes testing easier - and in a game with a complex branching narrative and many quests, testing is inevitably hard.

+

Interestingly, Kenshi — a game I’m increasingly impressed and influenced by — is not quite clockwork in this sense. As the player upsets the equilibrium of the game’s political economy, factions not impacted negatively will move against competing factions which are impacted negatively, in a way which may be scripted, but it’s so well done it’s hard to tell.

My vision for The Great Game is different. It is that the economy - and with it, the day to day choices of non-player characters - should be modelled. This means, non-player characters may unexpectedly die. Of course, you could implement a tag for plot-relevant characters which prevents them being killed (except when required by the plot).

-

Plot follows player

-

As Role Playing Games have moved towards open worlds - where the player’s movement in the environment is relatively unconstrained - the clockwork has become strained. The player has to get to particular locations where particular events happen, and so the player has to be very heavily signposted. Another solution - which I’d like to explore - is ‘plot follows character’. The player is free to wander at will in the world, and plot relevant events will happen on their path. And by that I don’t mean that we associate a set of non-player characters which each quest - as current Role Playing Games do - and then uproot the whole set from wherever they normally live in the world and dumping down in the player’s path; but rather, for each role in a quest or plot event, we define a set of characteristics required to fulfill that role, and then, when the player comes to a place where there are a set of characters who have those characteristics, the quest or plot event will happen.

-

Cut scenes, cinematics and rewarding the player

-

There’s no doubt at all that ‘cut scenes’ - in effect, short movies spliced into game play during which the player has no decisions to make but can simply watch the scene unroll - are elements of modern games which players enjoy, and see to some extent as ‘rewards’. And in many games, these are beautifully constructed works. It is a very widely held view that the quality of cutscenes depends to a large degree on human authorship. The three choices I’ve made above:

+

Plot follows player

+

As Role Playing Games have moved towards open worlds - where the player’s movement in the environment is relatively unconstrained - the clockwork has become strained. The player has to get to particular locations where particular events happen, and so the player has to be very heavily signposted. Sometimes the mark you have to hit to trigger the next advance of the plot can be extremely awkward; an example from Cyberpunk 2077 is finding the right spot, in the quest ‘They Won’t Go When I Go’, to trigger the button which raises the cross.

+

Another solution - which I’d like to explore - is ‘plot follows character’. The player is free to wander at will in the world, and plot relevant events will happen on their path. And by that I don’t mean that we associate a set of non-player characters which each quest - as current Role Playing Games do - and then uproot the whole set from wherever they normally live in the world and dump them down in the player’s path; but rather, for each role in a quest or plot event, we define a set of characteristics required to fulfil that role, and then, when the player comes to a place where there are a set of characters who have those characteristics, the quest or plot event will happen.

+

Cut scenes, cinematics and rewarding the player

+

There’s no doubt at all that ‘cut scenes’ - in effect, short movies spliced into game play during which the player has no decisions to make but can simply watch the scene unroll - are elements of modern games which players enjoy, and see to some extent as ‘rewards’. And in many games, these are beautifully constructed works. It is a very widely held view that the quality of cutscenes depends to a large degree on human authorship. The choices I’ve made above:

    -
  1. We can’t always know exactly what non-player characters will say (although perhaps we can in the context of cut scenes where the player has no input);
    2. -
  2. We can’t always know exactly which non-player characters will speak the lines;
    3. -
  3. We can’t predict what a non-player character will say in response to a question, or how long that will take;
    4. -
  4. We can’t always know where any particular plot event will take place.
    5. +
  5. We can’t always know exactly what non-player characters will say (although perhaps we can in the context of cut scenes where the player has no input);
    6. +
  6. We can’t always know exactly which non-player characters will speak the lines;
    7. +
  7. We can’t predict what a non-player character will say in response to a question, or how long that will take;
    8. +
  8. We can’t always know where any particular plot event will take place;
-

Each of these, obviously, make the task of authoring an animation harder. The general summary of what I’m saying here is that, although in animating a conversation or cutscene what the animator is essentially animating is the skeletons of the characters, and, provided that all character models are rigged on essentially similar skeletons, substituting one character model for another in an animated scene isn’t a huge issue, with so much unknowable it is impossible that hand-authoring will be practicable, and so a lot will depend on the quality of the conversation system not merely to to produce convincingly enunciated and emoted sound, but also appropriate character animation and attractive cinematography. As you will have learned from the Mass Effect analysis videos I linked to above, that’s a big ask.

+

each, make the task of authoring an animation harder. The general summary of what I’m saying here is that, although in animating a conversation or cutscene what the animator is essentially animating is the skeletons of the characters, and, provided that all character models are rigged on essentially similar skeletons, substituting one character model for another in an animated scene isn’t a huge issue, with so much unknowable it is impossible that hand-authoring will be practicable, and so a lot will depend on the quality of the conversation system not merely to to produce convincingly enunciated and emoted sound, but also appropriate character animation and attractive cinematography. As you will have learned from the Mass Effect analysis videos I linked to above, that’s a big ask.

Essentially the gamble here is that players will find the much richer conversations, and consequent emergent gameplay, possible with non-player charcaters who have dynamic knowledge about their world sufficiently engaging to compensate for a less compelling cinematic experience. I believe that they would; but really the only way to find out would be to try.

-

Interestingly, an early preview of CD PRoject Red’s not-yet-complete Cyberpunk 2077 suggests that there will be very, very few cutscenes, suggesting that these very experienced storytellers don’t feel they need cutscenes either to tell their story or maintain player engagement. (Later) It has to be said other commentators who have also played the Cyberpunk 2077 preview say that there are a lot of cutscenes, one of them describing the prologue as ‘about half cutscenes’ - so this impression I formed may be wrong).

\ No newline at end of file +

Interestingly, an early preview of CD Project Red’s Cyberpunk 2077 has relatively few cutscenes, suggesting that these very experienced storytellers don’t feel they need cutscenes either to tell their story or maintain player engagement.

+
\ No newline at end of file diff --git a/docs/codox/Economy.html b/docs/codox/Economy.html new file mode 100644 index 0000000..a3cd0c5 --- /dev/null +++ b/docs/codox/Economy.html @@ -0,0 +1,36 @@ + +Game world economy

Project

Topics

Namespaces

Game world economy

+

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

+

Primary producers

+

Herdsfolk

+

Herdsfolk are nomadic; it’s reasonable to think they’ll bring their herds to market, rather than selling at lots of tiny markets. So in the spring, shepherds will visit specific towns at the edge of open land, to hold a shearing festival/carnevale; and that both shepherds and cattle herders will visit towns on the edge of open land to sell fatstock in the autumn.

+

Miners

+

Miners mine. They’re settled, but they’re settled usually in specialist settlements at the location where the ore body is accessible, usually in mountenous territory. They’ll consume a lot of food, so there will be a local market for foodstuffs encouraging local farming. Different mines obviously mine different ores, but, for example, lead and silver are frequently found together.

+

Foresters

+

Foresters are more or less settled at the edge of forests, at locations from which timber can be moved by navigable water; again in specialist settlements. In addition to timber, foresters hunt and produce both meat and furs, so have less need for other food producers locally.

+

Farmers

+

Farmers are settled. Farmers occupy standard runrig plots, but because they don’t employ journeymen or apprentices, and don’t have workshops, the plots are mostly open with little building. Most farmers are ‘mixed farmers’, producing cereals, meat, eggs and milk. Some will be more specialist. Farm produce, taken broadly to include orchardsfolk, include:

+
    +
  • meat
    • +
  • milk and milk products
    • +
  • hides
    • +
  • eggs
    • +
  • cereals
    • +
  • root vegetables, onions, etc
    • +
  • peas and beans
    • +
  • leaf vegetables
    • +
  • fruits
    • +
  • fibres: linen, hemp and silk (from silk-moths in mulberry orchards)
    • +
  • possibly other stuff I’ve forgotten.
    • +
+

Farmers are all basically subsistence farmers, farming first to feed their own household and selling only surplus in the market.

+

Crafts

+

Crafts generally process primary goods into secondary goods - whether intermediate stages or final consumer items. Some elite ‘crafts’ deal with abstract primary goods like law and knowledge, and they may be seen as somewhat separate.

+

A master craftsperson may occupy a standard runrig plot, much like a farmer’s plot. Like a farmer, a poor master crafter household will cultivate part of the plot to produce food for the house - at least grow vegetables and keep hens. However, as the crafter takes on apprentices and journeymen - and gets richer - more buildings will be required as accommodation, workshop space and materials stores.

+

Also, Tchahua is much more a gold-rush town than an organic, grew over hundreds of years sort of town, so it is not ex-runrig; and additionally the original settlement was probably along the river bank, land which has now been redeveloped as warehouses and as rich merchant residences. Generally, town house plots are small from the get go.

+

Hans’hua is again an exception from normal organic development, as it has no agricultural land close to the city at all.

+

Generally, primary goods aren’t transported over land - because overland transport is expensive, by the time they’ve been transported they’re no longer low cost goods. So often the craftspeople who process primary produce into at least commodity intermediate forms will live close to the source of the primary goods.

+

So, for example, the town(s) where the shepherds hold their shearing fairs will tend to have a lot of weavers. While around mines there will be smelters producing ingots and bar stock to be marketed to smiths all over the place, there will also be smiths close to the mines producing commodity tools and weapons.

+

See the table in Populating a game world.

+
\ No newline at end of file diff --git a/docs/codox/Further-reading.html b/docs/codox/Further-reading.html new file mode 100644 index 0000000..553196b --- /dev/null +++ b/docs/codox/Further-reading.html @@ -0,0 +1,13 @@ + +Further Reading (and watching)

Project

Topics

Namespaces

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

+
    +
  1. Synthetic Silviculture: Multi-scale Modeling of Plant Ecosystems – see also this video.
    2. +
+

Systemic games

+
    +
  1. This video is thought provoking with excellent examples.
    2. +
+
\ No newline at end of file diff --git a/docs/codox/Game-engine-integration.html b/docs/codox/Game-engine-integration.html new file mode 100644 index 0000000..f30e628 --- /dev/null +++ b/docs/codox/Game-engine-integration.html @@ -0,0 +1,7 @@ + +Game-engine integration (unfinished)

Project

Topics

Namespaces

Game-engine integration (unfinished)

+

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

+

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

+

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

+
\ No newline at end of file diff --git a/docs/codox/Game_Play.html b/docs/codox/Game_Play.html index 277ea9b..b4b8841 100644 --- a/docs/codox/Game_Play.html +++ b/docs/codox/Game_Play.html @@ -1,31 +1,39 @@ -Game Play

Project

Topics

Namespaces

Game Play

+Game Play

Project

Topics

Namespaces

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

    Superpower: the player character has some special powers or skills that other characters in the game fo not have.

    2. -
  2. -

    Special status: the player character is ‘the chosen one’, ‘the hero’, or even just ‘the Witcher’ from the very beginning, without having done anything to earn those titles.

    3. -
  3. -

    Boss fights: some non-player characters have special, and specially strong, combat repertoire, and block progress in the game until you overcome them.

    4. -
  4. -

    Psychokiller: completing the game necessarily involves beating many, many other characters in combat.

    5. -
  5. -

    Slaughterhouse: the main way to interact with other characters is to kill them.

    6. -
  6. -

    The Script is King: everything is scripted. The player either can’t diverge from the script, or if they do, will find no interesting content.

    7. -
  7. -

    Dumb and dumber: non-player characters, even important ones, have extremely limited vocal repertoire.

    8. +
  8. +

    Superpower: the player character has some special powers or skills that other characters in the game fo not have.

    +
    9. +
  9. +

    Special status: the player character is ‘the chosen one’, ‘the hero’, or even just ‘the Witcher’ from the very beginning, without having done anything to earn those titles.

    +
    10. +
  10. +

    Boss fights: some non-player characters have special, and specially strong, combat repertoire, and block progress in the game until you overcome them.

    +
    11. +
  11. +

    Psychokiller: completing the game necessarily involves beating many, many other characters in combat.

    +
    12. +
  12. +

    Slaughterhouse: the main way to interact with other characters is to kill them.

    +
    13. +
  13. +

    The Script is King: everything is scripted. The player either can’t diverge from the script, or if they do, will find no interesting content.

    +
    14. +
  14. +

    Dumb and dumber: non-player characters, even important ones, have extremely limited vocal repertoire.

    +
-

Of these, the last two, I think, are key: they are the root cause of the other problems. In fact, to take it further, the real key is the last. We talk a lot about ‘Game AI’, but really there’s nothing remotely approaching artificial intelligence ins modern games. Non-player characters do not think; they do not learn; they do not reason; they do not know. They speak only from the script. And they speak only from the script because of the fetish for voice acting.

+

Of these, the last two, I think, are key: they are the root cause of the other problems. In fact, to take it further, the real key is the last. We talk a lot about ‘Game AI’, but really there’s nothing remotely approaching artificial intelligence in modern games. Non-player characters do not think; they do not learn; they do not reason; they do not know. They speak only from the script. And they speak only from the script because of the fetish for voice acting.

## Death to Dumb-Dumb

-

As I’ve argued elsewhere, repeatedly, we can now generate a wide variety of naturalistic speaking voices, and have them narrate text. Now of course there’s great deal of information conveyed in human vocal communication in addition to the words – of which emotion is only an example, although an important one. Generating voices with the right tone, the right emphasis, for different situations may be harder than I anticipate; there may be an ‘uncanny valley’ in which generated speech just sounds uncomfortably off.

+

As I’ve argued elsewhere, repeatedly(Selecting Character), we can now generate a wide variety of naturalistic speaking voices, and have them narrate text. Now of course there’s great deal of information conveyed in human vocal communication in addition to the words – of which emotion is only an example, although an important one. Generating voices with the right tone, the right emphasis, for different situations may be harder than I anticipate; there may be an ‘uncanny valley’ in which generated speech just sounds uncomfortably off.

But it’s a trade off. For possibly less than perfect vocal performance, you get the possibility of much richer repertoire. You get not only the possibility that non-player characters can talk about the weather, or gossip about their neighbours, or give you directions to local places of interest. You get the possibility that a non-player character’s attitude to you may be conditioned by the fact that they’ve heard that you stole from their second cousin, or that you killed an outlaw who’d raped one of their friends.

Suddenly, they can have attitudes about things that happen in the world, opinions about major political figures in it, about their neighbours, about you the player, which are not scripted, which are emergent. When they learn new information which conflicts with something they already knew, their attitudes will change, as that new information is integrated. Intelligent behaviour will emerge.

And with the emergence of intelligent behaviour comes the emergence of possibilities for negotiation, for diplomacy, for dynamic, unscripted, friendships and romances. Which means, there are things you can do to interact with every non-player character, even ones who are not ‘plot’ characters, other than just kill them.

-

And as now gameplay possibilities emerge, as new stories emerge organically out of the dynamically changing relationships between non-player characters in the world, the need for scripting decreases.

-

The problem with scripting is that it greatly limits player agency. The story can only have one of a few predetermined – literally, scripted – endings. This is clearly expressed in a review of Red Dead Redemption 2 which I recomment to you; but is equally true of almost all other games.

+

And as new gameplay possibilities emerge, as new stories emerge organically out of the dynamically changing relationships between non-player characters in the world, the need for scripting decreases.

+

The problem with scripting is that it greatly limits player agency. The story can only have one of a few predetermined – literally, scripted – endings. This is clearly expressed in a review of Red Dead Redemption 2 which I recomment to you; but is equally true of almost all other games.

Dynamic side quests have fallen into disfavour, because, when they’ve been tried in earlier generation games, there were too few possibilities, and they became repetitive and boring. I don’t believe, with the wealth of compute resource we now have, this any longer need be the case. On the contrary, I think we can now dynamically generate a wide range of different, and differently complex, side quests. I think, in fact, that these can emerge organically from the structure of the game world.

-

Death to Psycho-Killer

-

If the main way a player can interact with non-player characters is to kill them, and if the player doesn’t have a systematic combat advantage over non-player characters, then it’s going to be a short game. This is why players in many or most video games do start with a systematic combat advantage, and that combat advantage tends to increase over the course of the game as the player becomes more proficient with the combat system, and acquires better weapons, armour and combat buffs. This in turn means that to keep combat ‘interesting’, the game either has to through larger and larger armies of ‘bad’ non-player characters against the player – a fault seen at its worst in Dragon Age 2.

\ No newline at end of file +

Death to Psycho-Killer

+

If the main way a player can interact with non-player characters is to kill them, and if the player doesn’t have a systematic combat advantage over non-player characters, then it’s going to be a short game. This is why players in many or most video games do start with a systematic combat advantage, and that combat advantage tends to increase over the course of the game as the player becomes more proficient with the combat system, and acquires better weapons, armour and combat buffs. This in turn means that to keep combat ‘interesting’, the game has to through larger and larger armies of ‘bad’ non-player characters against the player – a fault seen at its worst in Dragon Age 2.

+
\ No newline at end of file diff --git a/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html b/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html index 69bafa6..4b27654 100644 --- a/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html +++ b/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html @@ -1,19 +1,19 @@ -Gossip, scripted plot, and Johnny Silverhand

Project

Topics

Namespaces

Gossip, scripted plot, and Johnny Silverhand

+Gossip, scripted plot, and Johnny Silverhand

Project

Topics

Namespaces

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. -
  2. A decision on whether to co-operate based on the particular NPC’s general demeanor and particular attitude to the player;
    3. -
  3. A search of the game state and lore for relevant information;
    4. -
  4. A filtering of the results based on what the particular NPC can be expected to know;
    5. -
  5. Generation of a textual response from those results based on a library of templates which defines the particular NPC’s dialect and style of speech;
    6. -
  6. Production of audio using a [Lyrebird]{https://www.descript.com/overdub?lyrebird=true) style generated voice.
    7. +
  7. Alexa/Siri style speech interpretation;
    8. +
  8. A decision on whether to co-operate based on the particular NPC’s general demeanor and particular attitude to the player;
    9. +
  9. A search of the game state and lore for relevant information;
    10. +
  10. A filtering of the results based on what the particular NPC can be expected to know;
    11. +
  11. Generation of a textual response from those results based on a library of templates which defines the particular NPC’s dialect and style of speech;
    12. +
  12. Production of audio using a Lyrebird style generated voice.

As I’ve argued before, the game engine necessarily knows everything about the lore, and the current state, of the game world. It would be possible for any non-player character to answer literally any question about the game world, from who was mayor of Night City in 2020 to who lives in the apartment one floor up from yours, to what the weather is like in North Oaks just now.

What individual characters know should, of course, be more limited. People who live in Japantown or Heywood are unlikely to know who lives in a particular apartment in Watson; only real old timers, like Rogue, are likely to remember who was mayor fifty years ago. That’s the reason for filtering; but the filtering really isn’t a big deal.

Again, the generation of distinct voices for hundreds of non-player characters isn’t any longer a big deal. Distinct social groups – the corpos, and the different gangs such as Maelstrom or the Mox, will have their own argot, their own slang, their own habitual figures of speech which can be encoded into template libraries, while technologies like Lyrebird can produce an infinite range of realistic-sounding voices.

-

In particular, they can mimic real voices. They can mimic the voices of real actors. They can mimic Keanu Reeves.

+

In particular, they can mimic real voices. They can mimic the voices of real actors. They can mimic Keanu Reeves. (Interestingly, since I first wrote this note, CD Projekt Red have used Lyrebird-like technology to resurrect a voice actor in Phantom Liberty, proving that the technology is good enough).

So: how do you integrate this free form ‘you can say anything to any character’ style of play with scripted plot?

Obviously, my vision – as I’ve set out in Organic Quests – is that many quests should emerge organically from modelling the lives, activities and motivations of non-player characters. But that’s a radical vision and not one you can really expect many people to buy into until it has been demonstrated to work. I think that investors are still going to want to have confidence that there’s something exciting in the game for players to engage with, and I think directors are still going to want to tell the stories they want to tell.

So if I’m to sell the idea of free-form speech interaction with characters in the game world, I need an account of how it works with scripted characters voiced by high value actors in a scripted plot. I’m picking Johnny Silverhand as a core example, here, because I think he presents particular challenges.

@@ -24,33 +24,34 @@

How should the game handle unscripted responses in scripted dialogues?

Well, the first and obvious thing is to parse the unscripted response to see whether it’s a variant of one of the scripted responses, and if it seems that it might be, perhaps ask the player to verify that:

-

V: Just get on with it already.

-

Panam: You mean, go to the shiv camp?

-

V: Yes, dammit.

+

V: Just get on with it already.

+

Panam: You mean, go to the shiv camp?

+

V: Yes, dammit.

But the second thing is to respond to the response exactly as the non-player character would if the player had initiated the conversation, using the pipeline given at the beginning of this essay. Of course, in the special case of Johnny Silverhand, he is – at least initially – decidedly hostile and extremely selfish, so his response will typically come at step two in the pipeline:

-

V: Hey, Johnny, what’s the quickest way from here to Jig Jig Street?

-

Johnny: What am I now, your fucking tour guide?

-

V: Oh, come on, Johnny, help me out a bit here, Where’s the nearest gun dealer?

-

Johnny: How the fuck should I know? I haven’t been here for fifty years, all I know is ancient history.

+

V: Hey, Johnny, what’s the quickest way from here to Jig Jig Street?

+

Johnny: What am I now, your fucking tour guide?

+

V: Oh, come on, Johnny, help me out a bit here, Where’s the nearest gun dealer?

+

Johnny: How the fuck should I know? I haven’t been here for fifty years, all I know is ancient history.

The benefit of this interaction style is that these responses could be real acted responses by the voice actor (in this case, Keanu Reeves), which avoids the ‘uncanny valley’ risk that generated speech from a character the player has become used to interacting with may not sound quite natural enough.

But, if we’ve used Lyrebird technology to capture and mimic Reeves’ voice, and if Johnny is for some reason uncharacteristically mellow, then generated voice responses should be used. So suppose the player asks something which Johnny ought reasonably to know:

-

V: Hey, Johnny, what’s between you and Rogue?

+

V: Hey, Johnny, what’s between you and Rogue?

That’s lore. It’s in at least one of the in-game ‘shard’ texts. The game engine knows it. A text can be generated for Johnny to respond:

-

Johnny: We were lovers, back in the day.

+

Johnny: We were lovers, back in the day.

In any of these cases, in order for the scripted plot to proceed, the non-player character can circle back to the thing they said that the player hasn’t yet made an appropriate response to:

-

Johnny:But you didn’t answer my question. Repeats question.

+

Johnny:But you didn’t answer my question. Repeats question.

or

-

Johnny: As I said before, Repeats what he said before.

+

Johnny: As I said before, Repeats what he said before.

Again, for key plot characters, the voice actors can actually record multiple different canned texts of this form, so that, when played, they don’t sound excessively repetitious.

-

In short, it doesn’t seem to me that it would be at all hard to integrate free form voice interaction with a modern scripted video game. The advantage is that player interaction with non-player characters would become far richer and more engaging, and consequently it would be much easier to allow the player to progress through the plot without the default outcome of every encounter having to be a blood-bath.

\ No newline at end of file +

In short, it doesn’t seem to me that it would be at all hard to integrate free form voice interaction with a modern scripted video game. The advantage is that player interaction with non-player characters would become far richer and more engaging, and consequently it would be much easier to allow the player to progress through the plot without the default outcome of every encounter having to be a blood-bath.

+
\ No newline at end of file diff --git a/docs/codox/MVP-Roadmap.html b/docs/codox/MVP-Roadmap.html new file mode 100644 index 0000000..e416625 --- /dev/null +++ b/docs/codox/MVP-Roadmap.html @@ -0,0 +1,42 @@ + +Minimum Viable Product, and a road map

Project

Topics

Namespaces

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.

+

I also know that the movement of a character around a convincing three dimensional representation of a world can be done, but that a great deal of effort is needed to build that world.

+

The minimum viable product does not need to demonstrate features which people have reasonable confidence can be done. What I need to demonstrate is the things which people haven’t seen done, or haven’t seen done well.

+

Prototype one: the minimum viable product

+

The minimum viable product can have just a text adventure style interface:

+
+

You are in the market square. It is mid morning. To the north is the guild hall; to the east there are market stalls; to the south is the residence; to the west is the bridge gate.

+

There is a merchant here; there is a guardsman here.

+
+

To which the user can type (for example)

+
+

Say to the guardsman, “Can you direct me to Master Dalwhiel’s house?”

+
+

Within that interface, you should be able to interact with characters who:

+
    +
  1. have different levels of knowledge of the world, partly driven by their age, trade and personal history;
    2. +
  2. move about and exchange gossip, even when the player is not present to see/hear this;
    3. +
  3. have different attitudes towards the player and other characters, which will be modified by what they learn in gossip;
    4. +
  4. have their own hierarchies of needs, which they make plans to satisfy;
    5. +
  5. have homes and trades;
    6. +
  6. will respond to speech addressed to them by the player depending on their attitude to the player, how busy they are and their knowledge of the world; and
    7. +
  7. as a stretch goal, will have different dialects in which they will express their responses to the player.
    8. +
+

There should be one or two multiple decision point quests in this world which can be resolved by talking to characters.

+

Prototype two: adding organic quests

+

Extends prototype one only by adding organic quests.

+

Prototype three: voice interaction

+

Extends prototype two by adding speech to text, so that the player can directly talk (via a microphone) to characters, and text to speech, so that the system can voice the characters’ responses.

+

Different characters should have different voices.

+

Prototype four: performative speech

+

This one is hard because I’m not absolutely sure how I can do it, but I need characters’ voices to convey emotion; the player needs to know from their voice whether they are angry, or frightened, or impatient, or bored.

+

There is a W3C specification for an XML markup for speech performance, and I can certainly generate that, but I’d need to find a text-to-speech library which could consume it. There’s also a separate specification to associate pronunciations with lexical tokens, which is also potentially useful, especially for names.

+

Google has a ‘Cloud Text-to-Speech’ service which understands SSML and might be good enough for a demo but is more likely just embarrassingly bad.

+

Prototype five traversible world

+

Now, a small section of a three dimensional open world, with at this stage simple block buildings that the player cannot enter, within which the characters act out their lives.

+

Stretch goal, JALI-like lip sync.

+
\ No newline at end of file diff --git a/docs/codox/Modelling_democracy_and_morale.html b/docs/codox/Modelling_democracy_and_morale.html new file mode 100644 index 0000000..809cbdf --- /dev/null +++ b/docs/codox/Modelling_democracy_and_morale.html @@ -0,0 +1,18 @@ + +The Red Company: modelling democracy and morale (unfinished)

Project

Topics

Namespaces

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.

+

These warrior tribesmen have settled down as local tyrants or robber barons, parasitising on the indigenous communities, and have evolved into an aristocratic (‘Ariston’) class. In the meantime, a mercantile class has grown up and established important long distance overland trade routes; and significant towns (called ‘cities’, but of only at most a few tens of thousand inhabitants) have grown up around markets.

+

These mercantile cities have been under the governance of powerful aristons known as tyrranoi, and the cities under their tyrranoi have competed militarily as well as commercially for control of strategic features on trade routes, such as bridges, fords, oases, mountain passes, and so on.

+

In the very earliest days of the warrior invasion, the warriors themselves fought against the indigenous peoples, who had very limited military equipment and tactics. Later, as they settled into Aristons, they fought by leading feudal levies of partially-trained peasants. Over the past hundred years or so, mercenary companies have emerged of specialist, trained warriors, and because these have more fighting experience (and often better equipment) they tend to beat feudal levies. These mercenary companies are base loosely on the condottierri of fourteenth century Italy.

+

So more and more, tyrranoi, rather than leading their own feudal levies, instead tax their peasantry and mercantile class more and hire condottierri to fight their wars.

+

Mercenary companies evolve out of feudal levies, and in the period of The Great Game, are mostly owned and led by aristons who employ their soldiers by paying them a wage.

+

One company, the Red Company, has become essentially a workers’ co-op, after its former ariston leader fled in the course of a battle which looked like an inevitable defeat (but which the company, without him, won). In this company, soldiers are paid a salary, probably lower than salaries in other companies, but also at the end of the year get a share in the profits. The soldiers are organised into squads of eight who elect their own sergeants; squads are organised into companies of eight squads, and the sergeants elect the captain; companies are organised into legions of eight companies, and the captains elect the captain-general.

+

However, while in combat this represents a chain of command, out of combat it is much more a delegate structure; when making significant decisions, the captains general will consult with the captains who will consult with the sergeants who will consult with the soldiers.

+

One of the themes of the stories I want to tell is that this more democratic structure contributes to higher morale and hence to greater military success. I could model this by just making membership of the Red Company a factor in the function which computes morale. However…

+

Modelling democracy

+

If each individual character has a hierarchy of needs, and plans actions based on that hierarchy of needs, then they have the mechanism in place to choose which of two options better conforms to their hierarchy of needs.

+

This implies that soldiers are likely to vote for the people (or ideas presented by the people) they consider most competent and/or most trustworthy. Which comes back to modelling reputation; which comes back to the gossip.

+
\ No newline at end of file diff --git a/docs/codox/Modelling_trading_cost_and_risk.html b/docs/codox/Modelling_trading_cost_and_risk.html new file mode 100644 index 0000000..9871109 --- /dev/null +++ b/docs/codox/Modelling_trading_cost_and_risk.html @@ -0,0 +1,8 @@ + +Modelling trading cost and risk (unfinished)

Project

Topics

Namespaces

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?

+

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

+
\ No newline at end of file diff --git a/docs/codox/My-setting.html b/docs/codox/My-setting.html new file mode 100644 index 0000000..60a7047 --- /dev/null +++ b/docs/codox/My-setting.html @@ -0,0 +1,6 @@ + +My setting for the Great Game

Project

Topics

Namespaces

My setting for the Great Game

+

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

+

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

+
\ No newline at end of file diff --git a/docs/codox/Naming-of-characters.html b/docs/codox/Naming-of-characters.html new file mode 100644 index 0000000..dd532a4 --- /dev/null +++ b/docs/codox/Naming-of-characters.html @@ -0,0 +1,32 @@ + +Naming of Characters

Project

Topics

Namespaces

Naming of Characters

+

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

+

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

+

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

+

Based on, roughly, historical name patterns like

+

Archibald (personal-name) the Grim (epithet), Earl (trade-or-rank) of Douglas (location)

+

Where

+
    +
  1. +

    epithet is a prefix based on some notable feature or feat of the character. Most characters won’t have an epithet, unless they have some notable feature or they’ve done something notable. If a character does something notable in the course of the game, they will subsequently gain an epithet; ‘notability’ may be measured by how many times the event is transmitted through the gossip network.

    +
    2. +
  2. +

    clan is special to the Western Clans, although people from the Great Place may possible use the name of their house similarly.

    +
    3. +
  3. +

    personal-name is chosen from one of a limited set of limited sets; different cultural groups will have different (possibly overlapping) sets of names, but within each set there will only be a limited subset

    +
    4. +
  4. +

    trade-or-rank is just that. “Smith”, “Miller”, “Ariston”, “Captain”. Either only master craftsfolk have the trade-or-rank name of their craft, or we distinguish between ‘Calon the Smith’, who may be a journeyman, and ‘Calon the Master Smith’, who is a master.

    +
    5. +
  5. +

    location is the name of a location; a village, town, city or province. The location which forms part of a character’s name is the location where there current home is, not the location where they were born or where their ancestors came from

    +
    6. +
+

Full names will almost never be used - only, perhaps, in extremely formal circumstances. The form of a name used will depend on context, and will generally be just sufficient to disambiguate the character in the context.

+

If the speaker is in Sinhua and referring to someone from Sinhua, they won’t refer to them as ‘of Sinhua’.

+

If everyone present is a bargee and the speaker referring to someone who is also a bargee, they won’t refer to them as ‘the bargee’.

+

The question asked influences the context: in answer to the question ‘who is the best sword smith’, the answer will not be ‘Calon the Smith’ but ‘Calon of Sinhua’.

+

Patronymics/matronymics will not normally be used of adults (although they may be used of apprentices and journeymen.

+
\ No newline at end of file diff --git a/docs/codox/Not_my_problem.html b/docs/codox/Not_my_problem.html new file mode 100644 index 0000000..4c07580 --- /dev/null +++ b/docs/codox/Not_my_problem.html @@ -0,0 +1,21 @@ + + Not my problem

Project

Topics

Namespaces

# 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

+
    +
  1. Gossip
    2. +
  2. Reputation
    3. +
  3. Dynamic character motivation and action, and hence
    4. +
  4. Dynamic economy, and
    5. +
  5. Dynamic plot
    6. +
  6. Procedural (‘genetic’) buildings.
    7. +
+

(Note that although procedural vegetation is in principle a solved problem and so I don’t need to solve it, I need repeatable procedural vegetation so I need to be a bit careful about the procedural vegetation library I pick).

+

Animation

+

I envisage a well rendered three dimensional world in which many non-player characters interact with one another and with the player character. All of my characters are either human, quadrupeds, or birds (my dragons animate like very large birds). The humans are all just human; there are infants, children, adolescents, youths, adults, elderly; there are multiple racial types — but they’re all human. Systems for creating varied distinct human models exist; systems for animating them exist; systems for applying and animating clothing exist. Even systems for animating continuous speech exist.

+

Rendering

+

Ideally I’d like a stylised, not-quite-photorealistic render, because such things age, in my opinion, better than things which do seek to be photorealistic. But actually that does not matter very much; the game won’t be made or broken by its rendering. Photorealistic renders are sort of the current default, that most game engines.

+

Continuous Open World

+

I’ve done a great deal of thinking about how to render a continuous open world over the years, and I think at least some of it is reasonably good; but I haven’t actually written any code, and in the same time period other people have written continuous open world libraries which do work, so I’d be much better choosing an existing one.

+
\ No newline at end of file diff --git a/docs/codox/On-dying.html b/docs/codox/On-dying.html new file mode 100644 index 0000000..b2c3ba2 --- /dev/null +++ b/docs/codox/On-dying.html @@ -0,0 +1,17 @@ + +On Dying, and Injury

Project

Topics

Namespaces

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.

+

Time has passed; events in the game world have moved on. You can talk to your saviours about it. You have lost a lot of strength, and most of the gear you were carrying. You must do whatever it is you do within the game mechanics to rebuild strength, and to acquire more gear. Significantly you have acquired a debt of honour to your saviours, which they may call on later. You almost certainly have new scars, and might possibly have some lasting effects (although how that interacts with other game mechanics might be tricky).

+

So who are the non-enemies? It depends on context. If you have a party, and some of that party survived the fight, it’s your party. Otherwise, if you’re in a populated place, it’s locals. If it’s on a road or other route, it’s passing merchants. If you’re in the wilderness, a hunting party. It’s a bunch of non-hostiles who might reasonably be expected to be around: that’s what matters. It’s about not breaking immersion.

+

Obviously losing a fight must have weight, it must have meaning, it must have in-game consequences; otherwise it is meaningless.

+

Injury

+

Similarly to death, injury must have meaning. Any injury takes time to recover from. It takes a certain amount of time if you’re able to rest somewhere safe, and considerably longer if you’re not. If you fight while injured, you’ll have less strength, less stramina, and probably also less agility. Depending where you’re injured, there will be certain things you cannot do. If you fight while injured, also, your recovery time will be extended, even if you take no further injury.

+

Some serious injuries will lead to permanent scarring, and permanent loss of agility; you’ll be just slightly slower in fights.

+

It should be said that Kenshi — a game I’ve only recently become aware of and greatly admire — handles all of this extremely well, and is worth studying.

+

Reciprocity

+

If the player is going to depend on good samaritans for rescue after losing a fight, then there must be at least a social convention that people should assist people found injured on the wayside. Consequently, if the player fails to do this, that should in itself become a ‘gossip’ event which will lower the player’s reputation with non-player characters.

+

On the other hand, helping NPCs found injured at the wayside can be another category of organic quest, as a special subcategory of an escort quest.

+
\ No newline at end of file diff --git a/docs/codox/On-sex-and-sexual-violence.html b/docs/codox/On-sex-and-sexual-violence.html new file mode 100644 index 0000000..e732298 --- /dev/null +++ b/docs/codox/On-sex-and-sexual-violence.html @@ -0,0 +1,36 @@ + +On Sex, and Sexual Violence, in Games

Project

Topics

Namespaces

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.

+

Secondly, it is extremely tricky to represent sexual violence in visual media without eroticising it. There’s a very famous scene in Last Tango in Paris which the director might claim is consented in context, but which appears to me to be a clear case of anal rape, which is nevertheless highly erotic. There’s a scene in High Plains Drifter where no part of the rape is actually represented — it happens off screen — but it is nevertheless perceived by many people (including me) as eroticised. Many people — I suspect more men than women, but certainly including many women — do find the idea of rape erotic. It seems to me highly undesirable that a game should be seen to be rewarding immoral action.

+

(Yes, I know many modern games do quite explicitly reward killing, including of characters whose culpability is at best trivial, but — surely — this is something we should be seeking to move away from.)

+

Subtlety and Nuance

+

A final issue here is that sexual interactions between people are subtle, and are subtle even around issues of consent. A less powerful person (normally a woman) — alone or as a member of a weak party, a party of perhaps older people, other women, children — may submit to sex with more powerful others without protest in order to protect others in their party, or to avoid death or serious injury, or to avoid starvation, or to escape debt. Do any of these things truly count as consent?

+

Again, a less powerful person may submit to sex with more powerful others transactionally in return to protection, or shelter, or food, or other resources. In modern society we might see this as sex work, and we might argue that sex work falls into the same moral category as any other labour entered into transactionally. But, generally, is it moral that people should be put into a position where their survival depends on their ability to sell any sort of unwilling labour?

+

(This is not to deny that some people, who do have secure living conditions or who could choose to do other things in order to gain secure living conditions do choose, willingly and voluntarily, to engage in sex work; and it isn’t to criticise those people in any way).

+

Games are not very good at subtly and nuance. When, while playing a game, the character who is our avatar in the game, who we thought we were controlling, does something which we didn’t intend them to do, it’s very wrenching and immersion-breaking.

+

At the same time, if other characters in the game interpret something the player’s character has done as sexual violence when the player did not intend sexual violence, that’s also undesirable.

+

So, questions:

+

Sex between non-player characters

+

People have sex. If people didn’t have sex, there wouldn’t be people; but more, if people didn’t have sex, there wouldn’t be (many) stories, since most stories are driven at least in part by sex. So pretending that non-player characters don’t have sex is worse than unrealistic.

+

We live in a pathologically repressed society, in which open sex — sex in public places, sex with other people present — is rare, is seen as deviant, is (perhaps in consequence) highly eroticised. Does that mean that all the societies we represent in our games must be similarly repressed?

+

I would argue strongly to the contrary. Games are environments in which we can explore moral possibilities, and a society in which public sexuality was normal is clearly a possibility. Would such a society be a better society? Games are a mechanism through which we can ask that question, and questions of that sort.

+

If we’re going to represent a society in which public sex is normal, then we’re going to have to represent public sex on screen. It can take one of many forms:

+
    +
  1. Sex as normal activity — it’s just going on in the background, and no other non-player characters pay much attention;
    2. +
  2. Sex as conscious performance — sex where the participants intend to be watched, and other non-player characters do pay attention (this may include consciously eroticised performance);
    3. +
  3. Sex as part of a religious or other ritual event — this is related to, and is, sex as conscious performance, but the purpose of the performance is symbolic and/or sacramental. This doesn’t mean it is not eroticised, but it may not be eroticised.
    4. +
+

By ‘eroticised’, I’m meaning deliberately intended to trigger sexual feelings in the audience — which, if the player character is present, includes the player.

+

Sexual violence between non-player characters

+

In a world in which there are characters who are thuggish, who seek to dominate, terrorise and subdue other characters, whether those characters are outlaws or soldiers or aristocrats, to pretend that rape would not be used as a means to dominate, terrorise or subdue is… bowdlerisation. It’s unrealistic, and it’s a morally indefensible choice.

+

So there has to be a mechanism for non-player characters to decide to commit acts of sexual violence towards other non-player characters. The player must at least hear of such events through the gossip network, and should be able to find the specific non-player characters involved, and speak to them. Whether it’s necessary to portray acts of sexual violence on screen is something I’m much less persuaded by, simply because it runs the risk of eroticising them.

+

Mutually consented sexual activity between the player character and non-player characters

+

Mutually consented sexual behaviour between the player character and (certain, scripted) non-player characters has been a feature of video games for some time, and has occasionally been portrayed with real sensitivity and eroticism. Two cases I would point to are

+
    +
  1. The sex scene between Geralt and Shani in The Witcher
    2. +
+

Sexual violence from the player character towards non-player characters

+
\ No newline at end of file diff --git a/docs/codox/Organic_Quests.html b/docs/codox/Organic_Quests.html index 750f61d..aced7ca 100644 --- a/docs/codox/Organic_Quests.html +++ b/docs/codox/Organic_Quests.html @@ -1,23 +1,23 @@ -Organic Quests

Project

Topics

Namespaces

Organic Quests

-

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

+Organic Quests

Project

Topics

Namespaces

Organic Quests

+

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

    -
  1. Kill quests
    2. -
  2. Combo quests
    3. -
  3. Delivery quests
    4. -
  4. Gather quests
    5. -
  5. Escort quests
    6. -
  6. Syntax quests
    7. -
  7. Hybrids
    8. +
  8. Kill quests
    9. +
  9. Combo quests
    10. +
  10. Delivery quests
    11. +
  11. Gather quests
    12. +
  12. Escort quests
    13. +
  13. Syntax quests
    14. +
  14. Hybrids

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

Note, however, that if we consider a delivery quest to have four locations, where some of these locations may be coincident, then a delivery quest and a fetch quest become the same thing. Thus

    -
  1. The location of the quest giver at the beginning of the quest;
    2. -
  2. The location from which the quest object must be collected;
    3. -
  3. The location to which the quest object must be delivered;
    4. -
  4. The location of the quest giver at the end of the quest.
    5. +
  5. The location of the quest giver at the beginning of the quest;
    6. +
  6. The location from which the quest object must be collected;
    7. +
  7. The location to which the quest object must be delivered;
    8. +
  8. The location of the quest giver at the end of the quest.

This characterisation assumes that at the end of each quest, the player must rendezvous with the quest giver, either to report completion or to collect a reward. Obviously, there could be some quests where this fourth location is not required, because there is no need to report back (for example, if the quest giver was dying/has died) and no reward to be collected.

Note that a location is not necessarily a fixed x/y location on the map; in a kill quest, for example, location 2 is the current location of the target, and moves when the target moves; location 3 and 4 are both normally the current location of the quest giver, and move when the quest giver moves.

@@ -27,9 +27,9 @@

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

So essentially quests break down into three core types

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

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

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

@@ -41,6 +41,7 @@

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

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

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

-

Stuff to consider

+

Stuff to consider

The games Middle Earth: Shadow of Mordor, and Middle Earth: Shadow of War have a procedural story system called Nemesis, which is worth a look.

-

There’s an interesting critique of Red Dead Redemption 2 which is relevant to what I’m saying here.

\ No newline at end of file +

There’s an interesting critique of Red Dead Redemption 2 which is relevant to what I’m saying here.

+
\ No newline at end of file diff --git a/docs/codox/Pathmaking.html b/docs/codox/Pathmaking.html index 703c9b3..604f4fb 100644 --- a/docs/codox/Pathmaking.html +++ b/docs/codox/Pathmaking.html @@ -1,24 +1,24 @@ -Pathmaking

Project

Topics

Namespaces

Pathmaking

+Pathmaking

Project

Topics

Namespaces

Pathmaking

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

-

Stages in creating routes between locations

+

Stages in creating routes between locations

see also Baking the world

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

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

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

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

-

Routing

+

Routing

Routing is fundamentally by A*, I think.

-

Algorithmic rules

+

Algorithmic rules

    -
  1. No route may pass through any part of a reserved holding, except the holding which is its origin, if any, and the holding which is its destination (and in any case we won’t render paths or roads within holdings, although traversal information may be used to determine whether a holding, or part of it, is paved/cobbled;
    2. -
  2. No route may pass through any building, with the exception of a city gate;
    3. -
  3. We don’t have bicycles: going uphill costs work, and you don’t get that cost back on the down hill. Indeed, downhills are at least as expensive to traverse as flat ground;
    4. -
  4. Any existing route segment costs only a third as much to traverse as open ground having the same gradient;
    5. -
  5. A more used route costs less to traverse than a less used route.
    6. +
  6. No route may pass through any part of a reserved holding, except the holding which is its origin, if any, and the holding which is its destination, if any (and in any case we won’t render paths or roads within holdings, although traversal information may be used to determine whether a holding, or part of it, is paved/cobbled;
    7. +
  7. No route may pass through any building, with the exception of a city gate;
    8. +
  8. We don’t have bicycles: going uphill costs work, and you don’t get that cost back on the down hill. Indeed, downhills are at least as expensive to traverse as flat ground;
    9. +
  9. Any existing route segment costs only a third as much to traverse as open ground having the same gradient;
    10. +
  10. A more used route costs less to traverse than a less used route.
-

Step costing:

+

Step costing:

Step cost is something like:

(/
   (-
@@ -30,67 +30,68 @@

Where

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

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

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

-

River crossings

-

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

+

River crossings

+

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

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

-

Representation

+

Representation

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

    -
  • exclusion used on polygons representing e.g. buildings, or impassable terrain which may not be traversed at all;
    • -
  • openwater used on polygons representing oceans and lakes, which may be traversed only by boat (or possibly swimming, for limited distances);
    • -
  • watercourse used on paths representing rivers or streams, with some additional attribute giving rate of flow;
    • -
  • navigable may be an additional class on a path also marked watercourse indicating that it is navigable by cargo vessels;
    • -
  • route used on paths representing a path, track or road whose final representation will be dynamically assigned at the end of baking, with some additional attribute giving total traversals to date;
    • -
  • path used on paths representing a path designed by the designers, which will certainly be rendered as a path no matter how frequently it is traversed;
    • -
  • track used on paths representing a track designed by the designers, which will certainly be rendered as a track no matter how frequently it is traversed;
    • -
  • road used on paths representing a road designed by the designers, which will certainly be rendered as a road no matter how (in)frequently it is traversed.
    • +
  • exclusion used on polygons representing e.g. buildings, or impassable terrain which may not be traversed at all;
    • +
  • openwater used on polygons representing oceans and lakes, which may be traversed only by boat (or possibly swimming, for limited distances);
    • +
  • watercourse used on paths representing rivers or streams, with some additional attribute giving rate of flow;
    • +
  • navigable may be an additional class on a path also marked watercourse indicating that it is navigable by cargo vessels;
    • +
  • route used on paths representing a path, track or road whose final representation will be dynamically assigned at the end of baking, with some additional attribute giving total traversals to date;
    • +
  • path used on paths representing a path designed by the designers, which will certainly be rendered as a path no matter how frequently it is traversed;
    • +
  • track used on paths representing a track designed by the designers, which will certainly be rendered as a track no matter how frequently it is traversed;
    • +
  • road used on paths representing a road designed by the designers, which will certainly be rendered as a road no matter how (in)frequently it is traversed.

At the end of the baking process the routing engine should be able to write out an updated SVG. New routes should be splined curves, so that they have natural bends not sharp angles.

-

The ‘Walkmap’

+

The ‘Walkmap’

Conventional game pathfinding practice is to divide the traversable area into a mesh of ‘convex polygons’, where a ‘convex polygon’ in this sense is, essentially, a polygon having no bays. Routes traverse from a starting point to the centre of a polygon ajacent to the polygon in which the starting point is located. I have reservations as to whether this will do what I need since I’m not convinced it will produce naturalistic paths; however, it’s worth at least experimenting with.

-

There are existing utilities (such as hmm) which convert heightmaps into suitable geometry files; however all I’ve found so far convert to [binary STL](https://en.wikipedia.org/wiki/STL_(file_format)). This isn’t a format I find very useful; I’d prefer an XML dialect, and SVG is good enough for me.

+

There are existing utilities (such as hmm) which convert heightmaps into suitable geometry files; however all I’ve found so far convert to binary STL. This isn’t a format I find very useful; I’d prefer an XML dialect, and SVG is good enough for me.

hmm converts the heightmap into a tesselation of triangles, which are necessarily convex in the sense given above. Utilities (such as binary-stl-toASCII) exist to convert binary STL to an ASCII encoded equivalent, which may be easier to parse.

So the pipeline seems to be

    -
  1. heightmap to binary STL
    2. -
  2. (optional) binary STL to ASCII STL
    3. -
  3. STL to SVG (where ‘SVG’ here is shorthand for a convenient vector format)
    4. -
  4. Exclude holdings, buildings, open water, and other exclusions
    5. -
  5. Where we have excluded exclusions, ensure that any non-convex polygons we’ve created are divided into new convex polygons.
    6. +
  6. heightmap to binary STL
    7. +
  7. (optional) binary STL to ASCII STL
    8. +
  8. STL to SVG (where ‘SVG’ here is shorthand for a convenient vector format)
    9. +
  9. Exclude holdings, buildings, open water, and other exclusions
    10. +
  10. Where we have excluded exclusions, ensure that any non-convex polygons we’ve created are divided into new convex polygons.

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

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

-

Pathmaking and scale

+

Pathmaking and scale

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

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

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

-

Phase one: hand-designed routes

+

Phase one: hand-designed routes

While, given the bottlenecks of the few mountain passes and the one possible pass over the plateau, the caravan routes we want would almost certainly emerge organically out of dynamic routing. But, actually, I know more or less where they need to be and it’s probably easiest to hand design them. It will certainly save an enormous amount of brute-force compute time.

I think I have to accept that if I want Alpe d’Huez-style switchbacks up the Sunset and Midnight passes, they’re going to have to be hand designed. The same applies to where the Hans’hua caravan road ascends the plateau.

-

Phase two: route segments ‘for free’ out of settlement activity

+

Phase two: route segments ‘for free’ out of settlement activity

If we start by pathmaking around settlements, we can make a first start by giving the template for a holding a segment of track parallel to and just in front of its frontage, and a segment of path along its left hand and rear edges. That, actually, is going to provide 90% of all routing within a settlement, and it’s done for us within the Settling-a-game-world phase.

-

Phase three: metre scale routing around settlements

+

Phase three: metre scale routing around settlements

So if we then collect groups of contiguous 100x100 metre zones each of which has at least one settled holding, we can route at one metre scale over that and what it will essentially do is join up and augment the route segments generated by settlement. Areas of dense settlement do not make up a great deal of the map. Note that experience may show that the metre scale routing is superflous.

-

Phases four, five and six: increasing granularity

+

Phases four, five and six: increasing granularity

Taking the augmented route map comprised of

    -
  1. The hand-designed, mainly long distance or plot-important routes;
    2. -
  2. The route segments bordering holdings;
    3. -
  3. The metre scale routing
    4. +
  4. The hand-designed, mainly long distance or plot-important routes;
    5. +
  5. The route segments bordering holdings;
    6. +
  6. The metre scale routing

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

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

-

Relevant actor classes by phase

+

Relevant actor classes by phase

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

-

Tidying up

+

Tidying up

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

-

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

\ No newline at end of file +

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

+
\ No newline at end of file diff --git a/docs/codox/Populating-a-game-world.html b/docs/codox/Populating-a-game-world.html index e208fd9..71f958c 100644 --- a/docs/codox/Populating-a-game-world.html +++ b/docs/codox/Populating-a-game-world.html @@ -1,297 +1,113 @@ -Populating a game world

Project

Topics

Namespaces

Populating a game world

-

Saturday, 6 July 2013

+Populating a game world

Project

Topics

Namespaces

Populating a game world

+

Saturday, 6 July 2013

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

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

-

Basic occupations

+

Basic occupations

The following are ‘unskilled’ occupations which form the base of the occupation system. Generally a male character at maturity becomes a ‘Vagrant’ and wanders though the world until he encounters a condition which allows him to advance up the occupation graph. If an occupation wholly fails, the character can revert to being a ‘Vagrant’ and start again.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + +
Occupation Dwelling condition New trade Notes
Vagrant None land available and animals available Herdsman
Vagrant None arable land available Farmer See crops
Vagrant None has weapons Outlaw
Herdsman None Insufficient food Vagrant
Farmer Farm Insufficient food Vagrant
Outlaw None loses weapons Vagrant
Vagrant None craftsman willing to take on apprentice Apprentice
Herdsman None arable land available Farmer
Outlaw None Battle hardened OutlawLeader
Apprentice (craftsman’s) Qualified Journeyman
Journeyman None Unserviced customers available Craftsman See crafts
Craftsman See crafts Too few customers Journeyman
Journeyman None arable land available Farmer
Vagrant None Lord with vacancies available Soldier See military
OutlawLeader None Unprotected farms available Laird See nobility
Occupation Dwelling condition New trade Notes
Vagrant None land available and animals available Herdsman
Vagrant None arable land available Farmer See crops
Vagrant None has weapons Outlaw
Herdsman None Insufficient food Vagrant
Farmer Farm Insufficient food Vagrant
Outlaw None loses weapons Vagrant
Vagrant None craftsman willing to take on apprentice Apprentice
Herdsman None arable land available Farmer
Outlaw None Battle hardened OutlawLeader
Apprentice (craftsman’s) Qualified Journeyman
Journeyman None Unserviced customers available Craftsman See crafts
Craftsman See crafts Too few customers Journeyman
Journeyman None arable land available Farmer
Vagrant None Lord with vacancies available Soldier See military
OutlawLeader None Unprotected farms available Laird See nobility
-

Gender dimorphism

+

Gender dimorphism

In the paragraph above I said ‘a male character’. It may seem unfair to create a game world in which the sexual inequality of the real world is carried over, and for that reason it seems sensible that female children should have the same opportunities as male children. But games work on conflicts and injustices, and so it seems reasonable to me to have a completely different occupation graph for women. I haven’t yet drawn that up.

-

Wandering

+

Wandering

Vagrants wander in a fairly random way. While vagrants are wandering they are assumed to live off the land and require no resources. Solitary outlaws similarly wander until they find a leader, although they will avoid the areas protected by nobles. Herdsmen also wander but only over unenclosed pasture. They visit markets, if available, periodically; otherwise, they live off their herds. Journeymen wander from market to market, but are assumed to trade skills with farmers along the way.

-

Crafts

+

Crafts

Crafts are occupations which require acquired skills. In the initial seeding of the game world there are probably ‘pioneers’, who are special vagrants who, on encountering the conditions for a particular craft to thrive, instantly become masters of that craft.

- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + + + + + + + + + + + + + + +
Craft Dwelling Supplies Perishable? Customer types Needs market? Customers Supplier Suppliers Recruits
Solo Per journeyman Per apprentice
Craft Dwelling Supplies Perishable? Customer types Needs market? Customers Supplier Suppliers Recruits
Solo Per journeyman Per apprentice
— — —
Min Max Min Max Min Max
— — — — — — —
Smith Forge Metal Items no Farmer, Soldier No 6 10 4 6 1 3 Miner 1 Vagrant
Baker Bakery Bread yes All NPCs No 20 30 12 18 6 10 Miller 1 Vagrant
Miller Mill Flour, meal no Baker, Innkeeper No 2 3 1 2 1 1 Farmer 6 Vagrant
Weaver Weaver’s house Cloth no All NPCs Yes 6 10 4 6 1 3 Herdsman 2 Vagrant
Innkeeper Inn Food, hospitality yes Merhant, Soldier, Farmer, Lord No 10 20 5 10 2 4 Farmer,Herdsman 2 Vagrant
Miner Mine Ores no Smith Yes 2 3 1 2 1 1 Farmer 1 Vagrant
Butcher Butchery Meat yes All NPCs No 10 20 4 8 2 4 Farmer, Herdsman 2 Vagrant
Merchant Townhouse Transport, logistics n/a Craftsmen, nobility Yes 10 20 4 8 2 4 n/a n/a Vagrant
Banker Bank Financial services yes Merchant Yes 10 20 4 8 2 4 n/a n/a Merchant
Scholar Academy Knowledge n/a Ariston, Tyrranos, General, Banker No 1 4 1 2 0.25 0.5 n/a n/a Vagrant
Priest Temple Religion n/a All NPCs No 50 100 Scholar
Chancellor Chancellory Administration n/a Ariston, Tyrranos No 1 1 0 0 0 0 Scholar
Lawyer Townhouse Legal services n/a Ariston, Merchant, Banker No 4 6 2 3 1 2 Scholar
Magus Townhouse Magic n/a Tyrranos, General No 3 4 1 2 0.25 0.5 Scholar
-

| | | | | | | — | — | — | | | | | | | | | | | Min | Max | Min | Max | Min | Max | | | | | — | | | | | | — | — | — | — | — | — | | | | | Smith | Forge | Metal Items | no | Farmer, Soldier | No | 6 | 10 | 4 | 6 | 1 | 3 | Miner | 1 | Vagrant | | Baker | Bakery | Bread | yes | All NPCs | No | 20 | 30 | 12 | 18 | 6 | 10 | Miller | 1 | Vagrant | | Miller | Mill | Flour, meal | no | Baker, Innkeeper | No | 2 | 3 | 1 | 2 | 1 | 1 | Farmer | 6 | Vagrant | | Weaver | Weaver’s house | Cloth | no | All NPCs | Yes | 6 | 10 | 4 | 6 | 1 | 3 | Herdsman | 2 | Vagrant | | Innkeeper | Inn | Food, hospitality | yes | Merhant, Soldier, Farmer, Lord | No | 10 | 20 | 5 | 10 | 2 | 4 | Farmer,Herdsman | 2 | Vagrant | | Miner | Mine | Ores | no | Smith | Yes | 2 | 3 | 1 | 2 | 1 | 1 | Farmer | 1 | Vagrant | | Butcher | Butchery | Meat | yes | All NPCs | No | 10 | 20 | 4 | 8 | 2 | 4 | Farmer, Herdsman | 2 | Vagrant | | Merchant | Townhouse | Transport, logistics | n/a | Craftsmen, nobility | Yes | 10 | 20 | 4 | 8 | 2 | 4 | n/a | n/a | Vagrant | | Banker | Bank | Financial services | yes | Merchant | Yes | 10 | 20 | 4 | 8 | 2 | 4 | n/a | n/a | Merchant | | Scholar | Academy | Knowledge | n/a | Ariston, Tyrranos, General, Banker | No | 1 | 4 | 1 | 2 | 0.25 | 0.5 | n/a | n/a | Vagrant | | Priest | Temple | Religion | n/a | All NPCs | No | 50 | 100 | | | | | | | Scholar | | Chancellor | Chancellory | Administration | n/a | Ariston, Tyrranos | No | 1 | 1 | 0 | 0 | 0 | 0 | | | Scholar | | Lawyer | Townhouse | Legal services | n/a | Ariston, Merchant, Banker | No | 4 | 6 | 2 | 3 | 1 | 2 | | | Scholar | | Magus | Townhouse | Magic | n/a | Tyrranos, General | No | 3 | 4 | 1 | 2 | 0.25 | 0.5 | | | Scholar |

A craftsman starts as an apprentice to a master of the chosen crafts. Most crafts recruit from vagrants, A character must be a journeyman merchant before becoming an apprentice banker, while various intellectual crafts recruit from journeyman scholars.

It’s assumed that a journeyman scholar, presented with the opportunity, would prefer to become an apprentice magus than a master scholar.

+

### Related crafts

+

There are groups of crafts which should probably be seen as related crafts, where apprenticeship in one should serve as qualification to serve as journeyman in another. For example, there is a family of woodworking crafts, whose base is probably Joiner.

+

Crafts within this family include

+
    +
  • Boatwright
    • +
  • Cabinetmaker
    • +
  • Cartwright
    • +
  • Cooper
    • +
  • Lutanist
    • +
  • Military Artificer
    • +
  • Millwright
    • +
  • Turner
    • +
+

So although I think these are separate crafts, all are Joiners; all can undertake construction joinery work; and a journeyman who has served as apprentice to any can serve as journeyman to any other. Since journeymen will typically serve under more than one master before settling down, it will be possible for one person to have served under masters in two different related trades and therefore be qualified to set up as a master of either.

A journeyman settles and becomes a master when he finds a location with at least the solo/min number of appropriate customer type who are not serviced by another master craftsman of the same craft; he also (obviously) needs to find enough free land to set up his dwelling. The radius within which his serviced customers must live may be a fixed 10Km or it may be variable dependent on craft. If there are unserviced customers within his service radius, the master craftsman may take on apprentices and journeymen to service the additional customers up to a fixed limit – perhaps a maximum of four of each, perhaps variable by craft. If the number of customers falls, the master craftsman will first dismiss journeymen, and only in desperate circumstances dismiss apprentices. Every apprentice becomes a journeyman after three years service.

The list of crafts given here is illustrative, not necessarily exhaustive.

-

Aristocracy

+

Aristocracy

As in the real world, aristocracy is essentially a protection racket, and all nobles are originally outlaw leaders who found an area with rich pickings and settled down.

- - - - - - - - - - - - - - - - - - - - - - - -
Rank Follower rank Client type Clients protected Trade in market Followers per client
Min Max Min Max Min Max
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - + + + + + + + + + +
Bonnet Laird Private Farmer 6 20 0 100 0.25 0.5
Ariston Captain Bonnet Laird 10 30 25 1000 0.5 1
Tyrranos General Ariston 10 unlimited 250 unlimited 0.1 0.5
Rank Follower rank Client type Clients protected Trade in market Followers per client
Min Max Min Max Min Max
— — — — — — — — —
Bonnet Laird Private Farmer 6 20 0 100 0.25 0.5
Ariston Captain Bonnet Laird 10 30 25 1000 0.5 1
Tyrranos General Ariston 10 unlimited 250 unlimited 0.1 0.5

Every noble establishes a market and, if he employs a chancellor, taxes trade in it. Crafts which ‘need a market’ can only be established in the vicinity of a market, irrespective of whether there are sufficient customers elsewhere. All non-perishable goods are traded through the markets, and merchants will transfer surpluses between markets if they can make a profit from it.

My world has essentially three ranks of nobility. The title of the lowest rank will probably change to something vaguely italianate. An aristocrat advances to the next rank when either the requisite number of clients become available in the locality to support the next rank, or the trade in his market becomes sufficient to support the next rank.

Obviously when a province has eleven unprotected bonnet lairds, under the rules given above any of them may become the ariston, and essentially it will be the next one to move after the condition becomes true. If the number of available clients drops below the minimum and the market trade also drops below the minimum, the noble sinks to a lower level – in the case of the bonnet laird, to outlaw leader.

-

Military

+

Military

The aristocracy is supported by the military. An outlaw becomes a soldier when his leader becomes a noble. Otherwise, vagrants are recruited as soldiers by bonnet lairds or sergeants who have vacancies. Captains are recruited similarly by aristons or generals, and generals are recruited by tyrranos. If the conditions for employment no longer exist, a soldier is allowed a period of unemployment while he lives off savings and finds another employer, but if no employer is found he will eventually become an outlaw (or, if an officer, an outlaw leader). A private is employed by his sergeant or bonnet laird, a sergeant by his captain, a captain by his arison or general, a general by his tyrranos.

- - - - - - - - - - - - - - - - - - - - + + + + + + + + + + +
Rank Follower rank Followers Condition New rank
Min Max
Rank Follower rank Followers Condition New rank
Min Max
— — — — — —
Private None 0 0 Battle hardened, unled privates Sergeant
Sergeant Private 5 15 More battle hardened, unled sergeantts Captain
Captain Sergeant 5 15 More battle hardened, unled captains General
General Captain 5 unlimited
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Private None 0 0 Battle hardened, unled privates Sergeant
Sergeant Private 5 15 More battle hardened, unled sergeantts Captain
Captain Sergeant 5 15 More battle hardened, unled captains General
General Captain 5 unlimited
-

Soldiers have no loyalty to their employer’s employer.

\ No newline at end of file +

Soldiers have no loyalty to their employer’s employer.

+
\ No newline at end of file diff --git a/docs/codox/Roadmap.html b/docs/codox/Roadmap.html index f91d207..81298ce 100644 --- a/docs/codox/Roadmap.html +++ b/docs/codox/Roadmap.html @@ -1,22 +1,23 @@ -Roadmap

Project

Topics

Namespaces

Roadmap

+Roadmap

Project

Topics

Namespaces

Roadmap

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

-

JMonkeyEngine

+

JMonkeyEngine

JMonkeyEngine is not, at this time, an AAA game engine. But at the same time I’m never, really, going to build an AAA game. It is a working game engine which can display characters on screen in scenery and have them move around, and, actually, they can be fairly sophisticated. It will be resaonably easy to integrate Clojure code with JMonkeyEngine - easier than it would be to integrate either Clojure or Common Lisp with Unreal Engine or Unity 3D. As a significant added bonus, JMonkeyEngine is open source.

Consequently I plan to stop agonising about what game engine to use, and seriously focus on getting something working in JMonkeyEngine.

-

Not Reinventing Wheels

+

Not Reinventing Wheels

JMonkeyEngine already has working code for walking animated characters, which is entirely adequate to proof-of-concept what I want to do. Rather than try to implement them myself, I just intend to use existing JMonkeyEngine code as far as possible.

-

The 1Km World

+

The 1Km World

I propose to build a 1Km square world, containing one settlement, as a proof of concept for

    -
  1. Procedural (genetic) buildings;
    2. -
  2. Procedural settlement planning;
    3. -
  3. Procedural characters, probably based on MakeHuman ‘Mass Produce’ plugin, using walk animation based on TestWalkingChar;
    4. -
  4. Characters with their own hierarchy of needs, and their own means of planning to fulfil these;
    5. -
  5. Characters with individualised knowledge about the world;
    6. -
  6. Characters who can parse typed questions, and produce either a textual or audio response;
    7. -
  7. Characters with procedurally generated accents (very stretch goal)!
    8. -
  8. Characters who can listen to spoken questions, and produce audio responses.
    9. +
  9. Procedural (genetic) buildings;
    10. +
  10. Procedural settlement planning;
    11. +
  11. Procedural characters, probably based on MakeHuman ‘Mass Produce’ plugin, using walk animation based on TestWalkingChar;
    12. +
  12. Characters with their own hierarchy of needs, and their own means of planning to fulfil these;
    13. +
  13. Characters with individualised knowledge about the world;
    14. +
  14. Characters who can parse typed questions, and produce either a textual or audio response;
    15. +
  15. Characters with procedurally generated accents (very stretch goal)!
    16. +
  16. Characters who can listen to spoken questions, and produce audio responses.
-

At that stage, I have a technology demonstrator that will be interesting. It still leaves the big procedural world builder still to do, but it would be enough technology to get other people interested in the project.

\ No newline at end of file +

At that stage, I have a technology demonstrator that will be interesting. It still leaves the big procedural world builder still to do, but it would be enough technology to get other people interested in the project.

+
\ No newline at end of file diff --git a/docs/codox/Selecting_Character.html b/docs/codox/Selecting_Character.html new file mode 100644 index 0000000..af764b4 --- /dev/null +++ b/docs/codox/Selecting_Character.html @@ -0,0 +1,52 @@ + +Selecting the Player Character

Project

Topics

Namespaces

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.

+

In more recent games, there has been a trend towards more limited choice. In the games of The Witcher series, you get no choice at all, but play as Geralt of Rivia, who in the categorisation of Dungeons and Dragons, is a Fighter/Ranger, male, human, and somewhere between chaotic good and chaotic neutral depending on how you play him. In the Horizon series, you play as Aloy, again a Fighter/Ranger, female, human, and essentially chaotic good.

+

As I’ve argued elsewhere, part of the reason for limiting choice is voice acting.

+

Limiting choice of player character, especially in games with increasingly highly scripted stories, limits replayability; after two or three playthroughs, there are very few interesting surprises left.

+

The Self-voiced Player

+

If we have voice interaction sufficiently sophisticated that we can allow the player character to say more or less whatever they want to say — and my argument here is that we can do this — then we don’t need voice acting for the player character, and that gives us a lot of freedom. There’s then really no reason why the player can’t inhabit any character in the game world and play as that character.

+

Tinder as a Character Selector

+

Tinder is a dating app. It shows you pictures of potential partners, and you choose from them by swiping left to reject them, or right to express interest in them. That’s a kernel of an idea for how to select from among a large selection of people.

+

So how about:

+
    +
  1. The game developer selects a large subset of characters in the game as potentially playable. This might be as large as all characters who are not plot characters, as small as only soldiers, or most plausibly, any adult who is not yet in a long term romantic relationship. This forms the candidate set.
    2. +
  2. In the character selector, the game shows a character chosen at random from the set, and, each time the player rejects the character shown, shows another until the player accepts a character.
    3. +
+

That works, but we can do better.

+

Refining the Selection

+

Suppose, below the image of the character on the selection screen, we have a short text caption with name, age, home, occupation, gender, and below that, we have a row of icons showing attributes, with some representation of the character’s relative measurement of that attribute. Clicking one of these attribute icons would be interpreted as meaning ‘show me a character quite like the current character, but having a higher score on this particular attribute’.

+

Refinable Attributes

+

In lots of games which present the player with dialogue options, there are some options which can’t be selected unless the player character passes a ‘skill check’. Very often, for example, a player won’t be able to issue a particular threat unless they have a specific value of strength, or to say something flirtatious unless they have a specific value of charm.

+

It makes no sense in a game in which the player gets to freely choose what to say for an attribute like ‘charm’ to be a refinable attribute. Instead, responding to ‘charming’ or flirtatious or threatening or funny or sexually suggestive speech is a matter for the programming of a particular non-player character (although the interpretation of the speech and the tagging of it as charming or flirtatious or threatening or funny or suggestive would be a function of the top level speech input processor).

+

So, sensibly refinable attributes might include things like

+
    +
  1. Strength;
    2. +
  2. Agility;
    3. +
  3. Dexterity;
    4. +
  4. Endurance.
    5. +
+

I did think that ‘intelligence’ or ‘learning’ might be on that list but the more I think of it, the harder I find it to understand how low intelligence might be represented in a game in which the player speaks freely.

+

There’s another attribute icon with slightly different semantics which might sensibly be added, and that’s gender. Selecting this icon would be interpreted as meaning ‘show me a character quite like the current character, but having a different gender’.

+

Summary design

+

So the character selecter now looks like

+
    +
  1. A main area in which a rendering of the proposed character is shown; this rendering can be zoomed and rotated, so that the player can look at the face and body from different angles;
    2. +
  2. A description panel, normally hidden but when displayed replacing the character rendering in the main area, giving fuller biographical information about the character;
    3. +
  3. Below the main area, a caption, giving name, age, gender, occupation, home;
    4. +
  4. To the right hand side, a vertical column of attribute icons.
    5. +
+

To interact with the screen, the player can

+
    +
  1. Zoom in and out on the rendered image, for example with a mouse scroll wheel or the left and right trigger buttons of a game controller;
    2. +
  2. Rotate the rendered image, for example by dragging with the right mouse button held down or with the right joystick of a game controller;
    3. +
  3. Toggle between the character render and the description panel;
    4. +
  4. When the description panel is displayed, scroll it;
    5. +
  5. Select any attribute icon to refine the choice of character;
    6. +
  6. ‘Swipe left’ (or other action) to reject the current choice of character and choose another, without refining in any specific way;
    7. +
  7. ‘Swipe right’ to select the current character and procede into the game.
    8. +
+
\ No newline at end of file diff --git a/docs/codox/Settling-a-game-world.html b/docs/codox/Settling-a-game-world.html index ec1a28b..aaa237c 100644 --- a/docs/codox/Settling-a-game-world.html +++ b/docs/codox/Settling-a-game-world.html @@ -1,68 +1,69 @@ -Settling a game world

Project

Topics

Namespaces

Settling a game world

-

Wednesday, 30 December 2009

+Settling a game world

Project

Topics

Namespaces

Settling a game world

+

Wednesday, 30 December 2009

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

-

Microworld

+

Microworld

Some twenty years ago I wrote a rather sophisticated cellular automaton which I called ‘Microworld’ which modelled the spread of human population over a landscape. It did this by first fractally folding a grid to assign elevations to cells. Then, cells below a critical elevation – the tree line – were assigned as forest. For each cycle – ‘year’ – a cell remained forest, its soil fertility would increase. Random events – ‘lightning strikes’ could change a cell from forest to clearing. Then the following transitions might take place, each with a probability, where each cell is considered to have eight neighbours:

    -
  • A forest cell with a lightning strike as a neighbour may catch fire and burn
    • -
  • A forest cell with a fire as a neighbour may catch fire and burn
    • -
  • A burning cell become a clearing cell
    • -
  • A clearing cell with forest or scrub as a neighbour may become scrub
    • -
  • A scrub cell may become forest
    • +
  • A forest cell with a lightning strike as a neighbour may catch fire and burn
    • +
  • A forest cell with a fire as a neighbour may catch fire and burn
    • +
  • A burning cell become a clearing cell
    • +
  • A clearing cell with forest or scrub as a neighbour may become scrub
    • +
  • A scrub cell may become forest

This more or less completes the ‘natural’ cycle… then we get to settlement. Pastoral and agrarian 1 cells gradually degrade soil fertility (erosion, etc). Agrarian 2 cells do not degrade fertility.

    -
  • A clearing cell (including cells above the treeline) may become a pastoral cell (pastoral 1, no settlement)
    • -
  • A pastoral 1 cell whose soil fertility falls below a threshhold becomes waste
    • -
  • A pastoral 1 cell with no pastoral neighbours may become waste
    • -
  • A waste cell below the treeline may become scrub
    • -
  • A waste cell may become clearing
    • -
  • A pastoral 1 cell with two or more pastoral neighbours may become a pastoral 2 cell (settlement)
    • -
  • A forest cell with two or more pastoral neighbours may become clearing
    • -
  • A pastoral 2 cell with two or more pastoral 2 neighbours may become agrarian 1
    • -
  • An agrarian 1 cell which falls below a critical fertility becomes pastoral 1
    • -
  • An agrarian 1 cell with three or more agrarian 1 neighbours becomes agrarian 2 (smith, mill)
    • -
  • A cell with three or more agrarian 2 neighbours becomes market
    • -
  • A market cell with no agrarian 2, market or urban neighbours becomes waste
    • -
  • A cell with two or more market neighbours becomes urban
    • +
  • A clearing cell (including cells above the treeline) may become a pastoral cell (pastoral 1, no settlement)
    • +
  • A pastoral 1 cell whose soil fertility falls below a threshhold becomes waste
    • +
  • A pastoral 1 cell with no pastoral neighbours may become waste
    • +
  • A waste cell below the treeline may become scrub
    • +
  • A waste cell may become clearing
    • +
  • A pastoral 1 cell with two or more pastoral neighbours may become a pastoral 2 cell (settlement)
    • +
  • A forest cell with two or more pastoral neighbours may become clearing
    • +
  • A pastoral 2 cell with two or more pastoral 2 neighbours may become agrarian 1
    • +
  • An agrarian 1 cell which falls below a critical fertility becomes pastoral 1
    • +
  • An agrarian 1 cell with three or more agrarian 1 neighbours becomes agrarian 2 (smith, mill)
    • +
  • A cell with three or more agrarian 2 neighbours becomes market
    • +
  • A market cell with no agrarian 2, market or urban neighbours becomes waste
    • +
  • A cell with two or more market neighbours becomes urban

That’s simple, but it provides a remarkable good model of population spread. however, it is essentially a grid and so doesn’t make for natural-seeming landscapes when considered as a three dimensional rendered world. How can we do better?

-

Microworld Two

+

Microworld Two

The objective of this essay is to outline an angorithm for creating inhabited landscapes in which games can be set, which are satisfyingly believable when rendered in three dimensions. The objective of creating landscapes ‘procedurally’ – that is, with algorithms – is that they can be very much larger than designed landscapes for the same richness of local detail. This does not mean that every aspect of the final landscape must be ‘procedural’. It would be possible to use the techniques outlined here to create landscapes which were different every time the game was played, but it would be equally possible to create a landscape which was frozen at a particular point and then hand edited to add features useful to the game’s plot. And while I’m principally thinking in this about role playing games, this sort of landscape would be applicable to many other sorts of games – strategy games, god games, first person shooters…

-

The physical geography

+

The physical geography

Consider our landscape as, once again, a fractally folded sheet on which any given point has characteristics based on its elevation and orientation. There are two critical levels – water level and treeline. The water level is, overall, sea level, but in the case of a localised depression it is equal to the lowest land height between the depression and the sea (lakes form in depressions). Computing the fractal sheet forms stage one in computing the landscape. Next, we need functions which, for any given point on the landscape, compute two different dimensions of soil fertility: water and warmth. We’ll assume a coriolis prevailing wind blowing from the west, bringing in damp air from an ocean in that direction. Western slopes are wetter than eastern slopes. In principle, also, there’s likely to be a rain shadow to the east of high ground leading to considerable aridity, but that may be too expensive to compute. Rain runs swiftly off steeper slopes, more slowly on flatter ground, so flatter ground is wetter than steeper ground. Water flows down hill, so lower ground is on the whole wetter than higher ground. This isn’t a precise model of soil hydrology, but I think it’s good enough. From each lake a watercourse follows the lowest possible path to the sea. Watercourses modify the land overwhich they flow, carving out a route at least sufficient to carry the amount of water collected in the watershed above each point. Where watercourses flow down steeper gradients, they carve out gullies, possibly with waterfalls. Where they cross shallower gradients or level ground, they become broader. Computing the watercourses becomes the second stage of computing the lanscape.

-

Vegetation

+

Vegetation

Now sprinkle seeds randomly across the landscape at a density of roughly one every ten square metres. Seeds which fall in water, ignore (? or make into water plants?). The position of the plant is taken from the random sprinkling. The species and size of the plant that grows from the plant are a function of the water and warmth functions described above, with latitude and longitude as seeds for pseudo-random functions delivering aspects like branching and so on – enough to make individual plants distinct and not carbon copies even of other plants of the same species, but nevertheless recreatable from just the latitude and longitude. So for each plant only two integers need to be stored, yet every time a player passes he will see an identically recreated world. Of course there is a trade-off between storage space and rendering time, and it may be more efficient to build and cache a detailed model of each plant. Like a lot of other things it depends on the game being designed and the processing power of the platform on which that game is delivered. As to how the functions which select the vegetation type work, obviously trees grow better in wetter places, grassland plants in dryer places; within the wetter places, coniferous trees are more prevalent where it is cooler, broadleaves where it is warmer. In the very wettest places, willows, alders and marshland plants. These plants – the seeded plants – are the feature plants of the landscape. When rendering the landscape the renderer would first apply a suitable local surface texture, for example, in grassland areas, grass.

-

Settling the world

+

Settling the world

So now we need to make this an inhabited landscape. My proposal for this is to introduce proto-actors, which may be the same software agents as the non-player characters the user will interact with (see my essay on the spread of knowledge). At this stage in their lifecycle, the proto-actors are fairly simple state transition machines. Generally, their algorithm is as follows: Starting from one or two seed points, proto-agents will initially move across the landscape travelling at most 20Km in a day, preferring to stop at inns or else at existing settlements; and will maintain a history of the places they have been, never revisiting a place until they have settled. Whenever moving, whether before they have settled or after, proto-actors will plan their route across the landscape, avoiding trees, buildings, and steep gradients, and will prefer to cross rivers at a bridge (if available) or else a ferry (if available), or failing that at the narrowest convenient point. When proto-actors settle, they will claim an area of territory appropriate to their trade – more below; the system must build up a database of land holdings. In particular a land holding will never cross a watercourse, an existing road or overlap another land holding (although roads may develop across existing holdings). This is key because I don’t want holdings normally to have regular shapes. A settled proto-agent will build a building to live in, and possibly an additional one for his trade. When building buildings, proto-actors will prefer to build at the edge of their land holding, as close as possible to existing buildings and ideally at the side of an existing road. The richer an existing building is, the more attractive it will be to new buildings. Buildings will be built with their long edge aligned with the edge of the owner’s hoding.

    -
  • A proto-actor is initially, as described above, an itinerant. Itinerants are introduced into the world at a small number of geographical locations, and gradually, not all at once. Itinerants travel as described above. As they move they will leave breadcrumb trails with a roughly ten metre resolution. If they cross an existing track which goes in roughly the right direction they will prefer to follow it. Once a track has been followed by a certain number of proto-actors, it becomes a road.
    • -
  • An itinerant who finds an area of unsettled grassland of ten hectares with low soil fertility and not more than one hundred trees settles and becomes a pastoralist. He builds a cottage.
    • -
  • An itinerant who finds an area of unsettled grassland of ten hectares with medium or high soil fertility becomes an agrarian. He builds a homestead. Depending on the fertility of his land he can support between zero and ten labourers, 10% of a smith, 10% of a miller and 10% of a bonnet laird.
    • -
  • An itinerant who finds an area of unsettled land of 100 square metres within five hundred metres of a homestead with unfulfilled labourer demand becomes a labourer. He builds a cottage.
    • -
  • An itinerant who finds an area of unsettled land of 100 square metres within five kilometres of ten farmers with unfilled smithing slots becomes a smith. He builds a cottage and a forge.
    • -
  • An itinerant who finds an area of unsettled land either at the side of a water course or at the top of a hill, and within 5 kilometers of ten farmers with unfilled milling slots becomes a miller. He builds a mill – water or wind, appropriate to location.
    • -
  • Any settler who plays host to more than a certain number of travellers becomes an innkeeper. He claims 400 square metres of unclaimed land as close as possible to his existing settlement and buids an inn and stableyard.
    • -
  • An itinerant who finds 400 square metres of unclaimed land within a certain distance of an inn and a smith will become a merchant, provided that there are three smiths within a 5Km radius who have unfilled market slots. The merchant builds a marketplace and a counting house.
    • -
  • An itinerant who finds 200 square metres of unclaimed land within a specified distance of a market with an unfilled chapel slot becomes a priest and builds a chapel and manse, and possibly a school.
    • -
  • An itinerant who finds 100 square metres of unclaimed land adjacent to where a road crosses a river becomes a ferryman.
    • -
  • A ferryman who carries more than a certain number of passengers in a given period becomes a tollkeeper and builds a bridge.
    • +
  • A proto-actor is initially, as described above, an itinerant. Itinerants are introduced into the world at a small number of geographical locations, and gradually, not all at once. Itinerants travel as described above. As they move they will leave breadcrumb trails with a roughly ten metre resolution. If they cross an existing track which goes in roughly the right direction they will prefer to follow it. Once a track has been followed by a certain number of proto-actors, it becomes a road.
    • +
  • An itinerant who finds an area of unsettled grassland of ten hectares with low soil fertility and not more than one hundred trees settles and becomes a pastoralist. He builds a cottage.
    • +
  • An itinerant who finds an area of unsettled grassland of ten hectares with medium or high soil fertility becomes an agrarian. He builds a homestead. Depending on the fertility of his land he can support between zero and ten labourers, 10% of a smith, 10% of a miller and 10% of a bonnet laird.
    • +
  • An itinerant who finds an area of unsettled land of 100 square metres within five hundred metres of a homestead with unfulfilled labourer demand becomes a labourer. He builds a cottage.
    • +
  • An itinerant who finds an area of unsettled land of 100 square metres within five kilometres of ten farmers with unfilled smithing slots becomes a smith. He builds a cottage and a forge.
    • +
  • An itinerant who finds an area of unsettled land either at the side of a water course or at the top of a hill, and within 5 kilometers of ten farmers with unfilled milling slots becomes a miller. He builds a mill – water or wind, appropriate to location.
    • +
  • Any settler who plays host to more than a certain number of travellers becomes an innkeeper. He claims 400 square metres of unclaimed land as close as possible to his existing settlement and buids an inn and stableyard.
    • +
  • An itinerant who finds 400 square metres of unclaimed land within a certain distance of an inn and a smith will become a merchant, provided that there are three smiths within a 5Km radius who have unfilled market slots. The merchant builds a marketplace and a counting house.
    • +
  • An itinerant who finds 200 square metres of unclaimed land within a specified distance of a market with an unfilled chapel slot becomes a priest and builds a chapel and manse, and possibly a school.
    • +
  • An itinerant who finds 100 square metres of unclaimed land adjacent to where a road crosses a river becomes a ferryman.
    • +
  • A ferryman who carries more than a certain number of passengers in a given period becomes a tollkeeper and builds a bridge.

This set of rules – and possibly others like them (woodcutters, fishermen, hunters…) provide the first wave of settlement. Once the landscape is sufficiently settled by this first wave, there needs to be a period of establishing trading routes. First, every settler will visit his nearest market, leaving a permanent track if there is not already a road. Where several of these tracks overlay one another, once again a road is created. Each merchant then visits each of the ten markets nearest his own, following existing tracks and roads where available. Wherever the merchants do not find roads, new roads are created. This completes the roads network. Each market is now assigned a value which is a function of

    -
  • the number of people for whom it is the nearest market
    • -
  • the sum of the wealth (soil fertility) of the homesteads for which it is the nearest market
    • -
  • the wealth of other markets within a day’s travel
    • +
  • the number of people for whom it is the nearest market
    • +
  • the sum of the wealth (soil fertility) of the homesteads for which it is the nearest market
    • +
  • the wealth of other markets within a day’s travel

Depending on its wealth a market may support up to twenty stallholders, including bakers, butchers, tanners, weavers, cobblers, chandlers and so on. So a second wave of itinerants sets off. These follow the original rules for itinerants, but if they find an unsettled 100 square metres within five hundred metres of a market, will set up as a stallholder, building a town house and appropriate trade building on their own settlement, and a stall in the market. An itinerant finding a hundred square metres within five hundred metres of a market which has all its stallholder slots filled may become a slum landlord, and build a tenement for day-labourers. Finally, aristocracy. In the second wave an itinerant who finds either a hilltop, an island in a lake or river, or a significant river crossing, with one hectare of unclaimed land and within 5Km of ten farms with unfilled bonnet laird slots becomes a bonnet laird (or ‘squire’, if you prefer) and builds a fortified house. At the end of the second wave of settlement the ten percent of bonnet lairds with the richest fiefs (using much the same metric as for the wealth of markets) become barons and build castles.

-

Rendering the buildings

+

Rendering the buildings

This seems to me to provide an algorithmic means of settling a landscape which will generate organic and satisfying patterns of settlement. But it all fails if the buildings are chosen from a limited palette of models. As with the trees I think we need algorithmic mechanisms of building similar-but-different buildings which can be repeatably rendered from relatively small data sets. As an example of what I mean, in damper landscapes where wood is likely to be available, there might be a higher probability of stave buildings, or weatherboarding, with mainly shingle roofs. In slightly less damp areas where timber is still available, cruck frames and half timbered buildings will prevail, with mostly thatched roofs. In the dryest areas, cob and brick buildings will be common, often with tile roofs. On steeper hillsides, stone buildings will be common, perhaps with slate roofs. Within each of these types there are essential cells from which a building is created. These cells can be longer or shorter, taller or lower, wider or narrower. A building may comprise a single cell, or more. If more than three cells they may be arranged in a row or round a courtyard. And they may have one story or two. Which they have can be based – like the details of the plants – on functions which take latitude and longitude as arguments and which, internally use pseudo-randoms seeded from those latitude and longitude values.

-

How vast a world?

+

How vast a world?

OK, so, with this general approach, how big can we go? The answer seems to me to be ‘big enough’. A 32 bit integer gives somewhat over four billion values, so can resolve down to one millimetre precision in a world 4000 kilometres by 4000 kilometres. But we don’t actually need millimetre resolution; centimetre would be quite small enough. And that gives us potential for a world 40000Km square, or 1.6 billion square kilometres, which is three times the surface area of planet Earth.

In practice we can’t go that big for all sorts of space and time reasons. Recording land heights is inevitably an issue. I don’t know of a pseudo random function which will generate satisfying land heights. Anything based on Julia sets, for example, ends up with landforms symmetrical around a central point. Furthermore, the shapes of fractals which can be constructed from simple functions tend to have a noticable and unnatural degree of self-similarity across scales. I’d dearly like to be wrong on this, but I think we need to store at minimum elevation values at ten metre intervals. If we can accept 100mm resolution for elevations, storing 16 bit values gives a range of 6,500 metres - 21,000 feet - from the deepest seabed to the peaks of the highest mountains.

This means that landform information alone requires 20Kbytes per square kilometre - unindexed, but seeing it’s a rigid ten metre grid that isn’t a problem. Which, in turn, means that you can store landform information for a planet the size of Earth in one terrabyte. But we don’t need a planet the size of earth. Scotland is 80,000 square kilometers of land area; allowing for a bit of sea around to the horizon around it, say 100,000 square kilometers. That seems to me more than big enough to be a game space. It amounts to 160Mb of landform data, which is completely manageable.

If we stored plant data for every distinctive plant in Scotland - even at one per ten square metres - that does become an impractically large data set, because quite apart from anything else, the plant locations do have to be indexed. But actually, given that the actual plants that grow are a function of the location at which they grow, no player is going to notice if the pattern of the locations of plants is the same for each square kilometre. So we can manage plant data for a land area the size of Scotland in 400,000 bytes - we could do it in less (if the locations were generated using a pseudo-random function, much less).

Building data is different. We need to store the latitude, longitude and type of every building explicitly, and again they need to be indexed in order that we can recover the buildings in a given area efficiently. We need about 16 bytes per building (four bytes latitude, four longitude, two type; then for each tile a null-terminated vector of pointers to building records). If we assume that our feudal land of 80,000 square kilometers has a population of a million, and that there are on average five occupants of every building, that’s two hundred thousand buildings, implying 3.2Mb of data.

-

Of course, that’s just the backing store size. As tiles are loaded into active memory - see the essay ‘Tiles and Flats’ this raw backing data has to be inflated procedurally into actual models that can be rendered; models which may have thousands of vertices and hundreds of kilobytes of textures. The functions which do that inflating have some finite size, and, significantly, they’ll need to work on prototype models which will in turn take storage space. Finally there are hand-edited models potentially used at particular plot locations; those need to be stored more or less in full. But all this has not become an unmanageable amount of data. It seems to me plausible that you could store a fully populated 100,000 square kilometer game world on one uncompressed 700Mb CD. On a 4Gb DVD, you could do it very easily.

\ No newline at end of file +

Of course, that’s just the backing store size. As tiles are loaded into active memory - see the essay ‘Tiles and Flats’ this raw backing data has to be inflated procedurally into actual models that can be rendered; models which may have thousands of vertices and hundreds of kilobytes of textures. The functions which do that inflating have some finite size, and, significantly, they’ll need to work on prototype models which will in turn take storage space. Finally there are hand-edited models potentially used at particular plot locations; those need to be stored more or less in full. But all this has not become an unmanageable amount of data. It seems to me plausible that you could store a fully populated 100,000 square kilometer game world on one uncompressed 700Mb CD. On a 4Gb DVD, you could do it very easily.

+
\ No newline at end of file diff --git a/docs/codox/Simulation-layers.html b/docs/codox/Simulation-layers.html index 04b2072..2de4961 100644 --- a/docs/codox/Simulation-layers.html +++ b/docs/codox/Simulation-layers.html @@ -1,13 +1,14 @@ -Simulation layers

Project

Topics

Namespaces

Simulation layers

+Simulation layers

Project

Topics

Namespaces

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

+

An economy simulation

As goods are transported between cities, prices rise and fall based on simulated production and consumption. As prices of commodities rise, more citizens will take up trades which produce those commodities. The simulation needs to be sophisticated enough that, for example, as a city grows richer, its citizens may switch from preferring low cost textiles, eg perhaps wool or linen, to higher cost textiles, such as for example silk (or more complex weaves, or…) Similarly for foodstuffs and for beverages.

Agricultural production will be affected by climate simulation.

This is mainly a land game. Broadly, caravans take the place of ships in Elite or Pirates! Caravans are broadly made up of camels, although some may use mules or possibly horses. In any case, a merchant may own camels and hire camel drivers, or may hire contractor drivers who have their own camels; and there will also be whole teams of camel drivers with their animals which can be hired in a single contract.

-

A political simulation

-

Broadly, aristons claim territories in an essentiallu feudal arrangement, drive out outlaws, and levy taxes.

+

A political simulation

+

Broadly, aristons claim territories in an essentially feudal arrangement, drive out outlaws, and levy taxes.

An ariston will be popular if their regime is stable, if taxes are low, justice is considered fair, oppression is low and depredations by outlaws are minimal. The more unpopular an ariston is, the more resistant the populace will be to paying their taxes, meaning the more military force needs to be diverted to tax collection and the greater the oppression. Taxes are required to pay soldiers and to maintain high roads, bridges, markets and other infrastructure. Merchants will prefer to travel routes which are better policed and maintained, which means more merchants trading in your markets, which means more tax.

-

Aristons who can generate surplus can hire more soldiers, ascend the feudal hierarchy, and wage war against neighbours.

\ No newline at end of file +

Aristons who can generate surplus can hire more soldiers, ascend the feudal hierarchy, and wage war against neighbours.

+
\ No newline at end of file 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 7d6d15c..714fe3a 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,9 +1,9 @@ -The spread of knowledge in a large game world

Project

Topics

Namespaces

The spread of knowledge in a large game world

-

Saturday, 26 April 2008

+The spread of knowledge in a large game world

Project

Topics

Namespaces

The spread of knowledge in a large game world

+

Saturday, 26 April 2008

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

-

Note

+

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.

These days we have television, and news. But in a late bronze age world there are no broadcast media. News spreads by word of mouth. If non-player characters are to respond effectively to events in the world, knowledge has to spread.

How to model this?

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

One obvious class of news-spreader is a merchant. Merchant agents can either shuttle mechanically between a fixed group of markets or else possibly respond intelligently to supply and demand. Provided that there is a mesh of merchant routes covering the markets of the game world, and that a useful subset of non-merchant characters are required to visit a market every few game days, this should give a reasonably realistic framework for news spreading.

What else? What things qualify as news items? I think at least the following:

    -
  • Deaths of sentient characters, especially if violent
    • -
  • Commodity prices
    • -
  • Changes of rulers in cities
    • -
  • Marriages of sentient characters
    • -
  • Plot events, flagged as events by the game designer
    • +
  • Deaths of sentient characters, especially if violent
    • +
  • Commodity prices
    • +
  • Changes of rulers in cities
    • +
  • Marriages of sentient characters
    • +
  • Plot events, flagged as events by the game designer

Obviously, news is more valuable if the people involved are important or notorious: the significance of a story is probably the product of the significance of the people concerned.

So a news item becomes a map with keys similar to

@@ -51,13 +51,14 @@

The timestamp could also be degraded, or lost altother - although how exactly this is represnted I’m not certain. Someone interested in the incident may remember ‘it was exactly 17 days ago’, whereas someone else may remember that it was ‘this month, I think’.

Obviously the rate of decay, and the degree of randomness, of the news-passing algorithm would need to be tuned, but this schema seems to me to describe a system with the following features:

    -
  • Non-player characters can respond to questions about significant things which happen in the world - without it all having to be scripted
    • -
  • If you travel fast enough, you can keep ahead of your notoriety
    • -
  • Characters on major trade routes will know more about what is happening in the world than characters in backwaters
    • +
  • Non-player characters can respond to questions about significant things which happen in the world - without it all having to be scripted
    • +
  • If you travel fast enough, you can keep ahead of your notoriety
    • +
  • Characters on major trade routes will know more about what is happening in the world than characters in backwaters

This seems to me a reasonably good model of news spread.

-

Scaling of the algorithm

+

Scaling of the algorithm

Let’s work around the idea that a ‘game day’ equates to about two hours of wall clock time. Let’s work around the idea that there are of the order of fifty markets in the game world, and that for each market there are two or three merchants whose ‘home base’ it is.

Obviously non-player characters who are within the vicinity of a player character have to be ‘awake’, in order that the player can see them interacting with their world and can interact with them. Those characters have to be in working memory and have to be in the action polling loop in any case. So there’s no extra cost to their gossiping away between each other - around the player there’s a moving bubble of gossip, allowing each character the player interacts with to have a high probability of having some recent news.

But the merchants who aren’t in the vicinity of a player don’t have to be in working memory all the time. Each merchant simply requires to be ‘woken up’ - loaded into memory - once per game day, move a day’s journey in one hop, and then, if arriving at an inn or at a market, wake and exchange news with one resident character - an innkeeper or a gossip. So the cost of this algorithm in a fifty-market game is at worst the cost of loading and unloading two non-player characters from memory every minute, and copying two or three statements from the knowledge set of one to the knowledge set of the other. If you’re dynamically modifying significance scores, of course, you’d need to also load the characters about whom news was being passed on; but this still doesn’t seem unduly onerous.

-

Obviously, if memory is not too constrained it may be possible to maintain all the merchants, all the innkeepers and all the characters currently being talked about in memory all the time, further reducing the cost.

\ No newline at end of file +

Obviously, if memory is not too constrained it may be possible to maintain all the merchants, all the innkeepers and all the characters currently being talked about in memory all the time, further reducing the cost.

+
\ No newline at end of file diff --git a/docs/codox/Things_Voice_Interaction_Enables.html b/docs/codox/Things_Voice_Interaction_Enables.html new file mode 100644 index 0000000..441dce4 --- /dev/null +++ b/docs/codox/Things_Voice_Interaction_Enables.html @@ -0,0 +1,42 @@ + +Things Voice Interaction Enables

Project

Topics

Namespaces

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.

+

Suppose you’re entering a village, and you meet a random character. That character knows any local quest giver, and what it is that quest giver needs –– and, indeed, they know this whether the quest is scripted or organic.

+

So the random character could say

+
+

Hello, I’m Tobias, and that my mill over there. Who might you be, stranger?

+
+

At which point you can either tell him, or not. Suppose you tell him, he could say

+
+

Oh! I’ve heard of you. It’s said you’re very handy with a sword.

+
+

And you can reply however you like, acknowledging, or being modest, or perhaps even denying (although from this line of dialogue if you deny he’ll think you’re being modest, for reasons see later). He can then say, taking our example from the ‘abducted child’ quest in the Introduction,

+
+

Thing is, old granny Grizzel’s granddaughter Esmerelda has been abducted by bandits, and we’ve done a whip-around for a reward for someone who can rescue the girl.

+
+

At which point you may reply that you’ll do it, or be non-committal, or say you won’t. If you say you will, he can say,

+
+

Well, you should talk to granny Grizzel, she lives in the white house by the crossroads, half a mile that-a-way (pointing).

+
+

If you say you won’t, he can say,

+
+

It would be a virtuous act, the old lady is fair desperate. If you should change your mind, you should talk to her; she lives in the white house by the crossroads, half a mile that-a-way (pointing).

+
+

OK, but what if, in the game world, the player character is not good with a sword? Well, the ‘abducted child’ quest can be resolved by violence; but it can also be resolved by persuasion, or by sneakiness, or by bribery. So suppose the player isn’t (in the game) good with a sword, but is good at negotiation. Then in the initial approach, Tobias could say

+
+

Oh! I’ve heard of you. It’s said you’re very handy at persuasion… Thing is, old granny Grizzel’s granddaughter Esmerelda has been abducted by bandits, and we’ve done a whip-around for a ransom, but she’s lacking someone who can negotiate for her.

+
+

It’s the same quest, and, whatever Tobias has said, the player can still use either violence or persuasion or trickery to complete the quest (and gain appropriate reputation thereby), but it’s flexible enough to adapt to the player’s in-game persona, and it means we can direct the player to quest-givers without having to stick a bloody great icon on the quest giver’s head.

+

So, to repeat for clarity: the idea is, if there is a quest in the vicinity, whether organic or scripted, all the quest giver’s neighbours know about it, and will bring it up in conversation, introducing it and directing the player to the quest giver. And I believe that this can be done reasonably naturally.

+

Command in Battles

+

Player characters in role playing games are often narratively great heroic leaders – see any of the Dragon Age games but particularly Inquisition for examples of this – but when it comes to a pitched battle all they can do is follow a scripted battle plan and fight individual actions, because in current generation role-playing games there is no effective user interface to allow strategic and tactical control of a battle.

+

So how would a real-world, before modern communications technology, war leader command a battle? Why, by observing the battle and talking to people, and those are both things that in our game the player can do.

+

So, there are two stages to battle communication: the first is the council of war, before the battle, in which the battle plan is agreed. For the non-player characters to have any significant input into this, we’d need a really good knowledge base of appropriate battle strategies with heuristics for which plan fits which sort of geography and which sort of enemy, but that could be quite fun to develop; but in principle it’s sufficient for the player character to be able to say to each of the divisional captains “I want you to do this,” and for each captain to say first “yes, I understand” (or “please clarify”), and then “yes, I will do it” (or “yes, I will try”).

+

No battle plan, of course, survives first contact with the enemy. It must be possible to update the plan during the battle, and messengers were used to carry new orders from the commander to subordinates. That, of course, we can also do.

+

So, ideally (and in describing this I’ll try to give ‘less than ideal’ alternatives where I see them), you can gather your captains to a council of war, either by speaking to them directly or by sending messengers round. At the council of war, non-player-character captains can suggest possible battle plans drawn from a common knowledge base, but can have individual levels of boldness or caution. However, if you’ve been appointed battle leader, then provided they’re individually still loyal to you then they will ultimately agree to what you order.

+

When battle is joined you can either join in the fighting in the front line in which case your strategic overview is going to be very limited and you’ll just have to hope your initial plan was good enough; or else you can sit on a hilltop overlooking the battlefield with your trumpeter and your messengers, and send messages to control the fight, but not actually take part much yourself (unless everything really goes to shit and your position is overrun).

+

In real world battles orders were often misunderstood; I don’t think I should do anything special to model that. But orders (other than trumpet calls) will necessarily take finite time, and if the battlefront is really messed up messengers may fail to get through.

+
\ No newline at end of file diff --git a/docs/codox/Uncanny_dialogue.html b/docs/codox/Uncanny_dialogue.html index ca223fe..90b01cc 100644 --- a/docs/codox/Uncanny_dialogue.html +++ b/docs/codox/Uncanny_dialogue.html @@ -1,7 +1,8 @@ -The Uncanny Valley, and dynamically generated dialogue

Project

Topics

Namespaces

The Uncanny Valley, and dynamically generated dialogue

+The Uncanny Valley, and dynamically generated dialogue

Project

Topics

Namespaces

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.

-

This gets even more problematic if, rather than heavily signposting the player towards locations where plot points will happen, we allow the player to roam the world relatively freely, and cause plot events to occur where the player is at the appropriate phase in the plot rather than when the player arrives at a particular location. This not only means that important plot beats will happen in unpredictable locations but also that we may have to dynamically assign the non-player character(s) who interact with the player character in order to deliver the plot point.

\ No newline at end of file +

This gets even more problematic if, rather than heavily signposting the player towards locations where plot points will happen, we allow the player to roam the world relatively freely, and cause plot events to occur where the player is at the appropriate phase in the plot rather than when the player arrives at a particular location. This not only means that important plot beats will happen in unpredictable locations but also that we may have to dynamically assign the non-player character(s) who interact with the player character in order to deliver the plot point.

+
\ No newline at end of file diff --git a/docs/codox/Voice-acting-considered-harmful.html b/docs/codox/Voice-acting-considered-harmful.html index 0e20790..5143cd0 100644 --- a/docs/codox/Voice-acting-considered-harmful.html +++ b/docs/codox/Voice-acting-considered-harmful.html @@ -1,29 +1,41 @@ -Voice acting considered harmful

Project

Topics

Namespaces

Voice acting considered harmful

-

Wednesday, 25 February 2015

+Voice acting considered harmful

Project

Topics

Namespaces

Voice acting considered harmful

+

Wednesday, 25 February 2015

The Witcher: Conversation with Kalkstein

-

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

+

Long, long, time ago, I can still remember when… we played (and wrote) adventure games where the user typed at a command line, and the system printed back at them. A Read-Eval-Print loop in the classic Lisp sense, and I wrote my adventure games in Lisp. I used the same opportunistic parser whether the developer was building the game

+
+

Create a new room north of here called dungeon-3

+
+

the player was playing the game

+
+

Pick up the rusty sword and go north

+
+

or the player was talking to a non-player character

+
+

Say to the wizard ‘can you tell me the way to the castle’

+
+

Of course, the parser didn’t ‘understand’ English. It worked on trees of words, in which terminal nodes were actions and branching nodes were key words, and it had the property that any word it didn’t recognise at that point in sentence was a noise word and could be ignored. A few special hacks (such as ‘the’, ‘a’, or ‘an’ was an indicator that what came next was probably a noun phrase, and thus that if there was more than one sword in the player’s immediate environment the one that was wanted was the one tagged with the adjective ‘rusty’), and you ended up with a parser that most of the time convincingly interpreted most of what the player threw at it.

Text adventures fell into desuetude partly because they weren’t graphic, but mainly because people didn’t find typing natural, or became dissatisfied with the repertoire of their parsers. Trying to find exactly the right combination tokens to persuade the game to carry out some simple action is not ‘fun’, it’s just frustrating, and it turned people off. Which is a shame because just at the time when people were abandoning text adventures we were beginning to have command parsers which were actually pretty good. Mine, I think, were good - you could have a pretty natural conversation with them, and in ‘building’ mode, when it hit a ‘sorry I don’t understand’ point, it allowed you to input a path of keywords and a Lisp function so that in future it would understand.

So much, so Eliza.

Modern role-playing games - the evolutionary successors of those high and far off text adventures - don’t have text input. Instead, at each stage in a conversation, the user is offered a choice of three or four canned responses, and can pick one; very often what the player’s character actually says then differs from the text the user has chosen, often with differences of nuance which the user feels (s)he didn’t intend. And the non-player-character’s response is similarly canned. Indeed, the vast majority of non-player characters in most games have a ‘repertoire’, if one may call it that, of only one sentence. Others will have one shallow conversational tree, addressing one minor quest or plot-point.

If you want to talk to them about anything else - well, you just can’t.

Only a very few key non-player characters will have a large repertoire of conversational trees, relevant to all parts of the plot. And even those trees are not deep. You soon exhaust them; the characters’ ability to simulate real agency just isn’t there.

I first wrote about the limiting effects of voice acting in my review of the original Witcher game, back in 2008; things haven’t got better.

-

On phones: speaking

+

On phones: speaking

In my pocket I carry a phone. It’s not big: 127 x 64.9 x 8.6mm. A small thing.

When I first used Android phones for navigation, I used to delight in their pronunciation of Scots placenames - pronouncing them phonetically, as spelled, and as though their spelling were modern English. What’s delightful about Scots placenames is that they are linguistically and orthographically so varied - their components may be Brythonic, Goidaelic, Anglian, Norn, French, English, or even Latin; and very frequently they combine elements of more than one language (Benlaw Hill, anyone? Derrywoodwachy?).

Yes, gentle reader, this does seem a long way from game design; be patient, I’m getting there. But I’m going to digress even further for first…

There have been orthographic changes, and pronunciation changes consequent on orthographic changes. For example, medieval Scots used the letter Yogh (ȝ), which isn’t present in the English alphabet. So when Edinburgh printers in the early modern period bought type for their printing presses from England, there was no Yogh in the font. So they substituted Zed. So we get names like Dalȝiel, Kirkgunȝeon, Menȝies, Cockenȝie. How do you pronounce them?

The letter that looks like a ‘z’ is pronounced rather like a ‘y’; so

    -
  • Deeyell
    • -
  • Kirkgunyeon
    • -
  • Mingis
    • +
  • Deeyell
    • +
  • Kirkgunyeon
    • +
  • Mingis

and… drumroll…

    -
  • Cockenzie.
    • +
  • Cockenzie.

What happened?

Well, Dalȝiel and Menȝies are personal names, and people are protective of their own names. Kirkgunȝeon is a small, unimportant place, and all the locals know how it is pronounced. Scots folk, are, after all, used to Scots orthography and its peculiarities. So those names haven’t changed.

@@ -32,18 +44,19 @@

Another more interesting example of the same thing is ‘Kirkcudbright’. It’s a town built around the kirk (church) of saint Cuthbert. So how does it come to have a ‘d’ in it? And why is it pronounced ‘Kirkoobry’? Well, the venerable Cuthbert pronounced his name in a way which would be represented in modern English as ‘Coothbrecht’, but he spelled it ‘Cuðbrecht’. See that ‘ð’? That’s not a ‘d’, it’s an Eth. Because Cuðbrecht was Anglian, and the Anglian alphabet had Eth; it’s pronounced as a soft ‘th’, and Icelandic still has it (as well as Thorn, þ, a hard ‘th’ sound). Medieval scribes didn’t know about Eth, so in copying out ð they wrote the more familiar d. The local people, however, mostly couldn’t read, so the pronunciation of the name didn’t change with the change in spelling (although the pronunciation, too, has drifted a little with time).

So, in brief, pronouncing Scots placenames is hard, and there are a lot of curious rules, and consequently it’s not surprising that five years ago, listening to Android’s pronunciation of Scots placenames was really funny.

But what’s really curious is that now it isn’t. Now, it rarely makes a mistake. Now, Android can do text to speech on unusual and perverse orthography, and get it right better than 95% of the time - and manage a reasonably natural speaking voice while doing so. On a small, low power machine which fits in my pocket.

-

On phones: listening

+

On phones: listening

But navigation is not all I can do with my phone. I can also dictate. By which I don’t mean I can make a voice recording, play it back later and type what I hear, although, of course, I can. I mean I can dictate, for example, an email, and see it in text on my phone before I send it. It quickly learned my peculiarities of diction, and it now needs very little correction. On a small, low power machine which fits in my pocket.

-

And breathe

+

And breathe

Right, so where am I going with all this? Well, we interact with modern computer role playing games through very restricted, entirely scripted dialogues. Why do we do so? Why, on our modern machines with huge amounts of store, do our non-player characters - and worse still, our player character, our own avatar - have such restricted repertoires?

Because they are voice acted. Don’t get me wrong, voice acting makes a game far more engaging. But for voice acting to work, the people doing the acting have to know not only the full range of sentences that their character is going to speak, but also roughly how they feel (angry? sad? excited?) when they say it. Ten years ago, voice acting was probably the only way you could have got this immediacy into games, because ten years ago, text-to-speech systems were pretty crude - think of Stephen Hawking’s voice synthesiser. But now, Edinburgh University’s open source synthesiser is pretty good, and comes with twenty-four voices (and seeing it’s open source, you can of course add your own). Speech to text was probably better ten years ago - think of Dragon Naturally Speaking - but it was proprietary software, and used a fair proportion of a machine’s horsepower. Now there’s (among others) Carnegie Mellon’s open source Sphinx engine, which can quickly adapt to your voice.

So, we have text-to-speech engines which can generate from samples of many different voices, and speech to text engines which can easily be tuned to your particular voice. There’s even a program called Voice Attack, built on top of Microsoft’s proprietary speech to text engine, which already allows you to control games with speech. Where does that take us?

Well, we already know how to make sophisticated natural language parsers for text, given moderately limited domains - we don’t need full natural language comprehension here.

-

You may think it’s a long way down the road to the chemist

+

You may think it’s a long way down the road to the chemist

There are things one needs to know in a game world. For example: I need a sword, where’s the nearest swordsmith? In a real quasi-medieval world, certainly every soldier would be able to tell you, and everyone from the swordsmith’s town or village. Very celebrated swordsmiths would be known more widely.

And the thing is, the game engine knows where the nearest swordsmith is. It knows what potion will heal what wound, and what herbs and what tincture to use to make it. It knows which meats are good to eat, and which inns have rooms free. It knows good campsites. It knows where there be dragons. It knows where the treasure is hid. It knows - as far as the game and its plot are concerned - everything.

So to make an in-game Siri - an omniscient companion you could ask anything of - would be easy. Trivial. It also wouldn’t add verisimilitude to the game. But to model which non-player characters know what is not that much harder. Local people know what’s where in their locality. Merchants know the prices in nearby markets. They, and minstrels, know the game-world’s news - major events that affect the plot. Apothecaries, alchemists and witches know the properties of herbs and minerals.

And to model which non-player characters are friendly, and willing to answer your every question; which neutral or busy, and liable to answer tersely; and which actively hostile, and likely, if they answer at all, to deliberately mislead - that’s not very much harder.

I’m not arguing that voice acting, and scripted dialogue trees, should be done away with altogether. They still have a use, as cutscenes do, to advance plot. And I’m not suggesting that we use voice to control the player characters movements and actions - I’m not not suggesting that we should say ‘run north; attack the troll with the rusty sword’. Keyboards and mice may be awkward ways to control action, but they’re better than that. Bur I am suggesting that one should be able to talk to any (supposedly sentient) character in the game, and have them talk reasonably sensibly back. As one can already do physically in wandering an open world, a full voice interaction system would allow one to go off piste - to leave the limited, constrained pre-scripted interaction of the voice-acted dialogue tree. And that has got to make our worlds, and our interactions with them, richer, more surprising, more engaging.

A hybrid system needn’t be hard to achieve, needn’t be jarring in use. You can record the phonemes of your voice actor’s voice, so that the same character will have roughly the same voice - the same timbre, the same vowel sounds, the same characteristics of  pronunciation - whether in a voice acted dialogue or in a generated one.

-

We don’t need to let voice acting limit the repertoires of our characters any more. And we shouldn’t.

\ No newline at end of file +

We don’t need to let voice acting limit the repertoires of our characters any more. And we shouldn’t.

+
\ 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 new file mode 100644 index 0000000..5d28a0a --- /dev/null +++ b/docs/codox/a-generic-planning-algorithm-for-craftworker-npcs.html @@ -0,0 +1,69 @@ + +A Generic Planning Algorithm for craftworker NPCs

Project

Topics

Namespaces

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.

+

A Master craftsperson has

+
    +
  1. a house and appropriate workshop, within a settlement;
    2. +
  2. zero or more apprentices;
    3. +
  3. zero or more journeyman;
    4. +
  4. a spouse, who is usually of lower status;
    5. +
  5. zero of more coresident children;
    6. +
  6. zero or more coresident non-working parents/elders.
    7. +
+

There are limits to the number of apprentices and journeymen a master may take on, essentially based on demand in the local market. The master is responsible for housing and feeding all of the household including apprentices and journeymen, and for obtaining sufficient craft supplies. All craft work done in the household belongs to the master.

+

Apprentices are definitely not paid. Journeymen should be paid, but this is a detail to ignore until we have other things working.

+

Journeymen will move on from master to master from time to time – infrequently, but it will happen; and may be dismissed by masters when markets are tight. Journeymen probably learn their craft recipes – which is to say, the items and qualities of item they are able to craft – from the masters they work with. Consequently, journeymen will seek out masters with higher reputation; masters will prefer journeymen with more experience.

+

Apprentices do not move on until the end of their period of apprenticeship (16th birthday?) when they become journeymen.

+

The master will plan work in four hour sessions - essentially, a morning session and an afternoon session each day.

+

All craftspeople have regular schedules covering mealtimes, sleep, and festivals. A lower status person within the household will have regular schedules covering each of fetching water, fetching fuel wood, taking out night soil, feeding chickens, washing dishes and laundry, and so on.

+

When the master works in the workshop, all the apprentices and journeymen will also work in the workshop; when the master is engaging in recreation, they’re also engaging in recreation. What they do when the master is e.g. going to market, I haven’t yet decided.

+

Commodity items and special commissions

+

In principle all craftspeople may make both commodity items and special commission items, but in practice many crafts will be mostly commodity and a few will be almost entirely special commission (for example a diplomat doesn’t produce peace treaties prèt-à-porter); but I don’t yet have a good model of how I’m going to handle special commissions, so I’m just doing some hand waving here to say they will exist and must be handled.

+

The algorithm

+

A master craftsperson needs to keep stock of a number of things

+
    +
  1. Sufficient food for the household;
    2. +
  2. Sufficient craft materials for immediate production;
    3. +
  3. Sufficient funds to buy more food/craft materials when needed;
    4. +
  4. Commodity craft items produced;
    5. +
  5. Craft items work in progress.
    6. +
+

Choosing tasks

+

So in planning a period of work, the master has to decide:

+
    +
  1. Do I need to go to market? +
      +
    1. Is there news of a travelling merchant who buys what I produce arriving at my nearest market? -> go to market;
      2. +
    2. Is the household running low on food? -> go to market;
      3. +
    3. Is the household running low on craft materials? -> go to market;
      4. +
    +
    2. +
  2. Do I have any commissioned items to produce? -> produce commissioned items;
    3. +
  3. Should I work on commodities or take the day off? This is a throw-of-the-dice decision, influenced by +
      +
    1. Cash on hand (if there’s little, greater incentive to work);
      2. +
    2. Weather (if it’s especially good, less incentive to work);
      3. +
    3. Gossip (if there’s interesting news, less incentive to work)
      4. +
    +
    4. +
+

Commodity production

+

If the decision is to work on commodities, the next decision is what commodity item to produce.

+

For each craft recipe the master knows there will be

+
    +
  1. A list of quantities of different craft materials needed per item, for example a sword might need two kilograms of steel of a particular quality, ten kilograms of charcoal, one kilogram of timber, half a square metre of leather;
    2. +
  2. An amount of craftsperson time - for example, a standard infantry sword might take ten hours;
    3. +
  3. Memory of prices achieved by item to that recipe in the local market.
    4. +
+

The master will choose a recipe for which there are sufficient materials on hand, and which is profitable to make – the more profitable, the more likely to be selected (but I think there’s probably some furtive dice rolling under the table here too; you don’t want all the smiths in town producing infantry swords at the same time, because that would swamp the market and drive prices down).

+

When an item is started, the materials for it are removed from stock and assigned to the item, which is added to the work in progress list. The number of items that can be produced in a work session is

+
(the number of hours in the session * the number of people in the team) / the hours to produce one item
+
+

At the end of the session, the integer number of items produced is removed from the work in progress queue and added to stock, and the modulus is added as :work-done to the remaining item, which is left in the work in progress queue.

+

Obviously items in the work in progress queue may need to be completed at the start of the next commodity work session.

+

Obviously, none planned at sufficient granularity to be animated unless the workplace is in the :active circle, and none of it gets actually animated unless it’s actually on camera, but the book-keeping in terms of food and craft materials consumed and of items produced must be done.

+

This implies that at least many master craftspeople must be in the :background circle, i.e. woken up once every game day to plan a work session, no matter how far away the player character is.

+
\ No newline at end of file diff --git a/docs/codox/building_on_microworld.html b/docs/codox/building_on_microworld.html index 96ccdf2..6a13727 100644 --- a/docs/codox/building_on_microworld.html +++ b/docs/codox/building_on_microworld.html @@ -1,7 +1,8 @@ -Building on Microworld

Project

Topics

Namespaces

Building on Microworld

+Building on Microworld

Project

Topics

Namespaces

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.

-

Secondly, being a cellular automaton, MicroWorld works on a grid. This means that everything is grid aligned, which is absolutely not what I want! So I think the way to leverage this is to use MicroWorld to establish which kilometre square cells om the grid should be populated (and roughly with what), and then switch to ad hoc code to populate those cells.

\ No newline at end of file +

Secondly, being a cellular automaton, MicroWorld works on a grid. This means that everything is grid aligned, which is absolutely not what I want! So I think the way to leverage this is to use MicroWorld to establish which kilometre square cells om the grid should be populated (and roughly with what), and then switch to ad hoc code to populate those cells.

+
\ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.agent.agent.html b/docs/codox/cc.journeyman.the-great-game.agent.agent.html index 19ff454..0e670d6 100644 --- a/docs/codox/cc.journeyman.the-great-game.agent.agent.html +++ b/docs/codox/cc.journeyman.the-great-game.agent.agent.html @@ -1,10 +1,24 @@ -cc.journeyman.the-great-game.agent.agent documentation

Project

Topics

Namespaces

Public Vars

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

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

Project

Topics

Namespaces

Public Vars

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, although I’m not clear whether it would ever be appropriate to invoke an act method on them.
    • +
  • :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.

pending-intentions

(pending-intentions actor)

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

view source
\ No newline at end of file +

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.

+
view source
\ 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 new file mode 100644 index 0000000..8ebf73e --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.agent.schedule.html @@ -0,0 +1,5 @@ + +cc.journeyman.the-great-game.agent.schedule documentation

Project

Topics

Namespaces

Public Vars

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

+
view source
\ 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 1c835a8..9d08fd0 100644 --- a/docs/codox/cc.journeyman.the-great-game.buildings.module.html +++ b/docs/codox/cc.journeyman.the-great-game.buildings.module.html @@ -1,39 +1,40 @@ -cc.journeyman.the-great-game.buildings.module documentation

Project

Topics

Namespaces

Public Vars

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

Project

Topics

Namespaces

Public Vars

    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. -
    2. Craft modules – workshops – which will normally be ground floor (except weavers) and may have the constraint that no upper floor module can cover them;
      3. -
    3. Upper floor modules, having NO external doors (but linking internal doors);
      4. -
    4. Roof modules
      5. +
    5. Ground floor modules, having external doors;
      6. +
    6. Craft modules – workshops – which will normally be ground floor (except weavers) and may have the constraint that no upper floor module can cover them;
      7. +
    7. Upper floor modules, having NO external doors (but linking internal doors);
      8. +
    8. Roof modules

    Role must be one of:

      -
    1. :primary a ground floor main entrance module
      2. -
    2. :secondary a module which can be upper or ground floor
      3. -
    3. :upper a module which can only be on an upper floor, for example one with a projecting gallery, balcony or overhang.
      4. +
    4. :primary a ground floor main entrance module
      5. +
    5. :secondary a module which can be upper or ground floor
      6. +
    6. :upper a module which can only be on an upper floor, for example one with a projecting gallery, balcony or overhang.

    Other values for role will emerge.

    Exits must be a sequence of keywords taken from the following list:

      -
    1. :left an exit in the centre of the left wall
      2. -
    2. :left-front an exit in the centre of the left half of the front wall
      3. -
    3. :front an exit in the centre of the front wall
      4. -
    4. :right-front an exit in the centre of the right half of the front wall
      5. -
    5. :right an exit in the centre of the right wall
      6. -
    6. :right-back an exit in the centre of the right half of the back wall
      7. -
    7. :left-back an exit in the centre of the back wall
      8. +
    8. :left an exit in the centre of the left wall
      9. +
    9. :left-front an exit in the centre of the left half of the front wall
      10. +
    10. :front an exit in the centre of the front wall
      11. +
    11. :right-front an exit in the centre of the right half of the front wall
      12. +
    12. :right an exit in the centre of the right wall
      13. +
    13. :right-back an exit in the centre of the right half of the back wall
      14. +
    14. :left-back an exit in the centre of the back wall

    A module placed on an upper floor must have no exit which opens beyond the footprint of the floor below - no doors into mid air! However, it is allowable (and indeed is necessary) to allow doors into roof spaces if the adjacent module on the same floor does not yet exist, since otherwise it would be impossible to access a new room which might later be built there.

    Load must be a small integer indicating both the weight of the module and the total amount of weight it can support. So for example a stone-built module might have a load value of 4, a brick built one of 3, and a half-timbered one of 2, and a tent of 0. This means a stone ground floor module could support one further floor of stone or brick, or two further floors of half timbered construction; while a brick built ground floor could support a single brick or half-timbered upper floor but not a stone one, and a half-timbered ground floor could only support a half timbered upper floor.

    There also needs to be an undercroft or platform module, such that the area of the top of the platform is identical with the footprint of the building, and the altitude of the top of the platform is equal to the altitude of the terrain at the heighest corner of the building; so that the actual building doesn’t float in the air, and also so that none of the doors or windows are partly underground.

    Each module needs to wrap an actual 3d model created in Blender or whatever, and have a list of optional textures with which that model can be rendered. So an upper floor bedroom module might have the following renders:

      -
    1. Bare masonry - constrained to upland or plateau terrain, and to coastal culture
      2. -
    2. Painted masonry - constrained to upland or plateau terrain, and to coastal culture
      3. -
    3. Half-timbered - not available on plateau terrain
      4. -
    4. Weatherboarded - constrained to forest terrain
      5. -
    5. Brick - constrained to arable or arid terrain
      6. +
    6. Bare masonry - constrained to upland or plateau terrain, and to coastal culture
      7. +
    7. Painted masonry - constrained to upland or plateau terrain, and to coastal culture
      8. +
    8. Half-timbered - not available on plateau terrain
      9. +
    9. Weatherboarded - constrained to forest terrain
      10. +
    10. Brick - constrained to arable or arid terrain
    -

    of course these are only examples, and also, it’s entirely possible to have for example multiple different weatherboard renders for the same module. There needs to be a way of rendering what can be built above what: for example, you can’t have a masonry clad module over a half timbered one, but you can have a half-timbered one over a masonry one.

    \ No newline at end of file +

    of course these are only examples, and also, it’s entirely possible to have for example multiple different weatherboard renders for the same module. There needs to be a way of rendering what can be built above what: for example, you can’t have a masonry clad module over a half timbered one, but you can have a half-timbered one over a masonry one.

    +
    \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html b/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html index 0d2f6d1..a6c2fd6 100644 --- a/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html +++ b/docs/codox/cc.journeyman.the-great-game.buildings.rectangular.html @@ -1,32 +1,39 @@ -cc.journeyman.the-great-game.buildings.rectangular documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Build buildings with a generally rectangular floow plan.

    -

    Motivations

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

    Project

    Topics

    Namespaces

    Public Vars

    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. -
    2. 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?)
      3. -
    3. Establish whether, in my current state of fairly severe mental illness, I can actually produce any usable code at all.
      4. +
    4. 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.
      5. +
    5. 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?)
      6. +
    6. Establish whether, in my current state of fairly severe mental illness, I can actually produce any usable code at all.
    -

    Key factors in the creation of a building

    -

    Holding

    +

    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

    +

    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

    +

    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.

    +

    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.

    +

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

    view source

    *crafts*

    dynamic

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

    view source

    *cultures*

    dynamic

    Cultures which affect building families. TODO: placeholder

    view source

    *terrain-types*

    dynamic

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

    view source

    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.

    view source

    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.

    view source
    \ No newline at end of file +

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

    +
    view source

    *crafts*

    dynamic

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

    +
    view source

    *cultures*

    dynamic

    Cultures which affect building families. TODO: placeholder

    +
    view source

    *terrain-types*

    dynamic

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

    +
    view source

    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.

    +
    view source

    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.

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

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.cloverage

    TODO: write docs

    +

    documented-project-dir

    TODO: write docs

    +
    view source

    opts

    TODO: write docs

    +
    view source
    \ 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 133e81e..85001a0 100644 --- a/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html +++ b/docs/codox/cc.journeyman.the-great-game.gossip.gossip.html @@ -1,5 +1,10 @@ -cc.journeyman.the-great-game.gossip.gossip documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Interchange of news events between gossip agents.

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

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source

    gather-news

    (gather-news world gossip)

    Gather news for the specified gossip in this world.

    view source

    move-gossip

    (move-gossip gossip world new-location)

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

    view source

    run

    (run world)

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

    view source
    \ No newline at end of file +

    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.

    +
    view source

    gather-news

    (gather-news world gossip)

    Gather news for the specified gossip in this world.

    +
    view source

    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.

    +
    view source

    run

    (run world)

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

    +
    view source
    \ 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 aa46e20..2adbe87 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,34 +1,54 @@ -cc.journeyman.the-great-game.gossip.news-items documentation

    Project

    Topics

    Namespaces

    Public Vars

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

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

    -

    Status

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

    Project

    Topics

    Namespaces

    Public Vars

    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

    +

    Discussion

    The ideas here are based on the essay The spread of knowledge in a large game world, q.v.; they’ve advanced a little beyond that and will doubtless advance further in the course of writing and debugging this namespace.

    A news item is a map with the keys:

      -
    • date - the date on which the reported event is claimed to have happened;
      • -
    • nth-hand - the number of agents the news item has passed through;
      • -
    • verb - what it is that happened (key into news-topics);
      • +
    • date - the date on which the reported event is claimed to have happened;
      • +
    • nth-hand - the number of agents the news item has passed through;
      • +
    • verb - what it is that happened (key into news-topics);

    plus other keys taken from the keys value associated with the verb in news-topics.

    -

    Notes:

    -

    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.

    view source

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

    view source

    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.

    view source

    degrade-character

    (degrade-character gossip character)

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

    view source

    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.

    view source

    degrade-news-item

    (degrade-news-item gossip item)

    TODO: write docs

    view source

    infer

    (infer item rule)

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

    view source

    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.

    view source

    interest-in-location

    (interest-in-location gossip location)

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

    view source

    interesting-character?

    (interesting-character? gossip character)

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

    view source

    interesting-item?

    (interesting-item? gossip item)

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

    view source

    interesting-location?

    (interesting-location? gossip location)

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

    view source

    interesting-object?

    (interesting-object? gossip object)

    TODO: write docs

    view source

    interesting-topic?

    (interesting-topic? gossip topic)

    TODO: write docs

    view source

    interesting-verb?

    (interesting-verb? gossip verb)

    Is this verb interesting to this gossip?

    view source

    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.

    view source

    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.

    view source

    make-all-inferences

    (make-all-inferences item)

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

    view source

    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:

    +

    Notes:

    +

    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.

    +
    view source

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

    +
    view source

    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.

    +
    view source

    degrade-character

    (degrade-character gossip character)

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

    +
    view source

    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.

    +
    view source

    degrade-news-item

    (degrade-news-item gossip item)

    TODO: write docs

    +
    view source

    infer

    (infer item rule)

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

    +
    view source

    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.

    +
    view source

    interest-in-location

    (interest-in-location gossip location)

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

    +
    view source

    interesting-character?

    (interesting-character? gossip character)

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

    +
    view source

    interesting-item?

    (interesting-item? gossip item)

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

    +
    view source

    interesting-location?

    (interesting-location? gossip location)

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

    +
    view source

    interesting-object?

    (interesting-object? gossip object)

    TODO: write docs

    +
    view source

    interesting-verb?

    (interesting-verb? gossip verb)

    Is this verb interesting to this gossip?

    +
    view source

    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.

    +
    view source

    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.

    +
    view source

    make-all-inferences

    (make-all-inferences item)

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

    +
    view source

    news-topics

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

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

    Characters

    +

    Characters

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

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

    -

    Locations

    +

    Locations

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

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

    -

    Inferences

    -

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

    view source
    \ No newline at end of file +

    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.

    +
    view source
    \ 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 index d7a3c86..97f61fe 100644 --- a/docs/codox/cc.journeyman.the-great-game.holdings.holding.html +++ b/docs/codox/cc.journeyman.the-great-game.holdings.holding.html @@ -1,3 +1,6 @@ -cc.journeyman.the-great-game.holdings.holding documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.holdings.holding documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source
    \ 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 d720419..7a46fb4 100644 --- a/docs/codox/cc.journeyman.the-great-game.location.location.html +++ b/docs/codox/cc.journeyman.the-great-game.location.location.html @@ -1,3 +1,9 @@ -cc.journeyman.the-great-game.location.location documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.location.location documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source
    \ 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 new file mode 100644 index 0000000..1e2a3d4 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.lore.digester.html @@ -0,0 +1,4 @@ + +cc.journeyman.the-great-game.lore.digester documentation

    Project

    Topics

    Namespaces

    Public Vars

    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 2608e30..aa3910f 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.markets.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.markets.html @@ -1,3 +1,8 @@ -cc.journeyman.the-great-game.merchants.markets documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source

    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.

    view source

    run

    (run world)

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

    view source

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.merchants.markets documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source

    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.

    +
    view source

    run

    (run world)

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

    +
    view source

    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.

    +
    view source
    \ 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 f09d7c3..c477366 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,3 +1,10 @@ -cc.journeyman.the-great-game.merchants.merchant-utils documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source

    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.

    view source

    burden

    (burden merchant world)

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

    view source

    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.

    view source

    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.

    view source

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.merchants.merchant-utils documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source

    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.

    +
    view source

    burden

    (burden merchant world)

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

    +
    view source

    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.

    +
    view source

    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.

    +
    view source

    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.

    +
    view source
    \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html b/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html index bd38270..c9a8520 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html @@ -1,3 +1,5 @@ -cc.journeyman.the-great-game.merchants.merchants documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Trade planning for merchants, primarily.

    run

    (run world)

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

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.merchants.merchants documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Trade planning for merchants, primarily.

    +

    run

    (run world)

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

    +
    view source
    \ 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 75facae..247a63a 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.planning.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.planning.html @@ -1,26 +1,32 @@ -cc.journeyman.the-great-game.merchants.planning documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source

    generate-trade-plans

    (generate-trade-plans merchant world commodity)

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

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

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source

    generate-trade-plans

    (generate-trade-plans merchant world commodity)

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

    Returned plans are maps with keys:

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

    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.

    view source

    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.

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

    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.

    +
    view source

    plan-trade

    (plan-trade merchant world commodity)

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

    The returned plan is a map with keys:

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

    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.

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

    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.

    +
    view source
    \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html b/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html index 4c52ab6..8f35de1 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html @@ -1,4 +1,9 @@ -cc.journeyman.the-great-game.merchants.strategies.simple documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Default trading strategy for merchants.

    -

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

    move-merchant

    (move-merchant merchant world)

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

    view source

    plan-and-buy

    (plan-and-buy merchant world)

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

    view source

    re-plan

    (re-plan merchant world)

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

    view source

    sell-and-buy

    (sell-and-buy merchant world)

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

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.merchants.strategies.simple documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Default trading strategy for merchants.

    +

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

    +

    move-merchant

    (move-merchant merchant world)

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

    +
    view source

    plan-and-buy

    (plan-and-buy merchant world)

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

    +
    view source

    re-plan

    (re-plan merchant world)

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

    +
    view source

    sell-and-buy

    (sell-and-buy merchant world)

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

    +
    view source
    \ 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 new file mode 100644 index 0000000..990c143 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.objects.character.html @@ -0,0 +1,4 @@ + +cc.journeyman.the-great-game.objects.character documentation

    Project

    Topics

    Namespaces

    Public Vars

    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 b2c1d75..c9e4f8f 100644 --- a/docs/codox/cc.journeyman.the-great-game.objects.container.html +++ b/docs/codox/cc.journeyman.the-great-game.objects.container.html @@ -1,3 +1,6 @@ -cc.journeyman.the-great-game.objects.container documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.objects.container documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source
    \ 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 5327da6..a506b58 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,3 +1,7 @@ -cc.journeyman.the-great-game.objects.game-object documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.objects.game-object documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source
    \ 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 40d51a2..d0ff744 100644 --- a/docs/codox/cc.journeyman.the-great-game.playroom.html +++ b/docs/codox/cc.journeyman.the-great-game.playroom.html @@ -1,3 +1,7 @@ -cc.journeyman.the-great-game.playroom documentation

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.playroom

    TODO: write docs

    app

    TODO: write docs

    view source

    init

    (init)

    TODO: write docs

    view source

    simple-update

    (simple-update tpf)

    TODO: write docs

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.playroom documentation

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.playroom

    TODO: write docs

    +

    app

    TODO: write docs

    +
    view source

    init

    (init)

    TODO: write docs

    +
    view source

    simple-update

    (simple-update tpf)

    TODO: write docs

    +
    view source
    \ 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 bd99aba..267845f 100644 --- a/docs/codox/cc.journeyman.the-great-game.time.html +++ b/docs/codox/cc.journeyman.the-great-game.time.html @@ -1,3 +1,22 @@ -cc.journeyman.the-great-game.time documentation

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.time

    TODO: write docs

    canonical-ordering-of-houses

    The canonical ordering of religious houses.

    view source

    date-string

    (date-string game-time)

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

    view source

    day

    (day game-time)

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

    view source

    day-of-year

    macro

    (day-of-year game-time)

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

    view source

    days-in-season

    TODO: write docs

    view source

    days-in-week

    This world has an eight day week.

    view source

    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.

    view source

    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.

    view source

    game-start-time

    The start time of this run.

    view source

    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.

    view source

    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.

    view source

    season

    (season game-time)

    TODO: write docs

    view source

    seasons-in-year

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

    view source

    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.

    view source

    waiting-day?

    Does this game-time represent a waiting day?

    view source

    week

    (week game-time)

    Week of season represented by this game-time.

    view source

    weeks-in-season

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

    view source

    weeks-of-season

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

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.time documentation

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.time

    TODO: write docs

    +

    canonical-ordering-of-houses

    The canonical ordering of religious houses.

    +
    view source

    date-string

    (date-string game-time)

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

    +
    view source

    day

    (day game-time)

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

    +
    view source

    day-of-year

    macro

    (day-of-year game-time)

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

    +
    view source

    days-in-season

    TODO: write docs

    +
    view source

    days-in-week

    This world has an eight day week.

    +
    view source

    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.

    +
    view source

    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.

    +
    view source

    game-start-time

    The start time of this run.

    +
    view source

    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.

    +
    view source

    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.

    +
    view source

    season

    (season game-time)

    TODO: write docs

    +
    view source

    seasons-in-year

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

    +
    view source

    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.

    +
    view source

    waiting-day?

    Does this game-time represent a waiting day?

    +
    view source

    week

    (week game-time)

    Week of season represented by this game-time.

    +
    view source

    weeks-in-season

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

    +
    view source

    weeks-of-season

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

    +
    view source
    \ 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 b9f77cd..3a58f50 100644 --- a/docs/codox/cc.journeyman.the-great-game.utils.html +++ b/docs/codox/cc.journeyman.the-great-game.utils.html @@ -1,3 +1,10 @@ -cc.journeyman.the-great-game.utils documentation

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.utils

    TODO: write docs

    cyclic?

    (cyclic? route)

    True if two or more elements of route are identical

    view source

    deep-merge

    (deep-merge & maps)

    Recursively merges maps. Stolen from https://dnaeon.github.io/recursively-merging-maps-in-clojure/

    view source

    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.

    view source

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

    view source

    truthy?

    (truthy? val)

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

    view source

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.utils documentation

    Project

    Topics

    Namespaces

    Public Vars

    cc.journeyman.the-great-game.utils

    TODO: write docs

    +

    cyclic?

    (cyclic? route)

    True if two or more elements of route are identical

    +
    view source

    deep-merge

    (deep-merge & maps)

    Recursively merges maps. Stolen from https://dnaeon.github.io/recursively-merging-maps-in-clojure/

    +
    view source

    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.

    +
    view source

    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.

    +
    view source

    truthy?

    (truthy? val)

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

    +
    view source

    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.

    +
    view source
    \ 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 68420fe..6ee3918 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.heightmap.html +++ b/docs/codox/cc.journeyman.the-great-game.world.heightmap.html @@ -1,5 +1,14 @@ -cc.journeyman.the-great-game.world.heightmap documentation

    Project

    Topics

    Namespaces

    Public Vars

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

    Functions dealing with the tessellated multi-layer heightmap.

    *base-map*

    dynamic

    TODO: write docs

    view source

    *noise-map*

    dynamic

    TODO: write docs

    view source

    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.

    view source

    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.

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

    Project

    Topics

    Namespaces

    Public Vars

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

    Functions dealing with the tessellated multi-layer heightmap.

    +

    *base-map*

    dynamic

    TODO: write docs

    +
    view source

    *noise-map*

    dynamic

    TODO: write docs

    +
    view source

    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.

    +
    view source

    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.

    view source

    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.

    view source

    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

    view source

    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

    view source

    scale-grid

    (scale-grid grid n)

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

    view source
    \ No newline at end of file +

    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.

    +
    view source

    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.

    +
    view source

    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

    +
    view source

    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

    +
    view source

    scale-grid

    (scale-grid grid n)

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

    +
    view source
    \ 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 2da9b89..bc1f1ff 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.location.html +++ b/docs/codox/cc.journeyman.the-great-game.world.location.html @@ -1,3 +1,6 @@ -cc.journeyman.the-great-game.world.location documentation

    Project

    Topics

    Namespaces

    Public Vars

    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

    view source

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.world.location documentation

    Project

    Topics

    Namespaces

    Public Vars

    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

    +
    view source

    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.

    +
    view source
    \ 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 b13ca0e..fc9af6e 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.mw.html +++ b/docs/codox/cc.journeyman.the-great-game.world.mw.html @@ -1,3 +1,4 @@ -cc.journeyman.the-great-game.world.mw documentation

    Project

    Topics

    Namespaces

    Public Vars

    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 +cc.journeyman.the-great-game.world.mw documentation

    Project

    Topics

    Namespaces

    Public Vars

    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 3de4783..95fafcb 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.routes.html +++ b/docs/codox/cc.journeyman.the-great-game.world.routes.html @@ -1,3 +1,6 @@ -cc.journeyman.the-great-game.world.routes documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.world.routes documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source

    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.

    +
    view source
    \ 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 9798a8e..00c2af0 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.world.html +++ b/docs/codox/cc.journeyman.the-great-game.world.world.html @@ -1,3 +1,7 @@ -cc.journeyman.the-great-game.world.world documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    view source

    default-world

    A basic world for testing concepts

    view source

    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.

    view source
    \ No newline at end of file +cc.journeyman.the-great-game.world.world documentation

    Project

    Topics

    Namespaces

    Public Vars

    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.

    +
    view source

    default-world

    A basic world for testing concepts

    +
    view source

    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.

    +
    view source
    \ No newline at end of file diff --git a/docs/codox/economy.html b/docs/codox/economy.html index 3287524..f95ccf8 100644 --- a/docs/codox/economy.html +++ b/docs/codox/economy.html @@ -1,33 +1,36 @@ -Game world economy

    Project

    Topics

    Namespaces

    Game world economy

    +Game world economy

    Project

    Topics

    Namespaces

    Game world economy

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

    -

    Primary producers

    -

    Herdsfolk

    -

    Herdsfolk are nomadic; it’s reasonable to think they’ll bring their herds to market, rather than selling it lots of tiny markets. So in the spring, shepherds will visit specific towns at the edge of open land, to hold a shearing festival/carnevale; and that both shepherds and cattle herders will visit towns on the edge of open land to sell fatstock in the autumn.

    -

    Miners

    +

    Primary producers

    +

    Herdsfolk

    +

    Herdsfolk are nomadic; it’s reasonable to think they’ll bring their herds to market, rather than selling at lots of tiny markets. So in the spring, shepherds will visit specific towns at the edge of open land, to hold a shearing festival/carnevale; and that both shepherds and cattle herders will visit towns on the edge of open land to sell fatstock in the autumn.

    +

    Miners

    Miners mine. They’re settled, but they’re settled usually in specialist settlements at the location where the ore body is accessible, usually in mountenous territory. They’ll consume a lot of food, so there will be a local market for foodstuffs encouraging local farming. Different mines obviously mine different ores, but, for example, lead and silver are frequently found together.

    -

    Foresters

    +

    Foresters

    Foresters are more or less settled at the edge of forests, at locations from which timber can be moved by navigable water; again in specialist settlements. In addition to timber, foresters hunt and produce both meat and furs, so have less need for other food producers locally.

    -

    Farmers

    +

    Farmers

    Farmers are settled. Farmers occupy standard runrig plots, but because they don’t employ journeymen or apprentices, and don’t have workshops, the plots are mostly open with little building. Most farmers are ‘mixed farmers’, producing cereals, meat, eggs and milk. Some will be more specialist. Farm produce, taken broadly to include orchardsfolk, include:

      -
    • meat
      • -
    • milk and milk products
      • -
    • hides
      • -
    • eggs
      • -
    • cereals
      • -
    • root vegetables, onions, etc
      • -
    • peas and beans
      • -
    • leaf vegetables
      • -
    • fruits
      • -
    • fibres: linen, hemp and silk (from silk-moths in mulberry orchards)
      • -
    • possibly other stuff I’ve forgotten.
      • +
    • meat
      • +
    • milk and milk products
      • +
    • hides
      • +
    • eggs
      • +
    • cereals
      • +
    • root vegetables, onions, etc
      • +
    • peas and beans
      • +
    • leaf vegetables
      • +
    • fruits
      • +
    • fibres: linen, hemp and silk (from silk-moths in mulberry orchards)
      • +
    • possibly other stuff I’ve forgotten.

    Farmers are all basically subsistence farmers, farming first to feed their own household and selling only surplus in the market.

    -

    Crafts

    +

    Crafts

    Crafts generally process primary goods into secondary goods - whether intermediate stages or final consumer items. Some elite ‘crafts’ deal with abstract primary goods like law and knowledge, and they may be seen as somewhat separate.

    -

    A master craftsperson occupies a standard runrig plot, much like a farmer’s plot. Like a farmer, a poor master crafter household will cultivate part of the plot to produce food for the house - at least grow vegetables and keep hens. However, as the crafter takes on apprentices and journeymen - and gets richer - more buildings will be required as accommodation, workshop space and materials stores.

    +

    A master craftsperson may occupy a standard runrig plot, much like a farmer’s plot. Like a farmer, a poor master crafter household will cultivate part of the plot to produce food for the house - at least grow vegetables and keep hens. However, as the crafter takes on apprentices and journeymen - and gets richer - more buildings will be required as accommodation, workshop space and materials stores.

    +

    Also, Tchahua is much more a gold-rush town than an organic, grew over hundreds of years sort of town, so it is not ex-runrig; and additionally the original settlement was probably along the river bank, land which has now been redeveloped as warehouses and as rich merchant residences. Generally, town house plots are small from the get go.

    +

    Hans’hua is again an exception from normal organic development, as it has no agricultural land close to the city at all.

    Generally, primary goods aren’t transported over land - because overland transport is expensive, by the time they’ve been transported they’re no longer low cost goods. So often the craftspeople who process primary produce into at least commodity intermediate forms will live close to the source of the primary goods.

    So, for example, the town(s) where the shepherds hold their shearing fairs will tend to have a lot of weavers. While around mines there will be smelters producing ingots and bar stock to be marketed to smiths all over the place, there will also be smiths close to the mines producing commodity tools and weapons.

    -

    See the table in Populating a game world.

    \ No newline at end of file +

    See the table in Populating a game world.

    +
    \ No newline at end of file diff --git a/docs/codox/genetic-buildings.html b/docs/codox/genetic-buildings.html new file mode 100644 index 0000000..b4c334d --- /dev/null +++ b/docs/codox/genetic-buildings.html @@ -0,0 +1,46 @@ + +Genetic Buildings

    Project

    Topics

    Namespaces

    Genetic Buildings

    +

    Building selection based on location

    +

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

    +

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

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

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

    +

    So you have the following general relationships

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

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

    +

    Rectangular genetic buildings

    +

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

    +

    Cell mutability

    +

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

    +

    Functional cells

    +

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

    +

    Reproducibility

    +

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

    +

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

    +

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

    +

    Seed the random number generator with latitude and longitude

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

    Project

    Topics

    Namespaces

    The-great-game 0.1.2-SNAPSHOT

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

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

    Installation

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

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

    Topics

    Namespaces

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

      Public variables and functions:

      cc.journeyman.the-great-game.cloverage

      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.gossip.news-items

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

      Public variables and functions:

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

      TODO: write docs

      Public variables and functions:

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

      TODO: write docs

      Public variables and functions:

      cc.journeyman.the-great-game.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.

      Public variables and functions:

      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.

      Public variables and functions:

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

      Default trading strategy for merchants.

      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

      Public variables and functions:

      cc.journeyman.the-great-game.time

      TODO: write docs

      Public variables and functions:

      cc.journeyman.the-great-game.utils

      TODO: write docs

      Public variables and functions:

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

      Functions dealing with the tessellated multi-layer heightmap.

      Public variables and functions:

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

      Functions dealing with location in the world.

      Public variables and functions:

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

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

      Public variables and functions:

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

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

        Public variables and functions:

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

        Run the whole simulation

        Public variables and functions:

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

        Access to data about the world

        Public variables and functions:

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

        Project

        Topics

        Namespaces

        The-great-game 0.1.2-SNAPSHOT

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

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

        Installation

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

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

        Topics

        Namespaces

        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.

          +

          Public variables and functions:

          cc.journeyman.the-great-game.cloverage

          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.gossip.news-items

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

          +

          Public variables and functions:

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

          TODO: write docs

          +

          Public variables and functions:

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

          TODO: write docs

          +

          Public variables and functions:

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

          TODO: write docs

          +

          Public variables and functions:

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

            Adjusting quantities and prices in markets.

            +

            Public variables and functions:

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

            Useful functions for doing low-level things with merchants.

            +

            Public variables and functions:

            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.

            +

            Public variables and functions:

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

            Default trading strategy for merchants.

            +

            Public variables and functions:

            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

              +

              Public variables and functions:

              cc.journeyman.the-great-game.time

              TODO: write docs

              +

              Public variables and functions:

              cc.journeyman.the-great-game.utils

              TODO: write docs

              +

              Public variables and functions:

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

              Functions dealing with the tessellated multi-layer heightmap.

              +

              Public variables and functions:

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

              Functions dealing with location in the world.

              +

              Public variables and functions:

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

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

              +

              Public variables and functions:

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

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

                +

                Public variables and functions:

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

                Access to data about the world

                +

                Public variables and functions:

                \ No newline at end of file diff --git a/docs/codox/intro.html b/docs/codox/intro.html index 1d6dcf4..0bc0655 100644 --- a/docs/codox/intro.html +++ b/docs/codox/intro.html @@ -1,128 +1,130 @@ -Introduction to the-great-game

                Project

                Topics

                Namespaces

                Introduction to the-great-game

                -

                The Great Game

                +Introduction to the-great-game

                Project

                Topics

                Namespaces

                Introduction to the-great-game

                +

                The Great Game

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

                So, firstly, how does one characterise this game?

                It has strong elements of a Role Playing Game, as currently understood; some elements of a Simulation Game; some elements of a God Game. But what I see it as is fundamentally a sandbox in which the player(s) can explore ideas about human conflicts and how to resolve them, without immediate real-world consequences. It’s also a sandbox in which story tellers can tell stories, but that’s essentially a side-effect - a consequence of the fact that I need to be able to use it to tell stories, in order to create initial threads of narrative from which players can start their exploration.

                Note that, by ‘conflict’, here, I explicitly do not mean ‘killing people’, or even ‘killing non-player characters’. I have written extensively about the problem in many current video games that all too often the only way of interacting with non-player characters is to kill them. Killing people should be one of the potential ways of resolving conflicts, because that is reality, but negotiation must be another.

                So this is a game in which rich interaction with non-player characters is possible. The NPCs have individual knowledge and individual agency: they have intentions, aspirations and desires. They also have a wide dynamic repertoire of speech.

                -

                Previous essays that are relevant

                +

                Previous essays that are relevant

                  -
                • The spread of knowledge in a large game world (2008) discusses what individual non-player characters know, and how to model dynamic updates to their knowledge;
                  • -
                • Settling a game world (2009) gives rough outline of ideas about creating the environment, including modelling things like soil fertility, local building materials, and consequently local architecture;
                  • -
                • Tessellated multi-layer height map (2013) gives ideas for how a designed geography for a very large world could be stored relatively economically;
                  • -
                • Genetic Buildings (2013) sketches algorithms which would allow procedurally-generated buildings to be site-appropriate, broadly variable and reproducable;
                  • -
                • Populating a game world (2013) provides outline algorithms for how a world can be populated, and how organic mixes of trades and crafts can be modelled;
                  • -
                • Modelling the change from rural to urban (2013) describes the idea of procedurally modelling settlements, but it is grid-based and not particularly satisfactory and has largely been superceded in my thinking;
                  • -
                • Of pigeons, and long distance messaging in a game world (2013) builds on ideas about flows of information;
                  • -
                • Modelling rural to urban, take two (2013) revisited the idea of modelling organic settlement structures, trying to find algorithms which would naturally produce more persuasive settlement models, including further ideas on the procedural generation of buildings;
                  • -
                • More on modelling rivers (2014) talks about modelling hydrology, with implications for soil fertility;
                  • -
                • Modelling settlement with cellular automata (2014) talks about successful implementation of algorithms to model vegetative environment, human settlement and the impact of human settlement on the environment;
                  • -
                • Voice acting considered harmful (2015) outlines the ideas behind full speech interaction with non-player characters, and modelling what those non-player characters should be able to speak about;
                  • -
                • Baking the world (2019) an outline of the overall process of creating a world.
                  • +
                • The spread of knowledge in a large game world (2008) discusses what individual non-player characters know, and how to model dynamic updates to their knowledge;
                  • +
                • Settling a game world (2009) gives rough outline of ideas about creating the environment, including modelling things like soil fertility, local building materials, and consequently local architecture;
                  • +
                • Tessellated multi-layer height map (2013) gives ideas for how a designed geography for a very large world could be stored relatively economically;
                  • +
                • Genetic Buildings (2013) sketches algorithms which would allow procedurally-generated buildings to be site-appropriate, broadly variable and reproducable;
                  • +
                • Populating a game world (2013) provides outline algorithms for how a world can be populated, and how organic mixes of trades and crafts can be modelled;
                  • +
                • Modelling the change from rural to urban (2013) describes the idea of procedurally modelling settlements, but it is grid-based and not particularly satisfactory and has largely been superceded in my thinking;
                  • +
                • Of pigeons, and long distance messaging in a game world (2013) builds on ideas about flows of information;
                  • +
                • Modelling rural to urban, take two (2013) revisited the idea of modelling organic settlement structures, trying to find algorithms which would naturally produce more persuasive settlement models, including further ideas on the procedural generation of buildings;
                  • +
                • More on modelling rivers (2014) talks about modelling hydrology, with implications for soil fertility;
                  • +
                • Modelling settlement with cellular automata (2014) talks about successful implementation of algorithms to model vegetative environment, human settlement and the impact of human settlement on the environment;
                  • +
                • Voice acting considered harmful (2015) outlines the ideas behind full speech interaction with non-player characters, and modelling what those non-player characters should be able to speak about;
                  • +
                • Baking the world (2019) an outline of the overall process of creating a world.
                -

                Organic and emergent game-play

                +

                Organic and emergent game-play

                If a world is dynamically populated, with dynamic allocation of livelihoods then several aspects of gameplay will emerge organically. First, of course, is just exploring; in a dynamically changing world there will always be more to explore, and it will be different in each restart of the game.

                -

                Trading

                +

                Trading

                Second is trading. If there are markets, and merchants moving between them, then the prices in the markets can be modelled dynamically. Markets in out of the way places which produce otherwise scarce primary products will have low prices for those products, and the player can make profit by carrying product to more urban markets where the prices are higher. Yes, that isn’t in itself a satisfying game, but if the player is in any case travelling from place to place it may be a useful side-game.

                -

                Dynamic quests

                +

                Dynamic quests

                Third is aiding. If dynamic events happen in the world, then, for some non-player characters, some of those events will be negative. A merchant who is robbed, a shepherd whose sheep have been driven off by wolves, a family whose child has been abducted, will seek help. These requests for aid can become dynamically generated quests. Dynamic quests have a bad reputation, but with better modelling of NPC behaviour and better repertoire, I think that satisfying dynamic quests shouldn’t be too difficult to do - they are, after all, just another instance of procedural generation.

                So in the ‘abducted child’ quest, for example, there are a range of things which may be going on:

                Did the child go willingly? If so, were they fleeing an abusive home, or seeking a better life, or eloping with a lover, or seduced by a bad actor? Do they want to go back, or do they want to stay away? If they want to stay away, can you force them to go back? Alternatively, can you negotiate a state of peace between the abductor and the family?

                So there are a range of possible outcomes:

                  -
                1. The player talks to the child and decides to take no further action;
                  2. -
                2. The player abducts/liberates the child from the abductors and returns the child to their parents;
                  3. -
                3. The player abducts/liberates the child from the abductors and allows the child to choose which to stay with;
                  4. -
                4. The player kills off the abductors and returns the child to their parents;
                  5. -
                5. The player kills off the abductors and allows the child to choose where to go;
                  6. -
                6. The player negotiates a ransom and returns the child to their parents;
                  7. -
                7. The player negotiates a reconcilliation between the parents and the abductor, and the child chooses which to stay with.
                  8. +
                8. The player talks to the child and decides to take no further action;
                  9. +
                9. The player abducts/liberates the child from the abductors and returns the child to their parents;
                  10. +
                10. The player abducts/liberates the child from the abductors and allows the child to choose which to stay with;
                  11. +
                11. The player kills off the abductors and returns the child to their parents;
                  12. +
                12. The player kills off the abductors and allows the child to choose where to go;
                  13. +
                13. The player negotiates a ransom and returns the child to their parents;
                  14. +
                14. The player negotiates a reconcilliation between the parents and the abductor, and the child chooses which to stay with.

                Generally, (1) and (2) above will enhance the player’s reputation for getting stuff done, (4) or (5) enhance their reputation as a fighter, and (6) or (7) as a negotiator. However, while (2), (4) and (7) will increase the player’s favour with the parents and consequently with their wider circly, returning an unwilling child to its parents will have a much more uncertain outcome. Allowing the child to choose will increase the player’s favour with the child, but probably decrease it with the parents.

                Thus there is a fairly rich dynamic quest graph for this general quest, and it’s conditioned by many factors. For example, if the player is already viewed favourably by the abductor, then negotiation will be much easier; if negatively, negotiation may be impossible. How favourably the child views the player will affect how willing the child is to go with the player (and, of course, if the abductor was the child’s lover, then killing the abductor will sharply reduce the child’s favour towards the player).

                There’s a similarly rich quest graph regarding goods in contested ownership, e.g. they’ve been stolen from a merchant (or the merchant claims that they have) but are now held by someone who claims that they bought them honestly. And so on: rich abstract quest graphs can be derived for quite a lot of c onflicts which will arise dynamically between non-player characters.

                To make dynamic quests work, of course, you need a dynamic world; a world in which conflicts can arise. A world in which traders trade, robbers rob, lovers love, haters hate, scandal-mongers make scandal, organically and dynamically whether the player is there or not, and where news of these events will filter through to the player through the gossip network also organically and dynamically.

                -

                Extending the story

                +

                Extending the story

                Dynamic quests do not mean that there should not be, or cannot be, scripted quests, and, indeed, I’m sure that there should be; which brings us to the next point.

                In a very large world, writing enough story to have satisfyingly constructed narratives everywhere the player goes is a very large job. But I became excited by role playing games, not so much by the original Neverwinter Nights itself, but by the authoring tools which came free with it. There were thousands of user-contributed add-on ‘mods’, mostly stories and quests, for Neverwinter Nights, of which I wrote several - and I greatly enjoyed doing so.

                Later on, with Carrol Dufault and others (including James Semple who wrote wonderful original music), I went on to write a new story for The Witcher which won CD Project’s prize for best mod.

                For me, writing story is every bit as compelling an activity as playing it, and I know I’m not alone in that. So I feel strongly that if The Great Game were ever released, it wouldn’t be necessary to fully populate the map with scripted story; rather, the release should include authoring tools which would allow players to extend story, and documentation which set the overall framework within which story could be extended. And then there should be a mechanism by which extensions of sufficient quality could be merged into the overall game for all players, and the authors of those stories rewarded with some degree of recognition.

                -

                Aspirations and goals

                +

                Aspirations and goals

                (In what follows I shall use the word ‘agent’ to cover both player characters and - but more particularly - non-player characters) In order to build a dynamic world in which we can play with ideas about human conflict, we need to model those things which give rise to conflict, which means we need to model not merely short term aspirations and goals but also long term aspirations and goals; agents have a hierarchy of needs and to achieve those needs they must have a hierarchy of goals.

                Not everyone has the same ‘top level goal’; different agents should have different top level goals. The following are some plausible top level goals:

                  -
                1. Ancestor: To be succeeded by children and grandchildren, to found a dynasty;
                  2. -
                2. Master: To become highly esteemed as a master of your craft;
                  3. -
                3. Explorer: To be widely travelled, to see the world;
                  4. -
                4. Climber: To climb as high as possible in the social hierarchy, to become Tyrranos or Imperator;
                  5. -
                5. Conqueror: To build the largest possible realm under your control;
                  6. -
                6. Citizen: To build a secure and comfortable home, able to feed and protect those within it;
                  7. +
                7. Ancestor: To be succeeded by children and grandchildren, to found a dynasty;
                  8. +
                8. Master: To become highly esteemed as a master of your craft;
                  9. +
                9. Explorer: To be widely travelled, to see the world;
                  10. +
                10. Climber: To climb as high as possible in the social hierarchy, to become Tyrranos or Imperator;
                  11. +
                11. Conqueror: To build the largest possible realm under your control;
                  12. +
                12. Citizen: To build a secure and comfortable home, able to feed and protect those within it;

                In this typology, a hero is a master soldier, and a sage a master scholar. Each of these types should be capable of being ‘scored’ by a real function which can be written over real parameters which exist in the game. Some are easy:

                  -
                1. Ancestor: how many living descendants does this agent have now?
                  2. -
                2. Master: what is the sum of (or average of) the esteem held for this agent by other agents of the same craft?
                  3. -
                3. Explorer: (e.g.) what is the sum of the distance between the most northerly and most southerly, and the most easterly and most westerly, locations this agent has visited?
                  4. -
                4. Climber: how many ‘promotions’ has this agent had in the game?
                  5. -
                5. Conqueror: how many total vassales, recursively, has this agent?
                  6. -
                6. Citizen: really, really tricky. Probably what is the average esteem for this agent among all agents within a specified radius? - although this will score more highly for agents who have taken part in notable events, and what I’m really thinking of for my ideal ‘good citizen’ is someone who really hasn’t.
                  7. +
                7. Ancestor: how many living descendants does this agent have now?
                  8. +
                8. Master: what is the sum of (or average of) the esteem held for this agent by other agents of the same craft?
                  9. +
                9. Explorer: (e.g.) what is the sum of the distance between the most northerly and most southerly, and the most easterly and most westerly, locations this agent has visited?
                  10. +
                10. Climber: how many ‘promotions’ has this agent had in the game?
                  11. +
                11. Conqueror: how many total vassals, recursively, has this agent?
                  12. +
                12. Citizen: really, really tricky. Probably what is the average esteem for this agent among all agents within a specified radius? - although this will score more highly for agents who have taken part in notable events, and what I’m really thinking of for my ideal ‘good citizen’ is someone who really hasn’t.

                So each agent is assigned - by the dreaded random number generator - one top level goal when they are instantiated. I don’t think it’s necessary to model change of top level goals, although of course that does happen in real life; however, although each agent has one top level goal, they will have lower level ‘stretch goals’ also taken from this list: so at each decision point in an agent’s planning loop, if base level needs are satisfied and progress on the top level goal is blocked, actions should be chosen which progress one of the lower goals. Indeed, it’s possible that all agents could have all goals, but randomly ordered.

                At the lowest level there are immediate needs goals every agent must satisfy: food for tonight, a safe place to stay tonight, food for next year, a safe place to stay next year.

                -

                On screen and off screen

                +

                On screen and off screen

                If we’re going to have a very large world with a very large number of characters (as an order of magnitude number, say 100,000), then obviously we cannot plan in detail every time each character lifts a cup to their lips to drink. When a character is on screen we must represent small actions, and at some level these must be planned for. But when they’re off screen, that’s just wasted computation. The only actions we need to plan are life altering actions, such as:

                  -
                • Killings and deaths;
                  • -
                • Raids, feuds, abductions and significant thefts;
                  • -
                • Marriages, especially among the high status;
                  • -
                • Treaties and wars;
                  • -
                • Scandalous liaisons.
                  • +
                • Killings and deaths;
                  • +
                • Raids, feuds, abductions and significant thefts;
                  • +
                • Marriages, especially among the high status;
                  • +
                • Treaties and wars;
                  • +
                • Scandalous liaisons.

                How far away should these actions be planned? Well, that’s driven by gossip. If news of an action is likely to reach the player through the gossip network, then that action needs to be planned; if it’s extremely unlikely, then not so much. So we need to have a moving bubble around the player in which every actor is woken for one iteration of their planning loop each game day; a larger bubble in which only Masters, Captains, Outlaw Leaders and Aristons and above are woken; and an outermost bubble comprising the whole world in which only Tyrannos and Generals are woken.

                Note that, if there’s a ‘fast travel’ mode (which likely there will be), ‘game days’ also happen while fast travelling, so this ‘wake loop’ has to be one of the things which are still computed during fast travel.

                Of course, gossip, markets and merchants are slightly different. For gossip to work, merchants (and other gossip agents) need to be woken every time they arrive at a new location, to exchange news; for trade simulation to work, the buying and selling decisions of merchants at markets need to be modelled, including modelling which markets the merchant will visit next. Also, there needs to be some sort of thing about at the end of each game day, if there’s an Outlaw Leader within a certain distance of a merchant, then that outlaw leader has to be woken for a decision on whether to attack (although this may simply be within the second bubble, in which case the outlaw leaders will be woken anyway).

                -

                Planning

                -

                Esteem and favour

                +

                Planning

                +

                Esteem and favour

                Note that for all this work there need to be several dimensions to reputation, and here I’d like to clearly discriminate between two: esteem, and favour. Suppose, for a moment, that you are a Captain, engaged in a battle with another Captain who wins the battle through what you regard as a sneaky trick. You’re not going to like your opponent much: your favour for them will go down. But you’re going to think they’re pretty effective at their job: your esteem for them will go up.

                In general, an agent will treat more favourably another agent for whom they have more favour, whether that’s sharing more information (gossip), sharing (or offering more favourable prices for) goods, or whatever.

                This isn’t the same thing as esteem. If there are two weapon smiths in town, and you need a high quality sword, you’ll go to the one you esteem more, not the one you favour more. Esteem itself may have multiple dimensions: that weaponsmith whom you esteem as a weaponsmith, you may not esteem as a fighter. Obviously, the more dimensions you give it the harder it is to model, but at least for player characters I’d like several dimensions of esteem, since a player who has been successful in negotiation, for example, should be offered more diplomacy quests, where one who has been more successful in battle should be offered more warlike quests.

                Generally, an agent will not employ another agent for whom they hold negative esteem or negative favour; so losing either esteem or favour with your employer will lead to vagrancy.

                -

                One class of agent

                +

                One class of agent

                But that brings me to a separate point: I feel strongly that every agent in the game world should be essentially the same, in as much as whichever agent the player inhabits, the game will still work. In some games, for example the Witcher series, the player has no choice at all of which character they play; in others, such as for example Dragon Age, you can choose your character within some broad parameters, although this choice won’t greatly affect the story.

                What I envisage is a game in which the player can choose to inhabit any character at all in the game world, and the game will still work. Of course, scripting a narrative with that sort of flexibility is a very big job, but actually everything about this proposal is a very big job; I’m not going to veer away from the view that the toolkit ought to at least support this (it ought also to support the player choosing not to inhabit any character at all, and just watch the stories unfold as with a movie, without taking part at all). Having every agent ‘the same’ also makes the software more orthogonal and thus simpler. Obviously, agents must differ, but that difference should be in parameterisation - data - rather than anything else.

                -

                More about merchants

                +

                More about merchants

                Having said that there’s one class of agent, there is something special about merchants (and also minstrels and diplomats, see below); they are travellers who make aspects of the dynamic game world work, and to do so they have to have some behaviours to a greater degree than other agents.

                A merchant has:

                  -
                • A home base at a particular location - in a town with a market;
                  • -
                • A caravan of pack animals, or else a ship, in either case of finite capacity;
                  • -
                • A line of credit with some banking network, again finite.
                  • +
                • A home base at a particular location - in a town with a market;
                  • +
                • A caravan of pack animals, or else a ship, in either case of finite capacity;
                  • +
                • A line of credit with some banking network, again finite.

                At each market, a merchant must decide

                  -
                1. Whether, and what, to sell;
                  2. -
                2. Whether, and what, to buy.
                  3. +
                3. Whether, and what, to sell;
                  4. +
                4. Whether, and what, to buy.

                In any case, the merchant can’t carry more than the capacity of their ship/caravan. The judgements are based on knowledge of likely prices in reachable markets, the likely costs of the routes to those markets, and thus the likely profitability of the trade. When away from their home market, there will be a slight bias in selecting trades which will take them closer to their home market. At each market, when goods are bought, the price of that commodity in that market will rise slightly; when goods are sold, the price of that commodity in that market will fall slightly. For some commodities it may be reasonably possible to fully model price movements; for others, they will probably need to be fudged. More modelling is better, but it costs compute, and thus it may be necessary to fudge. In any given market, the ‘buy’ price of any commodity is higher than the ‘sell’ price, by some markup, which is maybe around 10%.

                -

                Cost of movement

                +

                Cost of movement

                A caravan or ship costs so much per day to run, irrespective of whether full or empty. So the base cost of a journey is a function of the time taken, which is essentially a function of the distance.

                -

                Outlawry and merchants

                +

                Obviously, on top of the base cost of movement there are tolls, which are imposed by the aristons through whose territory the journey passes (and therefore predictable, and can be used in route planning), and also the risk of having to bribe or fight outlaws, and the possible need to hire mercenaries to defend against outlaws, which is not predictable but can be estimated and thus also used in route planning.

                +

                Outlawry and merchants

                Outside the domains of aristons, outlaws may intercept caravans; when this happens the following outcomes are possible:

                  -
                1. The merchant (together with any mercenaries the merchant has hired to protect the caravan) successfully fights off the outlaws;
                  2. -
                2. The outlaws steal the entire cargo (and may kill the merchant);
                  3. -
                3. The merchant pays protection money to the outlaws, typically around 5%-10% of the value of cargo carried;
                  4. -
                4. The merchant employs the outlaws as caravan guards (see below);
                  5. -
                5. The outlaws allow the caravan to pass unmolested;
                  6. -
                6. There is no contact.
                  7. +
                7. The merchant (together with any mercenaries the merchant has hired to protect the caravan) successfully fights off the outlaws;
                  8. +
                8. The outlaws steal the entire cargo (and may kill the merchant and others);
                  9. +
                9. The merchant pays protection money to the outlaws, typically around 5%-10% of the value of cargo carried;
                  10. +
                10. The merchant employs the outlaws as caravan guards (see below);
                  11. +
                11. The outlaws allow the caravan to pass unmolested;
                  12. +
                12. There is no contact.

                Why should a merchant hire outlaws a guards? In this world, all fighter are more or less mercenaries, and there’s a fluidity between outlaws and mercenaries; a fighter is employed by their sergeant, and if their sergeant is employed by an ariston (or a captain employed by an ariston), they’re a soldier, and that’s respectable. If, however, the sergeant isn’t employed, then at some point they become outlaws. At the point they become outlaws, they start to raid unprotected farms, villages and caravans. Every time they raid, the favour in which they are held by all other agents who hear of it through the gossip network will decline.

                A captain or ariston will choose to employ sergeants whom they view with favour over equally esteemable sergeants they don’t, so once you’ve become an outlaw you’re on a downward spiral. However, if you work for a merchant and the merchant is happy with your work (i.e. he completes his journey without being hit up by any other outlaws), then positive favour towards you will propagate through the gossip network, and this is the outlaw’s way out of the downward spiral.

                The fee for being a caravan guard is X per fighter per day, where X varies a bit but is essentially a known rough amount.

                -

                Aristons and merchants

                -

                Generally, if a merchant buys goods in an ariston’s market, or sells goods in the ariston’s market, then the economy benefits and the ariston benefits from that; so the ‘tax’ element is part of the market markup. But if a caravan passes through an ariston’s territory without stopping at a market, there’s probably a tax of about 5% of value.

                +

                Aristons and merchants

                +

                Generally, if a merchant buys goods in an ariston’s market, or sells goods in the ariston’s market, then the economy benefits and the ariston benefits from that; so the ‘tax’ element is part of the market markup. But if a caravan passes through an ariston’s territory without stopping at a market, there’s probably a toll of about 5% of value.

                Generally, an ariston’s army will control outlawry within the ariston’s domain, so outlaw encounters within a domain are unlikely. Soldiers could be able seek bribes, but that would bring a strongly negative impact on favour and I’m not sure it’s work modelling.

                -

                Other habitual travellers: gossipers

                -

                Apart from merchants, the habitual travellers are diplomats (who, in the craft tree, are similar to chancellors) and minstrels (who aren’t on the craft tree but should be); and vagrants. However, vagrants almost certainly don’t have positive favour, so aren’t likely to be useful gossip agents. Each game day, every habitual traveller within the ‘local’ gossip bubble exchanges some items of gossip with the nearest innkeeper to their current location. In the second and third gossip bubbles, it’s probably only more favoured gossip agents who do this. See The spread of knowledge in a large game world

                \ No newline at end of file +

                Other habitual travellers: gossipers

                +

                Apart from merchants, the habitual travellers are diplomats (who, in the craft tree, are similar to chancellors) and minstrels (who aren’t on the craft tree but should be); and vagrants. However, vagrants almost certainly don’t have positive favour, so aren’t likely to be useful gossip agents. Each game day, every habitual traveller within the ‘local’ gossip bubble exchanges some items of gossip with the nearest innkeeper to their current location. In the second and third gossip bubbles, it’s probably only more favoured gossip agents who do this. See The spread of knowledge in a large game world

                +
                \ No newline at end of file diff --git a/docs/codox/modelling_trading_cost_and_risk.html b/docs/codox/modelling_trading_cost_and_risk.html index d2fb39b..82372fa 100644 --- a/docs/codox/modelling_trading_cost_and_risk.html +++ b/docs/codox/modelling_trading_cost_and_risk.html @@ -1,7 +1,8 @@ -Modelling trading cost and risk

                Project

                Topics

                Namespaces

                Modelling trading cost and risk

                +Modelling trading cost and risk

                Project

                Topics

                Namespaces

                Modelling trading cost and risk

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

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

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

                -

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

                \ No newline at end of file +

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

                +
                \ No newline at end of file diff --git a/docs/codox/naming-of-characters.html b/docs/codox/naming-of-characters.html index 51d2a68..c19bf56 100644 --- a/docs/codox/naming-of-characters.html +++ b/docs/codox/naming-of-characters.html @@ -1,26 +1,32 @@ -Naming of Characters

                Project

                Topics

                Namespaces

                Naming of Characters

                +Naming of Characters

                Project

                Topics

                Namespaces

                Naming of Characters

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

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

                -

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

                +

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

                Based on, roughly, historical name patterns like

                Archibald (personal-name) the Grim (epithet), Earl (trade-or-rank) of Douglas (location)

                Where

                  -
                1. -

                  epithet is a prefix based on some notable feature or feat of the character. Most characters won’t have an epithet, unless they have some notable feature or they’ve done something notable. If a character does something notable in the course of the game, they will subsequently gain an epithet; ‘notability’ may be measured by how many times the event is transmitted through the gossip network.

                  2. -
                2. -

                  clan is special to the Western Clans, although people from the Great Place may possible use the name of their house similarly.

                  3. -
                3. -

                  personal-name is chosen from one of a limited set of limited sets; different cultural groups will have different (possibly overlapping) sets of names, but within each set there will only be a limited subset

                  4. -
                4. -

                  trade-or-rank is just that. “Smith”, “Miller”, “Ariston”, “Captain”. Either only master craftsfolk have the trade-or-rank name of their craft, or we distinguish between ‘Calon the Smith’, who may be a journeyman, and ‘Calon the Master Smith’, who is a master.

                  5. -
                5. -

                  location is the name of a location; a village, town, city or province. The location which forms part of a character’s name is the location where there current home is, not the location where they were born or where their ancestors came from

                  6. +
                6. +

                  epithet is a prefix based on some notable feature or feat of the character. Most characters won’t have an epithet, unless they have some notable feature or they’ve done something notable. If a character does something notable in the course of the game, they will subsequently gain an epithet; ‘notability’ may be measured by how many times the event is transmitted through the gossip network.

                  +
                  7. +
                7. +

                  clan is special to the Western Clans, although people from the Great Place may possible use the name of their house similarly.

                  +
                  8. +
                8. +

                  personal-name is chosen from one of a limited set of limited sets; different cultural groups will have different (possibly overlapping) sets of names, but within each set there will only be a limited subset

                  +
                  9. +
                9. +

                  trade-or-rank is just that. “Smith”, “Miller”, “Ariston”, “Captain”. Either only master craftsfolk have the trade-or-rank name of their craft, or we distinguish between ‘Calon the Smith’, who may be a journeyman, and ‘Calon the Master Smith’, who is a master.

                  +
                  10. +
                10. +

                  location is the name of a location; a village, town, city or province. The location which forms part of a character’s name is the location where there current home is, not the location where they were born or where their ancestors came from

                  +

                Full names will almost never be used - only, perhaps, in extremely formal circumstances. The form of a name used will depend on context, and will generally be just sufficient to disambiguate the character in the context.

                If the speaker is in Sinhua and referring to someone from Sinhua, they won’t refer to them as ‘of Sinhua’.

                If everyone present is a bargee and the speaker referring to someone who is also a bargee, they won’t refer to them as ‘the bargee’.

                The question asked influences the context: in answer to the question ‘who is the best sword smith’, the answer will not be ‘Calon the Smith’ but ‘Calon of Sinhua’.

                -

                Patronymics/matronymics will not normally be used of adults (although they may be used of apprentices and journeymen.

                \ No newline at end of file +

                Patronymics/matronymics will not normally be used of adults (although they may be used of apprentices and journeymen.

                +
                \ No newline at end of file diff --git a/docs/codox/on-dying.html b/docs/codox/on-dying.html index 36b097b..030f121 100644 --- a/docs/codox/on-dying.html +++ b/docs/codox/on-dying.html @@ -1,9 +1,17 @@ -On Dying

                Project

                Topics

                Namespaces

                On Dying

                +On Dying, and Injury

                Project

                Topics

                Namespaces

                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.

                Time has passed; events in the game world have moved on. You can talk to your saviours about it. You have lost a lot of strength, and most of the gear you were carrying. You must do whatever it is you do within the game mechanics to rebuild strength, and to acquire more gear. Significantly you have acquired a debt of honour to your saviours, which they may call on later. You almost certainly have new scars, and might possibly have some lasting effects (although how that interacts with other game mechanics might be tricky).

                So who are the non-enemies? It depends on context. If you have a party, and some of that party survived the fight, it’s your party. Otherwise, if you’re in a populated place, it’s locals. If it’s on a road or other route, it’s passing merchants. If you’re in the wilderness, a hunting party. It’s a bunch of non-hostiles who might reasonably be expected to be around: that’s what matters. It’s about not breaking immersion.

                -

                Obviously losing a fight must have weight, it must have meaning, it must have in-game consequences; otherwise it is meaningless.

                \ No newline at end of file +

                Obviously losing a fight must have weight, it must have meaning, it must have in-game consequences; otherwise it is meaningless.

                +

                Injury

                +

                Similarly to death, injury must have meaning. Any injury takes time to recover from. It takes a certain amount of time if you’re able to rest somewhere safe, and considerably longer if you’re not. If you fight while injured, you’ll have less strength, less stramina, and probably also less agility. Depending where you’re injured, there will be certain things you cannot do. If you fight while injured, also, your recovery time will be extended, even if you take no further injury.

                +

                Some serious injuries will lead to permanent scarring, and permanent loss of agility; you’ll be just slightly slower in fights.

                +

                It should be said that Kenshi — a game I’ve only recently become aware of and greatly admire — handles all of this extremely well, and is worth studying.

                +

                Reciprocity

                +

                If the player is going to depend on good samaritans for rescue after losing a fight, then there must be at least a social convention that people should assist people found injured on the wayside. Consequently, if the player fails to do this, that should in itself become a ‘gossip’ event which will lower the player’s reputation with non-player characters.

                +

                On the other hand, helping NPCs found injured at the wayside can be another category of organic quest, as a special subcategory of an escort quest.

                +
                \ No newline at end of file diff --git a/docs/codox/sandbox.html b/docs/codox/sandbox.html index d914974..7803bcb 100644 --- a/docs/codox/sandbox.html +++ b/docs/codox/sandbox.html @@ -1,39 +1,41 @@ -Sandbox

                Project

                Topics

                Namespaces

                Sandbox

                +Sandbox

                Project

                Topics

                Namespaces

                Sandbox

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

                Why?

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

                  -
                • Where is the nearest craftsman of this craft?
                  • -
                • What price can I expect to get for this item in the local market?
                  • -
                • What news have you heard recently?
                  • -
                • Where does this person from your village live?
                  • +
                • Where is the nearest craftsman of this craft?
                  • +
                • What price can I expect to get for this item in the local market?
                  • +
                • What news have you heard recently?
                  • +
                • Where does this person from your village live?

                and where there’s a sufficiently sophisticated and robust economy simulation that buying goods in one market and selling them in another is viable.

                The original BBC Micro space trading game Elite had very little more in terms of game mechanics than a sandbox with a means to navigate it and an economy simulation, which wasn’t even nearly as sophisticated as the one I have working now. Yet that combination resulted in engaging game play.

                -

                Main sandbox roles

                +

                Main sandbox roles

                The idea of a sandbox is that the player character should be able to do pretty much anything they like within the mechanics of the game. From that, it seems to me reasonable that the player ought to be able to do more or less everything a non-player character can do. But creating the game mechanics to make each additional task doable takes time and investment, so there’s a need to prioritise.

                So, as Elite did, I propose to make the first available sandbox roles

                -

                Merchant

                +

                Merchant

                Someone who travels from city to city, buying goods cheap in one and selling them for more in another; and

                -

                Outlaw

                +

                Outlaw

                Someone who intercepts and steals from merchants (and may also attack outlying farms and villages)

                -

                Second tier playable roles

                +

                Second tier playable roles

                The next tier of playable roles rotates around issues arising from the mercantile ecosystem.

                -

                Aristocracy

                -

                Aristocrats are basically settled outlaws who seek to establish a monopoly on extracting taxes from inhabitants and travellers in a particular region by driving out all other outlaws. Within the comain of an aristocrat, you have to pay tax but you’re reasonably safe from being attacked by other outlaws and losing everything. Aristocrats may also maintain and improve roads and bridges and do other things to boost the economy of their territory, may expant into adjoining territory with no current aristocratic control, and may wage war on other aristocrats.

                +

                Aristocracy

                +

                Aristocrats are basically settled outlaws who seek to establish a monopoly on extracting taxes from inhabitants and travellers in a particular region by driving out all other outlaws. Within the domain of an aristocrat, you have to pay tax but you’re reasonably safe from being attacked by other outlaws and losing everything. Aristocrats may also maintain and improve roads and bridges and do other things to boost the economy of their territory, may expand into adjoining territory with no current aristocratic control, and may wage war on other aristocrats.

                An outlaw ought to be able to become an aristocrat, by dominating an ungoverned area or by defeating an existing aristocrat.

                -

                Soldiery

                +

                Soldiery

                Soldiers, like aristocrats, are basically on the same spectrum as outlaws. Outlaws may hire themselves out to merchants as caravan guards, or to aristocrats as soldiers. Soldiers or guards, falling on bad times, may revert to outlawry.

                -

                Routine, Discretion and Playability

                -

                There’s a term that’s used in criticism of many computer games which is worth thinking about hard here: that term is ‘farming’. ‘Farming’, in this sense, is doing something repetitive and dull to earn credits in a game. Generally this is not fun. What makes roles in a game-world fun is having individual discretion - the ability to choose between actions and strategies - and a lack of routine.

                -

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

                -

                Cruise control

                -

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

                -

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

                -

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

                -

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

                +

                Routine, Discretion and Playability

                +

                There’s a term that’s used in criticism of many computer games which is worth thinking about hard here: that term is ‘farming’. ‘Farming’, in this sense, is doing something repetitive and dull to earn credits in a game. Generally this is not fun. What makes roles in a game-world fun is having individual discretion — the ability to choose between actions and strategies — and a lack of routine.

                +

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

                +

                Cruise control

                +

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

                +

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

                +

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

                +

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

                +

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

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

                -

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

                -

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

                \ No newline at end of file +

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

                +

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

                +
                \ No newline at end of file diff --git a/docs/codox/sexual-dimorphism.html b/docs/codox/sexual-dimorphism.html index 1fbe0f8..e351da7 100644 --- a/docs/codox/sexual-dimorphism.html +++ b/docs/codox/sexual-dimorphism.html @@ -1,6 +1,6 @@ -Sexual dimorphism

                Project

                Topics

                Namespaces

                Sexual dimorphism

                +Sexual dimorphism

                Project

                Topics

                Namespaces

                Sexual dimorphism

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

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

                OK? Let’s start.

                @@ -10,19 +10,28 @@

                For all sorts of reasons, some of which are clearly cultural but others of which are fundamental, it’s much easier for men to walk away from responsibility for their children than it is for women. For example, considering a pre-modern world, women would always know for certain which children were theirs, and men would not.

                For a woman, consequently, the best breeding strategy is to have sex only with men who will be ‘good fathers’, where there are three essential parameters to “good fathers”:

                  -
                1. Desirable genetic traits;
                  2. -
                2. Preparedness to stick around and share the work;
                  3. -
                3. Ability to provide and protect.
                  4. +
                4. Desirable genetic traits;
                  5. +
                5. Preparedness to stick around and share the work;
                  6. +
                6. Ability to provide and protect.

                The essential trade-off in the traditional western marriage is that the man gets to have sex, and the woman gets to have protection for her progeny.

                Another significant point is that women’s ability to bear children ceases at a much younger age than men’s ability to father them.

                -

                Why have sex at all?

                +

                Why have sex at all?

                If a character has ‘having children’ - the Ancestor aspiration, in my typology - as their key aim, then they will want to have sex. But to have children in this sense is to have acknowledged children, so while a male character may be motivated to have multiple female partners, he will never the less have some degree of long term committment to them, and will want both to feel confident that the children are his and to be recognised by their father.

                From the point of view of seeking to become an Ancestor, there is little benefit to the woman in having multiple partners, except in very harsh environments. It will be easier to give one partner confidence that all your children are his, and while a man can increase his number of potential progeny by having multiple wives, mistresses or other classes of long-term female sexual partners, a woman cannot.

                -

                Why have children?

                +

                Why have children?

                In modern Scotland, I have met a lot of women with a strong drive to have children for the sake of having children, where the best explanation they could give is that it’s instinctual; it may be so. But beyond that, in many cultures children provide their (acknowledged) parents with care and security in their old age, may tend their graves and perform belief-related services after they die, and carry on their name and their stories into the future.

                Not everyone wants to have children; in thinking about the driving aspirations of game characters, I view having children one of six potential key aspirations.

                -

                Why else have sex?

                +

                Why else have sex?

                Sex, done right, is an extremely pleasant pastime. Sex can also be used to create and maintain bonds of committment, to demonstrate social status, to defuse tense situations, and transactionally in many ways, both formal and informal.

                For women, sex with other women carries with it no risk of pregnancy, so can be enjoyed or used for any of these purposes in very much the same way as it can by men; in other words, particularly for women, homosexual sex can be more lighthearted and carefree than heterosexual sex. To what extend our notions of homosexuality and heterosexuality are cultural I simply don’t know. But because no children will result, a woman can afford to be more promiscuous with other women than she can with men.

                -

                ##

                \ No newline at end of file +

                Women and warrior/adventurer lifestyles

                +

                Generally speaking, people do not want to take their children onto a battlefield. If you’re going to have a game world in which women significantly take on warrior or adventurer roles, then you must either have

                +
                  +
                • A culture which expects female warriors to be celibate; or
                  • +
                • A culture with access to and acceptance of safe and reliable contraception or abortion; or
                  • +
                • An acceptance of leaving infant children with grandparents, other relatives or foster carers for long periods;
                  • +
                • A system of long term creches;
                  • +
                • Any combination of the above.
                  • +
                +
                \ No newline at end of file diff --git a/project.clj b/project.clj index 9315ba9..56344f1 100644 --- a/project.clj +++ b/project.clj @@ -29,7 +29,7 @@ :url "https://www.gnu.org/licenses/old-licenses/gpl-2.0.en.html"} :plugins [[lein-adl "0.1.7"] [lein-cloverage "1.2.2"] - [lein-codox "0.10.7-cloverage"] + [lein-codox "0.10.8"] ;;[lein-codox "0.10.7-cloverage"] [lein-cucumber "1.0.2"] [org.clojars.benfb/lein-gorilla "0.7.0"] ] diff --git a/src/cc/journeyman/the_great_game/agent/agent.clj b/src/cc/journeyman/the_great_game/agent/agent.clj index 05eef48..f63c915 100644 --- a/src/cc/journeyman/the_great_game/agent/agent.clj +++ b/src/cc/journeyman/the_great_game/agent/agent.clj @@ -66,46 +66,46 @@ `world`.") (tired? [actor world circle] "True if this `actor` needs rest.")) -(defrecord Agent - ;; "A default agent." - [name craft home culture] - ProtoObject - ProtoContainer - ProtoAgent +;; (defrecord Agent +;; ;; "A default agent." +;; [name craft home culture] +;; ProtoObject +;; ProtoContainer +;; ProtoAgent - (act - “Return a world like this `world `except that this `actor `has acted in it. - ‘Circle’ indicates which activation circle the actor is in. +;; (act +;; “Return a world like this `world `except that this `actor `has acted in it. +;; ‘Circle’ indicates which activation circle the actor is in. - Note that this implies that a `plan `is a function of three arguments, an - actor, a world. and a circle.” - [actor world circle] - (let [urgent (case circle - :other (cond - (pending-scheduled-action? actor world circle) - (plan-scheduled-action actor world circle) - (empty? (:plans actor)) - (plan-goal actor world circle)) - :background (cond - (threatened? actor world circle) - (plan-fight-or-flight actor world circle) - (pending-scheduled-action? actor world circle) - (plan-scheduled-action actor world circle) - (empty? (:plans actor)) - (plan-goal actor world circle)) - ;; else - (cond - (threatened? actor world circle) - (plan-fight-or-flight actor world circle) - (hungry? actor world circle) - (plan-find-food actor world circle) - (tired? actor world circle) - (plan-find-rest actor world circle) - (pending-scheduled-action? actor world circle) - (plan-scheduled-action actor world circle) - (empty? (:plans actor)) - (plan-goal actor world circle))) - a’ (if urgent - (assoc actor :plans (cons urgent (:plans actor))) - actor)] - (eval ((first (:plans a’)) a’ world))))) +;; Note that this implies that a `plan `is a function of three arguments, an +;; actor, a world. and a circle.” +;; [actor world circle] +;; (let [urgent (case circle +;; :other (cond +;; (pending-scheduled-action? actor world circle) +;; (plan-scheduled-action actor world circle) +;; (empty? (:plans actor)) +;; (plan-goal actor world circle)) +;; :background (cond +;; (threatened? actor world circle) +;; (plan-fight-or-flight actor world circle) +;; (pending-scheduled-action? actor world circle) +;; (plan-scheduled-action actor world circle) +;; (empty? (:plans actor)) +;; (plan-goal actor world circle)) +;; ;; else +;; (cond +;; (threatened? actor world circle) +;; (plan-fight-or-flight actor world circle) +;; (hungry? actor world circle) +;; (plan-find-food actor world circle) +;; (tired? actor world circle) +;; (plan-find-rest actor world circle) +;; (pending-scheduled-action? actor world circle) +;; (plan-scheduled-action actor world circle) +;; (empty? (:plans actor)) +;; (plan-goal actor world circle))) +;; a’ (if urgent +;; (assoc actor :plans (cons urgent (:plans actor))) +;; actor)] +;; (eval ((first (:plans a’)) a’ world))))) diff --git a/src/cc/journeyman/the_great_game/lore/digester.clj b/src/cc/journeyman/the_great_game/lore/digester.clj index c6c227f..b7d2d54 100644 --- a/src/cc/journeyman/the_great_game/lore/digester.clj +++ b/src/cc/journeyman/the_great_game/lore/digester.clj @@ -1,4 +1,5 @@ (ns cc.journeyman.the-great-game.lore.digester - (:require [org.clojurenlp.core :refer [pos-tag sentenize split-sentences - tag-ner tokenize word - ]])) + ;; (:require [org.clojurenlp.core :refer [pos-tag sentenize split-sentences + ;; tag-ner tokenize word + ;; ]]) + )