[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