> That way the community has the opportunity to run their own servers if they want to.
That might be fine for very small titles - where the "game server" is a relatively simple binary that can be run anywhere. Larger titles depend on a huge amount of infrastructure, for authentication, progression, matchmaking, etc... It's not feasible to open-source all of that, especially given that it may well still be in use for more recent titles.
> It's not feasible to open-source all of that, especially given that it may well still be in use for more recent titles
If they're still running their authentication server (for example), then they wouldn't need to release that service.
Patching the game to no longer contact the authentication server would also be acceptable, for services that aren't a core part of the game. It's pretty likely the game already allows this for development/debugging.
If they've accepted money from people to buy the game, and don't want to keep the authentication service running, and don't want to patch the game to no longer require the authentication service, and don't want to refund people, and don't want to release the authentication service so others can run it - I think it's fair for a regulation to force one of those.
So do games just have to have a perpetual endowment to fund any shared component costs? This seems like a logical conclusion. You wouldn't get scalability from reuse (e.g. reusing an auth library).
Or what's likely cheaper is budgeting for that patch in the game.
You may bemoan "oh they just don't want to release the auth service", but it functionally shuffles the cost math.
I'd personally rather the 5% cheaper games than trying to play a multiplayer only game 20 years later wtih 6 people on the server.
> So do games just have to have a perpetual endowment to fund any shared component costs? This seems like a logical conclusion.
They don't need to keep services running perpetually. strags's objection seemed to be that it could be infeasible to release services like authentication that they're still running, to which I'm saying they don't really need to consider any of this until they stop running it.
> You may bemoan "oh they just don't want to release the auth service", but it functionally shuffles the cost math.
Releasing or patching it out is largely just fulfilling their side of the deal.
If I sell you a lawnmower that depends on some authentication server to start up, then shut down the server the next day (I got your money, why would I keep the cost?), and don't release the server code or a patch to work without it, then would you not say I've scammed you?
The resource cost of everyone I've sold to losing access to their lawnmowers would be far greater than what it'd cost me to release a patch, just that the former is not a cost borne by me if the law allows me to ignore it.
> I'd personally rather the 5% cheaper games than trying to play a multiplayer only game 20 years later wtih 6 people on the server.
Allowing a company to cut people off of their software (large cost) just to save having to push out a patch (small cost) will, on net, result on more expensive products - since on net you're wasting more resources.
Particularly when it comes to authentication checks, this doesn't just apply to multiplayer games. Imagine if this applied to other forms of media (already kind of happening with DRM), like if we couldn't read books from over 20 years ago.
"If I sell you a lawnmower that depends on some authentication server to start up, then shut down the server the next day (I got your money, why would I keep the cost?), and don't release the server code or a patch to work without it, then would you not say I've scammed you?"
A lawnmower isn't a piece of software. It's not licensed. There's an expectation it should continue working. The lawnmower is a single player game.
I think it's understood that online games are a license (read multiplayer ones, not the Crew).
If I sell you an IoT lawnmower, and you get 20 years out of it, do I owe you a full refund if I shut down my server? imo, any refund should be prorated.
I get your externalities argument, but I think multiplayer games should be treated differently if there's not an easy solution.
>Allowing a company to cut people off of their software (large cost) just to save having to push out a patch (small cost) will, on net, result on more expensive products - since on net you're wasting more resources.
I don't think all the patches are small costs when you factor in licensing, etc. Also keep in mind if you use a library for networking and the API changes, do you have to then roll it on your own? I'm skeptical of the middleware that's made life easier
>Allowing a company to cut people off of their software (large cost) just to save having to push out a patch (small cost) will, on net, result on more expensive products - since on net you're wasting more resources.
This doesn't logically follow. Mandating you need to put out a patch creates a legal obligation that would sit on your books. Cutting the 12 people off your multiplayer game after 20 years isn't a large cost, and it's not going to make your next game more expensive. It was an externality that made consumers sad, not one making products more expensive.
>Particularly when it comes to authentication checks, this doesn't just apply to multiplayer games. Imagine if this applied to other forms of media (already kind of happening with DRM), like if we couldn't read books from over 20 years ago.
I think the DRM thing is a separate issue from the mandate for recoding games to be usable post server shutdown. I'd like it to be legislated separately as well. The books are analogous to single player games.
I think it's a slippery slope to turn that entitlement onto multiplayer games; if not that, then why not all software that you buy? Everyone should get a full refund when any software EoL's and companies go bankrupt whenever an online product stops being profitable.
You don't get a full refund in other sectors when they kill the consumable after a long while. Printer cartridges can stop being made and you don't get a refund for your printer. We didn't give HP the option "make your competitors ink work on your printer, give full refunds, support indefinitely, or open up your ink manufacturing line blueprints".
> A lawnmower isn't a piece of software. It's not licensed. There's an expectation it should continue working.
I believe we should be able to have the same expectation of software, at least where not specifically sold as "X months of access".
> If I sell you an IoT lawnmower, and you get 20 years out of it, do I owe you a full refund if I shut down my server?
Ideally, to avoid unnecessary e-waste, you should patch out the requirement or release the server-side code so I can continue using my lawnmower. Buying it off me might also work, if you're offering approximately what I'd get out of having it continue to work, but I'm not sure if that scales well.
> I don't think all the patches are small costs when you factor in licensing
If bills like this pass, middleware providers would need to license under terms that allow distribution at end-of-life, or lose out on all customers selling software in California/EU/etc. Should also help clear obstacles for developers who already want to distribute their server/source code even before this law but are held back from doing so.
> Mandating you need to put out a patch creates a legal obligation that would sit on your books
There's no issue with creating the patch/releasing the server-side software early, just that I assume they'd want to maintain exclusivity to milk profit for as long as possible.
> It was an externality that made consumers sad, not one making products more expensive
If you expend resources to create some media/software/product, then brick that product while customers would've otherwise still extracted value in excess of the patch's resource cost (developer time, not licensing price), then you're on net wasting resources and thus making products in general more expensive.
Issue is that because the cost of patch is borne by the company, whereas they get to ignore the cost to the customers of bricking the products, the latter is often preferred even though it's typically the more expensive option by a significant margin. A bill like this should fix that.
> I think it's a slippery slope to turn that entitlement onto multiplayer games; if not that, then why not all software that you buy?
I believe it should, and that for a lot of software the case is even stronger.
> Everyone should get a full refund when any software EoL's and companies go bankrupt whenever an online product stops being profitable.
If you take someone's money to buy a CAD package, then no longer want to provide some service it relies on (usually just for authentication reasons), then you should release the server software or patch out the authentication check.
> We didn't give HP the option "make your competitors ink work on your printer, give full refunds, support indefinitely, or open up your ink manufacturing line blueprints"
Plenty of games (especially MMOs) have lots of gameplay logic in the server. In many cases that is intertwined with the rest of the intrastructure, like databases, logging, deployment or even subscription services. Lots of games simply wouldn’t be functional without the publisher’s infrastructure.
Of course that is regrettable and could be changed, but it would require a significant change in incentives.
Authentication is an interesting example - it sounds like might be the easiest component to remove. But without authentication, you don't have identity. And without identity you have no viable notion of accounts - and without accounts you don't have persistence, entitlements, progression, achievements, or any of the meta aspects that are deeply entwined with modern games. Not to mention how extensively identity ties into Matchmaking - another fairly complex backend service.
This legislation might be more persuasive if it were tied to a reasonable time limit, but I don't see anything of that nature in the text. An obligation to support or refund customers that lasts for a fair timespan (ie. preventing rugpulls) is far less onerous than an obligation to release your code to satisfy someone's nostalgia.
For many games (and software, IoT devices, etc.), persistence/progression is tied to save files on your own device, and any authentication is more to the publisher's benefit of making sure you have an authorized copy - that's where it should be fine to just patch out the authentication check.
Even for games with centralized server-side progression, if you don't want to release the authentication service when you stop running it, then it could still be acceptable to patch out authentication by default and let those running community servers substitute in their own access system (like cracked/leaked unofficial servers already do).
> This legislation might be more persuasive if it were tied to a reasonable time limit, but I don't see anything of that nature in the text. An obligation to support or refund customers that lasts for a fair timespan (ie. preventing rugpulls) is far less onerous than an obligation to release your code to satisfy someone's nostalgia.
Should we be able to read books and watch movies that were released over, say, 20 years ago - or is that just satisfying someone's nostalgia? Maybe you don't think this matters for games, but with DRM it seems other media isn't far behind.
I remember that PIC project. I don't know if source was ever released, but I recall a lot of folks being very dubious about the claims made.
Quote:
The PIC has 1024 words (12-bits) of program ROM,
~256 bytes contain a hand-crafted RFC1122-compliant implementation of TCP/IP including.
HTTP/1.0 and i2c eeprom Filesystem, using 3 to 99 instructions.
TCP and UDP protocol stack, using 70 to 99 instructions.
ICMP [supports upto ping -s 11], using upto 14 instructions.
IP - Internet Protocol, v4, using 68 to 77 instructions.
SLIP - Serial Line IP packetisation, about 76 inst
Fully buffered UART, upto 115200 bps, using 38 to 56 instructions.
Operating system: RTOS with Rate Monotonic Analysis, using 3 to 15 instructions.
The problem with shebangs that I really want to solve is that I often need to edit files on a Windows machine, and then try to run the resulting CR/LF scripts on a Linux machine using a shared filesystem. (Docker, WSL, Vagrant etc...).
I'd like to invoke them with just (eg.) ./dostuff.py - Python, Ruby etc... have absolutely no problem running files containing Win-style line-endings. The only issue is that /usr/bin/env complains that it can't find (eg.) "python3\n".
Yes, I know I could convert these files with dos2unix, and I also know that I can just invoke the interpreter explicitly - but I'm lazy, and this seems like such a trivial thing to solve that I can't believe it's not been done already.
I've taken to actually recompiling /usr/bin/env to strip trailing whitespace from the executable name - but there must be a better solution.
There are editors that allow preserving the line endings (be they LF, CRLF or CR) from the source file. That could be a solution since you already seem to have control over your environments.
From personal experience, I've always had better results from Simulated Annealing than Genetic Programming. I hasten to point out that it's entirely possible I've been doing GP poorly - but part of the problem seems to me that GP has so many more knobs/dials/parameters that need to be tweaked correctly in order to yield good results.
Are you referring to GA or GP? GP is not comparable to simulated annealing, as it's kind of non-parametric.
Many ideas of GP are getting reused in Bayesian program induction, in conjunction with differentiable programming, SAT solvers, etc [1]. IMHO a very promising route to AGI.
These are orthogonal things. Simulated annealing is an algorithm. Genetic Programming is pursuit, which can (among other things) use simulated annealing to achieve its goal. Are you sure you're not confusing this with something else? Did you mean Koza-style GP perhaps? Or did you mean a genetic algorithm (GA)?
Because I wanted a strongly typed language that among many good things provides the opportunity for better error messages. Also, the AngelScript compiler is 100% embedded in the application and does not rely on an external environment like Python does. This makes it very easy to install and use AngelCAD.
I know Python is popular, and there is nothing to stop you from developing an alternative front end in Python or any other language of your liking, and still use the AngelCAD boolean engine, just implement the xcsg protocol https://github.com/arnholm/xcsg/wiki
A better question would be, why yet another C knockoff on top of XML bloat? It just seems so uninspired. 3D drawing ought to be a slam-dunk for a dedicated DSL: pure functional composition (objects described in terms of relationships with each other), homoiconic (so code can generate code directly; no need for XML middleware makework).
Plus pure FP code should time-independent in its evaluation, so it doesn’t take a genius to imagine the benefits of (safely!) introducing a time axis on top of that. Procedural generation, animation; great potential there.
This is not all idle speculation, BTW: I wrote a semi-declarative DSL for 2D artwork production that blew its traditional imperative rivals out of the water while also being easy enough for non-programmers to use. So I know there’s potential there, and I’d be fascinated to see what kind of language someone with a mind for 3D math could shape for the task. Plus as a trained sculptor turned automation junkie who can’t stand GUI-based 3D drawing apps (they just don’t fit my head), I’d love to try something with a language-based interface instead.
My team and I run the servers for a number of very big videogames. For a high-cpu workload, if you look around at static on-prem hosting and actually do some real performance bencharking, you will find that cloud machines - though convenient - generally cost at least 2x as much per unit performance. Not only that, but cloud will absolutely gouge you on egress bandwidth - leading to a cost multiplier that's closer to 4x, depending on the balance between compute and outbound bandwidth.
That's not to say we don't use the cloud - in fact we use it extensively.
Since you have to pay for static capacity 24/7 - even when your regional players are asleep and the machines are idle, there are some gains to be had by using the right blend of static/elastic - don't plan to cover peaks with 100% static - and spin up the elastic machines when your static capacity is fully consumed. This holds true for anything that results in more usage - a busy weekend, an in-game event, a new piece of downloadable content, etc... It's also a great way to deal with not knowing exactly how many players are going to show up on day 1.
Regarding latency, we have machines in many smaller datacenters around the world. We can generally get players far closer to one of our machines than to AWS/GCP/Azure, resulting in better in-game ping, which is super important to us. This will change over time as more and more cloud DCs spring up, but for now we're pretty happy with the blend.
I discovered that my son (17 months old at the time) loves to mess with stereo controls. So I bought a few rotary encoders and neo-pixel rings - build a wooden enclosure with a plastic faceplate, and wrote some code to generate fancy light and audio effects when he turns/clicks the knobs. He loved it. We call it the "Max Distractor".
I recently needed to encode a 32-bit value into something easy for QA folks to remember and report. I opted for 3 words out of an 11-bit (2048 entry) dictionary of commonly used words.
How to build the dictionary? Well, in order to determine the most commonly used English words, I downloaded a bunch of free texts from Project Gutenberg, and did some simple filtering - nothing less than 5 letters, no duplication of singular + plural, etc...
A valuable lesson that I learned during this process is that when your corpus includes older english texts, you should always give your final list a visual once-over and apply some judicious manual filtering. I'm looking at you, "The Adventures of Tom Sawyer". (And, to a lesser extent, Moby Dick).
Or use the BIP39 lists since they also encode 2048 bits. If you just use BIP39 you also get a checksum. RFC 1751[1] is the "standardised" option but IMHO the wordlist they use is far too easy to misread (though this is because the words are all less than 4 characters).
I have a Sonos that came with my house. It's actually the least of my worries.
The house was built about 10 years ago with what (I presume) was a state-of-the-art system at the time - an "AudioAccess WHEN" system. It works fine - there are keypads and speakers in every room, and I can pipe audio from the Sonos (or an Airplay receiver) to anywhere.
It's a weird topology, however - the speakers in each room are wired to the keypads (which is where the amps live). Each keypad has a power connection, and some kind of (presumably proprietary) Cat-5 connection to a central hub. The hub in turn is connected via Cat-5 to a head unit with FM receiver, CD/AUX inputs, etc...
When we moved into the house, the head unit wasn't working - it refused to establish a connection to the hub. I managed to track down a working tech support phone number, only to hear that they don't make this system any more, and that the head units often fail in this way. I managed to find what may have been the last replacement head unit in existence on Ebay - bought it, and fortunately everything started working!
I am, however, dreading the day when it inevitably dies. Since the speaker wires go to the keypad amps, and not to the wiring closet (where the hubs live), I'm not sure what I could replace it with - beyond re-running new speaker wire to a completely new system in the wiring closet.
If there's cat5 at the keypads back to the central hub, and the speaker wires go to the keypads, then you can just hook the wires from the speakers to the cat5 - choose one or two pair (depending on the distance, you might want to "double up" to lower the impedance over the run), and hook 'em up. Then you just need to figure out a distribution system at the central hub location.
If you find you can run the speakers on a single pair per speaker - that will leave you with 2 other pairs on the cat5 - which you could use for control or communication.
But what I would do before all of that is try to reverse-engineer the protocols or whatnot that the whole system is currently using, so you can keep the keypads/amps and such, and create some kind of custom main "head unit" later.
That might be fine for very small titles - where the "game server" is a relatively simple binary that can be run anywhere. Larger titles depend on a huge amount of infrastructure, for authentication, progression, matchmaking, etc... It's not feasible to open-source all of that, especially given that it may well still be in use for more recent titles.