barleyguy: You're still not understanding what I'm talking about, at all. I'm not going to try to explain it a third time.
Always entertaining when "common practices" tied up to conventional distribution models (invented less than 10 years ago) suddenly is turned into the only possible solution technically.
But yeah, of course you're right. There's no licensing schema that will force HelloGames to disallow users from creating universe instances on their own computer, or a different server of their choice. If it was, it would have to be tied to an existing service ecosystem, for example. Although even if it ran on MS Exchange ... hehe, sorry... even if it ran on Exchange, it would probably not be illegal to use parts of the foundation and license the use of that as a separate product tied to this particular release. It'd cost money, but it wouldn't be anything actually preventing you from deploying it in a different usage-scenario.
What is very typical, though, is that you tend to leverage existing snippets of code that does something in a particular way, and end up favoring similar solutions compared to what has been used before. And it's not like it makes a lot of sense to spend time on creating anything complex or serverless for maintaining the universe status, like a cross-platform cluster-distribution of names for creatures and general exploration status.
Not that it would take a huge amount of effort to do it, but you would essentially spending time on something that removes or "unprotects" the distributor's statistics and user-status. And if you want to deploy this on consoles, you would have to go through the console-makers' conventions as well. So since we're talking about Sony here, this is something you would likely have had to plan several years in advance. Like people mention, the always on model's main purpose is to log how much time people spend on certain games, to have something to go on when it comes to user-base and future purchases and interests of such and such players. And it gives "value" to the title in form of documenting that people spend so and so much time on it.
Having deployment control is really a very secondary concern - UBISoft, for example, took the distribution problematic with piracy seriously, and have simply spent ridiculous amounts of money on making their system inconvenient and cumbersome. Very similar to their approach with Starforce back in the day - the installation essentially blacklisting software and devices on random computers that prevented the installs from completing. I know, because I used to be part of a filesharing portal admin, that the amount of people who started pirating games because of Ubisoft titles very specifically (after they owned the games) is .. significant. It's not anecdotal evidence from talking to a couple of people, it's a look at the popularity of crack/nocd releases next to the full release purely statistically. You could object that perhaps people just downloaded the discs and shared them offline, and that this is why the nocd/offline package releases stayed. But the idea that someone keeps sharing the nocd release for the last patch several years after the release, and then shares the disc on a different sharing network, just so us other pirates wouldn't be able to see it in our statistics is.. a bit too fantastic.
And talking to Ubisoft folks does usually lead to them admitting that they don't actually have any faith that the DRM system prevents piracy (in fact they fear the opposite, like it is possible to document they have reason to be worried about). But that they keep the DRM/online portal model there anyway, because:
1. It allows them to document their users and their purchase habits.
2. It allows them to target their users with advertisement more effectively (whatever that means).
3. It allows them to predict how much a title will sell (with better precision than when scrying the future in tealeaves).
4. It allows them to integrate microtransactions in the actual game.
Last one of course being the big one. If you can deploy a title and make sure that you can let people spend their phonymoney (bought by real money) in the game, this is a salespoint to people who buy games for their kids. If.. you have established on beforehand that microtransactions must exist. And it then makes it possible to "differentiate" the cost of the title more fairly to people who spend more time with it. Like.. the guys who just buy the title for full price gets to play most of it. And the ones who really like it get to spend more than full price! It's brilliant.
Positive aspects of the always online content portal schema, that we of course were sold on in the long long-ago was such things as that you could log in on one computer, have "cloud saves" as it's been known later on, and then resume your title on some other device.
(.... broke the forums again, sorry..)
(cont'd)..
And some companies actually do provide that now (although notable exceptions being games-companies, who tend to insure splits between platforms, and have partial syncs of achievements and progress that generally serves literally no purpose for the user (but again allows the developer to see how much progress people who bought the game made, generally). Like Spotify or Netflix, for example, by saving your progress in an episode or a playlist or songs, and so on, between devices. And that's useful - and it of course is not reliant on a locked content portal to actually provide that in any way.
In the same way, that multiplayer games tend to be routed through a server-side service is actually not a very efficient way to do it, or a very solid way to make sure users get a stable service. In fact, there's nothing nefarious about why MMO games tend have all their communication routed through a status server, where the account is updated fifteen times every second, etc. Instead it's usually because the developer just don't care to plan for when they actually would need to run account syncs. I.e., let the players spend in-game currency and earn events offline for hours and hours, and then validate local content to the server during transactions or syncs - perfectly possible. But it would put certain limitations on when interactions between online players could take place. So why not just have some application phone home every second, and log your every step on the server, right? No one minds until the servers burst and the entire network is dead because someone overloaded a node in a particular region at, say, peak hours.
Take Battlefield, for example - brilliant example. The actual server structure in that game is extremely efficient. But to actually play the game, the progress and unlock status had to be synced at the start and the beginning towards EA's rickety backend. So BF3, for example, was offline for large parts of the weeks after release because the stat-server backend broke. It still regularly breaks and has to be rebooted - and they know exactly what the problem is, other than that their lookup routines and database structure is essentially one step removed from the oracle example database. But they won't do anything with it, because they're already paying for upkeep to maintain the current system (by rebooting it every week). And paying to upgrade it would just be a cost with no return, as user-satisfaction is measured in "yay, I can now log on again - thank you so much, EA, I love you now".
(more rant)...
So there's no push from anyone to actually provide a better service, and also very little knowledge about what the options are in the developer clusters they wish to leverage solutions from. That being of course very cheap providers of quick and dirty solutions on project contracts - because they take so much less money for developing this than people who actually know what they're doing. Such as DICE, who developed the game and the netcode for their games here, that actually worked. And who made recommendations for infrastructure backbone that EA then ignored. You know, things like that happen.
But the end product had to be a portal service, where everyone connect through EA's backserver before they get to log on to the game. In practice, most of the traffic doesn't actually go through the portal at all. But they had to tie it to the EA accounts because reasons. So that's why you're not allowed to take DICE's very good server code, put that on your private server, and then offer that server to public play or to private play, like we did back in the old days.. you know.... 2005.
Anyway - about No Man's Sky: so let's assume that it makes sense to have a central universe server where everyone post their naming of the planets and the species, and log in their progress. And where trade prices and gear (new gear, updates even, universe maintenance, patching, faction movement, genocides, wars, ecological disasters, space station progress, etc.) would be run through, for all active users.
(last part, I promise...)
Would that prevent Hello Games from creating a lan instance where one player hosts a normal game, and a second player piggiback on their instance? Of course not. Would there be anything stopping Hello Games from making an offline universe, and seamlessly integrate that into an online mode that people might skip into whenever they feel like? No. Would it be possible to have a lan or private universe play that spans the whole of the galaxy? No. Their model doesn't actually fetch planet location or specific information from a universe server, and also doesn't populate the planets via the universe server. So there's nothing stopping them from doing that logically or towards some game-flow perspective. And there's certainly no licensing problem involved if they write the communication protocols between the clients to the project, even if that's done with licensed software.
