Game World #4 starts 29th Apr 2018

[Sami]

The new Game World #4 will open on Sunday April 29th

» Pre-join now!

GW#4 is one of the four main and long airline sim games at AirwaySim. This time the starting year for GW#4 will be earlier than before, the time period is 1955 to 2035.

Your new airline in 1955 has plenty of opportunities with the arrival of new post-war piston-engined propliners and the first jets are not far away either. The first decades offer an interesting period in the history of air travel and you can continue to build up your airline empire into the future.

This game world, like all others, will include the cargo features powered by City Based Demand system. And as a twist from the normal random events in the system we shall also create more random (non-historical) events that affect the global economy and air travel demand.


You can already pre-join this upcoming game world. Go to the Game Area and you will find this new game waiting for you there. With the pre-joining function you can reserve a spot in this new game and we will e-mail you to remind of the game world's opening.

The opening time of this game world will be at approx. 15.00 UTC on Sunday 29th April. The first 24 hours of the game is static and the game clock will start on Monday.

This game world follows the standard settings for long AirwaySim games:

• Standard difficulty level
  
  
• All airports, all aircraft models (including the "prototypes") and all features are included.
  
  
• Additional base airports follow the standard rules, max 10 bases per airline, and the amount of planes based outside HQ will grow over time.
  
  
• Alliances are available to be formed from the first day.
  
  
• Game's speed is initially 30 minutes per day but will speed up to 25 minutes per day in 1990.
  
  
• Passenger demand levels are much larger than in real history at the start of the game, especially in the early parts of the game.
  
  
• Fuel prices are random and may or may not follow the historical oil/jet fuel developments (or a combination of both where it follows the real history at some periods and is random at others).

» Pre-join the game here

[MuzhikRB]

will be any modifications to new AC ordering process included in this GW ?

[Zombie Slayer]

[/li][li]Passenger demand levels are much larger than in real history at the start of the game, especially in the early parts of the game.

This. While it makes the early game more interesting, it absolutley destroys fleet transition. IRL aircraft sizes grew with demand growth. With this inflated demand early on, demand does not increase with aircraft size thus making fleet transitions significantly more painful than they have to be. GW2, for example, many routes that I scheduled to ~110% of demand *25 years ago* are still not under 100% supplied. When going from 80 passenger Caravelles to 105 passenger F100's (an aircraft chosen simply because of its size, everything else is too big without massive rescheduling) it causes issues.

I for one would MUCH rather go back to 200 players to start, growing slowly, rather than this new inflated initial demand and slow to non existant growth over time.

[gazzz0x2z]

While I disagree with the solution, I agree that the immobility of the demand since 1970 in GW2 is rather boring. I had quite overloaded my lines because the battle for Poland was pityless, and now I'm at 60% LF just because there is not one single more pax in 1990 than in 1970.

[Cedric3108]

Well, I think the best way to go about this is also the most complex one. The real world airplanes we use were designed with the hub-and-spoke system in mind. Since this isn't modeled, we have to work with these work-arounds like increased demand etc. If connecting passengers/cargo were modeled in AWS you would automatically have to increase you average aircraft size with every fleet transition, simply because you network grows and so does the number of passenger connecting to your "old" flights. I know this is incredibly hard to model and probably even harder to display in such a fashion that is play-able.

ZS, I'm not here for so long, how was it before? 200 players max at game-start, but more gameworlds? Or simply less people playing this game?

[Talentz]

I agree in principle with Z, pax numbers should remain normal (non-inflated). However the reason is a bit different. My reasoning reflects my (initial) view of the CBD-Pax roll out.

Pax numbers will be far less then what were used too and it will come as quite a shock for most, more so the longer term players. I think the trend in AWS GWs should start reflect this reality and generate "normal" pax numbers to get the playerbase mind set ready for this. Even if CBD-pax is still months from coming to term.

Personally, I think with the addition of cargo to the early start, this should give players different options and strategies to play with. Not solely focusing on pax only, domination starts.

Anywho, that's my view 


Talentz

[Tha_Ape]

@Cedric

Less people to start with (to divide less pax amongst less people), then progressively increased as the demand catches up.
A bit like the A/C outside HQ limit, but for players.

[schro]

Well, I think the best way to go about this is also the most complex one. The real world airplanes we use were designed with the hub-and-spoke system in mind. Since this isn't modeled, we have to work with these work-arounds like increased demand etc.

Nope. Hub and spoke operating models didn't appear until the late 1970's with AA's hub at DFW and DL's hub at ATL.  Prior to that, especially during regulation, you'd see far more point to point and milk run style routes - i.e. RDU-GSO-CLT-GSP-ATL - and if you wanted to fly RDU to ATL, you'd get to stop at all those other airports along the way.

[Zobelle]

Nope. Hub and spoke operating models didn't appear until the late 1970's with AA's hub at DFW and DL's hub at ATL.  Prior to that, especially during regulation, you'd see far more point to point and milk run style routes - i.e. RDU-GSO-CLT-GSP-ATL - and if you wanted to fly RDU to ATL, you'd get to stop at all those other airports along the way.

So you’re saying...allow ABCBA in the early game?

[Jake]

So you’re saying...allow ABCBA in the early game?

IMO that would make the game much more realistic (until hubs became a thing that is)

[Zombie Slayer]

IMO that would make the game much more realistic (until hubs became a thing that is)

It was a thing until about 8 years ago. Was replaced with bases.

[schro]

So you’re saying...allow ABCBA in the early game?

Nope. Not at all.

IMO that would make the game much more realistic (until hubs became a thing that is)

Not really. There are many aspects to the game that are intentionally not realistic to make the game more playable. If you wanted things to be realistic, then you'd have to get every new route you wanted to fly in the US approved by the CAB which also set your prices for anything you fly before the early 1980's. Sure, then you could watch deregulation send things sideways for a bit once price and destination regulation goes away, but who wants to mess with that as a player? That sounds less fun than having a base at HND when NRT opens.

The main benefits for hub flying are related to connections (which aren't modeled) anyway. There's an effect called the "S curve" that applies to revenue as you add frequency and more destinations to a single hub - makes for some good economic theory reading if you've got some time to burn.

[Zobelle]

Yeah but wouldn’t it be fun to try ABCDCBA along with bases?

It’d be great to fill a plane up as you go along and in route back.

[wilian.souza2]

If connecting passengers/cargo were modeled in AWS you would automatically have to increase you average aircraft size with every fleet transition, simply because you network grows and so does the number of passenger connecting to your "old" flights. I know this is incredibly hard to model and probably even harder to display in such a fashion that is play-able.

AWS has already an embedded demand generator that creates demand from tiniest cities to big metropolis like New York, so the next step would be to create this feature of transporting demand from one place to another. And it isn't so hard in principle; Railroad Tycoon featured cargo connection between stations since its first version, back in 1989. You could, for example, pick up coal on station A and drop it on station B, which didn't have demand for it, but you could leave it there until another train pick it up and take it to any place where there was demand for it.

[MikeS]

AWS has already an embedded demand generator that creates demand from tiniest cities to big metropolis like New York, so the next step would be to create this feature of transporting demand from one place to another. And it isn't so hard in principle; Railroad Tycoon featured cargo connection between stations since its first version, back in 1989. You could, for example, pick up coal on station A and drop it on station B, which didn't have demand for it, but you could leave it there until another train pick it up and take it to any place where there was demand for it.

The principle is easy. The problem is how to process the calculation of millions of daily connecting passengers with all route possibilities on a web based game.

[wilian.souza2]

The principle is easy. The problem is how to process the calculation of millions of daily connecting passengers with all route possibilities on a web based game.

Computers today process zillions of calculations, and I think the processing of these logistic calculations is no more complex than, for example, rendering a Unity-based web game. So we could try it for sure!

[gazzz0x2z]

Computers today process zillions of calculations, and I think the processing of these logistic calculations is no more complex than, for example, rendering a Unity-based web game. So we could try it for sure!

Nope, as it goes cubic, if you allow, let's say, 2 depots before cargo/pax reaches destination. 2800 airports means 21 billions of flights possible with 2 connections. For each, you've got to manage quite a lot of information. Worse, you need to make comparisons between routes. for each of the 8 million possible route pairs, you'd have to compare 8 millions of routes. Each day.

Another way to do is to manage each passenger individually. You trade the route complexity for pax complexity. Would be probably more realistic, but the weight in RAM of having each pax individually modelled, deciding individually to make BOS-JFK-AMS-MPL instead of BOS-FCO-MPL (I had actually to choose between both 2 years ago), and also in computing power, would be huge either.

It's not a problem of complexity. It's a problem of sheer numbers. It's probably still possible, but with servers that can't be paid with what players are paying those days. There are probably plenty of algorithm optimizations possible, but the problem remains. Each abstraction layer that disappears has an exponential cost in terms of computing power.

[JumboShrimp]

If you read through the City Based Demand thread, there are quite a few posts about connecting traffic (cargo and pax), how the calculations can be cut down.  You can go back a few years...

SQL throught its magic can accomplish quite a lot, to identify the candidate flights for, say MPL-BOS.  Let's say it comes up with 100 candidate flight combinations, ranks them and selects top 20 (or more or less depending how busy the route is).

Since route creation and destruction happens VERY infrequency, the above complex SQP does not have to happen every day, only say once per month.

Every day, the system would do its allocation among the 20 candidates, very similarly to what the system does today with direct flights.  Additionally, the table of candidates would also keep how successful the candidate was in attracting passengers.  Then at the end of the month, it would dump, say bottom 5, it would re-run the SQL and get new top 5 candidates to replace the 5 that were dropped. 

So this way, the time consuming processing to identify the would be a background task run at low priority.  There would be some increase in processing because the number of flights (direct and connecting) between say MPL and BOS would be higher.  CBD may have a demand of 15 pax, and for such a low demand, probably no more than 5 candidate connecting flights would be needed.

[Sami]

Some quick answers while waiting to press "go":

- a/c ordering system is naturally the same as before (no announced updates for it), but I am considering some changes for the "launch rush" of new aircraft (probably allowing for example a few game months of time where everyone interested can place orders and slots are given only after that). Any changes will affect all games, and announced (& discussed) separately.

- Demand levels are higher compared to standard game settings, but lower compared to previous early game world start. You can expect a steady growth, apart from possible local economy changes (cargo) and major events (pax/cargo). This time the events can be longer lasting too, so while the passenger travel index does grow all the time the events will create periods of slower growth, steady situation or even decline (to keep the game more interesting).

- ABC routes were indeed the reality but traffic was also regulated. And that wouldn't be any fun....

- Cargo and City demand systems are not yet perfect, but eventually I am hoping to introduce the connections etc. too. But utmost care needs to be taken so that the interface is good and naturally of the technical resources too. But a lot to do before all that, so not a relevant discussion yet.

Anyway.. 5 mins to go.