From 2bb7e1a87c8fcd8fe24519650695a3bd9d9ddce6 Mon Sep 17 00:00:00 2001 From: Simon Brooke Date: Mon, 10 Jun 2024 16:59:24 +0100 Subject: [PATCH] Still nothing playable, but updated and new documentation --- doc/3D-formats.md | 20 +-- docs/codox/3D-formats.html | 134 ++++++++++++++++++ ...anning-algorithm-for-craftworker-npcs.html | 2 +- docs/codox/API_Spec.html | 2 +- docs/codox/Appraisal.html | 2 +- docs/codox/Architecture.html | 2 +- docs/codox/Baking-the-world.html | 2 +- docs/codox/Biomes_and_ecology.html | 2 +- docs/codox/Building_on_microworld.html | 2 +- docs/codox/Canonical-dictionary.html | 2 +- ...on_of_tasks_between_server_and_client.html | 2 +- docs/codox/Dynamic-consequences.html | 2 +- docs/codox/Economy.html | 2 +- docs/codox/Further-reading.html | 12 +- docs/codox/Game_Play.html | 2 +- docs/codox/Genetic-buildings.html | 2 +- ...p_scripted_plot_and_Johnny_Silverhand.html | 2 +- docs/codox/MVP-Roadmap.html | 2 +- .../codox/Modelling_democracy_and_morale.html | 2 +- .../Modelling_trading_cost_and_risk.html | 2 +- docs/codox/Naming-of-characters.html | 2 +- docs/codox/Not_my_problem.html | 2 +- docs/codox/On-dying.html | 2 +- docs/codox/On-sex-and-sexual-violence.html | 2 +- docs/codox/Organic_Quests.html | 2 +- docs/codox/Pathmaking.html | 2 +- docs/codox/Populating-a-game-world.html | 2 +- docs/codox/Pseudo-object-inheritance.html | 2 +- docs/codox/Roadmap.html | 2 +- docs/codox/Sandbox.html | 2 +- docs/codox/Selecting_Character.html | 2 +- docs/codox/Settling-a-game-world.html | 2 +- docs/codox/Sexual-dimorphism.html | 2 +- docs/codox/Simulated-genetics.html | 2 +- docs/codox/Simulation-layers.html | 2 +- ...ad-of-knowledge-in-a-large-game-world.html | 2 +- .../Things_Voice_Interaction_Enables.html | 2 +- .../Towards-a-procedural-animation-api.html | 2 +- docs/codox/Tree-library-evaluation.html | 2 +- docs/codox/Uncanny_dialogue.html | 2 +- .../Voice-acting-considered-harmful.html | 2 +- docs/codox/Worlds-and-flats.html | 2 +- ...journeyman.the-great-game.agent.agent.html | 2 +- ...rneyman.the-great-game.agent.schedule.html | 2 +- ...eyman.the-great-game.buildings.module.html | 2 +- ....the-great-game.buildings.rectangular.html | 2 +- ...urneyman.the-great-game.character.sex.html | 2 +- ...urneyman.the-great-game.gossip.gossip.html | 2 +- ...yman.the-great-game.gossip.news-items.html | 2 +- ...eyman.the-great-game.holdings.holding.html | 2 +- ...cc.journeyman.the-great-game.launcher.html | 10 +- ...yman.the-great-game.location.location.html | 2 +- ...urneyman.the-great-game.lore.digester.html | 2 +- ...yman.the-great-game.merchants.markets.html | 2 +- ...e-great-game.merchants.merchant-utils.html | 2 +- ...man.the-great-game.merchants.planning.html | 2 +- ...yman.the-great-game.objects.character.html | 2 +- ...yman.the-great-game.objects.container.html | 2 +- ...an.the-great-game.objects.game-object.html | 2 +- ...cc.journeyman.the-great-game.playroom.html | 2 +- ...ourneyman.the-great-game.proving.core.html | 2 +- ...eyman.the-great-game.proving.sketches.html | 2 +- .../cc.journeyman.the-great-game.time.html | 2 +- .../cc.journeyman.the-great-game.utils.html | 2 +- ...neyman.the-great-game.world.heightmap.html | 2 +- ...rneyman.the-great-game.world.location.html | 2 +- ...cc.journeyman.the-great-game.world.mw.html | 2 +- ...ourneyman.the-great-game.world.routes.html | 2 +- ...journeyman.the-great-game.world.world.html | 2 +- docs/codox/index.html | 2 +- docs/codox/intro.html | 2 +- 71 files changed, 227 insertions(+), 83 deletions(-) create mode 100644 docs/codox/3D-formats.html diff --git a/doc/3D-formats.md b/doc/3D-formats.md index 6c81fed..e30a37c 100644 --- a/doc/3D-formats.md +++ b/doc/3D-formats.md @@ -13,7 +13,7 @@ XML formats are easy to parse; they're also reasonably easy to edit both as text 1. [3DXML](https://en.wikipedia.org/wiki/3DXML), a proprietary format owned by Dassault Systèmes; 2. [Collada](https://www.khronos.org/collada/), an open format apparently seen primarily as an unlossy interchange format between 3d applications; 3. [X3D](https://www.web3d.org/x3d/what-x3d/), an open format seen as the successor to (and much more prolix than) VRML; -4. Ogre 3D, a format designed for the [Ogre 3D game engine](https://www.ogre3d.org/) and now widely used in the jMonkeyEngine community, but for which I can find no documentation. +4. Ogre 3D, a format designed for the [Ogre 3D game engine](https://www.ogre3d.org/) and now widely used in the jMonkeyEngine community, but for which I can find no user-oriented documentation. ## JSON-based formats @@ -25,14 +25,14 @@ JSON is also easy to parse and to edit; the [glTF 2.0](https://www.khronos.org/g ## Features -| Name | XML | JSON | Blender | jME3 | Notes | -| -------------------------------------------- | ------- | ------- | ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ | -| [3DXML](https://en.wikipedia.org/wiki/3DXML) | ✓ | | [Unsupported](https://blenderartists.org/t/3dxml-importer/469975/2) | No | Proprietary; apparently, engineering oriented | -| [Collada](https://www.khronos.org/collada/) | ✓ | | Built in importer/exporter | [No](https://hub.jmonkeyengine.org/t/collada-io/46406) | Prolix, but sort-of interpretable and manageable. | -| [X3D](https://www.web3d.org/x3d/what-x3d/) | ✓ | | Built in importer/exporter | No | | -| [Ogre 3D](https://www.ogre3d.org/) | ✓ | | [Unsupported](https://github.com/OGRECave/blender2ogre) | [built in importer](https://javadoc.jmonkeyengine.org/v3.6.1-stable/com/jme3/scene/plugins/ogre/package-summary.html) | | -| [glTF 2.0](https://www.khronos.org/gltf/) | | ✓ | Built in importer/exporter | [built in importer](https://javadoc.jmonkeyengine.org/v3.6.1-stable/com/jme3/scene/plugins/gltf/package-summary.html) | On inspection, the glTF 2.0 files generated by Blender are thoroughly inscrutable. Although they are technically text files, they're essentially very thin wrappers around ascii-coded binary blobs. This doesn't look usable to me. | -| [VRML](https://en.wikipedia.org/wiki/VRML) | | | Apparently accepted by the X3D importer; no exporter | No | I couldn't make import of a sample file into Blender work. The import completed with no errors, but no objects appeared in the scene. | +| Name | XML | JSON | Blender | MakeHuman | jME3 | Notes | +| -------------------------------------------- | ------- | ------- | ------------------------------------------------------------ | --------- | ------------------------------------------------------------ | ------------------------------------------------------------ | +| [3DXML](https://en.wikipedia.org/wiki/3DXML) | ✓ | | [Unsupported](https://blenderartists.org/t/3dxml-importer/469975/2) | No | No | Proprietary; apparently, engineering oriented | +| [Collada](https://www.khronos.org/collada/) | ✓ | | Built in importer/exporter | Exporter | [No](https://hub.jmonkeyengine.org/t/collada-io/46406) | Prolix, but sort-of interpretable and manageable. | +| [X3D](https://www.web3d.org/x3d/what-x3d/) | ✓ | | Built in importer/exporter | No | No | | +| [Ogre 3D](https://www.ogre3d.org/) | ✓ | | [Unsupported](https://github.com/OGRECave/blender2ogre) | Exporter | [built in importer](https://javadoc.jmonkeyengine.org/v3.6.1-stable/com/jme3/scene/plugins/ogre/package-summary.html) | | +| [glTF 2.0](https://www.khronos.org/gltf/) | | ✓ | Built in importer/exporter | No | [built in importer](https://javadoc.jmonkeyengine.org/v3.6.1-stable/com/jme3/scene/plugins/gltf/package-summary.html) | On inspection, the glTF 2.0 files generated by Blender are thoroughly inscrutable. Although they are technically text files, they're essentially very thin wrappers around ascii-coded binary blobs. This doesn't look usable to me. | +| [VRML](https://en.wikipedia.org/wiki/VRML) | | | Apparently accepted by the X3D importer; no exporter | No | No | I couldn't make import of a sample file into Blender work. The import completed with no errors, but no objects appeared in the scene. | ## Discussion @@ -167,7 +167,7 @@ So... it's not obvious to me how I extract a piece of solid geometry, namely a c Nothing in this explicitly says it's a cube. But where we have two triangles with a common edge and a common normal, we know they form part of the same face; and, given that each of the distinct normals are either at right angles to, or in opposition to, each of the others, the boxiness is easily inferred. Finally, given all the edges are of the same length, we have a cube. -Although the [Ogre import/export add on](https://github.com/OGRECave/blender2ogre) is not supported by Blender, an exported cube can be successfully reimported into Blender. +Although the [Ogre import/export add on](https://github.com/OGRECave/blender2ogre) is not supported by Blender, an exported cube can be successfully reimported into Blender. However, although Blender can export the meshes of a model to Ogre format successfully, it fails to export the skeleton. However the MakeHuman Ogre exporter does successfully export the skeleton. The only documentation for Ogre 3D XML that I can find is [two DTDs here](https://github.com/OGRECave/ogre/tree/master/Tools/XMLConverter/docs), but, in fact, that is what I most need. diff --git a/docs/codox/3D-formats.html b/docs/codox/3D-formats.html new file mode 100644 index 0000000..6f2d9b9 --- /dev/null +++ b/docs/codox/3D-formats.html @@ -0,0 +1,134 @@ + +3D file formats

Project

Topics

Namespaces

3D file formats

+

I’m going to be doing a lot with programatically manipulated models. Therefore there’s a benefit to me in using a file format which is human-readable, and also easily parsed. Compactness is also a virtue, but it’s a virtue I can achieve by compressing human readable files, I think.

+

Loading time is an issue, but I will be loading relatively few models and manipulating them in memory to produce large numbers of variants, rather than loading a new model for every asset I wish to place. So both from the point of view of total disk space and from the point of view of performance, I think that formats which are optimised more towards my needs as a developer than to raw performance or storage size are probably justified.

+

Obviously jMonkeyEngine’s own .j3o format is something I can parse – because I have the native jMonkeyEngine libraries to do it – but it’s not something I can inspect or hand edit, so I’m unwilling at this stage to use it. As I understand it, it’s a file of serialised Java objects, which, if so, would make it relatively efficient to load.

+

XML formats

+

XML formats are easy to parse; they’re also reasonably easy to edit both as text files and as structured files. So my preference is to use them as a starting point for search. The obvious XML formats are

+
    +
  1. 3DXML, a proprietary format owned by Dassault Systèmes;
    2. +
  2. Collada, an open format apparently seen primarily as an unlossy interchange format between 3d applications;
    3. +
  3. X3D, an open format seen as the successor to (and much more prolix than) VRML;
    4. +
  4. Ogre 3D, a format designed for the Ogre 3D game engine and now widely used in the jMonkeyEngine community, but for which I can find no user-oriented documentation.
    5. +
+

JSON-based formats

+

JSON is also easy to parse and to edit; the glTF 2.0 standard, in its JSON/ASCII representation, is such a format.

+

Other text formats

+

VRML isn’t either XML or JSON, but it looks reasonably easy to parse.

+

Features

+ + + + + + + + + + + + +
Name XML JSON Blender MakeHuman jME3 Notes
3DXML ✓ Unsupported No No Proprietary; apparently, engineering oriented
Collada ✓ Built in importer/exporter Exporter No Prolix, but sort-of interpretable and manageable.
X3D ✓ Built in importer/exporter No No
Ogre 3D ✓ Unsupported Exporter built in importer
glTF 2.0 ✓ Built in importer/exporter No built in importer On inspection, the glTF 2.0 files generated by Blender are thoroughly inscrutable. Although they are technically text files, they’re essentially very thin wrappers around ascii-coded binary blobs. This doesn’t look usable to me.
VRML Apparently accepted by the X3D importer; no exporter No No I couldn’t make import of a sample file into Blender work. The import completed with no errors, but no objects appeared in the scene.
+

Discussion

+

I did not investigate 3DXML, because I’m not going to sign up to even a free licence from an armaments company.

+

Of the rest: I’m pretty disappointed.

+

glTF

+

glTF might as well be a binary format; it’s unusable for my purposes.

+

X3D

+

X3D export of the simple cube from Blender results in a file which is readable, but which does not have explicit vertices or edges. Instead it has an attribute whose value is a string representation of a sequence of 24 numbers:

+
<Coordinate DEF="coords_ME_Cube"
+			point="1.000000 1.000000 1.000000 1.000000 1.000000 -1.000000 1.000000 -1.000000 1.000000 1.000000 -1.000000 -1.000000 -1.000000 1.000000 1.000000 -1.000000 1.000000 -1.000000 -1.000000 -1.000000 1.000000 -1.000000 -1.000000 -1.000000 "/>
+
+

I’m confidently assuming that that sequence is expected to be read as a set of six triples, each triple representing a vertex with x, y, z coordinates; but it’s not at all clear to me how edges and faces are encoded.

+

Furthermore, when you reimport an X3D file exported by Blender back into Blender you get nothing visible (and no error message). This is exactly the same as what you get when you import a VRML file, which does not raise confidence.

+

Collada

+

Collada is a little better in that it explicitly says how many numbers are in the array, and does not present them as an attribute but as data; additionally, it has information on how to decode that data into tuples:

+
        <source id="Cube-mesh-positions">
+          <float_array id="Cube-mesh-positions-array" count="24">1 1 1 1 1 -1 1 -1 1 1 -1 -1 -1 1 1 -1 1 -1 -1 -1 1 -1 -1 -1</float_array>
+          <technique_common>
+            <accessor source="#Cube-mesh-positions-array" count="8" stride="3">
+              <param name="X" type="float"/>
+              <param name="Y" type="float"/>
+              <param name="Z" type="float"/>
+            </accessor>
+          </technique_common>
+        </source>
+
+
+

and the vertices are declared as being the points in this array:

+
        <vertices id="Cube-mesh-vertices">
+          <input semantic="POSITION" source="#Cube-mesh-positions"/>
+        </vertices>
+
+
+

but again there’s nothing obvious to indicate which vertices are joined by edges. There is an array of six normals, which presumably imply the faces of the cube, but that’s a little sketchy. There are also triangles, declared as follows:

+
        <triangles material="Material-material" count="12">
+          <input semantic="VERTEX" source="#Cube-mesh-vertices" offset="0"/>
+          <input semantic="NORMAL" source="#Cube-mesh-normals" offset="1"/>
+          <input semantic="TEXCOORD" source="#Cube-mesh-map-0" offset="2" set="0"/>
+          <p>4 0 0 2 0 1 0 0 2 2 1 3 7 1 4 3 1 5 6 2 6 5 2 7 7 2 8 1 3 9 7 3 10 5 3 11 0 4 12 3 4 13 1 4 14 4 5 15 1 5 16 5 5 17 4 0 18 6 0 19 2 0 20 2 1 21 6 1 22 7 1 23 6 2 24 4 2 25 5 2 26 1 3 27 3 3 28 7 3 29 0 4 30 2 4 31 3 4 32 4 5 33 0 5 34 1 5 35</p>
+        </triangles>
+
+

H’mmm… Twelve triangles makes sense for six square faces, but there are 108 numbers in that <p> element, which is eighteen numbers per triangle; and since the highest number is 35, they’re not indices into either the Cube-mesh-vertices (8) or the Cube-mesh-normals (6) arrays, so that implies they are indices into Cube-mesh-map-0, which does have 36 entries…

+
        <source id="Cube-mesh-map-0">
+          <float_array id="Cube-mesh-map-0-array" count="72">0.875 0.5 0.625 0.75 0.625 0.5 0.625 0.75 0.375 1 0.375 0.75 0.625 0 0.375 0.25 0.375 0 0.375 0.5 0.125 0.75 0.125 0.5 0.625 0.5 0.375 0.75 0.375 0.5 0.625 0.25 0.375 0.5 0.375 0.25 0.875 0.5 0.875 0.75 0.625 0.75 0.625 0.75 0.625 1 0.375 1 0.625 0 0.625 0.25 0.375 0.25 0.375 0.5 0.375 0.75 0.125 0.75 0.625 0.5 0.625 0.75 0.375 0.75 0.625 0.25 0.625 0.5 0.375 0.5</float_array>
+          <technique_common>
+            <accessor source="#Cube-mesh-map-0-array" count="36" stride="2">
+              <param name="S" type="float"/>
+              <param name="T" type="float"/>
+            </accessor>
+          </technique_common>
+        </source>
+
+

which is six entries per face. Which sort of makes sense. But the numbers make no obvious sense to me. There are nine distinct values:

+
user=> (def s (set [0.875 0.5 0.625 0.75 0.625 0.5 0.625 0.75 0.375 1 0.375 0.75 0.625 0 0.375 0.25 0.375 0 0.375 0.5 0.125 0.75 0.125 0.5 0.625 0.5 0.375 0.75 0.375 0.5 0.625 0.25 0.375 0.5 0.375 0.25 0.875 0.5 0.875 0.75 0.625 0.75 0.625 0.75 0.625 1 0.375 1 0.625 0 0.625 0.25 0.375 0.25 0.375 0.5 0.375 0.75 0.125 0.75 0.625 0.5 0.625 0.75 0.375 0.75 0.625 0.25 0.625 0.5 0.375 0.5]))
+#'user/s
+user=> s
+#{0 0.125 0.25 0.5 0.625 0.375 0.75 0.875 1}
+user=> (sort s)
+(0 0.125 0.25 0.375 0.5 0.625 0.75 0.875 1)
+
+

But there’s no obvious pattern to how frequently these values occur:

+
user=> (map (fn [i] (count (filter (fn [j] (= i j)) all-values))) s)
+(3 3 6 12 15 15 12 3 3)
+
+

So… it’s not obvious to me how I extract a piece of solid geometry, namely a cube with sides of length 2, centred on the origin, from this data. I know it can be done, because when Blender reimports the file it not only renders a cube but recognises it as a cube; but it isn’t trivial.

+

Ogre 3D

+

Ogre 3D is a lot clearer. Here is (part of) its attempt at saving the cube:

+
<mesh>
+    <sharedgeometry vertexcount="24">
+        <vertexbuffer colours_diffuse="False" normals="true" positions="true" tangent_dimensions="0" tangents="False" texture_coords="1">
+            <vertex>
+                <position x="1.000000" y="1.000000" z="-1.000000"/>
+                <normal x="0.000000" y="1.000000" z="-0.000000"/>
+                <texcoord u="0.625000" v="0.500000"/>
+            </vertex>
+            <vertex>
+                <position x="-1.000000" y="1.000000" z="1.000000"/>
+                <normal x="0.000000" y="1.000000" z="-0.000000"/>
+                <texcoord u="0.875000" v="0.250000"/>
+            </vertex>
+			...
+        </vertexbuffer>
+    </sharedgeometry>
+    <submeshes>
+        <submesh material="Material" operationtype="triangle_list" use32bitindexes="False" usesharedvertices="true">
+            <faces count="12">
+                <face v1="0" v2="1" v3="2"/>
+                <face v1="3" v2="4" v3="5"/>
+                ...
+            </faces>
+        </submesh>
+    </submeshes>
+    <submeshnames>
+        <submesh index="0" name="Material"/>
+    </submeshnames>
+</mesh>
+
+

Nothing in this explicitly says it’s a cube. But where we have two triangles with a common edge and a common normal, we know they form part of the same face; and, given that each of the distinct normals are either at right angles to, or in opposition to, each of the others, the boxiness is easily inferred. Finally, given all the edges are of the same length, we have a cube.

+

Although the Ogre import/export add on is not supported by Blender, an exported cube can be successfully reimported into Blender. However, although Blender can export the meshes of a model to Ogre format successfully, it fails to export the skeleton. However the MakeHuman Ogre exporter does successfully export the skeleton.

+

The only documentation for Ogre 3D XML that I can find is two DTDs here, but, in fact, that is what I most need.

+

Summary

+

Generally, this is disappointing. I may need to rethink my approach. But, although I was initially prejudiced against Ogre 3D because of its relative obscurity and lack of user-oriented documentation, it is probably the best of the bunch.

+
\ No newline at end of file diff --git a/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html b/docs/codox/A-generic-planning-algorithm-for-craftworker-npcs.html index a807c3c..c386636 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

Project

Topics

Namespaces

A Generic Planning Algorithm for craftworker NPCs

+A Generic Planning Algorithm for craftworker NPCs

Project

Topics

Namespaces

A Generic Planning Algorithm for craftworker NPCs

Preamble

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

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

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

Project

Topics

Namespaces

API Spec (unfinished)

+API Spec (unfinished)

Project

Topics

Namespaces

API Spec (unfinished)

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

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

Tracking what happens in the world

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

Project

Topics

Namespaces

Appraisal (unfinished)

+Appraisal (unfinished)

Project

Topics

Namespaces

Appraisal (unfinished)

What is Appraisal

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

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

diff --git a/docs/codox/Architecture.html b/docs/codox/Architecture.html index 66a7cdd..a403c7c 100644 --- a/docs/codox/Architecture.html +++ b/docs/codox/Architecture.html @@ -1,6 +1,6 @@ -Architecture

Project

Topics

Namespaces

Architecture

+Architecture

Project

Topics

Namespaces

Architecture

OK, the basic idea is this

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

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

diff --git a/docs/codox/Baking-the-world.html b/docs/codox/Baking-the-world.html index 08ae24e..5c721a0 100644 --- a/docs/codox/Baking-the-world.html +++ b/docs/codox/Baking-the-world.html @@ -1,6 +1,6 @@ -Baking the world

Project

Topics

Namespaces

Baking the world

+Baking the world

Project

Topics

Namespaces

Baking the world

Wednesday, 8 May 2019

Devorgilla's Bridge in Dumfries, early fourteenth century

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

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

Project

Topics

Namespaces

Biomes and ecology (unfinished)

+Biomes and ecology (unfinished)

Project

Topics

Namespaces

Biomes and ecology (unfinished)

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

Broader geography

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

diff --git a/docs/codox/Building_on_microworld.html b/docs/codox/Building_on_microworld.html index 3cd4c9b..32ee6ba 100644 --- a/docs/codox/Building_on_microworld.html +++ b/docs/codox/Building_on_microworld.html @@ -1,6 +1,6 @@ -Building on Microworld

Project

Topics

Namespaces

Building on Microworld

+Building on Microworld

Project

Topics

Namespaces

Building on Microworld

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

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

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

diff --git a/docs/codox/Canonical-dictionary.html b/docs/codox/Canonical-dictionary.html index b127fe6..5b34df6 100644 --- a/docs/codox/Canonical-dictionary.html +++ b/docs/codox/Canonical-dictionary.html @@ -1,6 +1,6 @@ -Canonical dictionary for this documentation

Project

Topics

Namespaces

Canonical dictionary for this documentation

+Canonical dictionary for this documentation

Project

Topics

Namespaces

Canonical dictionary for this documentation

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

Actor

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

diff --git a/docs/codox/Division_of_tasks_between_server_and_client.html b/docs/codox/Division_of_tasks_between_server_and_client.html index 36e4774..c2cbcdd 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

Project

Topics

Namespaces

Division of tasks between server and client

+Division of tasks between server and client

Project

Topics

Namespaces

Division of tasks between server and client

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

What do I mean by the ‘server’?

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

diff --git a/docs/codox/Dynamic-consequences.html b/docs/codox/Dynamic-consequences.html index 950640a..b820457 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

Project

Topics

Namespaces

On the consequences of a dynamic game environment for storytelling

+On the consequences of a dynamic game environment for storytelling

Project

Topics

Namespaces

On the consequences of a dynamic game environment for storytelling

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

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

    diff --git a/docs/codox/Economy.html b/docs/codox/Economy.html index 6333526..37a2e66 100644 --- a/docs/codox/Economy.html +++ b/docs/codox/Economy.html @@ -1,6 +1,6 @@ -Game world economy

    Project

    Topics

    Namespaces

    Game world economy

    +Game world economy

    Project

    Topics

    Namespaces

    Game world economy

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

    Primary producers

    Herdsfolk

    diff --git a/docs/codox/Further-reading.html b/docs/codox/Further-reading.html index 52d891c..0c10ec6 100644 --- a/docs/codox/Further-reading.html +++ b/docs/codox/Further-reading.html @@ -1,13 +1,23 @@ -Further Reading (and watching)

    Project

    Topics

    Namespaces

    Further Reading (and watching)

    +Further Reading (and watching)

    Project

    Topics

    Namespaces

    Further Reading (and watching)

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

    ## Modelling the natural environment

    +

    Forests

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

    Water

    +
      +
    1. Effective Water Simulation from Physical Models
      2. +
    2. Modelling Ocean Water
      3. +

    Systemic games

    1. This video is thought provoking with excellent examples.
    +

    Procedural animation

    +
      +
    1. This video builds really impressive character animation on extremely simple foundations. I’m not saying this is easy, but it looks doable.
      2. +
    \ No newline at end of file diff --git a/docs/codox/Game_Play.html b/docs/codox/Game_Play.html index 292aa0e..cb58e6c 100644 --- a/docs/codox/Game_Play.html +++ b/docs/codox/Game_Play.html @@ -1,6 +1,6 @@ -Game Play

    Project

    Topics

    Namespaces

    Game Play

    +Game Play

    Project

    Topics

    Namespaces

    Game Play

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

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

      Project

      Topics

      Namespaces

      Genetic Buildings

      +Genetic Buildings

      Project

      Topics

      Namespaces

      Genetic Buildings

      Building selection based on location

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

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

      diff --git a/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html b/docs/codox/Gossip_scripted_plot_and_Johnny_Silverhand.html index b911c5a..56a783d 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

      Project

      Topics

      Namespaces

      Gossip, scripted plot, and Johnny Silverhand

      +Gossip, scripted plot, and Johnny Silverhand

      Project

      Topics

      Namespaces

      Gossip, scripted plot, and Johnny Silverhand

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

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

        Project

        Topics

        Namespaces

        Minimum Viable Product, and a road map

        +Minimum Viable Product, and a road map

        Project

        Topics

        Namespaces

        Minimum Viable Product, and a road map

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

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

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

        diff --git a/docs/codox/Modelling_democracy_and_morale.html b/docs/codox/Modelling_democracy_and_morale.html index 200186f..a052ceb 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)

        Project

        Topics

        Namespaces

        The Red Company: modelling democracy and morale (unfinished)

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

        Project

        Topics

        Namespaces

        The Red Company: modelling democracy and morale (unfinished)

        Background

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

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

        diff --git a/docs/codox/Modelling_trading_cost_and_risk.html b/docs/codox/Modelling_trading_cost_and_risk.html index 4e9f110..a3818b0 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)

        Project

        Topics

        Namespaces

        Modelling trading cost and risk (unfinished)

        +Modelling trading cost and risk (unfinished)

        Project

        Topics

        Namespaces

        Modelling trading cost and risk (unfinished)

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

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

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

        diff --git a/docs/codox/Naming-of-characters.html b/docs/codox/Naming-of-characters.html index 769216d..bfc3110 100644 --- a/docs/codox/Naming-of-characters.html +++ b/docs/codox/Naming-of-characters.html @@ -1,6 +1,6 @@ -Naming of Characters

        Project

        Topics

        Namespaces

        Naming of Characters

        +Naming of Characters

        Project

        Topics

        Namespaces

        Naming of Characters

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

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

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

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

        Project

        Topics

        Namespaces

        # Not my problem

        + Not my problem

        Project

        Topics

        Namespaces

        # Not my problem

        Introduction

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

          diff --git a/docs/codox/On-dying.html b/docs/codox/On-dying.html index beb620a..6bf6de6 100644 --- a/docs/codox/On-dying.html +++ b/docs/codox/On-dying.html @@ -1,6 +1,6 @@ -On Dying, and Injury

          Project

          Topics

          Namespaces

          On Dying, and Injury

          +On Dying, and Injury

          Project

          Topics

          Namespaces

          On Dying, and Injury

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

          So how could this be better handled?

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

          diff --git a/docs/codox/On-sex-and-sexual-violence.html b/docs/codox/On-sex-and-sexual-violence.html index f37a03d..3683b1b 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

          Project

          Topics

          Namespaces

          On Sex, and Sexual Violence, in Games

          +On Sex, and Sexual Violence, in Games

          Project

          Topics

          Namespaces

          On Sex, and Sexual Violence, in Games

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

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

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

          diff --git a/docs/codox/Organic_Quests.html b/docs/codox/Organic_Quests.html index 9e5ec68..1f6dac8 100644 --- a/docs/codox/Organic_Quests.html +++ b/docs/codox/Organic_Quests.html @@ -1,6 +1,6 @@ -Organic Quests

          Project

          Topics

          Namespaces

          Organic Quests

          +Organic Quests

          Project

          Topics

          Namespaces

          Organic Quests

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

          1. Kill quests
            2. diff --git a/docs/codox/Pathmaking.html b/docs/codox/Pathmaking.html index 19f4c87..9d96302 100644 --- a/docs/codox/Pathmaking.html +++ b/docs/codox/Pathmaking.html @@ -1,6 +1,6 @@ -Pathmaking

            Project

            Topics

            Namespaces

            Pathmaking

            +Pathmaking

            Project

            Topics

            Namespaces

            Pathmaking

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

            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 82f31ee..8d3232d 100644 --- a/docs/codox/Populating-a-game-world.html +++ b/docs/codox/Populating-a-game-world.html @@ -1,6 +1,6 @@ -Populating a game world

            Project

            Topics

            Namespaces

            Populating a game world

            +Populating a game world

            Project

            Topics

            Namespaces

            Populating a game world

            Saturday, 6 July 2013

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

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

            diff --git a/docs/codox/Pseudo-object-inheritance.html b/docs/codox/Pseudo-object-inheritance.html index 229f55a..f65f35b 100644 --- a/docs/codox/Pseudo-object-inheritance.html +++ b/docs/codox/Pseudo-object-inheritance.html @@ -1,6 +1,6 @@ -Pseudo object inheritance

            Project

            Topics

            Namespaces

            Pseudo object inheritance

            +Pseudo object inheritance

            Project

            Topics

            Namespaces

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

            Project

            Topics

            Namespaces

            Roadmap (obsolete)

            +Roadmap (obsolete)

            Project

            Topics

            Namespaces

            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 6d3d507..b3bf5dc 100644 --- a/docs/codox/Sandbox.html +++ b/docs/codox/Sandbox.html @@ -1,6 +1,6 @@ -Sandbox

            Project

            Topics

            Namespaces

            Sandbox

            +Sandbox

            Project

            Topics

            Namespaces

            Sandbox

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

            Why?

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

            diff --git a/docs/codox/Selecting_Character.html b/docs/codox/Selecting_Character.html index 0b2519c..a921897 100644 --- a/docs/codox/Selecting_Character.html +++ b/docs/codox/Selecting_Character.html @@ -1,6 +1,6 @@ -Selecting the Player Character

            Project

            Topics

            Namespaces

            Selecting the Player Character

            +Selecting the Player Character

            Project

            Topics

            Namespaces

            Selecting the Player Character

            Background

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

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

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

            Project

            Topics

            Namespaces

            Settling a game world

            +Settling a game world

            Project

            Topics

            Namespaces

            Settling a game world

            Wednesday, 30 December 2009

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

            Microworld

            diff --git a/docs/codox/Sexual-dimorphism.html b/docs/codox/Sexual-dimorphism.html index d443b22..c83ab79 100644 --- a/docs/codox/Sexual-dimorphism.html +++ b/docs/codox/Sexual-dimorphism.html @@ -1,6 +1,6 @@ -Sexual dimorphism

            Project

            Topics

            Namespaces

            Sexual dimorphism

            +Sexual dimorphism

            Project

            Topics

            Namespaces

            Sexual dimorphism

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

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

            OK? Let’s start.

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

            Project

            Topics

            Namespaces

            Simulated Genetics

            +Simulated Genetics

            Project

            Topics

            Namespaces

            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 3fc967e..c942609 100644 --- a/docs/codox/Simulation-layers.html +++ b/docs/codox/Simulation-layers.html @@ -1,6 +1,6 @@ -Simulation layers

            Project

            Topics

            Namespaces

            Simulation layers

            +Simulation layers

            Project

            Topics

            Namespaces

            Simulation layers

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

            That is to say there is

            An economy simulation

            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 5d935da..8a66759 100644 --- a/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html +++ b/docs/codox/The-spread-of-knowledge-in-a-large-game-world.html @@ -1,6 +1,6 @@ -The spread of knowledge in a large game world

            Project

            Topics

            Namespaces

            The spread of knowledge in a large game world

            +The spread of knowledge in a large game world

            Project

            Topics

            Namespaces

            The spread of knowledge in a large game world

            Saturday, 26 April 2008

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

            Project

            Topics

            Namespaces

            Things Voice Interaction Enables

            +Things Voice Interaction Enables

            Project

            Topics

            Namespaces

            Things Voice Interaction Enables

            Organic quest routing

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

            But something much richer occurred to me.

            diff --git a/docs/codox/Towards-a-procedural-animation-api.html b/docs/codox/Towards-a-procedural-animation-api.html index 88606eb..e37f6dd 100644 --- a/docs/codox/Towards-a-procedural-animation-api.html +++ b/docs/codox/Towards-a-procedural-animation-api.html @@ -1,6 +1,6 @@ -Towards a procedural animation API

            Project

            Topics

            Namespaces

            Towards a procedural animation API

            +Towards a procedural animation API

            Project

            Topics

            Namespaces

            Towards a procedural animation API

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

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

            diff --git a/docs/codox/Tree-library-evaluation.html b/docs/codox/Tree-library-evaluation.html index 4893a77..bff9293 100644 --- a/docs/codox/Tree-library-evaluation.html +++ b/docs/codox/Tree-library-evaluation.html @@ -1,6 +1,6 @@ -Tree library evaluation

            Project

            Topics

            Namespaces

            Tree library evaluation

            +Tree library evaluation

            Project

            Topics

            Namespaces

            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

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

            Project

            Topics

            Namespaces

            The Uncanny Valley, and dynamically generated dialogue

            +The Uncanny Valley, and dynamically generated dialogue

            Project

            Topics

            Namespaces

            The Uncanny Valley, and dynamically generated dialogue

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

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

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

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

            Project

            Topics

            Namespaces

            Voice acting considered harmful

            +Voice acting considered harmful

            Project

            Topics

            Namespaces

            Voice acting considered harmful

            Wednesday, 25 February 2015

            The Witcher: Conversation with Kalkstein

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

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

            Project

            Topics

            Namespaces

            Worlds and flats obsolete

            +Worlds and flats [obsolete]

            Project

            Topics

            Namespaces

            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 index d0abdca..bfa365a 100644 --- a/docs/codox/cc.journeyman.the-great-game.agent.agent.html +++ b/docs/codox/cc.journeyman.the-great-game.agent.agent.html @@ -1,6 +1,6 @@ -cc.journeyman.the-great-game.agent.agent documentation

            Project

            Topics

            Namespaces

            Public Vars

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

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

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

            Project

            Topics

            Namespaces

            Public Vars

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

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

            ProtoAgent

            protocol

            An object which can act in the world

            members

            act

            (act actor world circle)

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