The Outer Reaches - The Second Beginning (2000-2006)¶
Originally released in 2004, The Outer Reaches - The Second Beginning was a multi-player on-line space strategy game that was born out of our love of similar games that were around at the time such as Planetarion and Empire Quest.
Whilst these were both great games, we felt they were lacking in some key areas and that what they were lacking made the outcome of in-game events entirely predictable. Battles for example were very predictable because the strategy used in each battle was the same. This resulted in the emergence of battle calculators that could (with some reliability) predict the outcome of a battle just by knowing how many ships would be present on each side of the battle.
Development started in 2000 (if I recall correctly), with the first release 4 years later in the spring of 2004.
The original engine for the game was called Free Widgets Site Engine (a custom webserver that was being built for a side project). The entire website was contained in an Access database and was edited using a collection of forms and tables within the DB.
As the site grew, performance became a huge issue and so a new engine was built. Enter Outer Reaches Site Engine. Again, a custom web server that was built entirely with Delphi 5, but with one huge difference. Everything the server needed to run the site was loaded into memory and every page and script was cached in a compiled state ready to be served.
The server software consisted of four key elements (with database services provided by MySQL). There was the web server, the purpose of which should be self explanatory, the ticker, the lock server and the site editor (shown above).
The ticker was what made time pass in the game universe. Again, a Delphi 5 application packaged as a service, it would spring into life every hour and perform all the calculations and database updates to progress the game. The lock server meanwhile was a Kylix 3 application that ran on Linux and it provided system state storage and record locking facilities to ensure no two system elements could update a record at the same time (but why not use database record locking I hear you cry? Well, quite simply because that comes with baggage that can impact performance and prevent other services accessing the data they require in a timely fashion).
The site editor constructed the entire game site from components (templates, menu definitions, page content) and essentially did all the pre-processing meaning all the web server had to do was compile the page and execute it. For this, Delphi Web Script II was used. Once compiled, the resulting data structures were cached ready for the next time the page was requested.
Design wise the game progressed immensely. The first draft looked like this...
Which was OK... after a fashion, but as the game developed it felt a little dated, so the style was completely reworked to this...
An altogether much nicer looking page and one that took advantage of the increased screen real estate (the old version was a fixed width).
So how did we get around the predictability of battles?
We introduced new fleet orders that meant there was a good chance you didn't know exactly how many ships you were facing and the concept of fleet strategy that allowed the strategy of each type of ship in a fleet to be changed. You couldn't outright have them attack different classes, but you could change the order in which they attacked those classes.
The game was shutdown in 2006 after several cycles of Season 2. Season 3 was nearly complete at this time but interest in this type of game was waning and with rising energy costs, running the system with no return was simply not an economically sensible choice.