this post was submitted on 25 Jun 2025
148 points (89.4% liked)
Gaming
5218 readers
296 users here now
!gaming is a community for gaming noobs through gaming aficionados. Unlike !games, we don’t take ourselves quite as serious. Shitposts and memes are welcome.
Our Rules:
1. Keep it civil.
Attack the argument, not the person. No racism/sexism/bigotry. Good faith argumentation only.
2. No sexism, racism, homophobia, transphobia or any other flavor of bigotry.
I should not need to explain this one.
3. No bots, spam or self-promotion.
Only approved bots, which follow the guidelines for bots set by the instance, are allowed.
4. Try not to repost anything posted within the past month.
Beyond that, go for it. Not everyone is on every site all the time.
Logo uses joystick by liftarn
founded 2 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
With the exception of cross play, those are all only problems due to the massive scale of active and total players.
All of these things are already somewhat modular and very scalable in implementation, by very, very intentional design.
So... running a rented VPS or decently beefy home server that is just geared toward handling a much, muuuuch smaller total player count, with just one of every required module, instead of being networked to 5,000 other server units dispersed around the globe?
Totally feasible.
In fact, its often the case the scalability solution is the major 3rd party liscensed thing that causes this legal headache.
Just design a basic non scaling model that works for a lower player count with a simple dedi server model.
This is actually remarkably easier and more simple to code than what the industry does now... if you've ever run or coded any servers.
Have you ever run any dedicated private game servers, have you ever managed a remote server cluster/cloud/whatevercorpobuzzword?
I have!
Sure, matchmaking wouldn't work as well, because your smaller server set up / instance could only handle a smaller number of players... but its not like the code just magically doesn't work at all unless it is massively scaled.
In fact, all matchmaking fundamentally is, is finding an empty dedicated server, and then populating it with players who are in a queue, by some obscenely complex skill based matchmaking algorithm, and also trying to minimize total ping for the player roster it generates.
Or maybe its using one of the client's rigs as the actual host, etc.
Just take these parts out, and expose the more fundamental stuff that everything else is built off of, on your final patch. Make the new paradigm such that this fallback EoL scenario is accepted as a given from the start, and design the rest of everything with that in mind.
I will give you that uh, yeah, crossplay on consoles?
Thats almost certainly not feasible for post EoL games, as its just directly reliant on a Sony or Microsoft or Nintendo or whatever server at some point, and they're not gonna run a server in that situation.
So... the whole point is to make a new paradigm for things moving forward. Not retroactive.
Yes, it would potentially be unduly onerous to just suddenly demand all current games need to re-architect themselves before EoL.
But this isn't what SKG is advocating for. Its advocating for a new standard that applies to new games, such that they can be designed with this all in mind from the get go, and make it more like disabling/removing and swapping out some modules than rebuilding the whole thing from the ground up.
Think of it as having a spare tire and a jackstand in your car before you go on a roadtrip, where you know that one day, one of your tires is gonna blow.
Yep, the game company has to slightly alter the way they do things, have a clear, EoL contingency plan in mind from day one, ready to execute when their balding tire finally gives out.
But this really isn't that difficult or costly to implement at all. Its basically just an emergency fallback plan, which is very, very common in the brosder server hosting industry.
Also uh, obviously they won't release the source code. That would indeed be an insane legal/financial nightmare.
But... a compiled binary for a server?
That's gotten a final update that strips out what they don't directly own? Because the whole game was designed with that inevitabity in mind?
Thats ... completely legally not a problem for game publishers.
There are already tons of laws that punish people who decompile and then distribute or profit off of that, that's been a thing for longer than I've been alive.
It used to be the norm to just release dedicated server binaries for many games, usually shortly after the release of the game, way before support ended... so that people could host their own servers.
Like, by the logic of what you are worried about... Valve should be worried about my CD version of Half Life 2, because it uses a liscensed version of the Havok engine that they built off of to make the physics in the Source engine.
Uh yeah, if I somehow decompiled the Source engine and its Havok code, and then freely distributed that or built something with it I sold for money, I'd get sued into ~~oblivion~~ Xen.
Nah, it absolutely is, this was the standard norm for the vast majority of games until the new industry norm became games as service, always online.
They intentionally introduced this new paradigm that fucks consumers, the old paradigm of releasing server tools often even before EoL worked fine, they just got greedy.
To preface, I support SKG. I'm not at all disagreeing with the movement, and I understand the point of SKG is to be setting a standard going forward that will force developers to stop doing this bullshit.
My argument wasn't that SKG is bad. My argument was that the developers arguing against the movement are getting hung up on and bikeshedding about multiplayer and live service games. I was trying look at it from the perspective of a developer and explain that we (consumers) understand that it's not reasonable (for various reasons) to demand that they release the entire stack of backend services used by a game.
Games like Pal World still manage to publish their dedicated server binaries without publishing the dedicated server browser, and that's all we actually want. Shitheels like PirateSoftware are being disingenuous and framing it as though the movement is entitled and asking for the impossible.
Now, to respond directly:
For horizontal scaling, yes.
Respectfully, and as someone who has run community game servers, it's still not that simple or straightforward. A single private server can exist on a beefy machine or VPS and be fine. A private server designed to scale horizontally has much higher minimum requirements.
I'll use Minecraft as an example:
A private server for friends or a small community is exactly as you described. You download Paper, install MariaDB for SQL, and throw it on a VPS.
A large community server is a lot worse. You still have MariaDB and Paper, yeah. But now you have multiple shards of Paper, with one shard per world. These shards need to have a low-latency way to communicate and share information with each other, so now you need to set up a Redis server. And now since you have multiple shards, you need to set up the Waterfall/BungeeCord server software to act as an ingress. On top of that, with multiple shards you're going to want multiple nodes, and that now involves creating a private network.
You can run all that on a single dedicated server, but it's not going to be as cheap or simple to set up. Multiple gigabytes of memory are being wasted just on overhead for those services.
The problem here is that with newer games like Destiny 2, the server architecture is almost definitely designed for large-scale usage. If Bungee released the server and matchmaking software tomorrow, only people like us would actually have the experience and resources to host it. And if their server software was designed to only run within a container orchestration environment like Kubernetes, it would be even worse.
In contrast to Destiny and going back to my other comment, Team Fortress 2 was designed before horizontally scalable dedicated game servers were common. It's easy to distribute and easy to host.
My previous paragraphs should speak for themselves.
Which won't ever happen with AA or AAA devs unless it's legally required. It costs development time, probably won't ever be used internally, and doesn't bring in money. The suits won't allocate resources towards that out of the goodness of their hearts, which is why SKG needs to be successful.
It's really not.
In an ideal scenario where you have time to actually plan things out, you have a shared, common library for the game logic and two different projects that use the library for dedicated servers running under self-hosted or scalable environments.
If something like player inventory storage is handled by a dedicated service in the scalable environment, you can't use the same code for the self-hosted environment. To solve that, you create a
InventoryStorageinterface, aSQLBackedInventoryStorageimplementation, and aMemoryBackedInventoryStorageimplementation. Now you have abstraction, which makes the code harder to follow for on-boarding and maintenance purposes.Or, you could have two different implementations of the dedicated server. That comes with even worse problems stemming from code duplication. If you want to make sure those two implementations are fully compatible with each other, you also have to add full integration tests... and the only common interface between them is the game client network protocol.
Food for thought: what if the server source code is written in some scripting language like JavaScript or Python?
This is almost always going to be a viable option, but it's not a 100% guaranteed solution.
Particularly when it comes to shit like patents, you're entirely at the whims of the patent holder. A hypothetical example: the game absolutely needs to license some super-optimized physics simulation for its gameplay, and the only way they get that license is if it's not distributed to other parties. The easy solution is to only run the simulation on the server side, but if the server has to be distributed as well, that's a bit of a problem. Because it's patented, they can't just create their own copy of the library.
Good reference. Well played.
I really should have phrased that differently.
It's reasonable to expect dedicated server executables.
It's not reasonable to expect the entire tech stack used for the online services to be made available. For a shitty example that's straight to the point, I don't think Oracle would appreciate it if their SQL server was released alongside the server software to run a MMO.
Absolutely.
I hear you, and I understand.
I mean, generally, in many modern scenarios, yes, I broadly agree, releasing the entire stack of how many things are currently done, just as is, would be basically legally impossible, which I why I kept trying to stress the whole idea is ... not to do or demand that, for currently existing games... but to instead, introduce new laws that would force or at least significantly pressure this current paradigm of game server stack development to change, to enable that 'strip down at EoL' process to be possible, and ideally, easy, if that new paradigm is in place.
I mean... minecraft ia kind of notoriously memory inefficient... everywhere, at everything. I get that it makes sense as an example, you have experience with it, and it is very popular... but it is rather compute inefficient.
I also find this example, while generally illustrative of the kinds of problems that can occur...
You are using multiple third party, not officially connected to Minecraft, bits of software in your stack, to modify and add features and capabilities to the actual base game itself.
SKG says they want EoL games to be ideally fully function, or at least reasonably as functional as the base game is.
Your specific example here goes far beyind the scope of what SKG is asking for.
But, I also understand that you are using it to illustrate how generally... sometimes stacks don't scale well.
Well, no one is asking D2 to just release its entire stack as is.
If they hypotherically did release it as is... and its very complicated... I mean. Yeah. It probably is.
It probably is not as complicated as building an entire server emulator from basically juat packetsniffing the client... which many gaming communities have managed to do for many, many games over the years.
But uh, I bet Bungee has internal documentation on it.
Do an audit/review pass at EoL and release it?
Yeah, doing a standup would be hard and complicated.
That's fine! All SKG is asking for is for it to be legally possible, technically possible to stand up a server, as opposes to the current paradigm of ... essentially illegally reverse engineering the server/netcode and then running an emulator.
If the players are dedicated enough, and it is possible, they will figure it out. And I don't say that as cheery, unrealistic optimism... I say it because the even more complex task of just totally reverse engineering entire server/netcode has been done before, many, many times.
To just give one example: RPCS3, the PS3 emulator... yeah they made it entirely possible for two remote people to emulate the same game, connect to each other and play multiplayer games together.
https://wiki.rpcs3.net/index.php?title=RPCN_Compatibility_List
Its a work in progress... but yeah, this is just one example.
Yep. That's basically the point of SKG. Make it legally required.
So firstly, I guess I wasn't clear here?
As indicated by my sentence above where you started your quote of me...
I meant that setting up a dedi server for actual shared worldspaces... and that alone, basically, as in old school fps games... that, that is much more simple.
Secondly... I mean, you've described a solution here, to doing this in more modern games.
I have roughly done sort of an approximation of this over 15 years ago now, hooking up two GMod servers to a shared, seperate, player inventory db, as well as another db for the worldspace items of each server/map.
I figured out how to make a custom gamemode, configure it with things like uh, certain props like file cabinets also having their own inventory, which was persistent, as well as persistent world space dropped / semi random population of various items... and set up two basically map profiles within the gamemode... stuff like door ownership by specific players... ability to take items with you from the city map/server to the outlands map/server...
If an unpaid, not even 20 year old, with literally no formal CS schooling can figure this out, while going through uni... lets just say I woukd be very, very amused if this is somehow an unrealistic, overly difficult task for handsomely paid teams of professionals to figure out more a more complex game.
Like uh sure, at some point I would hit max map specific db saturation... but that wasn't really from the db itself. That was from if you tried to physics sim every single possible item in the map, simultaneously, or spawn every random loot item at once.
So what you do is... not that lol. You make items in world just go physics inert to most kinds of interactions, you keep most of them just in a player's inventory, or a containers inventory, have a tarkov style loot mexhanic in a gui, give containers a max volume and item count they can hold, only spawn a manageable number if a container explodes or is broken... you make the normal map load in first, block any connection attempts while you progressively spawn in world items on a tiny incrmentinf delay and/or batches and then do a verification pass, and then you allow connection attempts from players.
... And as for the shared player db... I can only ever remember that lagging when people were literally DDoSing something, or beta testing trying to dupe items... which i basically solved by mandating a bunch of client side and serverside warning triggers and conditions and cooldowns, and obfuscating the commands that would execute / show up in the player's console.
I realize this isn't anywhere near the same ... magnitude of scaling that like D2 or Warframe or something has, in its backend...
But the whole point would be to mandate that going forward, new games of that nature and scale, would have to offer some kind of lightweight, nowhere near as scale capable version of the server stuff at EoL....so they would just design this lightweight test version first, basically, then develop a tool ir script to translate between the small server framework and the huge scalable framework... and just do basic upkeep and maintenance on that conversion tool as the game gets more stuff overtime, and then at EoL, easy peasy, translate it all back to the small server format.
You could maybe do something like implementing a very long sort of string that encapsulates every single aspect of a persistent player account, then encrypt it, then give this code to players at EoL, then the new, light duty, blackbox server has a built in decrypter and recrypter... and there ya go, your player is now still persistent, hasn't lost anything, and can just hop to different post EoL servers, with all their stuff.
Yeah I wouldn't personally recommend that approach either, for the reasons you described.
Ok, unfortunately it is 4 am and my thought injestor is rapidly losing consciousness... I'll try to get back to the rest of this after .z.. sleep...