diff --git a/doc/Biomes_and_ecology.md b/doc/Biomes_and_ecology.md deleted file mode 100644 index 2dd83d8..0000000 --- a/doc/Biomes_and_ecology.md +++ /dev/null @@ -1,130 +0,0 @@ -# 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 - - - - - diff --git a/doc/Canonical-dictionary.md b/doc/Canonical-dictionary.md index 681c67e..9d84640 100644 --- a/doc/Canonical-dictionary.md +++ b/doc/Canonical-dictionary.md @@ -25,11 +25,11 @@ A `heightmap` is a raster image of the world, such that the intensity in which a #### Holding -A `holding` is a polygon 'owned' by an `actor` on which are built appropriate building units representing the `actors` craft and status. +A `holding` is a polygon 'owned' by an `actor` on which are built appropriate building units representing the `actor`'s craft and status. #### 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. +A `location` value is a sequence comprising at most the x/y or x/y/z coordinate location and the ids of the settlement and region (possibly hierarchically) that contain the location. If the :z coordinate is not supplied the terrain surface hieght at that x/y location will be assumed. 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. diff --git a/doc/Division_of_tasks_between_server_and_client.md b/doc/Division_of_tasks_between_server_and_client.md index fd0ce96..c88fb78 100644 --- a/doc/Division_of_tasks_between_server_and_client.md +++ b/doc/Division_of_tasks_between_server_and_client.md @@ -1,4 +1,4 @@ -# Division of tasks between server and client +# Division of tasks between server and client (unfinished) 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. diff --git a/doc/Economy.md b/doc/Economy.md index f6d8dd9..1fb3af7 100644 --- a/doc/Economy.md +++ b/doc/Economy.md @@ -1,4 +1,4 @@ -# Game world economy +# Game world economy (unfinished) Broadly this essay extends ideas presented in [Populating a game world](Populating-a-game-world.html), q.v. diff --git a/doc/Game_Play.md b/doc/Game_Play.md index c3c6bac..334f0c5 100644 --- a/doc/Game_Play.md +++ b/doc/Game_Play.md @@ -1,4 +1,4 @@ -# Game Play +# Game Play (unfinished) 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: diff --git a/doc/Modelling_democracy_and_morale.md b/doc/Modelling_democracy_and_morale.md deleted file mode 100644 index df4c0ac..0000000 --- a/doc/Modelling_democracy_and_morale.md +++ /dev/null @@ -1,29 +0,0 @@ -# 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](the-great-game.gossip.gossip.html). \ No newline at end of file diff --git a/doc/Naming-of-characters.md b/doc/Naming-of-characters.md index 8ca8e80..e031691 100644 --- a/doc/Naming-of-characters.md +++ b/doc/Naming-of-characters.md @@ -1,5 +1,7 @@ # Naming of Characters +**See [`wherefore-art-thou`](https://github.com/simon-brooke/wherefore-art-thou)** + 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. diff --git a/doc/Not_my_problem.md b/doc/Not_my_problem.md index 5f3b6b7..d53e592 100644 --- a/doc/Not_my_problem.md +++ b/doc/Not_my_problem.md @@ -1,4 +1,4 @@ -# Not my problem +# Not my problem ## Introduction diff --git a/doc/Useful-software-libraries.md b/doc/Useful-software-libraries.md new file mode 100644 index 0000000..caf1b2e --- /dev/null +++ b/doc/Useful-software-libraries.md @@ -0,0 +1,16 @@ +# Useful software tools and libraries (open source) + +## Animation + +* [Papagayo](https://www.lostmarble.com/papagayo/) -- lipsync animator, not up to JALI standards, but not nothing! However, not apparently under active development, and in C++. + +## Procedural assets + +## Textures + +* [Poly Haven](https://polyhaven.com/) -- free textures, also HDRI lighting maps and some 3D models, although few look relevant. + +## Others + +* [Festival Speech Synthesis](https://www.cstr.ed.ac.uk/projects/festival/download.html) Text to speech library, in C++ but there's a Java transducer. +* [Mary TTS](https://github.com/marytts/marytts) Text to speech library, probably not as good as Festival diff --git a/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html b/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html index d7412d3..8e9adf1 100644 --- a/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html +++ b/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html @@ -1,6 +1,6 @@ -A Generic Planning Algorithm for craftworker NPCs

A Generic Planning Algorithm for craftworker NPCs

+A Generic Planning Algorithm for craftworker NPCs

A Generic Planning Algorithm for craftworker NPCs

Preamble

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

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

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

API Spec (unfinished)

+API Spec (unfinished)

API Spec (unfinished)

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

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

Tracking what happens in the world

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

Appraisal (unfinished)

+Appraisal (unfinished)

Appraisal (unfinished)

What is Appraisal

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

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

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

Baking the world

+Baking the world

Baking the world

Wednesday, 8 May 2019

Devorgilla's Bridge in Dumfries, early fourteenth century

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

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

Building on Microworld

+Building on Microworld

Building on Microworld

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

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

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

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

Canonical dictionary for this documentation

+Canonical dictionary for this documentation

Canonical dictionary for this documentation

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

Actor

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

@@ -16,9 +16,9 @@

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

-

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

+

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

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.

+

A location value is a sequence comprising at most the x/y or x/y/z coordinate location and the ids of the settlement and region (possibly hierarchically) that contain the location. If the :z coordinate is not supplied the terrain surface hieght at that x/y location will be assumed. 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

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

    Division of tasks between server and client

    +Division of tasks between server and client (unfinished)

    Division of tasks between server and client (unfinished)

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

    What do I mean by the ‘server’?

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

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

    On the consequences of a dynamic game environment for storytelling

    +On the consequences of a dynamic game environment for storytelling

    On the consequences of a dynamic game environment for storytelling

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

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

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

      Game world economy

      +Game world economy (unfinished)

      Game world economy (unfinished)

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

      Primary producers

      Herdsfolk

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

      Further Reading (and watching)

      +Further Reading (and watching)

      Further Reading (and watching)

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

      ## Modelling the natural environment

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

        Game Play

        +Game Play (unfinished)

        Game Play (unfinished)

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

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

          Genetic Buildings

          +Genetic Buildings

          Genetic Buildings

          Building selection based on location

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

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

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

          Gossip, scripted plot, and Johnny Silverhand

          +Gossip, scripted plot, and Johnny Silverhand

          Gossip, scripted plot, and Johnny Silverhand

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

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

            Minimum Viable Product, and a road map

            +Minimum Viable Product, and a road map

            Minimum Viable Product, and a road map

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

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

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

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

            The Red Company: modelling democracy and morale (unfinished)

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

            The Red Company: modelling democracy and morale (unfinished)

            Background

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

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

            diff --git a/docs/codox/Modelling_trading_cost_and_risk.html b/docs/codox/Modelling_trading_cost_and_risk.html index 21860b9..c939b2a 100644 --- a/docs/codox/Modelling_trading_cost_and_risk.html +++ b/docs/codox/Modelling_trading_cost_and_risk.html @@ -1,6 +1,6 @@ -Modelling trading cost and risk (unfinished)

            Modelling trading cost and risk (unfinished)

            +Modelling trading cost and risk (unfinished)

            Modelling trading cost and risk (unfinished)

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

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

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

            diff --git a/docs/codox/Naming-of-characters.html b/docs/codox/Naming-of-characters.html index 7d348c9..da20d20 100644 --- a/docs/codox/Naming-of-characters.html +++ b/docs/codox/Naming-of-characters.html @@ -1,6 +1,7 @@ -Naming of Characters

            Naming of Characters

            +Naming of Characters

            Naming of Characters

            +

            See wherefore-art-thou

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

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

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

            diff --git a/docs/codox/Not_my_problem.html b/docs/codox/Not_my_problem.html index fec3600..f0d0c2c 100644 --- a/docs/codox/Not_my_problem.html +++ b/docs/codox/Not_my_problem.html @@ -1,6 +1,6 @@ - Not my problem

            # Not my problem

            +Not my problem

            Not my problem

            Introduction

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

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

              On Dying, and Injury

              +On Dying, and Injury

              On Dying, and Injury

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

              So how could this be better handled?

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

              diff --git a/docs/codox/On-sex-and-sexual-violence.html b/docs/codox/On-sex-and-sexual-violence.html index 00f8de0..bf46b3c 100644 --- a/docs/codox/On-sex-and-sexual-violence.html +++ b/docs/codox/On-sex-and-sexual-violence.html @@ -1,6 +1,6 @@ -On Sex, and Sexual Violence, in Games

              On Sex, and Sexual Violence, in Games

              +On Sex, and Sexual Violence, in Games

              On Sex, and Sexual Violence, in Games

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

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

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

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

              Organic Quests

              +Organic Quests

              Organic Quests

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

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

                Pathmaking

                +Pathmaking

                Pathmaking

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

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

                Stages in creating routes between locations

                diff --git a/docs/codox/Populating-a-game-world.html b/docs/codox/Populating-a-game-world.html index b116480..11014b2 100644 --- a/docs/codox/Populating-a-game-world.html +++ b/docs/codox/Populating-a-game-world.html @@ -1,6 +1,6 @@ -Populating a game world

                Populating a game world

                +Populating a game world

                Populating a game world

                Saturday, 6 July 2013

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

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

                diff --git a/docs/codox/Pseudo-object-inheritance.html b/docs/codox/Pseudo-object-inheritance.html new file mode 100644 index 0000000..ec893c5 --- /dev/null +++ b/docs/codox/Pseudo-object-inheritance.html @@ -0,0 +1,6 @@ + +Pseudo object inheritance

                Pseudo object inheritance

                +

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

                +

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

                +
                \ No newline at end of file diff --git a/docs/codox/Roadmap.html b/docs/codox/Roadmap.html index d126339..b84e6da 100644 --- a/docs/codox/Roadmap.html +++ b/docs/codox/Roadmap.html @@ -1,6 +1,6 @@ -Roadmap (obsolete)

                Roadmap (obsolete)

                +Roadmap (obsolete)

                Roadmap (obsolete)

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

                NOTE: this document has been superceded.

                JMonkeyEngine

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

                Sandbox

                +Sandbox

                Sandbox

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

                Why?

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

                diff --git a/docs/codox/Selecting_Character.html b/docs/codox/Selecting_Character.html index 365ee92..2679aef 100644 --- a/docs/codox/Selecting_Character.html +++ b/docs/codox/Selecting_Character.html @@ -1,6 +1,6 @@ -Selecting the Player Character

                Selecting the Player Character

                +Selecting the Player Character

                Selecting the Player Character

                Background

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

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

                diff --git a/docs/codox/Settling-a-game-world.html b/docs/codox/Settling-a-game-world.html index 98052f5..5c23bb2 100644 --- a/docs/codox/Settling-a-game-world.html +++ b/docs/codox/Settling-a-game-world.html @@ -1,6 +1,6 @@ -Settling a game world

                Settling a game world

                +Settling a game world

                Settling a game world

                Wednesday, 30 December 2009

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

                Microworld

                diff --git a/docs/codox/Sexual-dimorphism.html b/docs/codox/Sexual-dimorphism.html index 59393d8..0f747d1 100644 --- a/docs/codox/Sexual-dimorphism.html +++ b/docs/codox/Sexual-dimorphism.html @@ -1,6 +1,6 @@ -Sexual dimorphism

                Sexual dimorphism

                +Sexual dimorphism

                Sexual dimorphism

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

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

                OK? Let’s start.

                diff --git a/docs/codox/Simulated-genetics.html b/docs/codox/Simulated-genetics.html index d5e9f2a..6a03f80 100644 --- a/docs/codox/Simulated-genetics.html +++ b/docs/codox/Simulated-genetics.html @@ -1,6 +1,6 @@ -Simulated Genetics

                Simulated Genetics

                +Simulated Genetics

                Simulated Genetics

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

                This note discusses how this might be done.

                The pseudo-genome

                diff --git a/docs/codox/Simulation-layers.html b/docs/codox/Simulation-layers.html index 31e0354..587fc48 100644 --- a/docs/codox/Simulation-layers.html +++ b/docs/codox/Simulation-layers.html @@ -1,6 +1,6 @@ -Simulation layers

                Simulation layers

                +Simulation layers

                Simulation layers

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

                That is to say there is

                An economy simulation

                diff --git a/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html b/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html index f4208d9..7d96f9a 100644 --- a/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html +++ b/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html @@ -1,6 +1,6 @@ -The spread of knowledge in a large game world

                The spread of knowledge in a large game world

                +The spread of knowledge in a large game world

                The spread of knowledge in a large game world

                Saturday, 26 April 2008

                Note

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

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

                Things Voice Interaction Enables

                +Things Voice Interaction Enables

                Things Voice Interaction Enables

                Organic quest routing

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

                But something much richer occurred to me.

                diff --git a/docs/codox/Tree-library-evaluation.html b/docs/codox/Tree-library-evaluation.html new file mode 100644 index 0000000..fb5c16c --- /dev/null +++ b/docs/codox/Tree-library-evaluation.html @@ -0,0 +1,52 @@ + +Tree library evaluation

                Tree library evaluation

                +

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

                +

                SimArboreal

                +

                Overview

                +

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

                +

                Licence

                +

                BSD-style licence.

                +

                Assessment

                +

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

                +

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

                +

                Tree3D

                +

                Overview

                +

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

                +

                Licence

                +

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

                +

                Assessment

                +

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

                +

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

                +

                Proctree.js

                +

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

                +

                Licence

                +

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

                +

                Assessment

                +

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

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

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

                +

                What none of the candidates offer

                +

                None of the candidates have

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

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

                +

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

                +

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

                +

                Conclusion

                +

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

                +
                \ No newline at end of file diff --git a/docs/codox/Uncanny_dialogue.html b/docs/codox/Uncanny_dialogue.html index bd58062..fd05628 100644 --- a/docs/codox/Uncanny_dialogue.html +++ b/docs/codox/Uncanny_dialogue.html @@ -1,6 +1,6 @@ -The Uncanny Valley, and dynamically generated dialogue

                The Uncanny Valley, and dynamically generated dialogue

                +The Uncanny Valley, and dynamically generated dialogue

                The Uncanny Valley, and dynamically generated dialogue

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

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

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

                diff --git a/docs/codox/Voice-acting-considered-harmful.html b/docs/codox/Voice-acting-considered-harmful.html index 01c4a4e..a3336b5 100644 --- a/docs/codox/Voice-acting-considered-harmful.html +++ b/docs/codox/Voice-acting-considered-harmful.html @@ -1,6 +1,6 @@ -Voice acting considered harmful

                Voice acting considered harmful

                +Voice acting considered harmful

                Voice acting considered harmful

                Wednesday, 25 February 2015

                The Witcher: Conversation with Kalkstein

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

                diff --git a/docs/codox/Worlds-and-flats.html b/docs/codox/Worlds-and-flats.html index 6cc6d8e..0c75f8f 100644 --- a/docs/codox/Worlds-and-flats.html +++ b/docs/codox/Worlds-and-flats.html @@ -1,6 +1,6 @@ -Worlds and flats [obsolete]

                Worlds and flats obsolete

                +Worlds and flats [obsolete]

                Worlds and flats obsolete

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

                Of Compartmented Worlds

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

                diff --git a/docs/codox/cc.journeyman.the-great-game.agent.agent.html b/docs/codox/cc.journeyman.the-great-game.agent.agent.html new file mode 100644 index 0000000..bf27988 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.agent.agent.html @@ -0,0 +1,24 @@ + +cc.journeyman.the-great-game.agent.agent documentation

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

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

                +

                ProtoAgent

                protocol

                An object which can act in the world

                +

                members

                act

                (act actor world circle)

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

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

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

                +

                hungry?

                (hungry? actor world circle)

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

                +

                pending-intentions

                (pending-intentions actor)

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

                +

                pending-scheduled-action?

                (pending-scheduled-action? actor world circle)

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

                +

                plan-fight-or-flight

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

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

                +

                plan-find-food

                (plan-find-food actor workd circle)

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

                +

                plan-find-rest

                (plan-find-rest actor workd circle)

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

                +

                plan-goal

                (plan-goal actor world circle)

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

                +

                plan-scheduled-action

                (plan-scheduled-action actor workd circle)

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

                +

                schedule

                (schedule actor)

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

                +

                threatened?

                (threatened? actor world circle)

                True if this actor is threatened in this world.

                +

                tired?

                (tired? actor world circle)

                True if this actor needs rest.

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

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

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

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

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

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

                plan-scheduled-action

                (plan-scheduled-action actor world circle)

                TODO: write docs

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

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

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

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

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

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

                Modules need to include

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

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

                  Build buildings with a generally rectangular floow plan.

                  +

                  Motivations

                  +

                  Right, the idea behind this namespace is many fold.

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

                  Key factors in the creation of a building

                  +

                  Holding

                  +

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

                  +

                  Terrain

                  +

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

                  +

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

                  +

                  Culture

                  +

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

                  +

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

                  +

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

                  +

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

                  +

                  Craft

                  +

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

                  +

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

                  +

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

                  +

                  *building-families*

                  dynamic

                  Families of buildings.

                  +

                  Each family has

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

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

                  +

                  *crafts*

                  dynamic

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

                  +

                  *cultures*

                  dynamic

                  Cultures which affect building families. TODO: placeholder

                  +

                  *terrain-types*

                  dynamic

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

                  +

                  build!

                  (build! holding terrain culture craft size)

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

                  +

                  building-family

                  (building-family terrain culture craft gene)

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

                  +
                  \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.character.sex.html b/docs/codox/cc.journeyman.the-great-game.character.sex.html new file mode 100644 index 0000000..d376ee3 --- /dev/null +++ b/docs/codox/cc.journeyman.the-great-game.character.sex.html @@ -0,0 +1,4 @@ + +cc.journeyman.the-great-game.character.sex documentation

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

                  TODO: write docs

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

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

                  Interchange of news events between gossip agents.

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

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

                  Interchange of news events between gossip agents.

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

                  Innkeepers are also gossip agents but do not typically move.

                  dialogue

                  (dialogue enquirer respondent world)

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

                  -

                  gather-news

                  (gather-news world gossip)

                  Gather news for the specified gossip in this world.

                  -

                  move-gossip

                  (move-gossip gossip world new-location)

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

                  -

                  run

                  (run world)

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

                  -
                  \ No newline at end of file +

                  gather-news

                  (gather-news world gossip)

                  Gather news for the specified gossip in this world.

                  +

                  move-gossip

                  (move-gossip gossip world new-location)

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

                  +

                  run

                  (run world)

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

                  +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html b/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html index 8e65b18..42cca60 100644 --- a/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html +++ b/docs/codox/cc.journeyman.the-great-game.gossip.news-items.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.gossip.news-items documentation

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

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

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

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

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

                Status

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

                Discussion

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

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

                all-known-verbs

                All verbs currently known to the gossip system.

                -

                compatible-item?

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

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

                +

                compatible-item?

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

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

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

                -

                compatible-value?

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

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

                +

                compatible-value?

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

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

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

                -

                degrade-character

                (degrade-character gossip character)

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

                -

                degrade-location

                (degrade-location gossip location)

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

                -

                degrade-news-item

                (degrade-news-item gossip item)

                TODO: write docs

                -

                infer

                (infer item rule)

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

                -

                interest-in-character

                (interest-in-character gossip character)

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

                -

                interest-in-location

                (interest-in-location gossip location)

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

                -

                interesting-character?

                (interesting-character? gossip character)

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

                -

                interesting-item?

                (interesting-item? gossip item)

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

                -

                interesting-location?

                (interesting-location? gossip location)

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

                -

                interesting-object?

                (interesting-object? gossip object)

                TODO: write docs

                -

                interesting-verb?

                (interesting-verb? gossip verb)

                Is this verb interesting to this gossip?

                -

                known-item?

                (known-item? gossip item)

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

                +

                degrade-character

                (degrade-character gossip character)

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

                +

                degrade-location

                (degrade-location gossip location)

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

                +

                degrade-news-item

                (degrade-news-item gossip item)

                TODO: write docs

                +

                infer

                (infer item rule)

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

                +

                interest-in-character

                (interest-in-character gossip character)

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

                +

                interest-in-location

                (interest-in-location gossip location)

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

                +

                interesting-character?

                (interesting-character? gossip character)

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

                +

                interesting-item?

                (interesting-item? gossip item)

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

                +

                interesting-location?

                (interesting-location? gossip location)

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

                +

                interesting-object?

                (interesting-object? gossip object)

                TODO: write docs

                +

                interesting-verb?

                (interesting-verb? gossip verb)

                Is this verb interesting to this gossip?

                +

                known-item?

                (known-item? gossip item)

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

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

                -

                learn-news-item

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

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

                -

                make-all-inferences

                (make-all-inferences item)

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

                -

                news-topics

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

                +

                learn-news-item

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

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

                +

                make-all-inferences

                (make-all-inferences item)

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

                +

                news-topics

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

                • actor is the id of the character who it is reported performed the action;
                • other is the id of the character on whom it is reported the action was performed;
                • @@ -51,4 +51,4 @@ This namespace at present considers the :knowledge of a gossip to b

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

                  Inferences

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

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

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

                TODO: write docs

                +

                ProtoHolding

                protocol

                members

                building-origin

                (building-origin holding)

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

                +

                frontage

                (frontage holding)

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

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

                cc.journeyman.the-great-game.launcher

                Launcher for the game

                +

                -main

                (-main & args)

                Launch the game.

                +

                app

                TODO: write docs

                +

                cli-options

                TODO: write docs

                +

                init

                (init)

                TODO: write docs

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

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

                TODO: write docs

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

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

                TODO: write docs

                ProtoLocation

                protocol

                members

                altitude

                (altitude location)

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

                easting

                (easting location)

                Return the easting of this location

                northing

                (northing location)

                Return the northing of this location

                settlement

                (settlement location)

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

                terrain-altitude

                (terrain-altitude location)

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

                -
                \ No newline at end of file +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.lore.digester.html b/docs/codox/cc.journeyman.the-great-game.lore.digester.html index e375cba..80405e8 100644 --- a/docs/codox/cc.journeyman.the-great-game.lore.digester.html +++ b/docs/codox/cc.journeyman.the-great-game.lore.digester.html @@ -1,4 +1,4 @@ -cc.journeyman.the-great-game.lore.digester documentation

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

                TODO: write docs

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

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

                TODO: write docs

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

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

                Adjusting quantities and prices in markets.

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

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

                Adjusting quantities and prices in markets.

                adjust-quantity-and-price

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

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

                -

                new-price

                (new-price old stock supply demand)

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

                -

                run

                (run world)

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

                -

                update-markets

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

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

                -
                \ No newline at end of file +

                new-price

                (new-price old stock supply demand)

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

                +

                run

                (run world)

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

                +

                update-markets

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

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html b/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html index b6d2926..b55c3f1 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.merchant-utils.html @@ -1,10 +1,10 @@ -cc.journeyman.the-great-game.merchants.merchant-utils documentation

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

                Useful functions for doing low-level things with merchants.

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

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

                Useful functions for doing low-level things with merchants.

                add-known-prices

                (add-known-prices merchant world)

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

                -

                add-stock

                (add-stock a b)

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

                -

                burden

                (burden merchant world)

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

                -

                can-afford

                (can-afford merchant world commodity)

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

                -

                can-carry

                (can-carry merchant world commodity)

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

                -

                expected-price

                (expected-price merchant commodity city)

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

                -
                \ No newline at end of file +

                add-stock

                (add-stock a b)

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

                +

                burden

                (burden merchant world)

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

                +

                can-afford

                (can-afford merchant world commodity)

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

                +

                can-carry

                (can-carry merchant world commodity)

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

                +

                expected-price

                (expected-price merchant commodity city)

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html b/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html index 04c53b4..2d46f86 100644 --- a/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html +++ b/docs/codox/cc.journeyman.the-great-game.merchants.merchants.html @@ -1,5 +1,5 @@ -cc.journeyman.the-great-game.merchants.merchants documentation

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

                Trade planning for merchants, primarily.

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

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

                Trade planning for merchants, primarily.

                run

                (run world)

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

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

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

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

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

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

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

                augment-plan

                (augment-plan merchant world plan)

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

                Returns the augmented plan.

                -

                generate-trade-plans

                (generate-trade-plans merchant world commodity)

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

                +

                generate-trade-plans

                (generate-trade-plans merchant world commodity)

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

                Returned plans are maps with keys:

                • :merchant - the id of the merchant for whom the plan was created;
                • @@ -15,8 +15,8 @@
                • :distance - the number of stages in the planned journey
                • :dist-to-home - the distance from destination to the merchant’s home city.
                -

                nearest-with-targets

                (nearest-with-targets plans targets)

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

                -

                plan-trade

                (plan-trade merchant world commodity)

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

                +

                nearest-with-targets

                (nearest-with-targets plans targets)

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

                +

                plan-trade

                (plan-trade merchant world commodity)

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

                The returned plan is a map with keys:

                • :merchant - the id of the merchant for whom the plan was created;
                • @@ -28,5 +28,5 @@
                • :distance - the number of stages in the planned journey
                • :dist-to-home - the distance from destination to the merchant’s home city.
                -

                select-cargo

                (select-cargo merchant world)

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

                -
                \ No newline at end of file +

                select-cargo

                (select-cargo merchant world)

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html b/docs/codox/cc.journeyman.the-great-game.merchants.strategies.simple.html index bdacf8c..6d9f9a3 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,9 +1,9 @@ -cc.journeyman.the-great-game.merchants.strategies.simple documentation

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

                Default trading strategy for merchants.

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

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

                Default trading strategy for merchants.

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

                move-merchant

                (move-merchant merchant world)

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

                -

                plan-and-buy

                (plan-and-buy merchant world)

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

                -

                re-plan

                (re-plan merchant world)

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

                -

                sell-and-buy

                (sell-and-buy merchant world)

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

                -
                \ No newline at end of file +

                plan-and-buy

                (plan-and-buy merchant world)

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

                +

                re-plan

                (re-plan merchant world)

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

                +

                sell-and-buy

                (sell-and-buy merchant world)

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.objects.character.html b/docs/codox/cc.journeyman.the-great-game.objects.character.html index 5bf31d2..d88f732 100644 --- a/docs/codox/cc.journeyman.the-great-game.objects.character.html +++ b/docs/codox/cc.journeyman.the-great-game.objects.character.html @@ -1,4 +1,4 @@ -cc.journeyman.the-great-game.objects.character documentation

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

                TODO: write docs

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

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

                TODO: write docs

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

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

                TODO: write docs

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

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

                TODO: write docs

                ProtoContainer

                protocol

                members

                contents

                (contents container)

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

                is-empty?

                (is-empty? container)

                Return true if this container is empty, else false.

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

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

                Anything at all in the game world

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

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

                Anything at all in the game world

                ProtoObject

                protocol

                An object in the world

                members

                id

                (id object)

                Returns the unique id of this object.

                reify-object

                (reify-object object)

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

                -
                \ No newline at end of file +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.playroom.html b/docs/codox/cc.journeyman.the-great-game.playroom.html index 5e176fc..286d2c4 100644 --- a/docs/codox/cc.journeyman.the-great-game.playroom.html +++ b/docs/codox/cc.journeyman.the-great-game.playroom.html @@ -1,7 +1,7 @@ -cc.journeyman.the-great-game.playroom documentation

                cc.journeyman.the-great-game.playroom

                TODO: write docs

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

                cc.journeyman.the-great-game.playroom

                TODO: write docs

                app

                TODO: write docs

                -

                init

                (init)

                TODO: write docs

                -

                simple-update

                (simple-update tpf)

                TODO: write docs

                -
                \ No newline at end of file +

                init

                (init)

                TODO: write docs

                +

                simple-update

                (simple-update tpf)

                TODO: write docs

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.proving.core.html b/docs/codox/cc.journeyman.the-great-game.proving.core.html index 6d9d500..667b734 100644 --- a/docs/codox/cc.journeyman.the-great-game.proving.core.html +++ b/docs/codox/cc.journeyman.the-great-game.proving.core.html @@ -1,11 +1,11 @@ -cc.journeyman.the-great-game.proving.core documentation

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

                Phase one of ‘Baking the World

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

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

                Phase one of ‘Baking the World

                *life-goals*

                dynamic

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

                -

                get-biome-map

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

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

                -

                get-drainage-map

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

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

                -

                get-road-map

                (get-road-map populated-world)

                TODO: write docs

                -

                populate-cell

                (populate-cell world cell)

                TODO: write docs

                -

                populate-world

                (populate-world biome-map)

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

                -

                prove

                (prove height-map rainfall-map)

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

                -
                \ No newline at end of file +

                get-biome-map

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

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

                +

                get-drainage-map

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

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

                +

                get-road-map

                (get-road-map _populated-world)

                TODO: write docs

                +

                populate-cell

                (populate-cell world cell)

                TODO: write docs

                +

                populate-world

                (populate-world biome-map)

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

                +

                prove

                (prove height-map rainfall-map)

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.proving.sketches.html b/docs/codox/cc.journeyman.the-great-game.proving.sketches.html index 936d86b..85c336b 100644 --- a/docs/codox/cc.journeyman.the-great-game.proving.sketches.html +++ b/docs/codox/cc.journeyman.the-great-game.proving.sketches.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.proving.sketches documentation

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

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

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

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

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

                couple-cell?

                (couple-cell? c)

                TODO: write docs

                -

                happy-cell?

                (happy-cell? c)

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

                -
                \ No newline at end of file +

                happy-cell?

                (happy-cell? c)

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

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

                cc.journeyman.the-great-game.time

                TODO: write docs

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

                cc.journeyman.the-great-game.time

                TODO: write docs

                canonical-ordering-of-houses

                The canonical ordering of religious houses.

                -

                date-string

                (date-string game-time)

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

                -

                day

                (day game-time)

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

                -

                day-of-year

                macro

                (day-of-year game-time)

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

                -

                days-in-season

                TODO: write docs

                -

                days-in-week

                This world has an eight day week.

                -

                days-of-week

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

                -

                game-day-length

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

                -

                game-start-time

                The start time of this run.

                -

                game-time

                (game-time)(game-time timestamp)

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

                -

                now

                (now)

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

                -

                season

                (season game-time)

                TODO: write docs

                -

                seasons-in-year

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

                -

                seasons-of-year

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

                -

                waiting-day?

                Does this game-time represent a waiting day?

                -

                week

                (week game-time)

                Week of season represented by this game-time.

                -

                weeks-in-season

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

                -

                weeks-of-season

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

                -
                \ No newline at end of file +

                date-string

                (date-string game-time)

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

                +

                day

                (day game-time)

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

                +

                day-of-year

                macro

                (day-of-year game-time)

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

                +

                days-in-season

                TODO: write docs

                +

                days-in-week

                This world has an eight day week.

                +

                days-of-week

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

                +

                game-day-length

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

                +

                game-start-time

                The start time of this run.

                +

                game-time

                (game-time)(game-time timestamp)

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

                +

                now

                (now)

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

                +

                season

                (season game-time)

                TODO: write docs

                +

                seasons-in-year

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

                +

                seasons-of-year

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

                +

                waiting-day?

                Does this game-time represent a waiting day?

                +

                week

                (week game-time)

                Week of season represented by this game-time.

                +

                weeks-in-season

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

                +

                weeks-of-season

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.utils.html b/docs/codox/cc.journeyman.the-great-game.utils.html index e13d5bd..51aa484 100644 --- a/docs/codox/cc.journeyman.the-great-game.utils.html +++ b/docs/codox/cc.journeyman.the-great-game.utils.html @@ -1,10 +1,10 @@ -cc.journeyman.the-great-game.utils documentation

                cc.journeyman.the-great-game.utils

                TODO: write docs

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

                cc.journeyman.the-great-game.utils

                TODO: write docs

                cyclic?

                (cyclic? route)

                True if two or more elements of route are identical

                -

                deep-merge

                (deep-merge & maps)

                inc-or-one

                (inc-or-one val)

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

                -

                make-target-filter

                (make-target-filter targets)

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

                -

                truthy?

                (truthy? val)

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

                -

                value-or-default

                (value-or-default m k dflt)

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

                -
                \ No newline at end of file +

                deep-merge

                (deep-merge & maps)

                inc-or-one

                (inc-or-one val)

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

                +

                make-target-filter

                (make-target-filter targets)

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

                +

                truthy?

                (truthy? val)

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

                +

                value-or-default

                (value-or-default m k dflt)

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

                +
                \ No newline at end of file diff --git a/docs/codox/cc.journeyman.the-great-game.world.heightmap.html b/docs/codox/cc.journeyman.the-great-game.world.heightmap.html index 438d843..3df9d59 100644 --- a/docs/codox/cc.journeyman.the-great-game.world.heightmap.html +++ b/docs/codox/cc.journeyman.the-great-game.world.heightmap.html @@ -1,14 +1,14 @@ -cc.journeyman.the-great-game.world.heightmap documentation

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

                Functions dealing with the tessellated multi-layer heightmap.

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

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

                Functions dealing with the tessellated multi-layer heightmap.

                *base-map*

                dynamic

                TODO: write docs

                -

                *noise-map*

                dynamic

                TODO: write docs

                -

                excerpt-grid

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

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

                -

                get-surface

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

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

                +

                *noise-map*

                dynamic

                TODO: write docs

                +

                excerpt-grid

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

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

                +

                get-surface

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

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

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

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

                -

                interpolate-altitude

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

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

                -

                interpolate-cell

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

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

                -

                interpolate-grid

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

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

                -

                scale-grid

                (scale-grid grid n)

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

                -
                \ No newline at end of file +

                interpolate-altitude

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

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

                +

                interpolate-cell

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

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

                +

                interpolate-grid

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

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

                +

                scale-grid

                (scale-grid grid n)

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

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

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

                Functions dealing with location in the world.

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

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

                Functions dealing with location in the world.

                distance-between

                (distance-between location-1 location-2)

                TODO: write docs

                -

                get-coords

                (get-coords location)

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

                -
                \ No newline at end of file +

                get-coords

                (get-coords location)

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

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

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

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

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

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

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

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

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

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

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

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

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

                find-route

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

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

                -

                find-routes

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

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

                -
                \ No newline at end of file +

                find-routes

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

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

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

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

                Access to data about the world

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

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

                Access to data about the world

                actual-price

                (actual-price world commodity city)

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

                -

                default-world

                A basic world for testing concepts

                -

                run

                (run world)(run world date)

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

                -
                \ No newline at end of file +

                default-world

                A basic world for testing concepts

                +

                run

                (run world)(run world date)

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

                +
                \ No newline at end of file diff --git a/docs/codox/index.html b/docs/codox/index.html index 86444b9..1bd603b 100644 --- a/docs/codox/index.html +++ b/docs/codox/index.html @@ -1,10 +1,15 @@ -The-great-game 0.1.3-SNAPSHOT

                The-great-game 0.1.3-SNAPSHOT

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

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

                Installation

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

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

                Topics

                Namespaces

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

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

                +The-great-game 0.1.3-SNAPSHOT

                The-great-game 0.1.3-SNAPSHOT

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

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

                Installation

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

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

                Topics

                Namespaces

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

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

                +

                Public variables and functions:

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

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

                Public variables and functions:

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

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

                +

                Public variables and functions:

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

                  Build buildings with a generally rectangular floow plan.

                  +

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

                  TODO: write docs

                  Public variables and functions:

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

                    Interchange of news events between gossip agents.

                    Public variables and functions:

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

                    TODO: write docs

                    +

                    Public variables and functions:

                    cc.journeyman.the-great-game.launcher

                    Launcher for the game

                    +

                    Public variables and functions:

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

                    TODO: write docs

                    Public variables and functions:

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

                    TODO: write docs

                    Public variables and functions:

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

                      Adjusting quantities and prices in markets.

                      Public variables and functions:

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

                      Useful functions for doing low-level things with merchants.

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

                      Introduction to the-great-game

                      +Introduction to the-great-game

                      Introduction to the-great-game

                      The Great Game

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

                      So, firstly, how does one characterise this game?

                      diff --git a/workspace.code-workspace b/workspace.code-workspace index 70eb5bf..7d34ea6 100644 --- a/workspace.code-workspace +++ b/workspace.code-workspace @@ -10,11 +10,14 @@ "path": "../jme-clj" }, { - "path": "../MicroWorld/mw-parser" + "path": "../../Documents/fiction/merchants-war-game" }, { "path": "../MicroWorld/mw-engine" }, + { + "path": "../MicroWorld/mw-parser" + }, { "path": "../speechio" }, @@ -26,12 +29,6 @@ }, { "path": "../wherefore-art-thou" - }, - { - "path": "../MicroWorld/mw-parser" - }, - { - "path": "../../Documents/fiction/merchants-war-game" } ], "settings": {