Tangentially related, I just recently found out that Lumberyard actually was spun out[1] into the open source Open 3D Engine[2] under the stewardship of the Linux Foundation. It's a nice surprise to see that Lumberyard didn't just die out, and is joining the ranks of open-source engines.
I'd call D&D more of a framework for collaborative storytelling that can absolutely be played as a game. The DM leads the adventure, the players decide how to respond to things. Everyone plays D&D a bit differently.
The most straightforward adventures that typically have a "win condition" are one shots/self-contained adventures from either WoTC or 3rd Party Publishers, like Curse of Strahd, Waterdeep: Dragon Heist, etc.
However, a lot of D&D groups I've played with might have characters die, but will rarely have a group "lose". However, because every group runs things a bit differently, a different group can drastically change how the game feels.
During the initial kerfuffle, a Unity employee did quote one of their lawyers saying the following[1]:
> Our terms of service provide that Unity may add or change fees at any time. We are providing more than three months advance notice of the Unity Runtime Fee before it goes into effect. Consent is not required for additional fees to take effect, and the only version of our terms is the most current version; you simply cannot choose to comply with a prior version. Further, our terms are governed by California law, notwithstanding the country of the customer.
The communication around this rollout was absolute rubbish. Even employees were trying to get clarity, and they were forced to figure it out and real time.
> Further, our terms are governed by California law, notwithstanding the country of the customer.
So presumably if you’re a customer in the EU you’re still doing business directly with their CA HQ and not an office registered in Ireland/Luxemburg/etc. (pretty much how every other major company does it?)?
Then again why wouldn’t you say stuff like that as a lawyer? The fees from all the lawsuits would’ve been pretty immense (regardless of who wins..)
I know for me (as someone who would likely never have had to pay a dime under either pricing scheme) the crux of the issue was unilateral, retroactive changes to a license that was supposed to be tied to the software version, as well as the nebulous "we'll know what to charge you because of our proprietary data model, trust us" messaging that they first went with.
That, combined with the fact that there was no safeguard for the install fee to be capped at some percentage of gross revenue made it so clear that they were trying to get something out of their free to play market specifically, which seems to have been to force their F2P customers to use their Unity Ads service over Applovin or similar competitors since they gave credits towards the runtime fee if you vertically integrated with Unity.
Definitely use a battle-tested HTML sanitization library if possible. There's a million different pitfalls and footguns with XSS. See: Some of the insane XSS polyglots out there that can be used for testing.
Most extensions could likely be built and tested just fine on a ~$250-$350 used Mac mini. That's probably still more money than should need to be spent, but a brand new machine probably isn't necessary in this particular case.
I was thinking on that. You still need peripherals if you're using a Mac Mini, though that's no different than if you were using another desktop. Still though, if you don't use, or don't want to use a Mac as your daily driver, that's a dedicated machine just to build/publish an extension for a browser. IMO, there's a slightly stronger case for iOS apps, but requiring that for a browser extension is much harder to justify.
However, if you're the creator of a Firefox/Chrome extension, and want to utilize the WebExtension support in Safari, your deployment workflow can no longer be platform agnostic.
I've done this to build for MacOS, and it still becomes like a tax as the hardware ages out and Apple insists you have the latest OS to publish to their stores.
Synchronous communication typically means something that demands your attention as soon as something is sent. Asynchronous communication is something that typically handled whenever you're ready for it. To put it in programming terms, synchronous communication "blocks" until you deal with it, where as asynchronous doesn't require you to deal with it until you're ready to.
I mean, when a lawyer takes a case on contingency, they're essentially gambling their time on hopes of an outcome where their share (30-50% isn't uncommon, if I remember correctly) would make the time and effort spent on the case worth it. Against a company the size of Disney, with incentive to make the case as long and painful as possible to try and discourage other creators from trying to get what they're owed, it would likely take thousands of man hours, and tens of thousands of dollars out of pocket. Between discovery, filing fees, appeals, all for a victory that would result in (and I'm just completely guessing based on essentially no data) only hundreds of thousands of dollars. Lawsuits can very much end up being pyrrhic victories based on the costs incurred alone, not to mention the emotional toll that fighting a protracted legal battle can inflict upon a person.
