Submission Guidelines

SMW Hack Submission Guidelines

This page details the guidelines you need to follow when making a hack submission to SMW Central. Hacks submitted to the site are assumed to be ready for final evaluation for site readiness.

Keep in mind that the hack moderators are not playtesters their job is to evaluate hacks for appropriateness for the site, not for providing detailed feedback on level design or other aspects of the hack beyond addressing quality issues. Any playtesting desired by creators should be completed prior to submission. If you would like to seek out potential playtesters, you are advised to make a thread in Works in Progress.

You may have only two (2) waiting hack submissions under your account at the same time. Any submissions you make beyond that limit will be removed immediately.

Rejections or removals performed by the moderators will be logged here.

Core Valueslink

All submissions should try and adhere to the values below that SMW Central expects for hack submissions. Interpreting these core values is the job of the hack moderation team and leeway or benefit of the doubt may be given to particular hacks on artistic merit.

1. Hacks should have substance and keep players engaged  §
   Your submission should provide an acceptable amount of gameplay which should be engaging and keep the player active. This can take many different forms and makers are encouraged to interpret this creatively. For example, an interesting and engaging one-level hack may be accepted, but a multiple-level hack containing levels where all you do is jump over pits might be rejected.


2. Hacks should contain original material  §
   A submission that is small edits to the original levels of the base game, or works that directly copy the level design of another hack, without substantial creative reasoning for doing so may be rejected. One-off "vanilla-edits" in a hack that is otherwise all original material may also be acceptable if there is sufficient creative reasoning. Exceptions include translation hacks which are just a language conversion, see details below.


3. Hacks should have custom overworlds  §
   Hacks should make edits to the overworld that go beyond just changing level names and destinations. Overworlds in submissions don't have to be very complicated or fancy to be acceptable, so long as they are customized and not simply re-using the default overworld—they can simply be a grid of level tiles, for example. If you need some assistance on Overworld editing click here for a video tutorial on the Overworld Editor in Lunar Magic by DanofMostTrades.


4. Levels should be different from each other  §
   Levels in a hack ought to feel at least somewhat distinct from one another, and successive levels should not be repeats of earlier levels. Makers are encouraged to interpret this creatively. For example, a hack where every level has double jumping may be accepted, while a hack where every level has the player double jumping up the same vertical tower may be rejected.


5. Hacks should maintain consistent visual language throughout  §
   This should be interpreted to mean the visual elements of the game communicate their purpose to the player in a clear and understandable way. Don't change the meaning of known symbols or graphics in your hack or be inconsistent in new visual representations of things, this will wind up confusing some players. For example, if red-colored blocks mean death in one level, it is bad form to have them be safe in another level.


6. Hacks should have care put into their aesthetics  §
   The hack should maintain a clean, unbroken use of graphics and palettes throughout the hack. This includes avoiding visual discontinuity (a.k.a. "cutoff"), glitched sprites, and any other visual errors (e.g. "background garbage" or Map16 errors). Hacks with an overwhelming amount of graphical issues or bad palettes—where it doesn't fit into a theme—may be considered for rejection. However makers do have artistic license to experiment with unconventional visuals if it is on theme for the submission.


7. Hacks should only be submitted if the author is satisfied with the submitted version  §
   Try to submit the best, most complete version of your work that you can. Submitting multiple single-level demos or unpolished works may result in rejection. When making updates, please include notes about what was changed and include an updated version number if possible. This helps the moderators keep track of everything. Try to condense updates and don't submit individual bug fixes over and over.


8. Hacks should give the impression they have been well-tested  §
   A "well-tested hack" should have been at least played by the author themselves to ensure that levels can be cleared, as well as to catch any issues with the visibility of terrain and jumps, the understandability of obstacles, or any other oversights in the level-making process. If a submission gives too strong an impression that it wasn't fully tested it may be rejected with moderators pointing out issues to address. We highly recommend that you find someone else to test your hack before submitting as the moderation team are not playtesters.

Type-Specific Guidelines

For additional guidelines specific to the type hack you plan to submit, see these pages:

• Standard Hack Guidelines
• Kaizo Hack Guidelines
• Tool-Assisted Hack Guidelines
• Puzzle Hack Guidelines
• Troll Hack Guidelines

Anonymous Submissionslink

Registering a secondary or burner account to have an Anonymous submission, as a way to get around the fact that the "Submitted by" shows who submitted a hack, is forbidden by the Site-Wide Rules & Terms of Use. Instead, if you would like to submit a hack anonymously the moderation team can accommodate requests to do so directly.

What that involves is reaching out to someone on the SMW Hack Moderators team, that person or another member of the team will then agree to submit the hack on your behalf, as to obscure who submitted the hack. Moderation will then proceed as if it were a normal submission. For userbase integrity and accountability reasons, you will still be associated with your submission on an internal log that is viewable only to staff.

Before you request an Anonymous submission, prepare all relevant material for your hack as if you were submitting normally and give that material directly to the moderator assisting you, in as convenient a way as you can, so they can prepare the submission effectively.


Content Warningslink

We ask that hacks disclose their content through tags and optionally in the description for cases of sensitive material or the safety of users who may download hacks.

1. Mature Language
   If a hack has any crude language or suggestive dialogue it should be tagged as such and mention it in the description.


2. Adult-only Content
   If a hack has any sexual content, violence or otherwise "adult" or potentially traumatic themes it should be tagged appropriately and warned of it in the description.


3. Photosensitivity or Motion Sickness
   If a hack has any gimmicks or mechanics that dramatically change the visuals in a way that could be cause for concern regarding photosensitivity or motion sickness, that should be mentioned in the description. Examples of these effects include: flashing or pulsating colours, rapidly scrolling elements, or fast changes in contrast.

Review the hacks section tag guidelines for what particular tags are appropriate for the content above.


Collaboration Hack Guidelineslink

Large scale collaboration or compilation hacks may periodically be submitted, the following are guidelines particularly for those sorts of submissions.

1. All contributors must be in good standing with the site
   We view a "contributor" as any person who is actively aware of their participation in the collaboration and contributes materially* to the hack, is involved in organization, or takes part in any other significant way that would warrant being in the credits.
   
   Contributors who are in bad standing with the site would prevent a collaboration hack from being accepted, as per site rule A8, even if all other contributors are in good standing. Failure to disclose the participation of users who are in bad standing may result in a site infraction for the original submitter(s) and removal of the submitted hack.


2. Compilations of community content must credit the relevant community
   Any hack that is a compilation of the work of a community's userbase must credit that community as a collective entity, e.g. crediting "SMW Central" in the Vanilla Level Design Contest compilation.


3. Collaboration hacks must have appropriate tags
   All collaboration hacks must be tagged collab in addition to any other tags that are relevant.

*A material contribution is any new levels, resources, music, and so on that was knowingly and intentionally made for the submission.

Immediate Removalslink

Sometimes a submission will be immediately rejected without someone on the moderation team completing a full moderation or even claiming the submission. The following are the circumstances when this occurs.

Quality Control

• The submission has more than one (1) BPS patch that isn't an alternate version. Acceptable alternate versions include:
  • Those with or without custom music or graphics.
  • Those with or without a retry system or lives.
  • A translation of the hack into another language.
  In other words, a save file from one version must be valid for the other(s) because the content is identical.
• The patch is broken or in an invalid format, this includes IPS patches. Be sure to test your patch before submitting!
• It fails to run or load on the latest, stable version of either bsnes or Snes9x, using default configurations.
  • Some of the moderation team use a console for moderation, if an issue is suspected to be hardware-related they will test a submission in an emulator.
  • Hacks that have special emulator requirements or rely on emulator-specific functionality will not be accepted.
• There are any breaks or crashes in the latest, stable version of either SNES emulator on the site. This includes intentional crashes.
• It is a duplicate submission of a hack that was already accepted and is in the archive.

Rule Breaking

• It is uploaded without the consent of the original author.
• It has been submitted by an account that has re-registered to circumvent a section or site ban.
• It is submitted on behalf of a banned user. This would result in a site infraction to both accounts even if the submitting account is in good standing.
• It exceeds the waiting hacks submission limit of two (2).

Credit Guidelineslink

Including credits is a good way for resource makers to know the impact of their contributions and for hack makers to acknowledge that. So we recommend providing as detailed credits as you can. Importantly, all users deserve credit for their work regardless of their status on the site. In other words, banned users are still entitled to fair crediting.

Hacks that were already in the section before this came into effect (at the end of 2023) are exempt from this policy, as are those that have been put into the archive not by its original author(s) for historical purposes. The inclusion of credits only apply to new submissions, and rejected hacks that didn't get accepted before that date. There is no obligation for authors to go back and retroactively add credits to their hacks.

Minimum Requirements

• A formatted text document or in-game credits that list authors of resources and what sort of contribution they have made, e.g. "Music: Geno, Luigi, Birdo". You can do one or the other, you need not do both.
• That good faith effort was made to include all authors of resources used. No group attributions, be specific to individuals.

A good rule of thumb is to follow how the vanilla credits are organized: a list of names under how/what they contributed.

Exceptions

• If an author explicitly states that credit is not necessary. If it is unclear, we recommend crediting them regardless if you can trace who made a resource.
• If you have an appropriate reason to not include an author in your credits. Specify any such reason to the moderators in the Submission Notes. Do not abuse this clause, it is for the exceptional cases.
• If the author of a given resource is unlisted, missing or otherwise unknown you can omit them. Lots of ASM resources exist without clear authorship or is hosted by someone who is not the author.
• If the resource is a Tweak or other minor edits that are considered common knowledge, such as hex edits or code snippets that change RAM.

Suggested Format for Credit Documents

While the minimum required for the credits is just a list of authors and what type of resource they contributed. We suggest including the name of the resource, the author, and a link back to the resource on SMW Central (or elsewhere) so people viewing the document can track down a resource. Some examples:

List by resource title.


Author with multiple resources.




Special Caseslink

There are a number of special sorts of hacks that get different treatment when submitted for moderation or may granted permission to skip moderation or be pre-moderated and put directly in the archive.

1. Translations
   Hacks may be submitted to translate an existing hack or the base game so long as they are done in good faith and have reasonably good spelling and grammar. Note: if we cannot find someone to verify the translation, your translated hack may be rejected.


2. Graphic Base
   These are hacks that are a complete graphics replacement of the base game. These were formerly accepted to the Graphics section but should now be split and submitted as individual graphics resources to that section instead.


3. Tech Demos
   Hacks which exist strictly for demonstrating HDMA and ASM, or any other hack technology, will be removed.


4. Event Hacks
   Hacks created specifically for charity streams, speedrunning marathons, or other events featuring the hack being played for the first time in a large setting, may contact moderators to request an early moderation of their hack prior to the event. This is to allow the hack to be released and approved at the same time it is featured at an event. Examples of this type of release include the 2019 and 2022 kaizo relay race hacks featured at Summer Games Done Quick.
   
   These pre-moderations are reserved only for these event-specific hacks, and all requests must be approved by the Hack Moderation team before any advance moderation can begin. Requests should be made no later than ONE WEEK before the scheduled premiere of the hack.

How to Submit a Hacklink

When going to submit your hack to the Hacks section be sure to do all of the following to properly follow the submission process.

1. Create a ZIP archive of your hack for upload
   Along with the BPS patch of your hack, you can include additional text files for credits (see Credits Guidelines below) or other README-style documents, or images of custom art (such as covers or manuals) in your archive but these should be kept to a minimum. Even if you do not have additional files, you must still submit a ZIP archive.


2. State the Name of Your Hack
   The name of your hack must abide by the Site Rules. Emoji are permitted.


3. Mark if it is a Demo
   A demo is a hack that is not yet complete but is submitted to show off or preview an upcoming project. Demo hacks must still have substance and still be beatable with a clear ending to the demo. Do not submit unfinished levels as part of set of levels in the demo.


4. Specify the Length
   This must be the number of exits as displayed on the title screen after 100% completion of the hack (which is after credits roll and the game is reset). Keep in mind exits are not the level count so don't put the number of levels you have into this field; the number of exits is derived from events that pass when a level is beaten, not the number of level dots on the overworld.


5. Select which "Type" of Hack you're submitting
   You may select one (1) type designation from a maximum of two (2) of the categories below. You may not select more than two (2) types from the same category, nor can you select a second category if one of the categories is "Tool-Assisted".



Hack Type Categories
Standard	Easy, Normal, Hard, Very Hard
Kaizo	Beginner, Intermediate, Expert
Tool-Assisted	Kaizo, Pit
Misc	Troll, Puzzle



6. Describe your hack
   In the description field, tell players what your hack is all about, and what to expect from it. You can use this space as you see fit, but everything included must be relevant to your submission. .


7. State the Author(s)
   This is usually yourself for a single-person hack. You cannot submit anonymously or submit a hack authored by another person. When submitting a collaboration or team hack, instead of listing every author in the field you can simply put "Various Authors" or the name of the team.


8. Tag your hack appropriately
   Follow the Tag Guidelines for the Hacks Section when adding tags to your hack, and do not add any irrelevant tags.


9. Add at least three screenshots
   Screenshots must be taken from an emulator and follow the Screenshot Guidelines. Use a variety of screenshots that showcase different parts of your hack. Do not include screenshots inside your ZIP archive.