No-one here gets out alive

Avis (left) and Zoe (right) taken on Christmas Eve 2017.

My mental health, which had already been poor before my lover Avis died of cancer in July last year, has collapsed utterly since the suicide of my niece Zoe in November. Somehow I have to find my way back (or die, which would be easier). This essay is an attempt to plot a plan for the first option.

Partly as a consequence of my mental health collapse, my last remaining work contract is looking very shaky, and may not continue. I don't even really want it to continue, even though without it I have no income at all. And I don't believe I am now well enough to seek new paying work; I don't believe it's reasonable to expect that I will be well enough in the even moderately near future. But when I do seek new paying work, I need to have some story about what I was doing this year.

Finally, I'm not currently receiving any benefits, and I'm not well enough to apply for benefits. Zoe (before she died) started an application on my behalf, and my community psychiatric nurse has continued that application, but I have no faith in anything actually being paid. Fortunately, I shall inherit what little Zoe had, and I may be able to sell about £1,000 worth of cattle this autumn (if I'm well enough) but that isn't enough to keep me alive for a year.

What I need to recover health is a series of successful challenges, gradually increasing in difficulty. If I overface myself and fail, I end up further down the slope; things get worse. So it's important to pick challenges I can succeed at. So far so good.

Survey of the battlefield

Cattle

I have cattle. As I've had three calves born in the past fortnight, I now have ten cattle. Of these, one is ready for slaughter but because his paperwork is not in order cannot be sold. Three are last year's calves, and their paperwork is in order, so potentially they can be sold, but they're hybrids and not worth much except as meat, and they won't be ready for slaughter until this autumn at earliest. One of them, Draeg, is male and has not been castrated, so I urgently need to separate him from my cows (and, ideally, get him castrated). I do not want any of my three cows to get pregnant this year - lovely as calves are, I have too many cattle and could do with a year without them.
So the overall plan is

1. to slaughter Beelzebub this winter (or when I have sufficient freezer space, whichever is the earlier) - this I'm fairly confident I can do;
2. sell the three yearlings this autumn, either for slaughter or for fattening; they'll be worth at best a very few hundred each (and could fetch much less);
3. keep the three cows and their calves-at-heel.

Selling cattle is something I have not yet done, and I am not at all confident I can do it.

The Cattle Shed

For the past four years at least, I've been planning to build a cattle shed, and the plan has always been to get it finished before mid July of each of those years, so that I can put the year's hay harvest into its hay loft. The current state of play is that most of the materials are bought and paid for, the foundations and floor are in place, and most of the blocks for the lower walls are on site. Getting the blockwork up is probably about a fortnight's work, and it's something I can now definitely do: the last things blocking it were resolved yesterday.

But sawing the timber for the superstructure is not done, and building the frame can't happen until the timber is sawn. I cannot saw the timber alone, and the sawmill I'd assumed I'd be able to borrow I now probably can't borrow. So there are two options: one, abandon the timber I've already bought and buy new, sawn timber; or two, hire someone to mill the timber. I definitely cannot afford either of these. Even if I can get timber really soon, building the frame is at least a month's work, and completing the build at least another's. It's now the very end of May. So there's no way I can now get the shed finished in time for hay harvest this year. It isn't impossible that I could have it finished for winter, and having it finished for winter actually would make life easier even if the hayloft were empty (or even unfinished).

Hay

I've currently got my cattle in my bottom park; this leaves the middle and upper parks clear to grow hay. However, I'm not confident they've really got enough grass, and in any case I need to get Draeg away from the cows (or castrated) before they come into season again, which is pretty damn soon. So either I need to move my male cattle into the upper park, or else onto my neighbour Alice's land, with her permission - she has the grass. If I move the male cattle into my upper park, it makes work on the cattle shed building site vastly more difficult.

If all I am keeping over next winter is the three cows and their calves at heel, then the middle park should produce enough hay for that, assuming the winter is not too bad. But I'd really like to be able to mow the upper park as well, just as insurance.

All my hay making equipment needs quite a lot of maintenance, which I had planned to do over the winter and just have not been well enough to. If it is to be used there is at least a fortnight's work on that. However, the baler is almost ready to go, and if I can bale for James, I can get him to mow for me as a trade.

If I don't have the cattle shed up in time (and that is now virtually impossible), I can store hay in the old byre, although that's increasingly decrepit and in any case a hassle. So hay actually can be done. But also, in the last analysis, enough hay for three cows for the winter would not be enormously expensive to buy. Hay is not a major problem.

Software

Being someone who is reasonably good at writing complex software is an important part of my identity. At present I am not that person, because my attention span and concentration are mince. I feel that I need to gradually build back to the point where I am that person. One of the problems are that I have too many projects on the go, and am much better at starting new projects than at working steadily and consistently on existing ones. The current projects are:

1. Outlook add-in for SalesAgility's SuiteCRM product; this is the only paying work I currently have (and it doesn't pay much);
2. Project Hope, a voter intention/canvassing system for Indyref2, which is more than half finished;
3. The Great Game, a very large open world game project;
4. Post Scarcity, a software environment for the massively parallel computers which must, I believe, be the future of computing.

Taking these one by one:

The SuiteCRM Outlook add-in is not something I enjoy working on or would choose to work on, although I do appreciate working with the folk at SalesAgility I work with on it. However, I am increasingly not well enough to do it, and the strains of the project are not contributing to my mental health. Also, there are quite considerable costs in terms of software subscriptions involved in working on it; it is the only paid work I have, but even so it barely washes its face. If SalesAgility do not decide to drop the project, I probably ought to withdraw from it.

I have no confidence a second independence referendum will ever be held; it seems to me unlikely. The SNP will not go ahead without a Section 30 order from Westminster, and I can see no prospect at all of Westminster ever granting such an order. So Project Hope is probably useless. Even if it were useful, it is no use having such a system if the only person who can support it is an unreliable madman. So if the project is to continue, it needs help which in my present state I can't recruit: it needs a project manager, at least one additional developer, at least one evangelist, and, ultimately, a group of people to train canvassers and analysts to use it.

Nevertheless, if Project Hope could be finished, it would have real benefits:

1. It would help win a second independence referendum, if one were held;
2. Even if another independence referendum is never held, it would help with canvassing in other referenda and elections for any organisation which chose to use it;
3. It would be a solid and impressive piece of work which would form a key part of my CV when next I am well enough to seek paid work.

This is work in my core competences, in a software environment in which I am extremely comfortable, which could be genuinely useful in the real world. Rationally, it is probably the best candidate. But, without help, I cannot do it.

The Great Game is a fairly sketchy plan to build a game which would address what I perceive as many of the failings in modern computer games. It is vast and far beyond the capability of any one person to build. However, potentially, subsystems of it, especially the merchant subsystem and the gossip subsystem, could become libraries which could be sold to other game developers for use in their games; in other words, despite the overall project being ludicrous in scope, there is a potential here for a commercial business.

However, for that to be the case these modules would have to be broken out into libraries which could be called efficiently from C++ or similar code, and ideally integrated with one or more of the more common game engines.

The work which I've done on it so far is prototype work on algorithms for merchants and gossip.

Post Scarcity is even more ludicrously ambitious: to design a software environment - an operating system, if you like - which would make as yet undeveloped computers of unprecedented power tractable and useful. It's necessarily being done in very low level languages which are not my forte, and its present state is bogged down in hard-to-trace bugs. It would make a great PhD project for someone, but possibly not me. However, if I could focus on it, it would be very good mental exercise, and like eating an elephant, it can be done in teaspoonfuls.

In summary I need to focus on one project and largely abandon the others. Project Hope is rationally probably the best choice, but I can't make progress on my own and don't know how to recruit help. The Great Game (or, more specifically, its marketable subsystems) has the benefit of being something I can make progress on without outside help.

Plan for the campaign?

So it looks to me as though my best plan is

1. To erect the blockwork for the cattle shed as soon as possible, without worrying about when the superstructure can be completed: feasible, needs no outside support, can be achieved, will have some value as shelter and as a hard feeding pen even if the shed is never finished;
2. To separate the male cattle and move them at least to the upper park (but to ask Alice if I can move them into hers);
3. To procede with maintenance on the baler as soon as possible, with the rake and mower as stretch goals - if working in the Void is too stressful, fetch them down here to be worked on;
4. To ask friends for support on Project Hope, but, if I don't get that soon, to abandon it and focus software on The Great Game;
5. To not worry about anything else for the time being.

Comments?

Baking the world

Devogilla's Bridge in Dumfries, early foourteenth century

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

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

Phase one: proving - the procedural world

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

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

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

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

The outputs are

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

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

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

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

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

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

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

Phase two: kneading - making the world fit our needs

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

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

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

Procedurally generated models take a wee bit of compute power to reify, but not a huge amount, and they're trivial to store - you need one single birch leaf model and one single birch-bark texture generator to make every birch tree in the game, and probably a single parameterised tree function can draw every tree of every species (and quite a lot of shrubs and ground-cover plants, too). But once reified, they take no longer to render than a manually crafted model.

By contrast, a manually crafted model will take a very great deal more space to store, such that being able to render a large world from hand crafted models, without excessive model re-use, isn't going to be possible.

So it's better in my opinion to put effort into good procedural generation functions, not just for foliage but also for buildings. My reason for using a picture of a medieval bridge at the head of the essay is to illustrate exactly this point: even in the medieval period, bridges comprise a series of repeating modules. Take one arch module and one ramp module from Devorgilla's bridge as models, add texture skins for several different stone types, stretch the modules a little in whatever dimension is needed, and repeat the arch module as many times as needed, and you can create a range of bridges to span many different rivers - which will all be visibly similar, but that's fine, that's the nature of a traditional culture - but each slightly different.

Take half a dozen sets of models - timber bridges for forested biomes, brick bridges for biomes without stone or timber - and you can build procedural bridges across a whole continent without ever exactly repeating yourself.

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

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

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

Phase three: baking - making it delicious

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

Phase four: eating!

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

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

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

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