Clojure API for Bukkit-based Minecraft servers (Spigot/Paper/Glowstone)
- Create and control world, blocks, creatures, players, etc
- Handle events and create custom interactions
- Cursor/turtle API
- Shapes API
- Vector/Matrix transformation API
- Palette/Color API
There are two ways to use Witchcraft, for most cases the best option is using the Witchcraft Plugin. This provides a REPL connection, and the ability to load Clojure libraries. Download the plugin jar for your server and start playing.
You can also start a Clojure REPL yourself, and then start a Minecraft server from there. If you are already familiar with a Clojure workflow then maybe this is the more convenient way to get started. This works best with Glowstone, since then you don't have to worry about patching proprietary code or agreeing to the EULA.
Clojure's interactive programming make it perfect for creative coding. We try to provide convenient APIs so you can go and develop your ideas.
Start by watching some of the videos to get a sense of what you can and to get inspired.
There is a work-in-progress manual.
This is not the first attempt to bridge the gap between Clojure and Minecraft
witchcraft is part of a growing collection of quality Clojure libraries created and maintained by the fine folks at Gaiwan.
Pay it forward by becoming a backer on our Open Collective, so that we may continue to enjoy a thriving Clojure ecosystem.
You can find an overview of our projects at lambdaisland/open-source.
Everyone has a right to submit patches to witchcraft, and thus become a contributor.
Contributors MUST
- adhere to the LambdaIsland Clojure Style Guide
- write patches that solve a problem. Start by stating the problem, then supply a minimal solution.
* - agree to license their contributions as MPL 2.0.
- not break the contract with downstream consumers.
** - not break the tests.
Contributors SHOULD
- update the CHANGELOG and README.
- add tests for new functionality.
If you submit a pull request that adheres to these rules, then it will almost certainly be merged immediately. However some things may require more consideration. If you add new dependencies, or significantly increase the API surface, then we need to decide if these changes are in line with the project's goals. In this case you can start by writing a pitch, and collecting feedback on it.
* This goes for features too, a feature needs to solve a problem. State the problem it solves, then supply a minimal solution.
** As long as this project has not seen a public release (i.e. is not on Clojars)
we may still consider making breaking changes, if there is consensus that the
changes are justified.
Copyright © 2021 Arne Brasseur and Contributors
Licensed under the term of the Mozilla Public License 2.0, see LICENSE.