Fed2 Star - the newsletter for the space trading game Federation 2

The weekly newsletter for Fed2
by ibgames

EARTHDATE: August 9, 2015

Fed2 Star index Fed2 Star: Official News page 1 Fed2 Star next page


by Hazed

A few days ago, when I was planning what stories would go into this issue of the Fed2 Star, I asked Alan for a progress report on the refactoring work he is doing on the game’s code to make it more compatible with a future browser-based front-end.

He mumbled vaguely, but when I threatened to put something rude into the news about his failure to communicate, he coughed up a progress report. This is what he said:

Where it's at...

My current project is to get a front-end for Fed, similar to that currently available as a native Windows application (Fedterm), running in the browser. The problem is that we already have two different output formats - ASCII for people using front-ends like telnet and CMud, and XML for people using FedTerm. If we want a browser version, we really need to produce the output in HTML, or a format called JSON, which is the native data format for JavaScript (which is what I plan to use).

The problem is fairly simple. FedTerm itself wasn't really planned, it sort of came into existence  at AOL, via Borland C++ Builder, and evolved over a number of years. This has the predictable result (with 20/20 hindsight), that the code formatting the output is scattered all over the code base. There are literally thousands of places in the code where the game needs to send messages to players. All of those messages have to be formatted, even if it's the default 'Just display this as ordinary text'.

So, what I've been doing is gathering all the formatting information into one place instead of being in several thousand places. Instead of each different bit of code doing the formatting itself, the code sends the information to a central clearing house (aka a 'filter'), with details of what sort of information it is. The filter then looks up what sort of terminal the player is using, and formats the information accordingly before arranging for it to be sent. This is a simplification of what actually happens, but it captures the essence of the process.

There are two important issues involved doing this. The first, and most obvious, is that the new code mustn't have any bugs in it! The second is that the output when I've finished must be -exactly- the same as it was before I started. If you want to get some idea of the complexity involved, and you use FedTerm, go to the 'Help' menu and click on 'Display Server Stream'. Log on, move around a bit, go to an exchange and wait for a few prices to be displayed, then go to the systems tab and select a system and planet to look at. Finally click on the Scrollback tab, and you will see the raw data that's coming down to FedTerm displayed in all its XML glory!

So, I hear you ask, just how many is 'thousands'? Well, since I knew someone would ask, I just happen to have the figures to hand... There are exactly 2,286 places in the code where the server needs to communicate with the client. Since the number of lines of code for each item is not constant, I can only give you a rough estimate that it's probably somewhere around the 5,000 to 6,000 new lines of code written.

And once this is finished, I can look at writing the code for a browser front-end for Federation 2!

Fed2 Star index   Fed2 Star next page