The protagonist sends a message to the aliens asking to be allowed to review the alien civilization’s computer games. An AI submind called Smoke-Cursive-Cytoplasm-Snakebite-Singsong-Polychromatic-Musteline is given the task of contacting him by IM to begin the conversation. Its job is only to verify that they are talking to the right human (since not every human has a unique name) so it is only a simple chatbot and can only understand YES and NO responses. It asks if the protagonist understands and gets a sarcastic NO. It has to contact its parent mind Smoke-Cursive-Cytoplasm-Snakebite-Singsong-Polychromatic to ask what to do next. After working his way up the tree of subminds by answering questions of increasing complexity asked by subminds of increasing capability, the protagonist briefly talks to Smoke-Cursive-Cytoplasm-Snakebite which sets him a task to prove that it’ll be worth an (alien) anthropologist’s time to talk to him.

    Smoke-ccs-762d: Well, if it isn’t Mr. Sarcasm
    ABlum: YES
    Smoke-ccs-762d: Don’t quit your day job.
    Smoke-ccs-762d: I’m Smoke-Cursive-Cytoplasm-Snakebite.
    Smoke-ccs-762d: Let’s get down to business.

https://ziplyfiber.com/internet/multigig

Don Eyles even produced an updated version _after_ the Apollo 17 version was released, but before Apollo 17 flew, just to test a theory about how to make the software more responsive during the final landing when a human was actually selecting a landing site. Of course that version required changing the requirements, which in true Waterfall style were part of the contract his company had signed with NASA years before!

And even inside of a single waterfall cycle there is feedback from both automated and manual testing. Luminary was run in a simulator running on a supercomputer that simulated various landing conditions. It had to pass those simulations before it ever had a hope of being used in space. Eyles calls that “unfortunate”, but the reality is that it is simply necessary.

And then there was the manual testing, which NASA did on grand scale for the Apollo missions. They made an accurate 3D model of the terrain near the landing sites on a table. This table hung upside down in a hangar in Houston. A television camera was mounted on a six–axis mount below the terrain model. The mount was controlled by signals from a Lunar Module simulator used by the astronauts, and the image from the camera was fed to the screens outside the windows of the LM simulator. As the astronauts flew the simulator the camera moved along the same path, providing the astronauts with accurate real–time visuals. The LM simulator had a real AGC and ran the most up–to–date version of Luminary as the astronauts practiced their landings. Several improvements to Luminary resulted from feedback provided by each crew as they practiced.

Fundamentally Waterfall discourages iteration because it sees it as a waste of time and money. Ultimately this is because back then releasing software was expensive. Luminary had to be sewn, by hand, into a core memory rope before it could be installed in the spacecraft. Iteration could only happen on that scale because NASA had already planned multiple moon landings. Iteration in the simulators was much easier and cheaper though because they could load the software from disk drives. Those drives were the size of a washing machine though, and could never be flown in space.

The assumption that it is cheaper to fix bugs in the specification before you ever write any software was based on numbers gathered from software development done for the US Air Force. It turns out that if you detect a bug in your missile’s flight software _after_ you have manufactured hundreds of thousands of missiles for the Air Force then yes, fixing that defect is very expensive. You really would rather have found the problem earlier in the development process. But today we can release a new version of our software to hundreds of millions of users around the world with the press of a button. The assumption simply no longer holds so iteration should not be seen as “unfortunate” any more.

Correct. This is why I said that there would be multiple responses depending on the type of component. Many proprietary components are not critical and could easily be stripped out without harming the End–of–life version of the game, like matchmaking. But obviously that still leaves the critical ones. For those the game developer would obviously have to avoid any license agreement that would be unduly burdensome once the game was in the EOL state. Either there are already components without these onerous license terms, the existing components will be relicensed, new ones will be written and made available under less onerous licensing terms, or developers will just write their own. The market will provide.

> So the solution is to just stop developing multiplayer games?

No, not to stop developing multiplayer games but to stop putting networked components into single–player games. Remember that this all started with The Crew, which was purely a single–player game that was killed precisely because it nevertheless wouldn’t run if no server was available. If you don’t choose to make that design decision in the first place then this law has no effect on you at all. Your game is automatically safe from being killed when you stop selling it. You won’t have to do anything extra at all for players to keep playing it as long as they want to.

In practice a lot of those components can be simplified when you don't have to support a huge number of players. A server that only supports dozens of players can just use SQLite instead of a big multi–az database cluster. The cache can just be an in–process cache instead of a connection to an external Redis instance, etc, etc.

If the law passed after the game was released, then it doesn’t apply.

The ideal way for a game company to keep their game alive after they have stopped supporting it is to build it with that in mind from the start. A lot of the server–side components, such as monitoring, authentication, database storage, moderation, anti–cheat, etc, etc can all be made optional. It’s a small upfront cost, but set up the build system so that you can build without all of those components, or with simpler versions of them. That includes anything you cannot legally redistribute. If your last game used a middleware component that was critical to the functionality of the game but that you cannot redistribute, then you do need to find a replacement for that specific middleware component for your future games.

Then, when the end of life date of your game approaches you simply build the server binaries one last time, this time turning off all of the optional components, and let your customers download it. You don’t have to give them the source code and you don’t have to violate any license agreements in the process. Your customers can arrange for any necessary hosting of the servers themselves, most likely by simply running the server process on their own computer.

And of course the option remains to simply write a single–player game that runs entirely on the customer’s computer, with no networked components at all. It’s a little bit old–school, but lots of game developers manage to make money that way.