The Map System

In my first post I listed a number of elements that would be needed to make this system complete. The first is a means of generating maps.

I didn't want to just write a game. I wanted to write a game platform, on which you could play all sorts of games. How wide a range of games can be played on a single platform? With a single set of rules? I don't know yet. I haven't got there. At this stage I am visualising strategic historical games set in the 5th, 7th, 11th, 17th, 18th, 19th and 20th centuries, so it will be a challenge. For some of these there may need to be specific plug-in modules to the game engine, but I do want to keep as many parts as possible in common.

By the same token, then, I wanted to be able to generate any map whatever. My own interest in in historical simulations, but I don't exclude counterfactual or even fantasy scenarios, as long as they occur on an earth-like terrain. Wargames maps are necessarily somewhat abstract. You wouldn't want to rely on one for small boat navigation, nor for your bushwalking holiday. A certain amount of abstraction and distortion is therefore acceptable, but I do want the result to be reasonably accurate (or at least capable of being accurate). I also want them to be aesthetically pleasing. "Beautiful" is perhaps aiming too high, but let me by all means aim for a near miss.

A map in a system such as this must fulfil two functions (apart from the aesthetic).

1) It must encode where things are, how they relate to each other spatially, and what qualities they have. This encoding is the logical map, and it allows the program to regulate movement from one place to another, visibility of transient conditions (weather, the presence of troops, etc.) and what can be seen by whom.

2) Based on the logical map is the visual map, which is painted on the screen to be seen by the human eye. It must give visual clues to the information stored in the logical map. The visual map presented to a particular viewer will generally reflect only a subset of all the information stored.

The logical map must consist of a number of elements, each representing a discrete location, or perhaps an aspect of a location. By that I mean that one might choose to separate, say, the shape and location of a particular region, its climate profile, and its population, into three separate elements. Indeed, there need not be a one-to-one relationship between them - a "climate" element might cover several "province" elements, each of which contains several "settlement" elements. We can see, then, that the elements need not be the same size, or represent the same things. They must be capable, though, of being read (first by a computer, then by a human being) as a coherent whole.

The solution I have settled on for now is the traditional one of a map based on a hexagonal grid to regulate movement. I will set out in my next post why I chose a grid rather than area movement, and why a hex grid rather than square.

First Screenshot

I see that there is a good deal of text on this blog so far, and no pictures, although what I am writing about is overwelmingly visual.  High time for an image, I think, to give an idea of what I am banging on about.  Below is a screenshot from my "Europe" map, 1618 variant, showing the North Sea and countries about.  The whole map is 100 hexes square, and this selection about 25 hexes square.  It therefore covers about one sixteenth of the entire map area.  It is shown at "medium" resolution (smaller than you would generally use to play on), and with no overlaid hex grid.  The idea is that it should look not like a wargames map (although it can function as one) but like a regular map in an atlas.  Whaddayareckon?

Lotusphere!

I learned a week ago that my submission has been accepted to speak at Lotusphere next February.  This is the world's premiere conference for people working with Notes and Domino, and speaking there is a great honour.

I mentioned earlier that it was a session at a previous Lotusphere that got me started on this project from a technical perspective.  It is really very exciting to be back there presenting some of the fruits.  Yes, I will be talking about Geocomb.  Since the conference is business-oriented it is of course not the only application I will refer to, but the techniques I will be presenting are ones I first developed for this application.

Origins

The initial inspiration to have a go at building this system came from a presentation by Scott Good at Lotusphere in 2009. Scott presented on the construction of objects in Javascript, and the use of JSON (Javascript Object Notation). I had heard of JSON before, but had regarded it only as a lightweight alternative to XML in transporting data. That hadn't seemed a compelling enough reason to use it. What I had not understood, and which Scott brought home to me then, was that a simple eval() statement turns that mass of text into an object, which can then be manipulated programmatically. Yeah, I know. I'm a really  slow learner sometimes.

Anyway, it got me wondering about how many pieces of information I could juggle at once, and how many distinct images it would take to put together a mosaic that looks like a decent map...

On the plane on the way home I did some arithmetic, banged out a few simple terrain images, and started writing some code. Oh, by the way, I also immediately thought of a couple of cases where this could very usefully be applied to business problems - actual work for which I am paid. I have since put them into production, but it was fooling around with maps on aeroplanes and trains that taught me how to do it.

While I am on the subject of origins, there are a few games I have played or been involved in that will certainly be (if they are not already) influential in how I am approaching this. Some will influence the map, others the game rules. We'll see. Some of you may recognise particular influences as I start to reveal what I am doing.

Old Cossacks was a players' clan devoted to the multi-player Realtime Strategy game Cossacks, a few years ago. I am not a huge fan of RTS games, but what I really liked about Cossacks was that it was historically based, and on a period that is unfashionable but interesting. Indeed, I find the period interesting enough to re-enact, and have been doing so for many years. While I was involved with the Old Cossacks they ran a campaign called Europe in Flames. It was intended to supply a quasi-historical backdrop to a series of battles fought out on Cossacks maps, introducing a diplomatic element and giving the battles some degree of strategic significance. I didn't think the campaign was all that successful, but it did provide food for some very stimulating exchanges between those players who were interested in emphasising the historical realism aspect of the games, and with the designer and administrator of the campaign. Some of the first set of conversations led to the Old Cossacks game mod, by Old Cossack Davout. The strategic/campaign discussions, for me at least, didn't lead anywhere... until now.

At University, and for a number of years after, I was part of a circle of wargamers who got together fairly regularly for games of various sorts. A couple that I played many times, and which are shaping the way I think about this project are War Between the States, by Victory Games, and World in Flames, by Australian Design Group. Both are hex-based games, the first depicting the American Civil War, and the second World War II, at strategic/operational level. World in Flames, in particular, is a big, ambitious game, depicting the whole war with many units and fairly intricate rules. We played one evening a week, and the game needed to stay set up for months at a time.


Rise and Fall was another game we enjoyed - a Late-Rome-vs-the-Barbarians multi-player scenario that was simple but satisfying, not least because a player could at any time give up on his present nation and return as somebody else - a formerly dormant but now vigorous and expansive barbarian, or a newly-coalesced successor kingdom. Area movement was used, with relatively few military units (and few types) and simple rules.

Finally, there is Empires in Arms, a Napoleonic game at strategic/grand strategic level. It used area movement, and I did not play the game much as written. I did, however, use it as the basis for a tabletop campaign. Twenty or so players were involved as corps commanders in a replay of Napoleon's Russian campaign of 1812, with engagements at corps or higher level being fought on the tabletop with System 7 Rules.  Perhaps Empires in Arms could even be considered a dominant influence, for the first set of rules I propose to issue on top of Geocomb are Napoleonic, and the first scenario the War of the Third Coalition (the 1805 campaign, which historically culminated in the battle of Austerlitz).