I'm not a gamedev, but there's a more insidious issue with the CA "Stop Killing Games" legislation that was just passed --- namely, a Ship of Theseus problem.
Pick your favorite game today that you purchase once, then have long-term free multiplayer support. Something like, idk, Fortnite before it was made F2P in 2017. Games like these evolve their content over time: sometimes minor changes, like rebalancing guns or matchmaking, but sometimes these are major changes, like completely redoing the map or altering fundamental mechanics. There can also be seasonal events that are designed to be available for a limited time.
The obvious question, then, is: is it "OK" that significant parts of the multiplayer experience changed after you purchased the game? In the spirit of people who prioritize game preservation, the answer should be "no, that's destroying part of the game and losing it to history." If we accept that interpretation, then we end up killing live service games. On the other hand, if we allow significant parts of the multiplayer experience to change, then we've neutered the legislation, because the easy workaround is to slowly patch out all online features until you're left with a husk of what was originally sold.
California's legislation [1] attempts to dodge this by phrasing things in terms of "ordinary use" of the game, but the definition of "ordinary use" is quite vague and will absolutely be the subject of some court case at some point.
---
Of course, there's a bunch of other side effects to the "general" notion of "make games usable past end-of-life," too:
- You might be able to use certain open source libraries on the server side because you are not distributing them to the user, and thereby don't have to open source your server. However, if you were required to distribute a binary, that could pose issues.
- You could have a dependency on an expensive piece of software (e.g. an enterprise Oracle DB license), and be unable to package that with the download.
- You could have a dependency on another online service (e.g. AWS Game Development Services [2]) that discontinues an API you depended on, and would require massive rework to be able to release a functional binary at end of life.
- You could have a dependency on an internal system at your company that you aren't willing to release the IP for yet, due to its use in another game
But maybe that's insufficient. Hugo[2], one of the most widespread static site generators in existence, supports Pandoc markdown flavors as well as general GFM.[3]
The pandoc repository[1] has nearly 45k stars and 4k forks. It's embedded in Jupyter notebooks, which are used by data scientists the world over. The python wrapper for pandoc has 16 million downloads[2].
They're not defending it as an established workflow pattern or some kind of best practice.
The usage of "exhibit a pattern consistent with..." is just describing what it looks like the repository was used for. i.e. it's not a set of government sourcecode for an internal project, it's not something indicative of intentionally leaking large amounts of data, etc.
It's crazy to have 2100 distinct municipalities? The site isn't showing "here are 2100 different email hosts that municipalities in Switzerland use," but rather "here are the 2100 municipalities in Switzerland, and if you click you can see what host each one uses."
There's plenty of overlap, just from a cursory look.
The linked post points to OEIS A014233[1] for establishing their set of Miller-Rabin[2] bases, though it's actually possible to find smaller sets.
I remember asking about this on StackExchange some years ago [3], which pointed me to Wojciech Izykowski's site[4], on which "best known" base sets are tracked. For example, instead of considering the four bases {2,3,5,7} to cover all 32-bit integers, it would suffice to consider the three integers {4230279247111683200, 14694767155120705706, 16641139526367750375}.
This becomes more interesting the higher the bound you seek --- for example, instead of checking the first 11 prime bases for 64-bit integers, you only need to check the seven bases: 2, 325, 9375, 28178, 450775, 9780504, 1795265022.
This might not be something entirely obvious to people outside of academia, but the vast majority (which I'm only weakening a claim of "totality" in order to guard against unknown instances) of entities that bear the name of humans in the sciences do so because other people decided to call them by that name.
From another view, Adelson-Velsky and Landis called their tree algorithm "an algorithm for the organization of information" (or, rather, they did so in Russian --- that's the English translation). RSA was called "a method" by Rivest, Shamir, and Adleman. Methods/algorithms/numbers/theorems/etc. generally are not given overly specific names in research papers, in part for practical reasons: researchers will develop many algorithms or theorems, but a very small proportion of these are actually relevant or interesting. Naming all of them would be a waste of time, so the names tend to be attached well after publication.
To name something after oneself requires a degree of hubris that is looked down upon in the general academic community; the reason for this is that there is at least a facade (if not an actual belief) that one's involvement in the sciences should be for the pursuit of truth, not for the pursuit of fame. Naming something after yourself is, intrinsically, an action taken in the seeking of fame.
It's interesting to see Quanta make a foray into print publishing. I've long-wished for a print form of Quanta math articles in a monthly magazine, so maybe there is some hope for that eventually?
I remember reading a book on web usability well over a decade ago, and one of the things it pointed out was how Google ensured that the links you wanted to click were "above the fold" --- not ads, but honest-to-goodness search results.
Recently, after they added AI-generated search responses (which seem to be wrong a considerable percentage of the time, at least for things I search for), and the inlining of ads to the search results page, I've found I have to scroll at least a full screen height to actually get to the search results a significant portion of the time.
The level of blindness to user experience at Google that has allowed the state of search to get to this level is staggering.
> There's always an error rate. DocBots are almost certainly wrong more frequently, but they're also almost certainly much much faster than reading the docs.
A lot of the discourse around LLM tooling right now boils down to "it's ok to be a bit wrong if you're wrong quickly" ... and then what follows is an ever-further bounds-pushing on how big "a bit" can be.
The promise of AI is "human-level (or greater)" --- we should only be using AI when it's as accurate (or more accurate) as human-generated docs, but the tech simply isn't there yet.
The article doesn't explicitly state it in this manner in one concise place, but the way I would always think about A* from a "practical/easy-to-remember" perspective back when I was doing competitive programming is that they're all the same algorithm, but with different priorities on the priority queue:
Breadth-first Search: Priority is order of discovery of edges (that is, no priority queue/just a regular queue)
Dijkstra: Priority is distance so far + next edge distance
A*: Priority is distance so far + next edge distance + estimate of distance to target node.
This also helps me remember whether the estimate must over- or under-estimate: Since Dijkstra is making the estimate "0", clearly the "admissible heuristic" criteria must be an under-estimation.
This is cool data! ...however, I must ask --- where does the data come from?
HN certainly has a side that loves open-source data, but it also has a privacy-loving side. Focusing on the privacy aspects, has TomTom given any consideration to how it respects the privacy of its users/does it allow for opt-out of storing and analyzing its users' GPS traces?
There are three buttons that act as sorting directions at the top of the answers section: "Votes," "Oldest," and "Active." The "Active" option sorts by most recently modified, which is _usually_ what you'd want instead of strictly newest. (i.e. an edit would update the timestamp, making that answer have a more recent activity date)
So, I guess the answer to your question of "why can't I" is "good news! you can" :)
Pick your favorite game today that you purchase once, then have long-term free multiplayer support. Something like, idk, Fortnite before it was made F2P in 2017. Games like these evolve their content over time: sometimes minor changes, like rebalancing guns or matchmaking, but sometimes these are major changes, like completely redoing the map or altering fundamental mechanics. There can also be seasonal events that are designed to be available for a limited time.
The obvious question, then, is: is it "OK" that significant parts of the multiplayer experience changed after you purchased the game? In the spirit of people who prioritize game preservation, the answer should be "no, that's destroying part of the game and losing it to history." If we accept that interpretation, then we end up killing live service games. On the other hand, if we allow significant parts of the multiplayer experience to change, then we've neutered the legislation, because the easy workaround is to slowly patch out all online features until you're left with a husk of what was originally sold.
California's legislation [1] attempts to dodge this by phrasing things in terms of "ordinary use" of the game, but the definition of "ordinary use" is quite vague and will absolutely be the subject of some court case at some point.
---
Of course, there's a bunch of other side effects to the "general" notion of "make games usable past end-of-life," too:
- You might be able to use certain open source libraries on the server side because you are not distributing them to the user, and thereby don't have to open source your server. However, if you were required to distribute a binary, that could pose issues.
- You could have a dependency on an expensive piece of software (e.g. an enterprise Oracle DB license), and be unable to package that with the download.
- You could have a dependency on another online service (e.g. AWS Game Development Services [2]) that discontinues an API you depended on, and would require massive rework to be able to release a functional binary at end of life.
- You could have a dependency on an internal system at your company that you aren't willing to release the IP for yet, due to its use in another game
[1]: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtm...
[2]: https://aws.amazon.com/gametech/