This is one of the first articles I’ve read with a decent attack on reverse engineering the black boxes of neural networks. I particularly appreciate the use of corrupted prompts for isolating behaviors.
Which would be hella cool, especially if you abstract up a level and store and execute platform data (an MMO game vs. VR meeting place) in a distributed way.
Hi, fellow MUD/MMO person here with an additional background in blockchain.
Can you walk us through where you think a language like Verse really shines with transactionality versus the current server authoritative models we see implemented in [language here] using [framework/pattern] here (like C++ and ECS)?
I've done my fair share of FP (got into Haskell years ago) so I see value here, but I'm not sure I'm grokking your level of excitement and would like to understand better.
You know, your comment made me rethink a few things.
I don't know if they have the wrong end of the stick. I'm afraid they might, because based on their presentations so far the Metaverse bit seems more tacked on than intrinsic. However, these are credentialed people well known in the field - it's hard to tell how much is exuberance re: Metaverse usage.
Regarding my comment on AI, I think it's relevant. It's not that AI will "solve all our problems", but that AI-aided design and code implementation will make learning a language like this obsolete. Transpilation will be seamless and backgroundy. So now there's a cost/benefit factor to learning a new language that was used to write a distributed execution layer for the Metaverse in a transaction-first manner, versus using tools that just "do it for us" and interact with the "product" created with Verse.
As far as Fortnite having a dominant market position once they do stuff with it, I'm not sure of that. I mean, StateScript being awesome doesn't make a dominant market position for it because of its use in Overwatch. I recognize the fundamental difference because the latter is closed and proprietary, sure, but I'm just not sure about the level of separation between Language and Product here when they're talking about the Metaverse. I look forward to learning more.
There comes a point in any massively scaling networking project, and here I speak with some experience, when you realize that your goal, while admirable, has no bearing on the lessons learned over the last few decades of MMO development.
I fear this is a handwave.
What I mean by that is that its addressing the wrong problem for the Metaverse. Being able to implement an ECS model, for instance, where different platforms have common system requirements but because they're both built on Verse they can easily glom/reduce/map components and functions so entities in one ruleset can interact in the other... that's neat, but not a technology problem.
It's a combinatoric problem. And a game design problem.
By the time Verse is built up enough and has enough market penetration to try to take on this sort of role as a bedrock foundation layer for the Metaverse I think we're going to see two major shifts that make it obsolete:
1. The rise of AI-aided design and programming (think ChatGPT on steroids) that makes it pointless to worry about having One Great Solution when the AIs can just interop/translate and all the platforms (even competing corporate interests) can be "Metaversy" with their entities/players.
2. Either the combinatoric problem gets solved or it doesn't. Game designers have strong opinions on NFTs, for instance. The majority recognize them as incapable of solving the item portability problem (or as Raph Koster says, is it even desired?). Either novel ways emerge to do so and it's solvable, or they don't. I suspect either way the heavy lifting is not a programming technology problem, but a contractual/API one.
I'm concerned about hoping "millions" of Metaverse devs will use Verse when, right now, the biggest problems with Metaverse are more about frameworks/netcode than the underlying language.
An open framework for handling interpolation, client & server space simulation (w/ physics), forecasting/prediction for events, and handling at least 30 ticks/s for a connection target with <150ms latency, <10% packet loss, while being able to handle thousands of connections + tens of thousands of entities PER instance (and also seamlessly mirror data across instances to enable large maps without zoning): that's a huge need for large-scale MMORPG-style Metaverse design.
I'm not at all certain we need a new language to do that.
I know it's hard to compare the usage percentage of various programming paradigms because many languages are multi-paradigm, but FP represents a much smaller piece of the pie (especially in games/networking) and, honestly, we have several generations of existing engineers who don't do FP.
Still, it's nice to see that Sweeney hasn't given up on making FP more useful to the mainstream! =)
I just want to mention that the C++ code running UO was incredibly fast at what it did, and it even wrapped a custom scripting language called Wombat that ran all the gameplay logic.
Pretty sure Jason Spangler, genius, made a JIT compiler in LLVM for Wombat just to see how much code we could execute in each 250ms tick.
During one of my live events I got 500 people on-screen (in what, an 800x600 pixel screen?) thanks to how efficient the networking, gameplay, and client rendering code had become.
Well. Then the telestorming began because I forgot to disable it…
1. EA with original Origin devs
2. EA post-Origin
3. EA, integrated into Online group (with Westwood)
4. EA Mythic (UO & DAOC)
5. Broadsword (owned by the former GM of EA Mythic under a licensing deal)
I think that’s fairly accurate. Older devs correct me if I’m wrong.
No, stacks are stacks. They’re an object id with a quantity counter. Each stack, however, was capable of holding its own separate script and objvars; there were event triggers to handle special cases like “onStackAdd” and such.
I just want to note that I only started paying attention to cryptography after I left UO and got into Bitcoin, which sounds like an NFT-grifting MMO supervillain origin story - I know - but I sure did learn a lot about merkle trees and solving interesting social problems.
As a huge fan and experienced implementer of merkle trees in my modern work I really wish I had known what they were at the time :)
Merkle trees don’t solve the forgeability issue, just the unbroken chain of what you currently have. So, if you have control over the server you can just create a set of events with your “+5 billion gold” event injected in it, recalculate the tree and root and voila: forgery.
PoW doesn’t prevent this, it just adds computational time provably spent between the events so that if you DID try to inject a false record a year ago you’d have to spend that same amount of time calculating the resulting merkle tree.
Oh, and a good aside: thanks to player exploits the nodes themselves weren’t necessarily trustworthy (such as duping exploits across shards, not just areaservs).
Like I said, not saying we “needed blockchain”, but when AWS released QLDB I was like “ohhhh, that would’ve been useful” since, you know, forging log files is a thing.
Consider the sheer scale: people sell 200 million UO gold for $10. Can you imagine every gold piece having a unique UUID? Even if you didn’t use 256 bit hashes, even at 64 bits you’d be talking about 1.6gb per $10 worth of UO gold.
UXTO would’ve been a neat technology to have to experiment with at least.
Memory was at enough of a premium that even in the tagging system we made in the article it was just for the rarest items.
I hope anyone who enjoyed the article will find time to listen to the original team discuss UO’s early development and the crazy design and social problems they were trying to solve.
They succeeded at some, spectacularly failed at others, but brought forward things that still impact MMO and (now) Metaverse design today.