MUD: Past, present, and future by Alvarius | Devcon SEA

[Music] my name is alvarius and I have the honor of doing the intro keino today and I'm gonna talk about the past the present and the future of mut um some of you might have lived through the past of mut with us and some of you might have just discovered mut so after this hopefully all of you should have the same context past present and future of mud or with the words of Kent Beck make it work make it right and then make it fast it fits surprisingly well to the phases or chapters that mut went through um so I thought I'd I'd structure the talk like that um so we start with the first chapter make it work it started basically three and a half years ago when Justin and I um got really inspired by Dark Forest and decided to build our own fully onchain game and so this this was a very early version of what we started building um back then it was called ZK dungeon we quickly removed all the ZK from it because it actually didn't really matter for the for the game mechanics um but the game the name stuck for a little bit and then after around six months um we had this all the game mechanics were really polished um all the all the UI was really polished polished as well um but we made one big mistake which was we didn't really do any play tests until then we really only played with the two of us we thought it's fun and maybe with a couple of people from The Dark Forest office where we were working from at the time um but yeah we never did any larger scale play tests and so when we did our first larger scale play test um after like six months we realized it's actually not as fun as we thought and so lesson learned you should do play tests early and iterate based on that um we then tried to iterate from that point on but because of the custom Network stack that we had built for game specifically because there was no mud at the time um iterating on this game was actually really hard and for that let me let me illustrate just real quick how we had to do things before mud was a thing um we had positions in our game so we created a mapping on our contracts and then GAA functions on the contract so that the client can initialize the initial State when the client loads up and then we also had um events whenever anything changed on the contract so here in our move function we have to we have we have to um like set the set the storage but then also emit an event and then replicate the whole state on the client um and then we had to do that with every type of state that we wanted to have in our game position was obviously not the only type of state so Health Energy skills inventory and so on like you you get the idea lot of boiler plate just to keep the contract and the client state in sync and then at some point we also discovered ECS which which then kind of like made a big impression of us on us um it's kind of a pattern that people use in the you know traditional gaming industry a lot to manage the complexity of games and so around this time we decided to basically trash what we have so far and instead build a framework for ourselves to solve our own problems so that we for the next project can skip all the boiler plate and jump right into the the game mechanics and iterate much more quickly and so that's basically what became the version one of mud we basically implemented ECS on chain and it worked pretty well uh at least in terms of iterating faster this is a screenshot of of basically our second prototype we built and this time it only took us a couple weeks to build a functioning prototype um this is what eventually turned into Sky Drive we did play tests uh like a lot of them and then iterated on it and we also built another game around this time which we called opcraft and that started almost as a challenge for ourselves we wanted to see if we could put Minecraft fully on chain um and turned out it's possible and um we built actually the Prototype of this even in in the in the matter of a couple days it we we you know cut some corners but um like position for example wasn't fully Unchained like the player position but it was possible because M basically solved almost all the hard problems that we had for our first prototypes were already solved so here we could move much faster and then we did a twoe play test of this and it was really fun people build a lot of crazy stuff and there were even even some emerging drama there was uh one player who claimed a lot of regions around the spawn and then claimed the or declared the autonomous People's Republic of opcraft and declared himself the Supreme Commander and um it was basically a Communist Regime they they you could join the Communist Regime by giving up all your personal belongings and they even built some onchain and client extensions to basically be able to join the the the autonomous pup's Republic and then tap into the inventory of the of the Republic and so on and people built monuments and it was all very fun but eventually after two weeks play test nothing worked anymore and that was because we used pretty strict ECS patterns back then but there's some problems with ECS if you want to really model everything as ECS in our case one example was the inventory um we modeled our state in a way where each individual and each individual item was an entity and so once people figured out how to mine with Bots they had like tens of thousands of dirt blocks in their inventory and then each of those dirt blocks was a unique entity that had to be synchronized to the client and also because of our data model um basically every player had to download the entire state of the entire world and the inventory of every player every time they wanted to load the game and so after two weeks people had to download multiple gigabytes of data just to boot the client which brings us to our next chapter make it right mud one was really more of a prototype to see if we you know if this makes sense like does it make sense to have a full stack framework and this this these patterns to iterate faster um and it proved that the developer experience and the iteration speed was much faster with it but it had some fundamental limitations and for that to illustrate that um I'm going to give you a super quick ECS crash course in case you're not familiar um it's very simple ECS stands for entity component systems and entities are basically just IDs and then you associate data with them with components and it works really well for something like position you can have a position component and then each entity has their position in this component works well but then for something like an inventory it's much trickier because you have to you know you have to associate everything with entities so you have basically have two options for an inventory um option one is what we use for opcraft which is each item is its own entity and then you have something like an owned by component which basically Associates the owner of this entity with the enti with the item and then you model the inventory that way but then you run into this problem with you know 10,000 unique dirt blocks in your inventory another option is a little bit more hacky um you can basically create this kind of pseudo entity by something like hashing together the player and the item um and then that's your entity and then you associate the number of of entities or the number of items the player has um with this pseudo entity but it's really hacky not nice to work with you know you have only still one one column for player and item and in the worst case it's a hash so you can't even really see what's the player and what's the entity then we um had a realization which is um ECS is basically just a subset of relational databases and um it has one limitation which is the entity has to be the key and so we decided to lift this limitation and instead model it as a table which made modeling something like an inventory much easier and ECS can still be represented within this new model because it's a subset so you can now have something like the position table still um just by using the entity as the only key that sounds like an easy change but it was actually much harder than we thought um we proposed doing this um early in 2023 and then we also proposed uh changing the world framework to work better with the STA model but turns out we were wrong it wasn't just a 20-minute Adventure it almost took us um an entire year and was basically a full rewrite of the entire thing and migrating from version one to V2 was pretty painful for the people who started building with version one we felt that in our own team and we started building Sky Strife on the first version and then we had to migrate it to the second version which drove kusaba our main engineer on Sky strive almost crazy um but once we pushed through it it was worth it um the gas was way down because we focused way more on gas optimization and and the the improved data model on the improve the improved syn stack meant that now you could load the client much much much faster and so once we pushed through it it was it was worth it and kusaba was happy again then more and more teams started using M and also larger larger Studios like CCP games started building um their new game e Frontier on mud and so we realized oh and more more more and more team teams were already pushing for production back then and so we realized okay it's time for an audit um we then worked with open Zeppelin to audit the core of mud but still maintain the flexibility to add more features as modules because M version two was built to be very modular but what that also means is that there are no more breaking changes in the core of mud and that now means that we can on our end first focus more on the the Integrations and developer experience um but also other third parties can now you know trust this interface is that it won't break anymore um and build Integrations on top so I want to show you a couple a couple things um that we built in terms of developer experience since then um here you see the world Explorer which basically allows you to interact inspect the transactions that happening in your in this case local client but also remote deployed World um in real time and inspect the round trip and everything and then also the table view where you can inspect all of your tables data um yeah in in the in the world Explorer so all of your onchain state you can just inspect it here and then we have a second view of the world Explorer which is a slightly more complex table um where now we can even use SQL to uh filter the table so in this case we have a task list and we filter it to the ones that are completed or the ones that are not completed and then the last thing I want to show you is again World Explorer but the world Explorer is basically just do your ey for all the other features that we had to build below that um here you can see the world Explorer automatically synchronizes the ABI of the world and you can interact with the ABI through the world Explorer and then when you modify your your contracts your systems um it's automatically picked up by the you know contract Staff Runner and it's going to update the AI on the world Explorer immediately so you can again interact with your new functionality on the well Explorer immediately and these you know like these stable interfaces enable um more and more Integrations to be built and we wanted to take that commitment one step further for a dist stable interface and so we're now working on an on an ERC for the store standard so for the events and the interface of the store um it's currently in draft State IRC 7813 if you want to follow along or join the discussion and yeah the hope is that that will allow more and more uh tools and Integrations to be built on top of that and I want to give a shout out to block Scout at this point because they already built an integration format so now you can go on block Scout explore the worlds there and um even inspect the table data directly from blog Scout all right all of that brings us to the present chapter of making it fast imagine you want to join a new shiny autonomous world all right that doesn't load but just imagine use your imagination um but then suddenly you greet it by a fox and the fox tells you that you don't have any funds on this chain and now you have to find a bridge to bridge the funds to this chain and then you have to approve that transaction and then when you want to make a move in the world you have to approve that transaction and approve another one and every time you want to do anything you have to approve all of those transactions and we don't want that for our games at least like while when you're logged in we don't want to hit approve every time and so there there already is the foundation for very smart very smooth onboarding in the contracts of mud but we can take it further with like client side libraries and deeper integration with smart accounts so um what M already allows you is to create you know a session wallet and then create a scope delegation um and then avoid that approval popup and here's what it looks like in action hopefully that one loads so you can see you can you could connect a wallet here or you can just create a new wallet if you don't have a wallet yet in this case one that's um secured by pasy and then you get an allowance on this chain immediately which is basically some some e that you can only spend on actions on this chain and then uh you basically approve the Del the delegation scoped and temporary delegation to a session wallet and now you can make moves in this game um immediately without having to click the approv button all the time and one thing you also saw there is the fly was moving pretty fast um that's something I'm not going to talk about right now but we have another session later today that explains um how the fly can move so fast um okay B quick bonus chapter what's happening in the future after making it fast um make it scale we can already see the first worlds that are starting to you know outgrow at single chains and we can see much more worlds that are some of them presenting today that are basically you know have a clear trajectory of outgrown a single chain even the most powerful single chain so we eventually have to scale those worlds across multiple chains and mud was always about um improving the developer experience um and so one thing that one thing that will be a big theme of next year will be can we use mud to basically abstract away the multi-chain develop experience and just make it feel like you're building on a single chain but have the ability to scale across multiple chains all right with that we've completed the mud time travel and I'm very excited for what's next we'll see a bunch of demos and then also later a bunch of talks um and we have a gaming Corner over there where later you can try out some of the Mud Games as well um and then later I don't know what time but some something around one or something we have also some some announcements to make um so be sure to catch that and yeah with that thank you very much and have fun all right um alvaris cannot leave yet um we're going to give you guys about 30 seconds to scan this QR code um log into zass uh you don't need a frog for this interaction um but you should have frogs if you don't have frogs anyway so you scan this thing and you can ask questions to alvarus they will appear on the screen I will read the questions um and we'll see what he thinks we have about two minutes worth of question time so hurry up everybody's busy making ZK proofs whoa okay first question are there any plans to make mud use less gas alvarus that's a great question um so we spent already a lot of lot of time making mud two much more gas efficient than mud one and now now we're at the point where if you use mud to do the things you you know like if you would build an app from scratch and you would set the storage and you would um emit an event um you know to sync the state on the client it's not going to be much more gas efficient actually than than to use mod um so it might seem like it's using more gas but that's just because there's so much stuff that you know comes by default out of the box that you would have to implement yourself and solidity if you if you wanted to get to the same um functionality so um while we always you know optimize the stuff it's it's not as gas inefficient as you as you might think on first side thank you um the other the next most upvoted question is sorry I am a noob thanks for coming by the way if you're a noob uh we appreciate why is it good to put movements on chain for example it's essentially I mean it's it's almost like a philosophical question but the more stuff you put on chain the more Downstream Integrations you enable because it's it's like a you know you're deploying to this public computer and this public you know database that anybody else can also deploy to and the more stuff is in there the more can be used for Downstream integration so let's say you put movements on chain um now somebody could build an integration that you know does something if you move to a certain position that wouldn't be possible if you don't put movements on chain thank you alvarus another round of applause please