Home, Home on the Web...
Apologies to those of you who have been waiting more or less patiently for the final part in this series. Circumstances intervened to cut down the amount of time I had to sit down and finish the articles!
Needless to say, this occurred just as we finished a major six month rewrite which integrated our code with theirs in a far tighter fashion than ever before! (see the previous article 'Onward to America Online'.) The porting consequences of this rewrite were extremely nasty, to say the least. I've dealt with the hassles of buying machines and database software in the first article, so I won't go over that again - except to say that had the changeover taken place a year later we would have been in a much better position because so much more commercial database software is now available for Linux. Moving over to the Web involved us in a number of programming tasks: 1. We had to disentangle the program from AOL's
software. Other programming tasks not directly involving Federation itself included writing the billing software and its administrative tools, writing code to allow customers to check their accounts, and writing the code to talk to the company doing our credit card validation and billing. This, of course was in addition to the work we were doing to build a customer database. Most of the latter code was written in the ubiquitous Perl language, but the three main tasks were C/C++, and it is those that I want to concentrate on here. The first of these tasks was to get Federation up and running as an independent program - that is one which would run without all AOL support software. I suppose that it was of some minor help that we had only just finished integrating the AOL software when all this blew up. At least the code involved was fresh in our minds. Some things we were happy to leave in - for instance we continued to use Unix pipes for internal connections, rather than TCP/IP. Others, such as the AOL gateway code had to be stripped out. Frankly, there is nothing more boring than re-doing code you have already done... While doing this we took the opportunity to clean up a few other long standing problems. This was not perhaps a wise thing to do, because they added to the problems in debugging the program. I think this is a common problem when carrying this sort of exercise. It is understandable, no one writes a program that they can't improve upon, and the temptation to tweak is almost irresistible. It is, though, a sad fact, that more problems are caused by this sort of 'improvement' and by programmer added 'neat/cool' features than by virtually anything else! While this was being done we were considering how we should get players into the game, and what sort of terminal they would need to be running on their computer. We decided fairly early on that it wouldn't be realistic to have people use their Web browser to play. Just as an aside, I'd like to make a plea for the humble Web browser to be restored to its original task of browsing Web pages! Over the last few years browsers have sprouted all sorts of extensions and they have been touted as the silver bullet for all sorts of problems for which it is patently not suited (Microsoft's execrable 'Active Desktop' immediately springs to mind). The net (no pun intended) result has been grotesquely bloated all-singing all-dancing multi-megabyte 'browsers'. We did look at the possibility of having a Java front end that ran inside a browser. A number of games have gone down this route, some quite successfully, but the lack of sophistication of Java and its development tools made this a non-starter. There was also the fact that we were planning to run our Web site on a different machine to the Federation program. For 'security' reasons the current generation of browsers only allow Java applets to talk to the machine that served the applet. I have no idea why this improves security, and no Java aficionado that I have spoken with has been able to give me a satisfactory answer. The fact that we would have to send down the applet for each session and wouldn't be able to store the player's preferences on his/her machine was also felt to be a serious mark against using Java. Although we decided against a Java client, it hasn't been permanently rejected. We are still looking at what is available with a view to maybe adding it as an option at a later date, so that there is an 'instant' way of accessing the game. The key question is where we can provide, via Java, an experience of the game that matches what players can get using other options. There is little use in letting new players try the game with a piece of Java software if the resulting experience is so horrible that they never come back! What we settled on was letting the game use the standard Telnet protocol and the standard Telnet port. This had a number of advantages and one major disadvantage. The key advantage was that there were a number of excellent clients out on the net, both for Windows and for the Mac. They supported split screens for input and output, scrollback, and a whole host of features that players wanted in their client. The downside was that, unlike when we were on America Online, players would not be able to 'instantly' access the game - they would have to go and download a terminal program first. It was this consideration that made us look so long and hard at the possibility of a Java interface. Having settled on the telnet option, however, we were able to forge ahead on a number of fronts. I was able to write our own Windows based Telnet terminal for the game in 10 days, using Borland's Delphi development system. The terminal (FedTerm) provided automated logon, separate input and output windows, a window showing who was in the game, and configuration for the F-keys. More importantly, it did all this from the game's standard output, and didn't require any special control codes. This ensured that all the other Telnet based game clients would still work. The telnet decision also solved our second problem - that of getting players into the system and validating them. To do this we merely modified the standard Unix Telnet daemon so that instead of using Unix password validation it validated users via our user database. When validation was successfully completed, instead of firing up the usual shell program, it connected the player's client to Federation. A neat solution, made easier by the availability of the source code for the standard Unix utilities - score one for the open source software movement! This left us with the final of the three problems above - how to track usage. We needed to track usage because we wanted to charge by the time the player was on the system - 60 cents an hour. A flat rate system wouldn't have this requirement. Either a player had paid this month's subscription, or he/she hadn't, and the checking would be handled at logon. I have to say, though, that even with a flat rate system I suspect we would have had to eventually build in usage tracking so that the players could see their usage times. There were two possibilities for the tracking. Either the billing itself could track player usage - probably via the Telnet daemon that logged them in - or Federation could track the usage and report it to the billing system. With an eye to the future - when more than one product was up and running - we opted for the latter. It makes sense, Federation is the program best placed to know which of our users are logged on to it! To handle this a small set of library routines were written to allow the game to report billing information to the billing system. The intention is that this library will be useable in its present form by other products as they come on line. Only time will tell! So, was it all worth it? I guess so - we are still here, shaken and scarred, but still alive. Would I like to do it again? Definitely not, the last eighteen months has been a total nightmare. I think someone must have cursed me to live in 'interesting times'. This set of articles is in one way misleading. With the benefit of 20/20 hindsight I have disentangled the various decisions and threads to make it obvious what we were doing. It perhaps gives the idea that we sat coolly in Federation Towers calmly evaluating the alternatives and rational deciding on each course of action. Far from it, I'm afraid. We were as disorganised and as chaotic as the next company, and all the things I've discussed were going on at the same time, affecting and interacting with one another. And over everything was hanging the AOL deadline - a Sword of Damocles that shadowed every decision right from the start. This pressure caused us to make bad decisions, not think through the implications of what we were doing. It also meant that we had to live with the consequences of those decisions, because there was no time to go back and re-do anything. But, I suspect that is merely a reflection of the fact that we are living in a period where software is still at the cottage industry stage of development - pretty large cottages sometimes, but cottage organisation none the less. Some people argue that this is in the nature of software development - like mathematics the ultimate intellectual activity - and that may well be the case. Certainly none of the tools currently available show any sign of turning software development into an industrial process. On the other hand I'm pretty certain that 19th Century cabinet makers looking at the advance of the Industrial Revolution also thought that the nature of their work was such that it couldn't be mechanised! Have fun - may all your bugs be trivial ones.
|
If you have any questions or comments about the articles on my web site, click here to send me email. |