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.