BeastMaster's design is guided by the following principles:
- BeastMaster should eschew the use of NMS classes, since they are a maintenance obstacle.
- BeastMaster should avoid hard dependencies on other plugins. It should degrade gracefully in their absence.
- Configuration should be performed with in-game commands rather than by editing configuration files.
The last point deserves to be expanded upon in detail.
A lot of plugins require that the administrator edit a configuration file of some sort - usually YAML syntax. A couple of things can go wrong here:
- A simple typo - such as a misplaced apostrophe - can easily prevent the server from loading the whole YAML configuration.
- Syntactically valid YAML can be semantically invalid, and resolving multiple errors can require multiple reloads to resolve them one at a time.
- Sometimes, for brevity, plugin designers will opt to wedge a custom configuration language into YAML strings. These languages tend to be poorly documented. Typically, there is usually no EBNF specification of what constitutes valid syntax.
By contrast, mutating the configuration by commands ensures that each small change is validated by plugin code, rather than at some far future point by a generic configuration parser. Which is not to say that configuring BeastMaster only with commands does not have any drawbacks: the chief disadvantage is that it is difficult to visualise a complex configuration as text seen through the limited-size window of the Minecraft chat box. A possible remedy would be to have BeastMaster generate a web page summarising the configuration after each change.