Clojure API for Bukkit-based Minecraft
- 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
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.
- 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.
- 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.