Merging changes made on Mason over those made on Illuminator

Only file really affected is buildings/rectangular.clk

.gitignore

@@ -18,6 +18,8 @@ pom.xml.asc
 .lein-failures
 .nrepl-port
 .cpcache/
+.calva/
+.idea/
 *~
 
 
@@ -25,4 +27,14 @@ pom.xml.asc
 .settings/
 .project
 
+.lsp/sqlite.db
+
+libbulletjme.so
+
+liblwjgl64.so
+
+libopenal64.so
+
+.settings/
 .classpath
+.project

doc/Canonical-dictionary.md

@@ -0,0 +1,55 @@
+# A Canonical dictionary for this documentation
+
+Where a word is used in the documentation for The Great Game and its related projects, this file describes the canonical meaning of that word. This is because a lot of the concepts in play are messy and ambiguous, so that at times even I am confused by what I mean. The presence of this file is an acknowledment of this difficulty, and an implicit admission that not all the documentation is, at this stage anyway, consistent.
+
+#### Actor
+
+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](#God_mode), if implemented, the player can inhabit any actor within the game world.
+
+#### Agent
+
+`Agent` is probably just a synonym for `actor`. If it is different in any way, that way has not yet been determined.
+
+#### Gossip
+
+A `gossip` is an `actor` who exchanges news with other `actors`, even when the player character is not nearby. Thus `gossips` are the mechanism by which news propagates through the game world, and also the mechanism by which information degrades. Broadly:
+
+1. `innkeepers` (and possibly some others) are `gossips` who do not move; rather, they gather information from gossips who do move, and all `non-player characters` local to the are deemed to know everything that their local `innkeeper` knows;
+2. `merchants` (and possibly some others) are `gossips` who do move from place to place, and thus transfer news.
+
+See [the spread of knowledge in a large game world](The-spread-of-knowledge-in-large-game.html).
+
+#### 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.
+
+#### Location
+
+A `location` value is a sequence comprising at most the x/y coordinate location and the ids of the settlement and region (possibly hierarchically) that contain the location. If the x/y is not local to the home of the receiving agent, they won't remember it and won't pass it on; if any of the ids are not interesting, they won't be passed on. So location information will degrade progressively as the item is passed along.
+
+It is assumed that the `:home` of a character is a location in this sense.
+
+**Examples**
+
+1. [{:x 5445678 :y 9684351}]
+2. [{:x 5445678 :y 9684351} :karalin-palace :hanshua]
+
+#### Merchant
+
+A `merchant` is an `actor` and `gossip` who trades goods, and incidentally conveys news, between `markets`.
+
+#### Non-player character
+
+A `non-player character` is, for our purposes, an `actor` capable of engaging in conversation with the `player character`. Note, however, that, from a software point of view, the `player character` is just a special case of a `non-player character`.
+
+#### Player character
+
+The `player character` is the unique `actor` within the game currently controlled and inhabited by the player. 
+
+#### Route
+
+A `route` is a pre-prepared path through the game world that an `actor` may take. Most `actors` are not constrained to follow `routes`, but in general `routes` have lower traversal cost than other terrain.

doc/Gossip_scripted_plot_and_Johnny_Silverhand.md

@@ -1,6 +1,6 @@
 # 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,
+I've been writing literally for years -- since [Voice acting considered harmful](Voice-acting-considered-harmful.html) 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. A decision on whether to co-operate based on the particular NPC's general demeanor and particular attitude to the player;

doc/Organic_Quests.md

@@ -12,14 +12,14 @@ The structure of a modern Role Playing Came revolves around 'quests': tasks that
 
 'Gather quests' are more frequently referred to in the literature as 'fetch quests', and 'kill quests' are simply a specialised form of fetch quest where the item to be fetched is a trophy of the kill. And the trophy could be just the knowledge that the kill has happened. A delivery quest is a sort of reverse fetch quest: instead of going to some location or NPC and getting a specific item to return to the quest giver, the player is tasked to take a specific item from the quest giver to some location or NPC.
 
-Note, however, that if we consider a delivery quest to have four locations, where some of these locations may be conincident, then a delivery quest and a fetch quest become the same thing. Thus
+Note, however, that if we consider a delivery quest to have four locations, where some of these locations may be coincident, then a delivery quest and a fetch quest become the same thing. Thus
 
 1. The location of the quest giver at the beginning of the quest;
 2. The location from which the quest object must be collected;
 3. The location to which the quest object must be delivered;
 4. The location of the quest giver at the end of the quest.
 
-This characterisation assumes that at the end of each quest, the player must rendezvous with the quest giver at the end of the quest, either to report completion or to collect a reward. Obviously, there could be some quests where this fourth location is not required, because there is no need to report back (for example, if the quest giver was dying/has died) and no reward to be collected.
+This characterisation assumes that at the end of each quest, the player must rendezvous with the quest giver, either to report completion or to collect a reward. Obviously, there could be some quests where this fourth location is not required, because there is no need to report back (for example, if the quest giver was dying/has died) and no reward to be collected.
 
 Note that a location is not necessarily a fixed x/y location on the map; in a kill quest, for example, location 2 is the current location of the target, and moves when the target moves; location 3 and 4 are both normally the current location of the quest giver, and move when the quest giver moves.
 
@@ -43,11 +43,11 @@ Given that quests are as simple as this, it's obvious that narrative sophisticat
 
 But, if we're thinking of a game with much more intelligent non-player characters with much more conversational repertoir, as I am, can satisfying quests emerge organically? In space trading games such as [Elite](https://www.telegraph.co.uk/games/11051122/Elite-the-game-that-changed-the-world.html), a primary activity is moving goods from markets with surplus (and thus low prices) to markets with shortage (and thus high prices). This is, in effect, a game made up of deliver quests - but rather than deliver quests which are scripted, they are deliver quests which arise organically out of the structure of the game world.
 
-I already have working code for non-player character merchants, who move goods from city to city based on market information available to them. For player characters to join in this trading is an organic activity emerging from the structure of the world, which provides an activity. But moving merchants provides a market opportunity for bandits, who can intercept and steal cargoes, and so for mercenaries, who can protect cargoes from bandits, and so on. And because I have an architecture that allows non-player characters to fill economic niches, there will be non-player characters in all these niches.
+I already have working code for non-player character merchants, who move goods from city to city based on market information available to them. For player characters to join in this trading is an organic activity emerging from the structure of the world. But moving merchants provides a market opportunity for bandits, who can intercept and steal cargoes, and so for mercenaries, who can protect cargoes from bandits, and so on. And because I have an architecture that allows non-player characters to change occupation to fill economic niches, there will be non-player characters in all these niches.
 
 Where a non-player character can act, so can a player character: when a (non-player character) merchant seeks to hire a caravan guard and a player character responds, that's an organic escort quest.
 
-The key idea behind organic quests is that the circumstance and requirments for quests emerges as an emergent behaviour out of the mechanics of the game world. A non-player character doesn't know that there is a player character who is different from them; rather, when a non-player character needs something they can't readily achieve for themselves, they will ask other characters to help, and that may include the player character.
+The key idea behind organic quests is that the circumstance and requirements for quests emerge as an emergent behaviour out of the mechanics of the game world. A non-player character doesn't know that there is a player character who is different from them; rather, when a non-player character needs something they can't readily achieve for themselves, they will ask other characters to help, and that may include the player character.
 
 This means, of course, that characters need a goal-seeking planning algorithm to decide their actions, with one option in any plan being 'ask for help'. Thus, 'asking for help' becomes a mechanism within the game, a normal behaviour. Ideally non-player characters will keep track of quite complex webs of loyalty and of obligation - debts of honour, duties of hospitality, collective loyalties. So that, if you do a favour for some character in the world, that character's tribe, friends, obligation circle, whatever, are now more likely to do favours for you.
 
@@ -60,3 +60,5 @@ So quests can emerge organically from the mechanics of the world and be richly v
 ## Stuff to consider
 
 The games [Middle Earth: Shadow of Mordor](https://en.wikipedia.org/wiki/Middle-earth:_Shadow_of_Mordor), and [Middle Earth: Shadow of War](https://en.wikipedia.org/wiki/Middle-earth:_Shadow_of_War) have a procedural story system called [Nemesis](https://youtu.be/Lm_AzK27mZY), which is worth a look.
+
+There's an interesting [critique of Red Dead Redemption 2](https://www.youtube.com/watch?v=MvJPKOLDSos&feature=emb_logo) which is relevant to what I'm saying here.

doc/Roadmap.md

@@ -0,0 +1,28 @@
+# Roadmap
+
+This document outlines a plan to move forward from where I am in June 2021.
+
+# JMonkeyEngine
+
+[JMonkeyEngine](https://jmonkeyengine.org/) is not, at this time, an AAA game engine. But at the same time I'm never, really, going to build an AAA game. It is a working game engine which can display characters on screen in scenery and have them move around, and, actually, they can be fairly sophisticated. It will be resaonably easy to integrate Clojure code with JMonkeyEngine - easier than it would be to integrate either Clojure or Common Lisp with [Unreal Engine](https://www.unrealengine.com/) or [Unity 3D](https://unity.com/). As a significant added bonus, JMonkeyEngine is open source.
+
+Consequently I plan to stop agonising about what game engine to use, and seriously focus on getting something working in JMonkeyEngine.
+
+# Not Reinventing Wheels
+
+JMonkeyEngine already has working code for walking animated characters, which is entirely adequate to proof-of-concept what I want to do. Rather than try to implement them myself, I just intend to use existing JMonkeyEngine code as far as possible.
+
+# The 1Km World
+
+I propose to build a 1Km square world, containing one settlement, as a proof of concept for
+
+1. Procedural (genetic) buildings;
+2. Procedural settlement planning;
+3. Procedural characters, probably based on [MakeHuman 'Mass Produce' plugin](https://youtu.be/jRHnJX-TdT4), using walk animation based on [TestWalkingChar](https://github.com/jMonkeyEngine/jmonkeyengine/blob/master/jme3-examples/src/main/java/jme3test/bullet/TestWalkingChar.java);
+4. Characters with their own hierarchy of needs, and their own means of planning to fulfil these;
+5. Characters with individualised knowledge about the world;
+6. Characters who can parse typed questions, and produce either a textual or audio response;
+7. Characters with procedurally generated accents (very stretch goal)!
+8. Characters who can listen to spoken questions, and produce audio responses.
+
+At that stage, I have a technology demonstrator that will be interesting. It still leaves the big procedural world builder still to do, but it would be enough technology to get other people interested in the project.

doc/Voice-acting-considered-harmful.md

@@ -5,9 +5,18 @@
 ![The Witcher: Conversation with Kalkstein](https://3.bp.blogspot.com/-ZI90HLjEcuo/VO4f-yXP3sI/AAAAAAAAZt4/C0hQ7hScWyM/s1600/witcher_conversation.jpg)
 
  Long, long, time ago, I can still remember when... we played (and wrote) adventure games where the user typed at a command line, and the system printed back at them. A Read-Eval-Print loop in the classic Lisp sense, and I wrote my adventure games in Lisp. I used the same opportunistic parser whether the developer was building the game
-  Create a new room north of here called dungeon-3 the player was playing the game
+
-  Pick up the rusty sword and go north or the player was talking to a non-player character
+>  Create a new room north of here called dungeon-3
-  Say to the wizard 'can you tell me the way to the castle' Of course, the parser didn't 'understand' English. It worked on trees of words, in which terminal nodes were actions and branching nodes were key words, and it had the property that any word it didn't recognise at that point in sentence was a noise word and could be ignored. A few special hacks (such as 'the', 'a', or 'an' was an indicator that what came next was probably a noun phrase, and thus that if there was more than one sword in the player's immediate environment the one that was wanted was the one tagged with the adjective 'rusty'), and you ended up with a parser that most of the time convincingly interpreted most of what the player threw at it.
+
+the player was playing the game
+
+>  Pick up the rusty sword and go north
+
+or the player was talking to a non-player character
+
+>  Say to the wizard 'can you tell me the way to the castle'
+
+Of course, the parser didn't 'understand' English. It worked on trees of words, in which terminal nodes were actions and branching nodes were key words, and it had the property that any word it didn't recognise at that point in sentence was a noise word and could be ignored. A few special hacks (such as 'the', 'a', or 'an' was an indicator that what came next was probably a noun phrase, and thus that if there was more than one sword in the player's immediate environment the one that was wanted was the one tagged with the adjective 'rusty'), and you ended up with a parser that most of the time convincingly interpreted most of what the player threw at it.
 
  Text adventures fell into desuetude partly because they weren't graphic, but mainly because people didn't find typing natural, or became dissatisfied with the repertoire of their parsers. Trying to find exactly the right combination tokens to persuade the game to carry out some simple action is not 'fun', it's just frustrating, and it turned people off. Which is a shame because just at the time when people were abandoning text adventures we were beginning to have command parsers which were actually pretty good. Mine, I think, were good - you could have a pretty natural conversation with them, and in 'building' mode, when it hit a 'sorry I don't understand' point, it allowed you to input a path of keywords and a Lisp function so that in future it would understand.
 

project.clj

@@ -5,13 +5,16 @@
           :output-path "docs/codox"
           :source-uri "https://github.com/simon-brooke/the-great-game/blob/master/{filepath}#L{line}"}
   :cucumber-feature-paths ["test/features/"]
-  :dependencies [[com.taoensso/timbre "4.10.0"]
+  :dependencies [[com.taoensso/timbre "5.1.2"]
-                 [environ "1.1.0"]
+                 [environ "1.2.0"]
+                 [jme-clj "0.1.13"]
+;;                 [jme3-core "3.4.0-stable"]
                  [journeyman-cc/walkmap "0.1.0-SNAPSHOT"]
                  [me.raynes/fs "1.4.6"]
                  [mw-engine "0.1.6-SNAPSHOT"]
+                 [org.apache.commons/commons-math3 "3.6.1"] ;; for mersenne-twister implementation
                  [org.clojure/algo.generic "0.1.3"]
-                 [org.clojure/clojure "1.8.0"]
+                 [org.clojure/clojure "1.10.3"]
                  [org.clojure/math.numeric-tower "0.0.4"]
                  ]
   :description "Prototype code towards the great game I've been writing about for ten years, and know I will never finish."

src/cc/journeyman/the_great_game/agent/agent.clj

@@ -1,11 +1,12 @@
 (ns cc.journeyman.the-great-game.agent.agent
-  "Anything in the game world with agency"
+  "Anything in the game world with agency; primarily but not exclusively
-  (:require [the-great-game.objects.game-object :refer [ProtoObject]]
+   characters."
-            [the-great-game.objects.container :refer [ProtoContainer]]))
+  (:require [cc.journeyman.the-great-game.objects.game-object :refer [ProtoObject]]
+            [cc.journeyman.the-great-game.objects.container :refer [ProtoContainer]]))
 
-;;  hierarchy of needs probably gets implemented here
+;;;  hierarchy of needs probably gets implemented here
-;;  I'm probably going to want to defprotocol stuff, to define the hierarchy
+;;;  I'm probably going to want to defprotocol stuff, to define the hierarchy
-;;  of things in the gameworld; either that or drop to Java, wich I'd rather not do.
+;;;  of things in the gameworld; either that or drop to Java, wich I'd rather not do.
 
 (defprotocol ProtoAgent
   "An object which can act in the world"
@@ -37,7 +38,7 @@
 
 (defrecord Agent
   ;; "A default agent."
-  [name home tribe]
+  [name craft home culture]
   ProtoObject
   ProtoContainer
   ProtoAgent

src/cc/journeyman/the_great_game/buildings/rectangular.clj

@@ -0,0 +1,168 @@
+(ns cc.journeyman.the-great-game.buildings.rectangular
+  (:require [cc.journeyman.the-great-game.holdings.holding :refer [ProtoHolding]]
+            [cc.journeyman.the-great-game.location.location :refer [ProtoLocation]]
+            )
+  (:import [org.apache.commons.math3.random MersenneTwister]
+           ))
+
+;;; 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. Create good rectangular buildings, and investigate whether a single 
+;;;    function can be used to create buildings of more than one family (e.g.
+;;;    can it produce flat roofed, north African style, mud brick houses as
+;;;    well as pitch roofed, half timbered northern European houses?)
+;;; 3. Establish whether, in my current state of fairly severe mental illness,
+;;;    I can actually produce any usable code at all.
+;;;
+;;; ## Key factors in the creation of a building
+;;;
+;;; ### Holding
+;;;
+;;; 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.
+
+(def ^:dynamic *terrain-types* 
+  "Types of terrain which affect building families. TODO: This is a placeholder;
+   a more sophisticated model will be needed."
+  #{:arable :arid :forest :plateau :upland})
+
+(def ^:dynamic *cultures*
+  "Cultures which affect building families. TODO: placeholder"
+  #{:ariston :coastal :steppe-clans :western-clans :wild-herd})
+
+(def ^:dynamic *crafts*
+  "Crafts which affect building types in the game. See 
+   `Populating a game world`. TODO: placeholder"
+  #{:baker :banker :butcher :chancellor :innkeeper :lawyer :magus :merchant :miller :priest :scholar :smith :weaver})
+
+(def ^:dynamic *building-families* 
+  {:pitched-rectangular {:terrains #{:arable :forest :upland}
+                         :crafts *crafts*
+                         :cultures #{:coastal :western-clans}
+                         :modules []}
+   :flatroof-rectangular {:terrains #{:arid :plateau}
+                          :crafts *crafts*
+                          :cultures #{:coastal}
+                          :modules []}})
+
+;; TODO: So, modules need to contain
+;;
+;; 1. Ground floor modules, having external doors;
+;; 2. Craft modules -- workshops -- which will normally be ground floor (except
+;; weavers) and may have the constraint that no upper floor module can cover them;
+;; 3. Upper floor modules, having NO external doors (but linking internal doors);
+;; 4. Roof modules
+;; 
+;; There also needs to be an undercroft or platform module, such that the area of 
+;; the top of the platform is identical with the footprint of the building, and 
+;; the altitude of the top of the platform is equal to the altitude of the 
+;; terrain at the heighest corner of the building; so that the actual 
+;; building doesn't float in the air, and also so that none of the doors or windows
+;; are partly underground.
+;;
+;; Each module needs to wrap an actual 3d model created in Blender or whatever, 
+;; and have a list of optional textures with which that model can be rendered. 
+;; So an upper floor bedroom module might have the following renders:
+;;
+;; 1. Bare masonry - constrained to upland or plateau terrain, and to coastal culture
+;; 2. Painted masonry - constrained to upland or plateau terrain, and to coastal culture
+;; 3. Half-timbered - not available on plateau terrain
+;; 4. Weatherboarded - constrained to forest terrain
+;; 5. Brick - constrained to arable or arid terrain
+;;
+;; of course these are only examples, and also, it's entirely possible to have
+;; for example multiple different weatherboard renders for the same module. 
+;; There needs to be a way of rendering what can be built above what: for
+;; example, you can't have a masonry clad module over a half timbered one, 
+;; but you can have a half-timbered one over a masonry one
+
+(defn building-family
+  "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."
+  [terrain culture craft gene]
+  (let [candidates (filter #(and
+                             ((:terrains %) terrain)
+                             ((:crafts %) craft)
+                             ((:cultures %) culture))
+                           (vals *building-families*))]
+    (nth candidates (mod (Math/abs (.nextInt gene)) (count candidates)))))
+
+(building-family :arable :coastal :baker (MersenneTwister. 5))
+
+(defn build! 
+  "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."
+  [holding terrain culture craft size]
+  (if (satisfies? ProtoHolding holding)
+  (let [location (.building-origin holding)
+        gene (MersenneTwister. (int (+ (* (.easting location) 1000000) (.northing location))))
+        family (building-family terrain culture craft gene)]
+  (if 
+   (and (instance? ProtoLocation location) (:orientation location))
+    :stuff
+    :nonsense
+    ))
+    :froboz))
+
+;; (def ol (cc.journeyman.the-great-game.location.location/OrientedLocation. 123.45 543.76 12.34 0.00 {}))
+

src/cc/journeyman/the_great_game/holdings/holding.clj

@@ -0,0 +1,42 @@
+(ns cc.journeyman.the-great-game.holdings.holding
+  (:require [cc.journeyman.the-great-game.agent.agent :refer [ProtoAgent]]
+            [cc.journeyman.the-great-game.objects.container :refer [ProtoContainer]]
+            [cc.journeyman.the-great-game.objects.game-object :refer [ProtoObject]]
+;;            [cc.journeyman.the-great-game.location.location :refer [OrientedLocation]]
+            [cc.journeyman.the-great-game.world.routes :refer []]))
+
+;;; A holding is a polygonal area of the map which does not
+;;; intersect with any other holding, or with any road or water feature. 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.
+
+(defprotocol ProtoHolding
+  (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.")
+  (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."))
+
+(defrecord Holding [perimeter holder]
+  ;; Perimeter should be a list of locations in exactly the same sense as a
+  ;; route in `cc.journeyman.the-great-game.world.routes`. Some sanity checking
+  ;; is needed to ensure this!
+  ProtoContainer
+  ProtoHolding
+  (frontage [holding]
+            ;; TODO: this is WRONG, but will work for now. The frontage should
+            ;; be the side of the perimeter nearest to the nearest existing 
+            ;; route.
+    [(first (perimeter holding)) (nth (perimeter holding) 1)])
+  (building-origin [holding]
+                   ;; TODO: again this is wrong. The default building origin
+                   ;; should be the right hand end of the frontage when viewed
+                   ;; from outside the holding.
+                   (first (frontage holding)))
+  ProtoObject)

src/cc/journeyman/the_great_game/location/location.clj

@@ -0,0 +1,47 @@
+(ns cc.journeyman.the-great-game.location.location)
+
+;;; There's probably conflict between this sense of a reified location and
+;;; the simpler sense of a location described in 
+;;; `cc.journeyman.the-great-game.world.location`, q.v. This needs to
+;;; be resolved!
+
+(defprotocol ProtoLocation
+  (easting [location]
+   "Return the easting of this location")
+  (northing [location] "Return the northing of this location")
+  (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.")
+  (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.")
+  (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"))
+
+
+(defrecord Location [^Double easting ^Double northing ^Double altitude world]
+  ProtoLocation
+  (easting [l] (:easting l))
+  (northing [l] (:northing l))
+  (altitude [l] (:altitude l))
+  (terrain-altitude [l] 0.0) ;; TODO
+  (settlement [l] :tchahua))
+
+(defrecord OrientedLocation
+  ;; "Identical to a Location except having, additionally, an orientation"
+           [^Double easting ^Double northing ^Double altitude ^Double orientation world]
+  ProtoLocation
+  (easting [l] (:easting l))
+  (northing [l] (:northing l))
+  (altitude [l] (:altitude l))
+  (terrain-altitude [l] 0.0) ;; TODO
+  (settlement [l] :tchahua)) ;; TODO
+
+ ;; (.settlement (OrientedLocation. 123.45 543.76 12.34 0.00 {}))
+
+
+;; (OrientedLocation. 123.45 543.76 12.34 0.00 {})

src/cc/journeyman/the_great_game/playroom.clj

@@ -0,0 +1,68 @@
+(ns cc.journeyman.the-great-game.playroom
+  (require [jme-clj.core :refer :all])
+  (import [com.jme3.math ColorRGBA]))
+
+;; At present this file is just somewhere to play around with jme-clj examples
+
+(defn init []
+  (let [cube (geo "jMonkey cube" (box 1 1 1))
+        mat  (unshaded-mat)]
+    (set* mat :texture "ColorMap" (load-texture "textures/Monkey.jpg"))
+    (set* cube :material mat)
+    (add-to-root cube)
+    {:cube cube}))
+
+;; Let's create simple-update fn with no body for now.
+ (defn simple-update [tpf]
+   (let [{:keys [cube]} (get-state)]
+     (rotate cube 0 (* 2 tpf) 0)))
+
+
+;; Kills the running app var and closes its window.
+;; (unbind-app #'app)
+
+;; We define the `app` var.
+(defsimpleapp app
+               :opts {:show-settings?       false
+                      :pause-on-lost-focus? false
+                      :settings             {:title          "My JME Game"
+                                             :load-defaults? true
+                                             :frame-rate     60
+                                             :width          800
+                                             :height         600}}
+               :init init
+               :update simple-update)
+
+(start app)
+
+;; Reinitialises the running app
+;;(run app
+;;     (re-init init))
+ 
+ ;; By default, there is a Fly Camera attached to the app that you can control with W, A, S and D keys.
+ ;; Let's increase its movement speed. Now, you fly faster :)
+ (run app
+      (set* (fly-cam) :move-speed 15))
+
+
+ ;; Updates the app 
+(run app
+     (let [{:keys [cube]} (get-state)]
+       (set* cube :local-translation (add (get* cube :local-translation) 1 1 1))))
+
+  ;; Updates the app adding a second cube
+(run app
+      (let [cube (geo "jMonkey cube" (box 1 1 1))
+            mat  (unshaded-mat)]
+        (set* mat :texture "ColorMap" (load-texture "textures/Monkey.jpg"))
+        (setc cube
+              :material mat
+              :local-translation [-3 0 0])
+        (add-to-root cube)
+        (set-state :cube2 cube)))
+ 
+ ;; We added the new cube, but it's not rotating. We need to update the simple-update fn.
+ (defn simple-update [tpf]
+   (let [{:keys [cube cube2]} (get-state)]
+     (rotate cube 0 (* 2 tpf) 0)
+     (rotate cube2 0 (* 2 tpf) 0)))

test/cc/journeyman/the_great_game/world/routes_test.clj

@@ -1,6 +1,6 @@
 (ns cc.journeyman.the-great-game.world.routes-test
   (:require [clojure.test :refer :all]
-            [cc.journeyman.the-great-game.world.routes :refer :all]
+            [cc.journeyman.the-great-game.world.routes :refer [find-routes]]
             [cc.journeyman.the-great-game.world.world :refer [default-world]]))
 
 

workspace.code-workspace

@@ -11,6 +11,12 @@
 		},
 		{
 			"path": "../genbuildings"
+		},
+		{
+			"path": "../GreatGameTerrain"
+		},
+		{
+			"path": "../jme-clj"
 		}
 	],
 	"settings": {}