Tuesday, November 23, 2010

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 SystemLinux
Web ServerApache
DatabaseMySQL
Server-side Scripting LanguagePhP

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.

No comments:

Post a Comment