Stop Killing Games

> But it's less obvious to me how the legislation should work for a multiplayer-only game that goes out of business

The idea is to force the companies to provide an end-of-life plan that leaves the game in a "reasonably playable state". Depending on the game the approach can differ. Releasing the binaries along with instructions for hosting dedicated servers is one approach (that some games already take). I was playing on a (pirated, but it was a long way ago and I was a child) Lineage 2 server way back in 2007 on my local ISP network, so even something like MMORPGs can be covered if it's included in the discussion at the design stage of the game.

But even if the backend is very complex and vendor-locked, releasing something like a set of Cloudformation templates and saying "you can only host this on AWS and it's going to be restrictively expensive but there you go" is also an option that would satisfy the requirements. It's still better then having nothing at all to dig at (although some fans still do reverse-engineer and spin up community servers even without having access to any of this).

It seems like it should be legal for your end of life plan for the game to be “it is over and no one gets to play it anymore”.

Only if they change the wording of the game purchasing experience to be along the lines of 'Rent' or 'Subscribe' instead of 'Buy'.

If it's rented and not sold - sure.

The problem is that you can easily create negative effects that hurt all developers while only imagining the impact on profitable AAA games which seems to be how most of these discussions go since people always bring up blockbuster games like Lineage 2 and World of Warcraft.

Ensuring that the multiplayer server component of your game is a standalone end-user distributable is a huge task to impose on every game that wants to have a multiplayer component. Especially once you consider the vast majority of games that never even get traction much less turn a profit.

So, the second someone buys your prerelease indie slither.io game, what exactly does this checklist look like? It needs to also day 1 launch with a self-hostable standalone server distro instead of the crappy spaghetti mess you live coded on an EC2 machine?

But you’re not renting or subscribing to it so that is inaccurate and confusing for a one time upfront payment business model.

And the people who bought something are just...shit outta luck?

I fail to see the impact it would cause on a smaller studio - a lot of the times the games from those are usually are already pretty simple to self-host, as they don't want to bear the load of maintaining servers besides maybe a master-server (e.g. Valheim and the like).

> Especially once you consider the vast majority of games that never even get traction much less turn a profit.

Which is the whole point. Believe it or not - people who slave away on the game for years want people to maybe get to play it and enjoy it? Cause it's also art and not just business and there's a preservation angle to all of it?

> It needs to also day 1 launch with a self-hostable standalone server distro instead of the crappy spaghetti mess you live coded on an EC2 machine?

Not by day 1 launch, by day "we shut everything down". Not on an EC2 machine - as I mentioned in the thread above, even dumping your cloudformation templates and saying "enjoy all these queues" will satisfy the requirements.

The requirement is not to be standalone end-user distributable, the requirement is that it be somehow possible for an end user to set it up, which is a lot easier, unless the developers don't even know how to set up the backend. But that's a low bar still.

I've built a couple multiplayer browser games and getting the server component to a state where it's end-user distributable probably involves another 50% of the work that I put into building it in the first place since I'm just rsyncing code onto a VPS.

It's like thinking that just because the code exists, then it's in a state that could be pushed publicly to github, and that's not the case for almost any codebase.

To think that I would need to do all that the second I charge $1 seems unreasonable. And I think you underestimate how true this is for most games you see on Steam.

>But you’re not renting or subscribing to it so that is inaccurate

If the game can be taken away from you st any time then "buying" is definitely inaccurate too then. "Licensing for a limited time" might be the most accurate, but something like "Lease for X years" might be more concise and accurate enough.

I think the fact that you used the word "studio" kinda betrays a disconnect here. What about all the games that aren't built by "studios" and don't have "cloudformation templates" and have barely any sales?

They also need to have had invested in the extra work so that hypothetical players can have the opportunity to self-host the server on day 1 for a game that never caught on in the first place?

If you're buying a time limited license then the guaranteed time should be part of the license and considered part of the budget.

You are buying a license for 2 weeks sounds a lot less appealing than just "buying", but that would have been the reality for Concord had they not issued refunds. Is a year that much better? Maybe, but have it in writing.

These "we sell you a license we may terminate at any point for any reason" terms are absolute bullshit.

> since I'm just rsyncing code onto a VPS.

I mean, this covers it. Put that code out, and some one else can rysnc it to a VPS. The ask here in not that it's nicely bundled up into a single click deploy. It's that a path exists at all. If I need a fleet of servers and some technical know how, that's fine. Even expected for many games.

Yes?.. It does not have to be pretty. If you're able to deploy it, your community will be able to deploy it.

If you really don't want to bother with that - don't sell the game, sell timed access and shut it down once the last subscription runs out.

> Ensuring that the multiplayer server component of your game is a standalone end-user distributable is a huge task to impose on every game that wants to have a multiplayer component.

Is it? Your hosting it somehow? No one is asking for a 1-click installer. What do you do? Let us do that.

Fair enough, but that's a huge imposition on everyone for what probably comes from a very specific instance in your life of a single game that you loved having its server die after a while, long after you got your money's worth.

It seems short sighted.

> It seems short sighted.

In my opinion it's the other way around. It's short sighted to throw away so much of the medium's history with no way to preserve it.

This is a proposal for new games, not existing games. If the requirement for this is there in the design stage then it incentivizes developers to design it in from the start and pushes the implementation costs down signficantly.

If a developer decides to not take that requirement in the design stage then that is their prerogative, but not even doing it would be like not following any other EU consumer protection law.

Then companies should town down the "buy" language.

If not, then buying is not owning and piracy is not stealing.

Why not apply this only to AAA games, if that's your objection? You could say that only companies with annual revenue over $100 million have to follow the rule.

(Usually I don't like regulations that blatantly favor small businesses like this, because they're coming from a misguided place. But in this case, the benefit of the regulation scales with the number of customers of a given firm, while the costs are fixed per firm, so applying it to large firms but not large ones won't much encourage fragmentation and could capture most of the benefits of applying it to everyone without most of the costs.)

IMO, I'd be content with "dump the server binaries in a file server somewhere" as an adequate, if less than ideal, option. If the binaries are available, it'd take work, but not that much work, to wrangle them into something hostable by me. Some containerization here, some packet redirection proxies there, I can make it work.

How is dumping your server files in a file upload server somewhere a "huge imposition"?

> It needs to also day 1 launch with a self-hostable standalone server distro instead of the crappy spaghetti mess you live coded on an EC2 machine?

If you can't meet these very achievable goals, perhaps the game isn't at a point where it should be sold for money. What are you going to do when that ec2 instance gets randomware and becomes inaccessible, just tell all the people who paid you money to go home and forget about it?

I love indie developers, but if one can't have a modicum of professionalism, then they shouldn't ask people to pay for a product.

If that's the plan, then you should attach an expiration date to it. Tell the consumers how long you plan to keep things running, and commit to it. Don't just shrug and go "I dunno".

I think bankruptcy is clearly its own category here. This is targeted at companies who release something then shutter it because they didn't sell enough copies.

Nobody is even asking you to maintain the code. You had it working when I purchased the product that required the code. Just share that code. I'll even fiddle around with hard-coded paths or whatever you think is making this impossible

That's exactly the goal of this.

If you buy something, that will be yours, you can use it as long as you want, you can sold it or it can be inherited from you. (In copyright terms that's a perpetual, irrevocable license.)

If there is only a limited duration you can use something, that's called renting and the duration must be known before you enter into a contract.

No it isn't. People buy movie tickets, annual passes, and other things all the time that are not "rented". These are things you buy, and you may lose access to them if something happens to the business.

The terms of the purchase of an online game that might shut down are quite clear and known ahead of time. It's just not a fixed amount of time.

In many cases, this means you would have to design the server significantly differently as you may use proprietary first or third-party technology in your server that you cannot redistribute.

Who pays for that server's continued availability?

THAT is exactly why this whole thing is best solved by law, rather than consumer action, because that is a coordination problem. To be compliant with the law, you would have to not use software that you can't redistribute to make games that will be available to citizens of the EU (or, at the very least, that consumers can't reasonably get their own license to). Which in turn means that third party library developers would have to figure out a licensing model that works under the new legal framework.

Even if the company's file server is only available for a fixed period of time, as long as they announce it some fraction of the playerbase will pick it up. Or release it as a torrent, if you really want to cheap out.

If you mean the servers to actually host the self-hosted solution, then "me" is a perfectly reasonable option. Server hosting is far from an insurmountable hobby expense.

In that case you buy a ticket and not a movie / game. People buy movies on DVD / BR and they will be able to play them forever. This should be the same if you buy the same movie (with a one time payment) on a website, too.

There is a different valid business model, where you subscribe for eg. a monthly / yearly fee and can watch movies form a catalog or play games from a catalog as long as you keep paying and the service is working.

> The terms of the purchase of an online game that might shut down are quite clear and known ahead of time.

On a ticket or a pass there is a clear date or deadline printed on them. Do the same for games (buy thins game 10 EUR for 1 year) and that would be fine, too, (it is the same subscription model just with yearly duration).