The World config
In order to use World, your project needs a MUD framework config that can be interpreted by the deployer and the test-runner. Currently, the configuration parser supports typescript, but more format will come later (if you really despise javascript as an example 🥲).
The configuration file needs to be named mud.config.ts
and in the same folder as your foundry.toml
file. You’ll notice it’s the same configuration file as for Store: if you are already using Store, using World is as easy as adding additional fields to your config!
The config is used to define:
- All the tables in your project in the
tables
object of your configuration. You can head to the Store documentation to read more about the format for tables. - The namespace the systems and tables will be deployed in.
- The systems in your project. By default, the deployer will find all Solidity matching
*System*.sol
(so any file containingSystem
with a.sol
extension, in any folder) and deploy them as System. If you want greater control over your systems (to change their public access or their name), you can use thesystems
object in the config - The modules that will be installed on the World. More on this in the Modules section
An example of a World config with all the different configuration keys and options used:
import { mudConfig } from "@latticexyz/world/register";
import { resolveTableId } from "@latticexyz/config";
export default mudConfig({
excludeSystems: ["System3", "System2"],
worldContractName: "CustomWorld",
namespace: "mud",
systems: {
IncrementSystem: {
name: "increment",
openAccess: true,
},
},
tables: {
CounterTable: {
valueSchema: {
value: "uint32",
},
},
},
deploysDirectory: "./mud-deploys",
modules: [
{
name: "KeysWithValueModule",
root: true,
args: [resolveTableId("CounterTable")],
},
],
});
Global configuration keys
All of these global configuration keys are optional.
-
namespace
: astring
: which namespace to deploy the resources defined in the config into. The default value is the ROOT namespace. -
excludeSystems
: an array ofstring
: which systems to not deploy, even if their name includes “system”. -
worldContractName
: astring
: the name of a contract in your project implementing theIWorld
interface. Useful if you want to modify the default World implementation. Here be dragons 🐲 -
deploysDirectory
astring
: which folder to put the deployment artifacts into after deployment. -
modules
an array of module definition: module definition have aname
,root
(optional), andargs
key.-
name
: Name of the module to instantiate. The same module can be instantiated multiple times. This should be the name of the contract file without.sol
(eg: if the contract is namedDopeModule.sol
, the name of the module isDopeModule
) -
root
: whether to create aroot
module or not.root
modules have access to all tables and are not bound to namespace restrictions. -
args
: a list of arguments to be sent to theinstall
function of the module. In this array, you can use the functionresolveTableId
. This function will turn a table name from your config into its low-level ID in the World. It is useful to pass references of a table to a module.
-
-
systems
: a dictionary of system definitions. The keys in the array are file names without the.sol
extension. For example, if your system is namedSystemA.sol
, useSystemA
as the.The value is a dictionary of system configuration properties:
-
fileSelector
(optional): astring
: the file selector for the system. -
openAccess
(optional, defaulttrue
): abool
: if set tofalse
, only the systems in the same namespace and the addresses or systems listed from the accessList. -
accessList
(required if openAccess isfalse
): an array ofstring
. Each address in the array will be granted access to this system, allowing them to call it.
Example:
import { mudConfig } from "@latticexyz/world/register"; export default mudConfig({ systems: { SystemA: { name: "systema", openAccess: true, }, }, tables: {}, });
-