## BOS vs MUD: Game development is better on NEAR? (posted via [Build DAO Gateway](https://nearbuilders.org/feed?tab=idea)) **What idea are you proposing?** We may actually have most (all?) of the capabilities for which blockchain game builders leverage MUD innately built-in to NEAR and SocialDB. I would like to analyze the MUD docs to see if this is the case, identify any gaps, and see if we can build tools to close them, and then get game builders...building! **Context or additional information:** - Once upon a time, I was looking at the MUD protocol from Lattice (https://mud.dev/introduction) to see about some IPFS integration possibilities, etc. I'm planning to build a simple game project in Denver so I was poking around some notes and remembered this project. They outline the problems they're solving in their intro: "We identified many difficulties along the way: coupling of state and logic in smart contracts makes upgrading logic difficult, lack of synchrony between the chain and client can lead to inconsistencies in game state, irregularities with access controls pose problems for would-be third-party developers attempting to create their own plugins and clients. This revealed the need for a framework and a protocol to handle the inevitable complexity of game code, and to counteract the developer-unfriendly patterns inherent in the way smart contracts are traditionally written." Am I way off track in thinking we can already solve most (all?) of those problems with NEAR account structure/key management, BOS components, and SocialDB capabilities? If so, we definitely should build some content around that and get blockchain game devs looped in here. #build #idea