As another reader who has no idea what any of this is about, I've coerced my favorite LLM to digest it into ooga-booga format in the style of this essay[1]:
# grug see big sky boom
- sky make ooga FLASH but not light, just invisible whoosh (radio).
- whoosh so strong, like sun work many day, but all squish into blink of eye.
- smart sky-people have big ear rock (CHIME). ear rock say:
"boom come from there, galaxy far, but not too far (only 130 million fire-circles (light years) away)."
- ear rock also have many little ear-brother rock across land, help point finger very good.
- finger point so good, sky-people know spot of boom smaller than tree forest (13 parsec).
- then, magic glass eye (James Webb) look at spot. see old fat star (red giant) glowing soft.
- but fat star not make ooga boom. hmm. maybe fat star have sneaky tiny angry friend (neutron star).
- tiny angry friend go "KRAK!" → make fast radio boom.
# lesson for tree-brain
- boom in sky still big mystery.
- now smart sky-people can say where boom come from.
- if know where, can watch with other eyes, maybe find secret of why.
- grug think: many sky boom = maybe angry tiny stars yelling far away.
# Ooga booga translation:
"Tree no know why sky yell. But now tree know where sky yell. Soon, tree maybe know why sky yell."
Lots of bad takes in this thread. The whole idea behind this is just to stop defrauding customers that buy your software and then are left holding the bag. Nobody is asking for developers to keep running server infra for eternity.
Any of the following options are enough to satisfy this proposal:
- Put an expiration date on the storefront and make it clear that your software is not guaranteed to continue working after date X.
- Have your server source code (stripped down of proprietary stuff) ready for public release at EoL.
- Allow customers to reverse engineer the binaries and communication protocol after EoL.
- Package dedicated server binaries with the game and allow customers to connect to it via a LAN or direct IP option.
It's like people forgot what multiplayer gaming was like pre-2005. Everyone ran their own servers. You could run your own Half-Life game server and other users merely pointed their game client to your IP address.
The only exceptions back then were the MMORPGs.
There's no reason we can't go back to the way it used to be. I used to run multiplayer Starcraft on a LAN without an Internet connection. Why can't I do that with Starcraft II? We used to play Quake on custom servers. Some servers had fun communities. All that is gone in favor of live services that can be shut down on a whim.
I don't even think requiring server source code to be disclosed should be necessary. Merely the binaries with some basic instructions on setting it up (which could easily be based on internal documents for setting up test servers) would be sufficient.
Yeah, pre-console-ization of PC releases, devs would produce server binaries that would allow you to host your own servers. You could tweak rules, give preferential slots, etc. It allowed you to create a real community around your self-hosted server.
It's really difficult to create a cohesive gaming organization without controlling your own multiplayer servers. It's a sad state of gaming that every game has centralized servers. If anything, I'd love to see requirements that decentralize multiplayer hosting. The devs can release their own servers, but they'd be alongside the community ones, as well.
World of Warcraft actually made it very easy to use a custom server, since you'd just need to change a hostname in a single text file and the client would connect to it instead. Not that it was allowed but from a technical perspective it was quite supportive. I think it's no longer as simple but there's still private server projects around.
As a broke college student, I had a great time playing on third-party servers. The experience was janky, of course, but it was hilarious. I made some good friends there.
Then I had to stop playing because it was eating into my study time too much.
I've tried going back to MMOs a couple of times since then, but nothing seems to have the charm of a smaller community like that.
I developed a few commercial games on unity a while ago, here's why some of what's proposed is harder than you think,
- The original developper is not working on the game anymore, another company is maintaining it and has no capacity for making significant changes to it.
- You can't release your server source code because you will be using a lot of proprietary add ons that can't be released, and those are usually absolutely essential.
- Your server is going to be built against a now unsupported version of the engine, that you probably can't even install on current year operating systems
- stripping the source code of 'proprietary stuff' is significant work, there's no package management, code is copy pasted.
- Your protocol is based on third party commercial code and that other company doesn't like reverse engineering
- Changing the way the networking works to remove the lobby is significant development work, the networking framework is out of date, not maintained, and the devs are most likely not available anymore.
1. Not a problem because it's not being applied retroactively, but it should be included in the design from the start for new games
2. It is a problem now, but the license for those can and will change if the law mandates it. Unless addon authors don't want to make any money, that is.
3. I don't get the argument. If it works at the time of release - you're good. You're not expected to keep updating it to work on modern systems.
4. This is just point 2 repeated.
5. This is still just point 2 repeated and reverse engineering is allowed in EU, whether they like it or not.
6. Why do you need to change the way networking works?
If your game uses matchmaking or is multi region or crossplay it’ll be depending from a lot of different services, and tightly integrated with them.
Latency concerns, for example, might be handled at several points in the flow that would stop existing for a standalone server. None of the code involved is reusable because it was written for a completely different context.
There is nothing preventing you from writing an abstraction that supports both the fancy middleware as well as direct IP connections.
I can say this with certainty because I've also worked on multiplayer in several shipped multi-region cross-platform games, and this sort of arrangement is precisely what we have shipped. Granted, Direct IP connections are usually only supported on PC, but they are there, they do work, and our PC players appreciate that piece of mind.
I guess we could have made two different games at once, but we just needed one game that would work all the time for everyone. If we'd had the time or money to actually do that we would have used the time and money to made a completely new game in parallel.
I suspect you overestimate the amount of time or effort needed to write such an abstraction. Our base multiplayer abstraction is about 3k lines of C++, and once you have that in place there are a number of battle-tested low-level netcode libraries that can help implement the UDP subclass. Doing this also pays dividends during development, as it allows you to diagnose and fix issues with the application layer of your netcode far easier than having to navigate the authentication rigamarole of a middleware first.
Granted, I do realize that it is an additional lift. It helps that we reuse our engine between projects, and the games that we work on tend to be amenable to traditional client/server setups. We also don't support certain features over UDP, such as matchmaking or VoIP, and we also file the task of players actually finding and connecting to each other over UDP as "not our problem" unless they're on the same LAN segment. Our games also don't have in-game stores or microtransactions, so there's no digital goods to protect either.
However, in practice, the existence of the UDP layer was far and away the least difficult part of making a working multiplayer game. The most difficult parts are the same ones you run into on any normal multiplayer project - figuring out how to get the uber-flexible middleware you're using to play ball, solving the application layer bugs, and satisfying the certification whims of the platform owners.
I mean, sure, if we were forced to include end-of-life self hosting we could have shipped it with an early, janky QA build with most of the features that differentiated our game from others stripped out.
But why would we do that? It's not the game we designed, pitched, built, or advertised. It wouldn't be fun.
The hypothetical requirements I've seen throughout this discussion would result in whole categories of games either jacking up their prices or just skipping an EU launch entirely.
> The hypothetical requirements I've seen throughout this discussion would result in whole categories of games either jacking up their prices or just skipping an EU launch entirely.
That's not going to happen. Once the EU adopts some legislation, it will be likely that we will see the benefits of this downstream.
You can look to Apple and the EU regulations as an example as to why most publishers wont skip Europe.
Also you are not forced to include end-of-life hosting. You need to provide some form of a working game after it gets shutdown. Releasing server binaries, or something. Not just shutdown the game and giving your customers no recourse. Please remember that you have to sell some rights to the game, all we are asking for is that you not take away rights that were already sold.
The initiative is not even asking you to provide the full functionality of your online-components.
All you should have is a "reasonable effort" EOL plan that allows customers to continue using the parts that can work without the developers support. They even call out "Gran Turismo Sport" as a good example. Sony announced the EOL a year before, and stopped selling micro-transactions. Then they removed the online services while retaining offline support for add-ons and in-game items.
A reasonable EOL plan might be: We'll support the online matchmaking for 3 years. After that we retain the rights to shut down the services providing at least a one year notice. All in-game items and add-ons will be made downloadable for all players 6 months before shut-down. All offline game modes will remain playable using those items as before.
> You can't release your server source code because you will be using a lot of proprietary add ons that can't be released, and those are usually absolutely essential.
This hard from the developer perspective, but its solvable at the regulation level.
The rule won't apply retroactively to all games ever released, you know. All of these requirements can - and should - be met when new games are designed and architectured to satisfy the law.
That would require a complete re-architecture of game engines and complete rework of how the games are developed and published. If I had to satisfy those requirements next year, I just wouldn't release in Europe, and I say that as an European.
Then just keep doing things the same way, but add a disclaimer that says you are only selling a license to play the game, and it's not guaranteed to work after a certain date.
Then like what happened with the cookie banners, everybody is going to put the minimum date, and the only winners will be the lawyers selling consulting in EU regulation compliance with the publishers.
You are begging the question, the question being whether consumers care. You believe they don't (e.g. that the expires-on date won't affect sales) and the creators of this petition believe people will care and will prefer games that do not have that expiry date.
So no, it's not inevitable that every game will just sprout an expiry date. It's possible but only if you're right that consumers don't care about owning versus renting games.
I'm more and more baffled the more I go through this thread.
It is as easy as saying, "this game you're buying won't run after 2030"
Or publishing the bare minimum APIs you'd need to simulate to get the game to function. We have great people in the community that will make stuff work on their own, no instructions required.
Just don't go out of your way to destroy your game.
> - Put an expiration date on the storefront and make it clear that your software is not guaranteed to continue working after date X.
This software is not guaranteed beyond 0 Unix time.
> - Have your server source code (stripped down of proprietary stuff) ready for public release at EoL.
This isn't viable, and i would expect anyone on this site to understand that. it's roughly equivalent to saying "just make facebook stripped of proprietary code and ready for the public to run"
> - Allow customers to reverse engineer the binaries and communication protocol after EoL.
This is a reasonable path forward, but likely a non-starter in the US for political reasons. I understand that "stop killing games" is an EU thing.
> - Package dedicated server binaries with the game and allow customers to connect to it via a LAN or direct IP option.
No. Because any explanation will come from someone invested in the subject, so will all sound completely reasonable and may even contain aspects of truth.
I want to play games with my friends, not consider how the landscape of always-online services have distributed brokerage connectivity services, global banlists, and whatever powers microtransactions into what should be a game with four little dudes running a kitchen badly. I especially don’t want to consider how rising requirements for stability and cross-platform connectivity which have prompted these services means that P2PoverIP simply won’t work in the face of CGNAT or Sony’s distribution policies or fucking Comcast not having IPv6 yet; and I especially don’t want to think of the lower average technical acumen of the individual gamer has caused dedicated servers to completely fall out of fashion due to user confusion.
I really don’t want to think about the “paradox of polish”, where smaller games can get away with such things like dedicated servers and p2p networking that don’t work sometimes; whereas everything in an AAA title has to work flawlessly out of the gate or it’ll be panned despite the horse’s left testicle contracting appropriately in cold water.
Man, I don’t wanna be sad about market forces encouraging centralization for the efficiency necessary to stay competitive. I just wanna play dead or alive 2 with my bros even tho the dreamcast server’s offline.
Isn't that exactly how these companies scale across multiple data centers?
They write the code once, package it all together, and host it in multiple areas?
Getting back to games, I still don't see why allowing users to host private servers with their friends is impossible. If anything, it seems like its strictly a DRM issue...but at EOL for a game you no longer find profitable enough to keep the servers online, who really cares about DRM
Wat? E-trade is not an application, it's probably dozens of coordinated services. Meanwhile, a game usually has a single binary and another one for the server.
Well, this is about software you bought in advance. The Facebook comparison doesn't really work because you're not paying in advance to use it.
> This software is not guaranteed beyond 0 Unix time.
Grandma goes to the store to buy a game for their grandkid. She sees two game boxes. One says in the front "This game will stop working tomorrow and you will not get a refund" and the other says "This game will stop working in 2030". Which one does she pick?
Or if I understand right if you have some online component make final version of the game to operate without it. So you might lose multiplayer, but single player components of game should still continue to function.
Which to me doesn't sound huge ask. Unless you have overly strictly coupled the game with online. Which for single player games is likely bad design anyway.
That's sneering. Don't do this. If you have a specific argument that you respond to, then do it. Generically sneering at other comments is profoundly anti-intellectual, extremely boring, and directly against the HN guidelines (https://news.ycombinator.com/newsguidelines.html) - it actively degrades the quality of HN.
I guess the bad takes are unavoidable. I couldn't find a clear and succinct explanation of the mission anywhere on that site and had to read your post to have any idea what are they even arguing for and against.
> "Stop Killing Games" is a consumer movement started to challenge the legality of publishers destroying video games they have sold to customers. An increasing number of video games are sold effectively as goods - with no stated expiration date - but designed to be completely unplayable as soon as support from the publisher ends. This practice is a form of planned obsolescence and is not only detrimental to customers, but makes preservation effectively impossible. Furthermore, the legality of this practice is largely untested in many countries.
There you go, right on the front page, in case you missed it.
> Put an expiration date on the storefront and make it clear that your software is not guaranteed to continue working after date X.
Why wouldn't everyone just say "its not guaranteed to continue working after 0 seconds from release", which is basically the current situation, and be done with it?
- Clunky component and variable system; inadequate for more complex stuff with lots of parameters.
- Can't set connectors on Design files (used for documenting the navigation flow between different pages of an app).
- You can set connectors on FigJam files, but if you want to bring your components from Design files then you can't keep the instances synchronised to the component definition. And you can't attach the connector endpoint to some element inside the Design component. It's essentially just an image export of the Design component.
- Prototyping is very clunky and trying to build a flow that has elements reacting to interactions on other distinct elements is either variable hell or downright impossible.
Those are just off the top of my mind. I'm always finding threads from 5 years ago on their community forums with loads of people on the same boat and no activity from Figma side.
I'm really curious about this but searching for "Google Omaha" doesn't return anything related and the linked FOIA request is... just a request, which I assume anyone can write whatever they want in the request.
The request itself isn't very damning either. It just make references to vaguely worded "partnerships", and apparently uses that to imply that Google is handing over data. Even if we take that at face value, it says nothing about OP's claim, which is that NSA can ask google to serve backdoored updates.
I'm not sure they are "retrieving" data. People register on the website and upload stuff they want to be processed and used.
I mean, sometimes the government steps in when you willingly try to hand over something on your own will, such as very strict rules around organ donation, I can't simply decide to give my organs to some random person for arbitrary reasons even if I really want to. But I'm not sure if data should be the same category where the government steps in and says "no you can't upload your personal data to an American website"
Notion has been great for me since I started using it back in 2021. Hope they get all the success they deserve.
That being said, I'm honestly disappointed with their overall direction. The main product has not improved much since 2021, except for features I assume are catering to their big enterprise customers.
It's slow, the mobile app has bad UX, the Windows app is a memory hog and I run into issues whenever I build something more complex with it. It's still a great product, but as time passes I look more into alternatives...
This kind of thing amazes me. Radio is such a simple, yet omnipresent, technology that even something not made to listen to radio can accidentally catch and play the signal like an actual radio player would. I sure hope it's never going away.
When I was growing up, we lived within 6km line of sight from a powerful AM broadcaster on 660KHZ.
By some stroke of fortune, our woodstove smoke pipe and the tinfoil backed insulation of the house,
Along with the grounded base but rusty bolted on top of the woodstove created some kind of resonant receiver at that frequency. It would generate sufficient voltage to deliver the occasional electrical shock, which was very mysterious because we had no idea how this stove could shock you, even when the mains were turned off.
The mystery of the source of the power was shocks when we built a wire drying rack above the stove, which acted as a sound transducer. With the glove rack, we were treated to 24/7 programming, mostly community oriented stuff like “problem corner”(community issue discussion) bush relay messages for remote listeners outside of telephone reach, “tradio” (call in radio Craigslist, basically), news shows, talk shows, and some occasional music.
To me, it was just completely normal, never having known anything else besides electrocution hazard wood stoves and radio show mitten racks lol. It did fuel a fascination for electronics, though, so by the time I was seven I was an avid reader of popular electronics magazine. Forrest Mims. What a treasure of an engineer.
# grug see big sky boom
- sky make ooga FLASH but not light, just invisible whoosh (radio).
- whoosh so strong, like sun work many day, but all squish into blink of eye.
- smart sky-people have big ear rock (CHIME). ear rock say: "boom come from there, galaxy far, but not too far (only 130 million fire-circles (light years) away)."
- ear rock also have many little ear-brother rock across land, help point finger very good.
- finger point so good, sky-people know spot of boom smaller than tree forest (13 parsec).
- then, magic glass eye (James Webb) look at spot. see old fat star (red giant) glowing soft.
- but fat star not make ooga boom. hmm. maybe fat star have sneaky tiny angry friend (neutron star).
- tiny angry friend go "KRAK!" → make fast radio boom.
# lesson for tree-brain
- boom in sky still big mystery.
- now smart sky-people can say where boom come from.
- if know where, can watch with other eyes, maybe find secret of why.
- grug think: many sky boom = maybe angry tiny stars yelling far away.
# Ooga booga translation:
"Tree no know why sky yell. But now tree know where sky yell. Soon, tree maybe know why sky yell."
[1]: https://grugbrain.dev/