Now it becomes way more expensive for small studios to come out with games that have online features. This is a huge win for big studios who will suck up all that market share.
Handing over a standalone server to the public is a massive engineering, financial, and legal headache. Modern multiplayer games rarely run on a single isolated program. They rely on a huge network of interconnected cloud micro services.
A single match might require separate proprietary systems for matchmaking, player inventories, anti cheat, metrics tracking, and database management. Many of those come with licenses that don't allow you to just give away the code for free.
Disentangling the actual game logic from these third party platforms like AWS or Epic Online Services requires months of rewriting code. At that point you're basically re-inventing the wheel on so many technologies that your costs go up exponentially.
Games are rarely built entirely from scratch by a single company and are usually packed with licensed proprietary third party software. Because the studio doesn't own the rights to distribute these proprietary tools to the public for free then releasing a standalone server forces them to spend extensive legal and development hours stripping out the restricted code and replacing it with open source alternatives.
Releasing server code also exposes the inner workings of the company's technology. If a studio uses the same proprietary engine or backend framework for their active money making games then releasing the server code for a dead game essentially hands hackers and competitors a roadmap to exploit their current profitable titles.
> A single match might require separate proprietary systems for matchmaking, player inventories, anti cheat, metrics tracking, and database management. Many of those come with licenses that don't allow you to just give away the code for free.
None of those things are required to be supported by this law. It's the minimum viable product to enable multiplayer play.
- Ditch the matchmaking, players can build their own communities and use server lists for discovery
- Ditch the anti-cheat if you can't distribute it, it's not necessary for online play
- Ditch the metrics, of course
- Let the player download their inventory save file or something, idc
i mean its perfectly valid to create a new exception to copyright laws. in fact it might already exist because if you are legally required to release something that beats all the contracts you signed in any reasonable jurisdiction. weaker ip means giving a head start to new devs and bankrupting commercial engine vendors. and im all for making epic and unity go out of business
It's essentially saying that you start with an outline, then progressively fill in the sections, iterating and providing more detail at each iteration. I do something similar, which is why I prefer to work in outline mode (e.g. in MS Word) as it is the most flexible and "minimalist" mode for structured writing.
We're at the point now with AI where people are realizing that innovation doesn't happen automatically when you have more resources or the ability to crank out more output. Innovation usually requires real problems to solve, a limitation on resources, and creative people working on problems they find interesting. If you're in a mature industry, chances are, there is little room to innovate with AI. Not because AI isn't a wonderful tool but because your company, and competitors, have put in hundreds of thousands of human hours into solving the problems of your industry. If they haven't come up something innovative in the last 5 to 10 years, AI probably isn't either.
The speed of writing code was never the bottleneck in software. Yes, AI can do it faster, but the parts that are most challenging are finding a market and figuring out how to best serve it. Those are the parts that take the longest and, often, the most resources. In reality, this is the real business of any company, what they produce is just a side effect of finding these two things. AI hasn't shown much promise in this regard. There are some simulated and small real world tries like what Andonlabs[1] is doing but it seems humans are still better at this kind of problem solving.
Companies have been spending ridiculous amounts of money trying to squeeze innovation out of a tool that is designed to produce statistically average results. This leads to mass layoffs because workers, who also produce average results, are seen as redundant. But when average workers come together they can produce extraordinary results through the mere act of working on something long enough and synthesizing ideas. Eventually, someone will say or write something that triggers a thought for someone else and it leads to a breakthrough. AI can't do this, yet.
Came here to post this. Yes, there are similarities shown between the chart in the video at 4:50 and the github README. Perhaps its because LLMs are trained on human writing and when humans write about random numbers the AI learns these patterns. When viewed from that perspective its not that surprising.
The argument (maybe in a sibling comment) was that, if the US switched to a 4-day workweek, companies would simply offshore their work to poorer countries who work 5 days, so my question is, then why isn't the current workweek 7 days?
What is more of a joke is the fact that I remember a time when there were multiple computer companies that designed hardware and software (OS) and actually sold those items to the public 1980s early-late 1990’s all those companies are gone IBM (is but a shadow of its former self), Sun, Digital, Atari, Commodore Amiga, Next, Acorn, and SGI etc… At the time Next and SGI were completely unaffordable dreams when I was young.
For the most part, no one has really picked up the gauntlet since aside from Apple on the desktop as a vertical computer company.
Of course, pieces of the tech still live on notably from Next computers, Acorn (ARM) and SGI.
I wish someone would use Linux as part of being a new vertical computer company OS and hardware on the desktop. Why? Baffling.
If FreeBSD was a desktop OS this might be reasonable, but it’s simply not. This is akin to complaining that the executive director of the Linux Foundation (I assume) does not run Kubernetes on their toaster oven.
I wonder if with the speed of iteration with AI the industry will switch back to waterfall. Clear documentation first so the LLM can easily produce what's being asked with a round of testing before going back to the documentation stage and running it again. History does repeat itself.
As others have noted only the div is allowed. This isn't a unique situation either, the HTML spec despite being lenient in syntax is quite restrictive in behavior. It's unfortunate that XHTML (and XML parsing) didn't become the default as it's the opposite, more restrictive syntax, but lenient behavior.
For example in XHTML you can use custom elements as table rows or cells (provided you give them the correct role and CSS display property). This is because XHTML does not modify the tree during parsing, unlike HTML which will hoist out custom element children of the table to the table's parent.
They're not as you can see here[1] and here[2]. They both inherit from the HTMLElement interface but div is considered an HTMLDivElement which makes it distinct from a custom element.
HTMLDivElement has no properties or methods not inherited from HTMLElement. If you inspect the user-agent styling of div versus any non-standard named element, you'll see that they have the same styling path, specifically unlike with span. In other words, non-standard elements and divs are all block elements with the default HTMLElement attributes and methods.
The use of HTMLElement and HTMLUnknownElement for the non-standard elements is to support future additions to the standard elements and enable subclassing down-tree instead of across-tree, which is noted in the spec.
Exactly! It cracks me up when people name-check "semantic elements" when it doesn't actually mean anything in that context. Accessibility software doesn't understand the semantics of your custom elements, so there is no benefit in that situation whatsoever. Maybe it's easier for you to read and edit in the future, but that's it.
Somehow, people got convinced that <div> elements are evil and should never be used no matter what. Yes, you should use a more semantic element when it makes sense, but try to remember what that phrase actually means.
I use it for readability and to express intention and meaning to the reader of my program. In the age of AI, perhaps, we've lost the need for that. But it was much appreciated in times before by those who came upon my code.
However, "semantic elements" became popular shortly after the push for the "semantic web" which was entirely based around making the web easier to process for machines. Many of the original sources talk about how it's easier to digest for humans too, but that's just a happy byproduct.
Handing over a standalone server to the public is a massive engineering, financial, and legal headache. Modern multiplayer games rarely run on a single isolated program. They rely on a huge network of interconnected cloud micro services.
A single match might require separate proprietary systems for matchmaking, player inventories, anti cheat, metrics tracking, and database management. Many of those come with licenses that don't allow you to just give away the code for free.
Disentangling the actual game logic from these third party platforms like AWS or Epic Online Services requires months of rewriting code. At that point you're basically re-inventing the wheel on so many technologies that your costs go up exponentially.
Games are rarely built entirely from scratch by a single company and are usually packed with licensed proprietary third party software. Because the studio doesn't own the rights to distribute these proprietary tools to the public for free then releasing a standalone server forces them to spend extensive legal and development hours stripping out the restricted code and replacing it with open source alternatives.
Releasing server code also exposes the inner workings of the company's technology. If a studio uses the same proprietary engine or backend framework for their active money making games then releasing the server code for a dead game essentially hands hackers and competitors a roadmap to exploit their current profitable titles.
reply