Game publishers respond to Stop Killing Games claim it curtails developer choice

To my understanding, this wouldn't affect MMORPGs where you're explicitly buying X months of access (so long as you do get the access you paid for, or a refund if it's shut down early) which is how most I'm aware of work.

> Now this proposal requires you to also continually release your server code.[1] While adding documentation, support for different systems,

The proposal requires leaving the game in a reasonably playable state, but not any specific actions like these. In fact the FAQ specifically says "we're not demanding all internal code and documentation".

> while ensuring safety as the server can now be reverse engineered and while possibly being liable to abuse created through those servers

I don't see why the company would be liable for this. Moderation of the private servers would be up to those running the private servers. If there is something to this effect in EU law that I'm unaware of, it seems like it'd already be placing undue burden on games that do currently (or want to) release their server software and that this initiative would be a good opportunity to exempt them from that liability.

> but it hurts small developers

If anything I'd speculate small developers are likely to have less issue releasing server software/code, and more likely to have a game this doesn't even apply to in the first place, giving them an edge over larger publishers.

But even if it were a significant burden, I feel it's really just providing what was already purchased. At the extreme, do you think it'd be okay to take $70 from someone for a singleplayer game, then shut down authentication servers (rendering it unplayable) a few minutes later?

The only people you're effecting are legitimate players. Pirates crack the games and have an easier time for it. Unless you're talking about multiplayer games, which wasn't the target of the proposal (though even there I'd argue it's definitely doable).

> I work for a game company

You work for a shit game company.

... which is why it doesn't pass my smell test.

Say you're working on either a monolithic game server codebase, or just a microservice that's a part of a larger service mesh fulfilling that role. Are you writing any tests? You probably (hopefully) do. So where's that code gonna run the first time before it's even pushed up to version control? Locally. So some extents of it definitely have to run locally, or if you have good test coverage, all of it.

But okay, let's go a layer further. Say you're trying to go into production with this. As the saying goes, everyone has a production environment, but the lucky folks "even" have others. This sarcastically implies that you need to be able to deploy your solution into multiple environments. And you don't want to be doing this manually, because then e.g. you have no CI/CD, and thus no automated testing on code push. That's not even considering multi-geo stuff, because for multiplayer games I imagine latency matters, so you really want to deploy either to the edge or close to it, and will definitely want to be all around the world, at least in a few key places.

So you can test locally, and can deploy automatically. Tell me, what is the hold up then? It would take me approximately one entire minute to give you the binaries for anything I ever touch, because if I couldn't do that, the automation wouldn't be able to do so either. At some point, the bullshit has to end, and that's at operations. Not much docs to write either: if your stuff does anything super super custom, you're doing something very wrong. And respectfully, if the aforementioned do not apply to you, you shouldn't be operating any online service at scale in production for anyone in 2025.

Really the only technical wrenches you can throw into this that I can think of are licensing and dependencies. Neither of these are reasonable spots to be in from an economical or a technical standpoint. Like what, you can't mock other services? How are you testing your stuff then? Can't change suppliers / providers? How is that reasonable from a business agility standpoint?

So clearly if there is a salient technical rationale for this, it's going to have to be a very sharp departure from anything I've ever experienced in non-gaming enterprise, or my common sense.

Regarding all the other points (and this will read dismissive because I've already rambled on way too long and I'm trying to keep it short, I genuinely don't mean it like that):

- if you're writing an MMORPG as a small up-and-coming indie, you're definitely going bankrupt

- if you're writing an MMORPG, I'm pretty sure you'll have more than just one or two servers running, or there's nothing massive about that multiplayer online role playing game after all

- it does not require you to continually release anything

- it does not request you to release documentation (what is there to "document" btw? I'm certainly not imagining too much)

- it does not request you to support different systems

- it does not request you to release anything before EOS, thus, security concerns for the official client are null and void - and even if it wasn't (e.g. sequels), security by obscurity is not a reasonable security story anyways

- the dangerous parts of the reverse engineering efforts still routinely happen without access to server binaries anyways (see all COD games and their players getting hacked to pieces right as we type away)

- possibly liable is not liable, and I trust you're not a lawyer, just like I'm not

- it's just a client-server setup like any other - remember, other environments must be possible to connect to as well, if nothing else then for testing

All of this is completely ignoring how we had dedicated servers and competition events with private setups since forever.

I legitimately cannot imagine that you can cock up an online service architecture and codebase bad enough, that a team of devs and devops/SREs/ops, or even just a few of those dudes, couldn't get something mostly operational out the door in a few day(!) hackathon at most. Even without planning for all this. And how this would skyrocket the costs especially mystifies me. Surely asset development, staffing, operational costs and marketing are the cost drivers here? How would you surpass ALL or even ANY of that? Just doesn't make sense!

You're using "anecdotal" incorrectly. Your statement was ""voting with your wallet" will never work." and I provided a counterexample, meaning that your statement is factually incorrect, so you're just wrong. It's also incorrect to call it a "concession" - the players got everything they asked for - there was no compromise. There are also far more counterexamples if you cared to search the internet for a few minutes - the Skyrim paid mods incident, the League of Legends free lootbox removal, and The Crew 2 and Motorfest not having offline modes as just three more.

> Meanwhile, DLCs

Been around for decades, not just "a few years"...

> microtransactions and lootboxes went from "totally inacceptable" to "absolutely bog standard" in a few years

Yes, and? Not enough people cared to actually do anything about it. The fact is, that when people care enough, and actually put their money where their mouth is, companies either listen (as above) or go out of business (as a number of studios are today).

It's quite simple to see that when people don't buy a studio's games, the studio either changes things or goes out of business. The reason that companies get away with these practices is because people either (1) morally compromise enough to buy games with mechanisms that they don't approve of, (2) they literally just don't care, or (3) aren't even aware of the issues. The call to "vote with your wallet" is meant to encourage the compromisers to stop compromising and the apathetic to realize that they have to take action for change to happen.

If your claim is that when people make values-based purchases it doesn't affect the market or fix issues - that's just factually wrong. If your complaint is that people don't care enough to make values-based purchases - that's exactly what the call to action of "vote with your wallet" is meant to help.

> Literally straw-manning my point. I should have emphasized "isolated".

I assumed you weren't talking about isolated individuals because that's completely irrelevant to this discussion. The poster's call to action of "vote with your wallet" on a site with tens/hundreds of thousands of visitors is literally a call to collective action, so any references to isolated action is just not relevant or logically coherent.

And, because you got that part wrong, this isn't really relevant, but...

> To me calls to "vote with your wallet" are akin to a single worker demanding a raise or better working conditions

This is also completely incorrect. If an individual worker demands something from their employers, they can just get fired. The power is in the hands of the employer. In the case of games, the power imbalance is heavily skewed towards the purchasers - if you decide not to purchase a game, the studio loses on revenue, and you lose some tiny increment of entertainment. Comparing someone having to play a different game, with someone getting fired, is crazy. Those situations are categorically different.

> On the other hand, a collective effort to change the law like "Stop Killing Games", now we're talking.

Telling people to "vote with their wallets" is a collective effort, and it works. That doesn't mean you can't complement it with regulation, but anyone familiar with the legislative system knows how incredibly difficult it is to wield regulation and how much you should try to solve problems through other methods first.