Dev Log Week 2025-24: Tough calls

English Boards
1

Last week I ended my devlog on an optimistic note, saying that productive feature development is on the horizon again. I guess this still stands, but maybe not in the way I intended :smiley:

As written in said devlog, the biggest challenge after loading the migrated version onto the test server were data access issues. This isn’t all that surprising, as that’s where the vast majority of changes took place. But I more or less got stuck there, so I posted a question to the respective library’s forum. As this library is an open source project and we don’t have a commercial support contract, I (rightly) expected the answer to arrive late (if at all). So while waiting, I switched to a different migration: An upgrade to the application framework we use and which was and is the actual motivation behind this whole “Spring migration” to begin with, namely to use a framework that brings a few features out of the box that I deem necessary for adding a proper API to AirlineSim. This API will be great for users and 3rd party tools, but it’s also the foundation for the “third generation UI” for AirlineSim which I want to get started on as soon as possible.

Long story short: This switch is quite a technological leap for good ol’ AirlineSim. And like a blind frog, I basically leaped against a wall :rofl:. Remember, the current version of AirlineSim is based on a technical foundation from the early 2000s. We introduced a component-based web framework pretty much immediately after the first public release, but quite a few parts of the game still use an antiquated action-based one that, believe it or not, renders its pages using a technology called “JSP”. And for good reasons, this tech simply isn’t supported in modern frameworks anymore. So I have to make a hard call: Employ some ugly hacks or a half-assed migration to keep supporting JSPs for the time being. Or finally do away with all that dead weight and remove and/or rewrite the affected pages. Just to give you an idea, these are the parts of the game that would be affected:

  • the start page of the game (where you can see the current fuel price, latest in-game and meta news, etc.)
  • almost everything to do with stock exchanges
  • a lot of pages around aircraft types, like aircraft comparison, performance tool, the aircraft family listing, order books, ordering aircraft etc.
  • aircraft maintenance
  • service profiles
  • some parts of pax/cargo terminal management
  • enterprise cash flow schedule
  • interlining contract management
  • operations control
  • staff management and pilot training
  • flight detail page (including costing)
  • a bunch of info pages, like country and subdivision pages, fleet lists etc
  • global statistic pages
  • some parts of in-game messaging
  • several internal admin tools

Anything that has a path starting with /action/... in the game an overall quite a bit of stuff. But as you can probably tell, all of these things are really old. Many of them have entries on the roadmap for replacement or, as in the case of the stock market, for removal. But it’s nothing one does over night. For country listings and statistics I wouldn’t mind “just” replacing the pages with newer versions, but I’d hate to rewrite the current version of - say - aircraft maintenance just to replace the UI, when the underlying feature suffers from a lot of game design issues.

I will almost certainly go with the “hacky approach”, just because I can neither afford to maintain two versions in parallel until all work is done, nor just remove stuff and have players play an “incomplete” game. But something has to be done.

Fortunately, I’ll have some time to ponder these things this week…today’s my birthday, and starting Thursday I’ll have a 4 day weekend. Let’s see whether things will have cleared up next Monday :smiley:

3 Likes
Dev Log Week 2025-25: RTFM
3

I would suggest you get rid of the dead weight and make a full update to a new system. Otherwise, you will end up like the real FAA…trying to make things work for products that are no longer in service and that cause more and more problems as you get further down the line. One major upgrade that is not backwards compatible in 20 years is perfectly reasonable on your part.

Just a suggestion. But, what about saying that the current version of AS is locked and will not be updated any further. Obviously, you would still have to update your servers for security risks, but not change the game design any further. Then, work on the updates you are thinking of and at the same time that you release Quimbly XVII using the locked version and at the regular cost, enroll anyone who plays the new Quimbly XVII into Quimbly XVIIa running your new system at no cost to the player. It may be a pain, but I for one would be willing to play two games in parallel to help you make the transition and to give you real-time feedback of the updates you were making. I think a lot of us would since we call all see that not tying yourself to the antiquated system would make it easier to release new features.

Perhaps, delay the Quimbly XVII games by a few months or so to give you time to program key features into the new system. Anyone playing Quimbly XVIIa would know that the features you listed above would not be included until you had updated them but that they could use the Quimbly XVII game to get a rough approximately of cash flows, etc., and to obtain aircraft comparisons, performance tools, and such on the Quimbly world.

If you do not want to delay Quimbly’s release, release it in the static version and continue on your updates until you feel you are ready to release a prototype in parallel. Then, use whichever game world is to be released next.

The changes I would ask you to prioritize in the new version would be ordering aircraft (if it is easier for you to program it, at first just make it so the aircraft are delivered immediately so you did not need to keep track of the orders–add that feature when you get the chance and that new pilots were ALWAYS hired until you had the crew management system ready); cabin configurations and service profiles; flight detail pages; enterprise cash flow schedule; staff management and pilot training; the info pages; interlining; and then the rest. So long as ordering was already in place, the rest of the “the pages re: aircraft types, comparison, …” could be found on the Quimbly XVII server. Since you know several of the updates you want to include, programming the new system to work without JSPs would permit you to ensure that those items could be updated and expanded in the future. E.g., as you programmed the cabin configurations, you could plan ahead and ensure that your data structures are designed so that you could easily add different economy options as part of the current three choice menu later on.

For the various permanent servers, schedule a transfer month during which no one will be allowed to make any changes, run the month at 7x speed, and export the end of the month profile in a format that can be read into the new version. Then use the remaining three plus weeks to install the upgraded version, upload the data file, and try to run the game for a few days before “resetting” back to the uploaded file at the end of the month. You could even stagger them out, if that was easier.

I personally would also be willing to make a small one-time donation to help you account for the month(s) that your server(s) was not running a paying game so that you did not go bankrupt trying to improve the game. Estimate how many months you realistically think you would need to finish the major upgrades for the world running in tandem until you think you would feel comfortable releasing that updated version to run on all the game servers as a new game world came on line. Quadruple that amount of time as programmers and engineers tend to be way too optimistic in their delivery time estimates, and use that estimate as the basis for a request for funding based on your real monthly costs for the server(s) that would not be bringing in funding. Add (Donate to System Upgrade for 5 euros for the new system architecture or 130 credits if the Upgrade is stuck as the “half-assed” job if insufficient funds are collected) and other (Donate to System upgrade for XXX euros … or YYY credits) to your options under buying credits for a limited time of, say, one month, e.g., the month of July. If you receive or exceed your goal amount of funding donated to the game, the full upgrade goes forward. If, at the time that you finish the upgrade to the point where you are only releasing it on paying servers, you still have funds left over from those donated, prorate it as a deposit of credits into the donors’ accounts. If you do not get that funding, convert those people’s funds into game credits and stick with the “half-assed” migration. At that point, if people complain about your upgrade, you can honestly say that they should have put up the funds so now they can shut up (well, only if they were not one of the donors :slight_smile: ).

Happy belated birthday and enjoy your extended weekend.

K

1 Like
4

Thanks a lot for the supportive input! I am happy to say that things have turned out much more positively after I wrote the devlog. The JSP issue has been more or less resolved…more on that next week, of course :wink:

That said, replacing those old pages still isn’t a matter of “if”, but of “when”. It’s just that I favor a slightly more cumbersome “continuous delivery” approach, where the same system runs in production with different configurations in every game world, rather than maintaining two versions in parallel all by myself. And let’s face it: Whenever a new slightly disruptive feature comes along, I’d be faced with the same “version split situation” again. And AirlineSim players tend to find the tiniest of changes “disruptive” :smiley:

2 Likes