On the Subject of Making a Great Module

There are many things to do and many things to avoid while making a new module. Here is a list of tips to consider when developing a module.

1. Begin With a Working Manual

This is the most important part of developing a module. Make sure that you have a solid idea and a clear description of how each part of the module will work. This will allow you (or someone who is developing the module for you) to properly implement the module as intended.

2. Don’t be Afraid to Change

Often when developing a module, you realize that an idea you had or part of your manual is impossible (or at least very difficult) to implement. Instead of wasting your time trying to find a solution to the problem which is out of your skill set, consider changing your idea to better suit the constraints. You don’t always have to change your idea, but remember that it might be necessary.

3. Playtest, Playtest, Playtest

Always playtest your module. Any time you make a significant change, solve the module a few times to try and catch some bugs. Even if you don’t make a significant change, it never hurts to try solving it again. Also remember to have several people playtest your module before releasing it. In addition, if you notice strange behaviour, do not leave it. Try to figure out what is causing it.

4. Don’t Skimp on Your Logging

It is always a good idea to log too much information rather than too little. It can be nearly impossible to spot what is causing a bug with insufficient logging, so it is better to err on the side of caution. At the minimum, your module must log:

• All the information visible on the module that the players need to solve it.
• The intended solution. If the solution depends on something that can change (e.g. strike count, solve count), log all possible solutions for each possible situation.
• If the solution path is complicated, include all relevant steps of the calculation.

• All of the user’s relevant interactions with the module that change its state. In particular, if your module has a submit button, log all of the information on the module that is being submitted.
• When the module issues a strike, log the reason (unless it is obvious from the already-logged intended solution and submitted answer).
• In general, make sure that the module leaves no doubt as to what the user did and what the module expected so that every strike can be fully explained from the log.
• When the module is solved, include a “module disarmed” message.

5. Avoid Common Module Features that are Considered “Not Fun”

• Unicorns

  Unicorns are rules that occur rarely and make the module instantly solvable. The first such module and most famous example is Laundry. This does not add to the module gameplay.

• “Cruel” Versions

  Only create a “cruel” version of a module if it’s an entirely new gameplay idea. Don’t just add arbitrary complications that just make the module more laborious or confusing. Such variants of modules often don’t see play and are not received well in most cases.

• Overly Complicated Manuals

  Making a module more complicated does not make it more fun per se. Fun modules have interesting functional components and solving methods (which may be complicated) rather than unnecessary complexity which just makes a module harder to solve.

• Minor Variations on Vanilla Modules

  In general, slight variations of the vanilla modules rarely go over well. A great module is one that has original ideas, good design, and a lot of creativity. Just making a few tweaks to the manual, changing a few rules for added difficulty, or rearranging rules have almost never been enough to make a module stand out.

6. Make Your Module Open Source

There are many benefits to making the source of your mods public. Here are a few:

• Fellow modders can help you fix issues.
• Your modules can still be maintained after you stop developing, increasing their longevity.
• If done correctly, you will have a full version history of your mod so that you can revert file(s) to a previous revision if necessary.

Make sure to include all the project files as well as the code. Often this can be difficult to set up properly, so here is a tutorial on how to put a KTANE module on GitHub.

7. Use the Community

The KTANE community will let you know what they think of your module, whether it be good or bad reviews. Do not take constructive criticism personally. Be respectful and listen to the suggestions. If the community finds a bug or mistake, fix it. If they suggest a change or comment on your module, consider their input.

If you need help with modding, feel free to ask for help in #modding on the KTANE Discord server and most of the time, someone will be happy to help. Make sure to be specific and include any error messages or relevant code (having your source on GitHub can help with this, see #6).

If another member of the community submits a pull request to your GitHub repository, it means they love the module enough to have spent effort to help improve it for you. If such a pull request has no issues, be respectful and accept it and update the module. If you feel that you cannot do so in a timely fashion, allow another modder to take over maintainership of your module.

8. Spend Time on Aesthetics

Some modules aren’t received well simply due to their looks. Check blurry/stretched text, oddly shaped buttons (due to scaling), text that looks “lit up” when the lights turn off, meshes without materials, etc.

In addition, check the manual. Is it legible and is the information presented clearly? Does the module image (the SVG in the top-right corner) accurately represent the module? Any time spent making your module and manual look better will easily add to its value in the long run.