I received a question via e-mail about the game's time strategy, whether the game is turn-based on moves forward in real time. Here are details of the current plans to which comments would be appreciated (via our forum for example):

The first version of the game will use a turn-based time calculation. This means that one turn in game lasts for 1-4 days real time (depending on game settings) and one turn equals one month in game time. So all players have the few days time to make their moves and after that the results are processed, incomes calculated and game moved to next month. This approach has been selected because it gives players more equal chances to affect the status of their gameplay without having to sit on the computer "24/7" and watching for game developments. Also the turn-based game is much more server friendly as the results are processed only once every night (at off-peak times on the server). Airwaysim is running on a dedicated server among a couple of other flightsim/aviation sites but we of course don't want the project to be a server resource hog.

The second option is to have a real-time based timing. This means that for example one day in real time would equal one week of game time, and also that the calculation process of results is ongoing all the time in the background and game moves on day-by-day in game time. In this option the gameplay needs more attention from players if they wish to succeed, but also the management moves they make will be getting almost instant results while in turn-based game the player must wait till the next turn to see the results.

Like mentioned, the first version is being coded as turn-based game due to reasons above. And also more importantly, we wish to test the calculation processes and code with a large player group to see how much resources the calculations use with a 500 player game for example. All the options are still open however and it is still at this point fully possible to make the game "real time" - the game's user interface itself fully supports that and the calculation process code will be also built this in mind. Naturally the strategy change is not a flick of a switch, but in this early stage of development, we will take both options into consideration for future use. Or perhaps even make the game support both types of timing, depending on the game in question.

Comments are appreciated via our forums.