Tweak Submission Guidelines
All tweaks submitted in a valid format will be tested and reviewed by a staff member. Rejected submissions or removals will be logged here.
All tweaks submitted in a valid format will be tested and reviewed by a staff member. Rejected submissions or removals will be logged here.
- Don't submit a tweak unless you are sure of its function.
Ensure that your tweak works as described, and does not affect anything beyond its description. - Do not modify the global state of the base tweak patch.
Tweaks rely on a standard header that sets Asar math commands as well as numerous defines. You may not alter either in your submission. A copy of the header may be referenced here. - Tweaks may not add any new defines.
Use only those defines that appear in the base tweak patch header. Use parameters to include user-configurable values. - All labels that appear in a tweak must be macro labels.
Tweaks are generated in the form of macros, and must thus use macro labels to avoid conflicting with one another. - Tweaks may use neither freespace nor free RAM.
If your code jumps to freespace, even small empty spaces within or at the end of a bank, submit it as a patch instead. Code that allows any amount of free RAM to be used, even optionally, should be submitted as a patch. - Keep tweaks simple.
A tweak to a code should not change its overall purpose. For example, altering a speed value, changing the ID of a spawned sprite, or forcing a condition to always/never occur are acceptable; using a series of edits to give a sprite new abilities is not. - Tweaks should make singular changes.
A tweak to a code should change just one general aspect of its function. For example, having multiple separate tweaks for Sumo Bro step speed, sprite to spawn, stomp sound effect, etc. is preferred over a single consolidated "Sumo Bro tweak," for improved ease of searching and maintenance. - Make tweaks easy to use.
Tweaks are to be easily understood by those unfamiliar with ASM. Use "Select" type parameters if your tweak has a limited number of valid inputs. If modifying symmetrical data (ex. X speed values), use a single identifier to enforce symmetry (ex.db -<speed>,<speed>
or equivalent, instead ofdb <speed_left>,<speed_right>
). - Match parameters' default values to the original game, if applicable.
A tweak to the number of coins needed to give the player a 1-UP, for example, should have a default of $64 (100 in decimal).