Daily Running of Phoenix From the player perspective it just seems a case of create some orders and press submit. The orders are collected, processed along with everything else and the results generated. This can lead to confusion as to why certain things happen as they do. This is essentially a breakdown of what happens on a given day. Start - Around 7am Only turns that have been submitted by 6.50am GMT can be guaranteed to meet the deadline. Download Emails This checks a specific mailbox, pulls down everything and deletes them from the mailbox. It then has to decode any attachments, remove spam and check passwords and positions before adding them to the directory for incoming orders. Possible issues If the mailbox is not accessible the game will halt until the issue is resolved. We once had an issue with somebody mailing their entire turn directory as an order attachment. This caused the game to crawl as it attempted to download and read it for possible turns. This prompted a limit on the mail size to be set. Early on there were issues with unusual encoding for file attachments. These though have long since been resolved and we haven’t had issues in nearly many years.

Download Nexus Turns and Ancillary Data
While the game engine is dealing with the emails, DBsync shunts down turns that have been uploaded to Nexus from off-line order editors and those created using the Nexus Order Editor. Again there is a fair bit of data checking.

Ancillary data includes new ship designs, votes, changes to relations, mission actions and most importantly any new users (sign-ups).

Possible issues
These are not too common though generally relate to the shunting down of data. Data drop-outs can cause partial data downloads though DBsync has an indicator when this happens and a manual download can be initiated if necessary. This tends to occur when there are world events that are making the internet unstable (ISP maintenance, hacktivists hitting major nodes).
Once this has been done, Nexus is updated with the game status.

Maintenance Run
The next step is purely Game Editor and starts the process of organising the daily run. It updates the game with respect to new accounts and mission requests along with working out votes. There are quite a few steps to this of which the primary output at our end is a list of politicals to be maintained on the day and their current wealth.

Once these steps have been completed, a list of positions due for maintenance is generated. All positions undergo maintenance once per week on a pre-set day. For ships this is merely paying wages and seeing if the ship and its cargo decay a little more. For starbases it includes a full raft of checks, including research, production and merchandising to name a few. For starbases, outposts and political positions it will also process any orders that have been submitted for the position along with any standing orders, these being orders that have been specifically set to run at the time of maintenance (special actions are shuffled out and set for processing later in the day). For other positions, their orders will be processed later, even if they are maintained now.

The positions are processed sequentially from the first position to the last in the list.
Possible issues

The only real issue with this is that when a starbase, outpost or political has been set so that it runs after another position. If this happens to be on its maintenance day, it will remove any sequencing as it processes the orders for the position during this stage.

Orders Run
After the maintenance run is completed, the game editor moves on to create a list of all positions that have orders to process. This includes starbases, politicals and outposts that have not had their maintenance on this day. In the case of these positions, they need to have submitted a request update along with the submission of orders of the results of their orders will be appended to their between turns file to be generated when they next have a turn.

This is the longest part of the day and can account for thousands of positions encountering hundreds of positions. The amount of data that is processed means that a lot of effort has been made to make the code run as fast as possible where the code segments are used a lot. Nowadays, all positions are loaded into memory when they are first called and remain in memory until the game is closed. There are still a few more tricks to pull that Darak is working on though the separating of the run into orders and specials means that turns are sent out much earlier in the day.

Possible issues
This is a robust part of the game. If issues occur then it is highly likely that they are due to a recent upgrade. Positions that enter battles have their turns suspended and the position is removed from the front interface to prevent dozy GM meddling. This means that in some circumstances the submission of a special action will not even be accessible until after a battle is run. This can occasionally prove frustrating for players seeking to issue a mid-battle action.

An issue that thankfully happens infrequently is where a sequence includes a position with a special action. This halts the entire run in order for the GM to deal with the special action. The usual culprit is a ship in the middle of nowhere doing a surface exploration that has inexplicably been sequenced to a bunch of other positions presumably by accident. The other suspect is a base issuing a special action along with build hiport and therefore sequenced before the delivering ship. Occasionally, in fact, very rarely, there is a legitimate reason and the special action will be dealt with there and then.

Generally speaking, a halt in the run is spotted fairly promptly and dealt with. If you have sequenced specials into a run and turns arrived later than usual, then you probably have yourself to blame...

Battles
Battles require little more than selecting the identified battle and pressing a button – though the Game Master may take a closer look at any battle prior to initiating it. This may be done if there is something suspicious about the battle. These sorts of things used to be much more common, before the days of alliances, do not target lists and relations. On more than one occasion I have intervened for example when a Confederate (or was it Brotherhood) starbase and platform mistakenly added everybody to the enemy lists. I think that the pre-combat list indicated that a few dozen starbases, outposts and many more ships would have been pulled in.

Possible issues
This has been something of a minefield over the years as players have always pushed the boundaries. The biggest bugbear to date was the sending of entire warfleets into combat without enemy lists. The reliance on defend and support only resulted in spiralling checks as it looked for anyone willing to attack so that it could assign everybody to following them – over a thousand ships and not a set of balls between them. Something of an inruptus castratum. The code has now been modified to prioritise checks making this issue a thing of the past.

Where we are aware that there could be an issue, such as battles with thousands of ships, we will as a precaution take a battle-back-up. This pulls only part of the game data but reduces the time for a restore considerably. Over the years as the code has become ever more robust, this feature, like many others has become largely redundant and an unnecessary time constraint.

Finish Order Run and Send
After battles and updates to battling positions have been completed the next step is to add the manifests to the positions in the order run and any positions in the maintenance run that are to be sent out. This leaves only the positions with special actions, investigations and explorations outstanding.
At this point the game has generally been running solidly for around two hours and everything should have been received before lunch (in the UK).

This step assigns the turns to the email client and DBsync, freeing up the editor for the Game Master to deal with the remaining positions and their orders. As these are two separate programs they run simultaneously. On a day with few internet issues, the uploading of turns to Nexus will take around an hour while emails take around twice as long. Nexus is updated as to the progress.
As part of the step Nexus is also updated to include changes in markets, squadrons, treaties, stellar transactions, missions and a raft of other things including personal data.

Possible issues
The main issue is internet connectivity. While DBsync attempts retries that cope very well with natural blips, a longer drop-out will cause a halt that needs to be manually reset. This can cause timing issues as a complete fail close to the end of an upload requires it to start again. This is because it is normally a lot faster to upload all the data files (html turn results) then update the database that links them to Nexus accounts.

The email client however deals with turns individually so any drop-out simply requires the client to be started again. These are not particularly common.

Specials Run
Before we separated special actions from the orders run there was always the pressure to try to finish the run as fast as possible, or at least defer special actions if it was getting late in the day. This is simply because players need time to evaluate the results of the day before creating and submitting more orders. In the case of battles getting the results of a battle back in the early evening meant submitting orders for the next day was very difficult.

During this phase the Game Master simply deals with the explorations, investigations and special actions submitted for the positions. This is often very time consuming with the need for breaks (some days can feel like sitting exams). More details about being a Game Master for Phoenix can be found in IGN 5. Breaks in this case are often doing other things for the game such as writing IGN’s, looking at data in the game, discussing game improvements with Darak and answering PM’s – amongst other things.

Possible Issues
There is always the situation where a special action can present itself as part of a sequence of turns. Often this is simply a player getting over enthusiastic with the sequence request and they don’t really need some chaps to examine amphibians before their warfleet teams up with the rest of the armada. When these pop up a quick glance at the sequencing list allows the position to be removed from the list. There is also the potential that the actions of the position could trigger a battle though to date this has not happened in a situation where it is at all significant.

Send Specials and Back-up
The sending of these turns is as above, though rarely takes more than a couple of minutes though this second time there is also turn fee charges included. Following this the game normally initiates back-up.

Weekly Markets On a Monday, there is an extra step. This calls the routines that sell goods from starbases to the planetary markets. This step also deals with income generated from claiming systems. This is very intensive and takes more than an hour to run though as it is done overnight, has no significant impact on game timing. Bank Holidays With Bank holidays everything is effectively run twice, one complete day after the other. The only real difference between the two runs is that in the first run only a couple of hours are spent doing Game Mastering (investigations etc). Sometime after lunch when an hour or so has passed since turns have been uploaded, all remaining positions will have their orders deferred. It is not quite this arbitrary though. The Game Master will have a look at the turns to see if some are urgent and try to give appropriate priority. Deferred positions will depending on their type, be pushed through the next run or their next maintenance (in the case of bases). Then it is just a case of completing the stages and starting again with a new download.