barleyguy: Very lucid and informative perspective. It makes sense that something like Battlefield does a lot of small-group communication, because in that case it's easy to know who the peers are. Generally they are the people in the same instance of the game. But in No Man's Sky, I'm not sure there's a clear definition of who the peers are. Are they the people closest to you geographically in the game universe? But actually I'm not sure it matters, because it's not a true MMO, at least not at launch. The central service seems to mostly just be a database of names, for planets people have visited and named, as well as the plants and creatures there. I think currency things like trading may also get transmitted between users, but maybe that doesn't even happen.
Right. There's got to be very little time-dependent checking going on (even if I'm sure Sony HQ will want everyone's avatars and screenshots, smileys and blurbs of the day to jump at you every time you're within three lightyears of a different player). But since there's no need to actually update anything in real time, it's possible to structure for updates in the background that for example cause no locks, and doesn't mysteriously hang the program, or happens to open 5000 ports into the firewall and other lan-addresses through the .net package before hanging the entire computer, etc. But we'll see.
Thing is that almost all "server-side application" servers today actually are distributed in some way. So even if you actually wanted to make sure all instances were synced at all times (but really .. who would care in No Man's Sky?), you could do that towards distributed cells too, to make sure you don't just have one single database that croaks every weekend, like EA (and a lot of game companies have). If not Oracle, then .Net - but it's not complicated to do it properly either. It's just that what large companies normally do is to hire consultant firms that create one specialized solution for their particular instance of a database server. And then they.. sell that solution about 100 times every year to equally happy customers. And run the different server software on the same servers, etc.
You have to be really well paid to understand why this is great, apparently. In the same way that you have to be really poor to think that a distributed and primary serverless network is an actual alternative that is much more efficient and less prone to collapses.
But what you'd do is to have master-nodes (and sub-nodes), and then refuse to shut down those master-nodes until they update a new live cluster. And since we're not talking about banking here, there's really no danger if you end up losing the exchange once. Because you simply store it locally and try again when it becomes active near another node. So you'd distribute updated clusters (not just the next client, because then the datamass would be huge), but have logic on each client that syncs if any overlaps exist. And then you destroy the updated node traffic and replace it with ones that are not current. Frequency doesn't actually have to be very low before the total amount of bandwidth used is reduced compared to a master server system. And it doesn't actually scale upwards per user. This is basically peer-to-peer in a nutshell, right..?
Questions that frequently turn up is:
1. wouldn't people hack this really easily...?
And no, that doesn't have to be a problem if the security model actually can assure the other clients are valid. Most of the weaknesses we have on master server systems now come from the fact that they rely on obscurity rather than actual security. It's well-known, and if people knew how screwed they and their online banking really were before SSL, they would freak out. But yes, of course you can validate a client to another client in the same way you would validate it towards a server. And then refuse any unsecure or improperly signed transmission through the galaxy-com.
2. but the entire cluster will always be out of date, and the amount of contests will be massive.
Yes, but when you're not dealing with real-time anyway, what does it matter? We're talking about a special case here where that one guy in Camden is somehow picking your exact route through the galaxy, and always naming the new planets "SUCKY BUCKFACE!", "MY PENIS!", and so on, right ahead of you. So that whenever you backtrack, all your "Pink Borealis", Purple Moons, and "Playmate Bunny" species and planets are gone. But if you're not actually having content locks for real-time contests anyway - and that will not be an issue on a game-server like this - then the concept is actually identical to a server model with or without physically distributed external server components.
Not insisting on anything one way or the other here. But just food for thought, and for some context for why we always seem to have this "always on" schema". Because what you have 99% of the time with games is actually a login server, that you have to say you're still alive to once in a while. So that any updates you want to make to a different server instance is supposedly validated towards a user. You know, this makes sense in banking (and when real money is involved, just to make sure people don't spend the whole bank before they get validated, etc). But if you don't need to deal with that, then this is complete overkill. Actually, most banks worth anything will insist that you do not stay on a validation server (as presence like that can be fabricated - although it is difficult), and instead validate yourself every time you actually perform a transaction instance. (I talked to a guy who had been arguing about this with a bank - they had to force them to accept that if people were to have secure login in the first place, then this would make sense and 100% ensure that no one managed to add extra transactions to valid certificates, etc. They also demonstrated that the traffic bandwidth compared to some radius-ish server was negligible.)
So to have people somehow lose connection to the universe server, and then have to log out, and hard lock and f***, etc. This is usually just annoying, draws massive amounts of resources (linear running times per user - at some point all those real-time updates before you get to the navigation screen, etc., are going to create a pause - you know it on beforehand), and is completely unnecessary. On either a master or a distributed model.
barleyguy: Where my licensing argument comes in is that the "Universe Server" as you call it, probably runs some portion either closed source software not created by Hello Games, or open source software with a viral license. The most likely thing would be the database. (Maybe I'm wrong and they wrote their own database, but I doubt it.)
Why wouldn't they make their own? :p
Anyway. You could just use common open-source or project specific modules, and then not claim ownership over the transport protocol, for example. That's.. out of the question at Microsoft, for some reason.. presumably because they think the information in the packets people send belong to them or something. But there's nothing actually stopping a games-developer (without EA and Sony on their ass) from just having a server, made to work with just one single product, and licensed to be used with this specifically (and of course secured to only work against other clients on this particular instance) -- but where the fundamental components are open-source.
Also, Santa isn't real, vitamin pills can be bad for you, and dolphins have random sex all the time and like to play games with their food. Everything you know is a lie!!!
*cough*... excuse me. I think I broke my "1" key. Drat.
barleyguy: But there would definitely be coding to do for LAN play. It wouldn't come for free. Which I think was the original thing I was trying to point out.
Right. But it would be something completely different from the central universe server thing anyway. You're right that separating it out of the original server-package would be unusual, though. And that this is why the licensing question is relevant. But .. not necessarily a problem.
barleyguy: Or does the second person still see their own names and the first person's names get sent out to every other player?
I think they both should be stored for a while locally, and then updated to some master node. And then the Time-lords could decide which one sounded the least like "boaty McBoatface" in the end or something. :p
And thank you as well. I preach a lot, but I'm looking for alternative views and explanations for them, of course.