Cheith

Sorry, but having lived through the initial FTP mania I can tell you that the driver was the whiners who had time but no money - so they had time to make a lot of noise - and drove a lot of companies to make the messy FTP transition (and it usually was messy) and add loot boxes and other crap to their games to support it. The real driver for a lot of it initially was trying to keep up with WoW eating all the subs and no one else having enough to really be profitable (at least not in the way their backers wished). Now, I will agree that it works, but you get for the most part crap in return. If your expected retention is 1-2 months then you don't need a lot of content or good background or single sharded persistent universes on a large scale because no one will ever see it. That is also also fine if that is the game you want to play. If however you believe you are creating a game where your revenue earners will play for significant lengths of time then the subscription model is the way to go. You may augment it with some cosmetic BS that people who wish to pay for it can get but for the most part your revenue is subs. As it also matches your cost model it does make the financial planning a lot easier and more transparent. Of course someone may hate it at that point as they can't play games with the money as easily but that is another story!

What elephant? If you are running something on servers you need a revenue stream - or enough up front cash to invest it to create a revenue stream. If you want a single player game the up front fee is fine - but otherwise not so much. It is not so much an outdated model but a model that the 'I want everything for free' culture bashed at until some weak willed companies crumbled. Also it is only a month's subscription to try a pure subscription game usually (you can complain and I would agree about games with an up front cost and a subscription). Nothing wrong with the model.

In the end the screens are great, and some form of display is required to support the programming, but if they are destroying the basic functionality then the reality is something needs to change. The screen data (that is publicly visible) is a difficult thing to scale - and maybe what is needed is a split between personal screens (cockpit) and public screens. Remember every public screen has to go to every client - the more players there are in the game the more public screens there will be which means it is a multiplicative factor. This is bad. You need things to linearly scale as much as possible. So, maybe the way to go here is in-cockpit screens (ie only viewed by the pilot for example) can be html/svg while public screens need to dynamically generate on the client based on the rest of the data regularly sent there. Just a thought.