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).

The Platform

I wrote earlier that, over the last twenty years, some of my game designing has taken the form of exercises to help me in learning new computer languages or environments.  This one started as such an exercise.  It was not on a new platform as such, but on one that has provided my living for many years, and I hope will continue to do so for many years to come.  The platform is Lotus Domino.

Most people are unaware of Domino, yet it is used by around 100 million people around the world (exact figures can't be got, but the number is in that area somewhere).  Domino is actually one half of  the platform, the other half being Lotus Notes.  Domino is the server (the computer way over there, where all the mysterious hard work goes on), Notes the client (the computer right here, that you type at).  When people are aware of Notes/Domino at all, they tend to think that it is a corporate e-mail platform, like Microsoft Outlook/Exchange.  Further, they tend to think that it is comprehensively inferior to the Microsoft offerings, and that it has been comprehensively trounced in the market by Microsoft.

So why on earth would I choose such a platform to build a game engine on?  Because the popular perception is entirely untrue.  This is not the right place to give a history of how the software, and perceptions of it, got to be where they are today, but I do need to make a few brief remarks so that you understand where I am coming from.  First, Notes is not an e-mail client.  Yeah, yeah, it does e-mail (and does it, in my view, far more capably than Outlook, although the gap has narrowed in recent years) but that is almost by accident.  What Notes is (and which made it so wildly successful back in the 90's) is a platform for developing applications.  By an application, I mean here a piece of software that allows you to do something that you want to do.  At first, applications developed in Notes could be used only by the Notes client (optionally deployed on what was then called the Notes server).  Then the internet went public, and the web happened.  That changed everything.

Incapable as browsers then (about 1994) were, people loved the web, and browsers showed promise of turning into the universal client.  Fifteen years on they have still not yet entirely fulfilled that promise, but they are slowly getting there.  The sort of material that was then being delivered on browsers was a subset of what was already being built for Notes clients.  Lotus already had all the tools to allow people to develop and deliver such applications - all they needed was to translate the content on the fly into HTML, and add support for the HTTP protocol as a delivery vehicle.  As a result, Lotus was one of the first companies to provide a full-blown stack for web application development and delivery - years before Microsoft, Oracle, or any other major player.  The Notes server was re-named the Domino server, and developers could develop applications for the Notes client, the browser client, or for both.

In my working life, I have developed mostly for the Notes client.  Why?  Well, it is in most respects far more capable than the browser client, so is a lot less work for me to develop the same functionality for Notes than for a browser.  That means that I can be far more productive, delivering value sooner and more often.  In addition, although there are international standards that in theory tell browsers how to behave, browsers conform to them only unevenly, so in developing for the web you are not really developing for one client, but for several.  In a corporate/intranet environment you can expect everybody to have the same browser, which helps, but it is still the less capable client for non-trivial tasks.  Nearly everything that people do with browsers is, in fact, trivial, so often that doesn't matter, but in an environment where people need to do real work (or play real games!), it's a different matter.  Where I can develop for one client in a controlled environment, I'll still go for the Notes client almost every time.

This time I am developing purely for the browser client.  Given my remarks above, again, why?

First up, games require graphics.  "What?", you ask.  "You can't do a game without graphics?"  Sure, you can, but it's visually dull.  It's also hard to follow.  You can explain epidemiology without graphics, too, but Hans Rosling demonstrates here how the addition of appropriate graphics makes it infinitely more compelling (really, go and watch it!).  So what's that to do with Notes vs browser?  Well, it has to said that Notes is pretty ordinary in the way it deals with graphics.  Dynamic, programatically-driven graphics, anyway.  Static graphics are fine.  Notes has supported graphics both in application design and in user content from the very beginning.  But taking a data set and displaying it as a picture?  Not so much.  The web browser, on the other hand, is quite good at that.

Second, I am not now writing for a limited internal audience who all have access to a Notes client.  I am writing for the world, and the world has a browser.  If I can make something that will run on any browser whatever, so much the better, but I may assume a certain browser, at least at first.  They are all free, so that should not be such a hurdle.  At the least, I will be assuming support for Javascript, which is the language that will provide all the client-side smarts.

As for the server, why Domino?  First, because I know it well.  I want to learn something new and achieve something new out of this exercise, but I don't feel the need to go to a whole new platform.  The only viable alternative that I can see is the LAMP stack, which is certainly the flavour of choice in recent years for backyard (and many other) developers.  LAMP, for those of you who don't move in these circles, is an informal name for a stack of four technologies that go together to create web applications.  You get hold of them from four separate places, then wire them together to create the effect you want.

Operating System	Linux
Web Server	Apache
Database	MySQL
Server-side Scripting Language	PhP

Or, I could use Domino, which includes a web server, a database, and a server-side scripting language (actually, an array of them) in one package.  It also includes built-in security - authentication, access control, encryption etc., and a development environment (Domino Designer) that enables me to pull all the pieces together.  It doesn't include an operating system, but doesn't assume any particular one either.  I can run the server on Linux if I want to, or on AIX, Windows, i-Series, p-Series, x-Series.... it doesn't matter.  I don't have to port it from one OS to another, either.  I happen to be writing the application on Windows (I have a copy on my Windows 7 laptop, and one on my Windows XP desktop - the two update each other automatically, and I can extend that to as many additional machines on as many additional operating systems as I care to.

Works for me.

Welcome

Welcome to the GeoComb blog.

This is my first dipping of the toe into the water of the blogosphere (as a practitioner, that is).

Let me cut to the chase - this blog will be about the building of a place for online strategic gaming - especially historical gaming. I may stray from that focus from time to time, as the fit takes me. This will involve building elements for:

• map editing
• scenario design
• order of battle management
• troop deployment
• one or more game rule sets
• game play engine(s)

As of March 2010, the first is largely complete, and the next several well on the way, though no doubt not nearly as well as I would like to imagine.

This project brings together a few of my interests.

I have been playing strategic games since I was a child (first chess, then later more historical games, of the sort published back then by Avalon Hill, Game Designers Workshop, and the like), as well as table-top battlegaming, mostly in the Ancient period, but also Napoleonic and Early Modern. For most of that time I have played around with game and rule design. I never really intended to publish anything - it was for my private satisfaction and edification, and for that of my friends.

I have a fascination with maps likewise dating from childhood. I never studied geography at school (although I did study history through to post-graduate level), which is a pity. Despite my early lack of interest and education I have come to realise (this will come as a surprise to nobody) that geography underlies a great deal of what we humans do. You can't have more than a very shallow understanding of our current society unless you understand the events that have led to it, and you can't understand those until you can visualise the stage on which they are played out. This is obvious when you consider military history (which will admittedly end up being the focus of this project) but applies equally to the siting of cities, the extent of tribal or national territories, the skills and economies that develop in certain regions, and how different regions interact with their neighbours. The more abstruse areas of human experience - philosophy, mathematics, theology and so on. - may appear at first glance to be exempted, but this is not so. They are practised, at all times and in all places, by people embedded in a particular society, which in turn developed in the context of a particular geography.

Are you still with me?

Quite separately (almost accidentally, and somewhat against my will), I got into the world of computing about twenty years ago, and have been making my living that way ever since. I have never really thought of myself as a programmer, but as a provider of solutions that happen to be delivered via a computer program. I care about economy, elegance, and beauty of design. I don't promise that all of these will be evident in what you see here, but I will try not to disappoint. As part of that journey, I have fooled about over the years with using game design as a vehicle for learning whatever technology I happened to be involved with at the time. None of these efforts was more than an exercise, and none resulted in a finished product, but this one may be different - who knows?

Stick around, and you will see how I have come as far as I have to date, and follow me as I take it further. If any readers (assuming there are any readers) care to offer suggestions or ideas, I am more than happy to have them. I have found nothing so far on line dealing with exactly such things, but I trust I am not the only person in the world who will take an interest.