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.

I hear you, and I understand.

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.

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.

Minecraft example

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.

Destiny 2 example.

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.

Which won't ever happen with AA or AAA devs unless it's legally required.

Yep. That's basically the point of SKG. Make it legally required.

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

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.

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.

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 InventoryStorage interface, a SQLBackedInventoryStorage implementation, and a MemoryBackedInventoryStorage implementation. Now you have abstraction, which makes the code harder to follow for on-boarding and maintenance purposes.

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.

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.

Yeah I wouldn't personally recommend that approach either, for the reasons you described.

Food for thought: what if the server source code is written in some scripting language like JavaScript or Python?

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...

I disagree with Louis Rossmann on a lot more than any of the people involved in this, but man, he's a much, much more effective activist.