Contributing code

We welcome contributions from people of all different interests, skill levels and backgrounds!

See also: Where to contribute

We do our best to be friendly and helpful to everyone who wants to help make Rabbit Escape better - feel free to experiment and chat with us, and have fun. We all frequently make mistakes and have terrible ideas, so don't worry if you think you might do the same!

The way we normally interact is by creating GitHub issues. Feel free to create a new issue if you have an idea, a question, bug report, or want to start a conversation.

We are a very small project, and we haven't got around to writing our own code of conduct, but when we do it will look a lot like The Rust Code of Conduct. If you are in any doubt about what behaviour is acceptable in our community, please refer to that. Please let us know if we don't succeed in being welcoming, constructive and friendly, or if someone in our community is acting in a threatening or excluding way, or otherwise conflicting with the code of conduct. You can do that by emailing Andy Balaam on rabbitescape@artificialworlds.net, or by creating a GitHub issue.

Preparing a pull request

See Code style for how we like to lay out our code.

You can find out how to compile the code in INSTALL.md.

If you're working on a pull request, when you think it's ready to be merged, make sure you do:

make clean slowtest

This will make sure the code compiles with no warnings or errors (including on Android), so that if your pull request is merged you won't break anyone else's build.

Note: if you have not yet set up for Android development, make slowtest will fail saying it can't find the Android SDK. In this case, you can still run the slow tests by running make clean test slowtest-run. This bypasses the Android compile step, which means there is some danger you broke the Android build, but don't worry - we'll help you fix it if you do.

Warnings

In our build, warnings are errors, but they may not be in your IDE, so you may miss some. If you need to write code that triggers compile warnings, you can use the @SuppressWarnings annotation to suppress them, but you should expect to be asked why we need to do this!

Testing the code

• make test runs the unit tests only
• make slowtest does a full system test, running the real game in text mode and checking it works (and compiles for Android)
• make test slowtest-run does the same as make slowtest except it skips the Android build

---