Introducing the revamped Submission Guidelines

As part an initiative to make the site more informative and easier to use, we've overhauled how we present all of the guidelines for submitting things to site. Introducing the newly established Submission Guidelines section.

    Submission Guidelines →

This new directory brings together all of the guidelines and core values for each of the sections here on SMW Central they are easy to access, find, and read before you get to deep into working on your submission.

What's New

Before, the guidelines for each section lived behind that section's "Submit" button which made them difficult to access or discover, especially for newbies. Additionally, since the guidelines for each section varied in length and were stuck above the submit form, it made the process of submitting more cumbersome–the guidelines are still there for a quick review but in a collapsible section.

Now, this new directory remedies both of those things by making the guidelines a very prominent information resource on the site and unburdening the submit form from being the first point at which you see the guidelines. The new directory structure also makes it easy to see the guidelines in the context of the other site guidelines and make them more easy to share since they have a permanent URL.

Also, nearly all of the guidelines have received revisions and updates, some more significantly than others, to clear up how they were written or to codify some of the unwritten guidelines for the site; the newly written guidelines include:

• Screenshot Guidelines - to explain the requirements expected for screenshots in the sections and give some examples and resources
• Update Policy - this is expanding on the largely unwritten expectations around updates and to fill in some inferred parts from the relevant section in the Site Rules.

Some other major changes include: splitting the guidelines for hacks into ones for each submission type, and moving and updating all the tags guidelines for each section to this directory.

Updates

Since this was a major overhaul that was an internal project for awhile with only a few eyes looking at we may have missed or overlooked some smaller things or errors, so now that it has been released to you all you may see updates to tweak the language or layout of some guidelines in the coming weeks as people provide feedback (which you are free to do in the forums or to staff/me directly).

---

Thanks to  Telinc1 for the behind the scenes connecting of the pipes and to the staff who helped me with the revisions to the section guidelines.

Thanks for the revamp! The new guidelines are easy to access and cover literally everything. We all appreciate it!

---

Você sempre alegre e eu sem razão
Estou dividido entre o amor e a paixão

What happened to the official tag list for music? I ask because it appears to have gone missing.

It has been migrated into this new section: https://www.smwcentral.net/?p=guidelines&page=1634039-music-tags

OK, I see. Still, the text for the music submission page implied that the tag list was down below, so that will probably need some minor edits. I also think we need a minor update to the collapsible section of the music submission page to include the tag guidelines there, since previously the tag list was shown there.

I made an edit after you mentioned. All submission forms also now link to the allowed tags right where you pick the tags so having them up there wasn't needed anymore.

The "Special Cases" section of the "All Hacks" page says to submit graphic base hacks to the Graphics section, but the "Graphics" page says these kinds of hacks are no longer being accepted.

Might want to make an edit to the former page to remove the mention of submitting graphics hacks, or edit it to say they're no longer accepted.

---

Edit made, thanks for the catch.

Two more things (they are very minor):
1. Core value 4 of the "All Hacks" page is missing a period after the word "rejected".
2. On the "Screenshots" page, below this image:

This image's caption says "A external", it should be "An external" instead.

---

That works, too. Thanks!

I have some suggestions regarding the tool submission guidelines:

Currently, as it stands, I feel that unlike the other sections, it doesn't cover everything to be aware of with tools given how we use tools has changed drastically since the tool submission rules was last updated.

My current suggestions for new guidelines are:
-Ensure your tool works out of the box with currently supported versions of Windows (and if applicable, macOS and Linux) without changing any additional settings.
-If applicable, the tool should work with the latest versions of any essential SMW hacking resource. (Lunar Magic, SA-1, PIXI, GPS, UberASM, AddmusicK)
-Don't submit tools that are in a prerelease/beta state.
-Tools made primarily with web technologies like HTML5 are preferred to be added to the Online Tools section instead.

In addition, tool submission tags should be formalized, as an official list for tool submission tags currently doesn't exist.

Besides that, I'd also suggest tweaking the sprite submission rules to have other (minor sprite) and run-once sprite types be represented as well as clarify whether or not tweaked sprites (which are made by selecting normal in PIXI's CFG Editor) are accepted.

One more thing: The tutorials submission rules were written as if the site had a tutorials section, which it used to have back in the day. Not sure how those rules would work out now.

Green's suggestions: Show/Hide

Originally posted by Green

I have some suggestions regarding the tool submission guidelines:

Currently, as it stands, I feel that unlike the other sections, it doesn't cover everything to be aware of with tools given how we use tools has changed drastically since the tool submission rules was last updated.

My current suggestions for new guidelines are:
-Ensure your tool works out of the box with currently supported versions of Windows (and if applicable, macOS and Linux) without changing any additional settings.
-If applicable, the tool should work with the latest versions of any essential SMW hacking resource. (Lunar Magic, SA-1, PIXI, GPS, UberASM, AddmusicK)
-Don't submit tools that are in a prerelease/beta state.
-Tools made primarily with web technologies like HTML5 are preferred to be added to the Online Tools section instead.

In addition, tool submission tags should be formalized, as an official list for tool submission tags currently doesn't exist.

Besides that, I'd also suggest tweaking the sprite submission rules to have other (minor sprite) and run-once sprite types be represented as well as clarify whether or not tweaked sprites (which are made by selecting normal in PIXI's CFG Editor) are accepted.

One more thing: The tutorials submission rules were written as if the site had a tutorials section, which it used to have back in the day. Not sure how those rules would work out now.

I have a few comments about these suggestions:
This

Is a bit of an over-requirement in my opinion, because there are cases where making an executable (or a script, or whatever, to run) that "just works" without changing anything, is hard.
Of course it is preferrable to make something that works with a simple double click and requires nothing else, but maybe this would be a good suggestion, rather than a rule. In any case, the tool author could simply supply a HOW TO file that explains what's necessary to run the tool (setting changes, installations, etc)

This

is a bit mediocre, mostly because, like before, sometimes it's hard to keep up with all the new versions of tools, I would say again that this would work well as a strong suggestion rather than a rule.

I completely agree with the third suggestion.

This

is a bit weirdly worded, because there are tools made with "web technologies" but they are not fit to be in the Online Tools section.
I would reword it as so:
- If your tool is a simple HTML or JavaScript single file, it is better fit for the Online Tools section and should be submitted there.

As for tool tags, I honestly think tools have already so many categorization options that tags are not really necessary but some can thought of

Yeah I agree about talking up submissions to Online Tools, I'll add a section about that.

Apologies in advance for the lots of words, I had more to say than I expected to.

Not sure if this was a pre-existing guideline, but in my re-read I noticed the clause stating that a kaizo hack should be confirmed clearable specifically by its author. Setting aside questions of how this applies to collaborative hacks, I think codifying this is as an official guideline even just in the context of one authorial clear per one hack sets a bad precedent for a few reasons and I’ll try to explain those as effectively as I can.

To preface against a certain interpretation of my making these points as a known frequent “hard levels guy”, I will say up front that I personally do play and beat my own stuff, alongside my testers, every time. That’s a principle I adhere to because, in addition to designing for other people’s enjoyment, I’m also designing for my own. However, I don’t think that’s the only valid approach.

I’ll offer for consideration the fact that development of so-called “real games” of any size or scope can and often will involve developers playing and testing significantly less than their playtesters. Games are not always fully driven by their developers’ own preferences as players. It’s possible for game designers to have talent for creating certain experiences that they themselves have little or no taste for compared to their target audience. A good experience for an audience comes less by the designers' own relationship to the material than by thorough research, consultation, and playtesting.

Although it’s common for hobbyist projects like romhacks to be more of a reflection of their authors than traditional games, I want to make the case that that’s merely a tendency and not a rule, and thus, that the creator clear is not the immutable, essential quality filter many in this scene see it as. It’s recommendable especially for creators who consider themselves part of their target audience, but it’s not the be-all and end-all; it doesn’t on its own make or break the experience.

I think the perceived importance of the creator clear in this scene endures in no small part due to games like Super Mario Maker and Geometry Dash wherein level designers are mechanically required to beat their own levels to publish them. But given the more prominent focus on external playtesting in this scene than in those, I would argue that the cultural necessity/utility of the creator clear doesn’t exist in the same way.

On the other hand, anyone can claim to have beaten anything, so you might figure why does it even matter whether or not that guideline is there? Well, my thesis here is simply that this solidifies an expected approach for all kaizo makers in all contexts that shouldn’t necessarily be so solidified. I wholeheartedly agree with the expectation that a hack be confirmed clearable before its submission, but there ought to be more room for interpretation as to how that’s done. I think a more effective guideline would be either specifically inclusive of playtesters or just not specific at all as to who should ultimately be bringing about that confirmation.

Thanks for hearing me out. I’d be interested to know what others have to say about this. This is actually something I’ve been thinking about for years and I believe it’s a conversation worthy of being had.

Good point. The suggestion regarding beta tools originated after an update of a tool hosted was rejected for being a beta build.

BTW, I edited my post before both responses were posted, adding notes about my thoughts with the sprite and tutorial section guidelines.
Repost of text mentioned: Show/Hide

Besides that, I'd also suggest tweaking the sprite submission rules to have other (minor sprite) and run-once sprite types be represented as well as clarify whether or not tweaked sprites (which are made by selecting normal in PIXI's CFG Editor) are accepted.

One more thing: The tutorials submission rules were written as if the site had a tutorials section, which it used to have back in the day. Not sure how those rules would work out now.

Additionally, I'd like to suggest an addition to the music section rules stating the submission's sound volume needs to be balanced.

It was.



The long and short of it is that kaizo hacks that are submitted to the non-tool assisted section are there for players to download and play/beat tool-less, to whatever degree that entails and regardless of nicheness of the submission. So, a reasonable expectation the site/moderation team holds creators to is: that they should have also cleared their own levels if they expect others to do the same (especially since the moderation team has to clear the hacks themselves RTA).

This guideline does not speak to what is or is not a valid development process or what is or is not a valid experience playing hacks, it is there to give the moderation team ground to stand on to reject or re-categorize a hack for having levels that are overwhelmingly considered unviable for toolless play, or if the design is clearly indicative of being "tooled through" such that it makes the hack impossible for RTA play (both these things do and have occurred). It is not set-up to be a cultural regulation at all, but purely quality control in the most basic sense.

While it is true anyone can claim to have beaten anything, if for all intents and purposes a moderator plays through a hack and it is deemed acceptable for the section then no harm no foul, hacks won't be removed if someone has been discovered or have been up front about having built a hack with tools.

All this said, we can rephrase the guideline to make it clear it is more about that aspect of quality control than about it being a moral expectation put upon creators.

Edit: the kaizo guidelines have been updated to make those changes.

Would it not be the case that requiring the hack to be beatable by a playtester without tools would suffice as evidence that a hack be human viable? I do not see the point in requiring the creator, specifically, to beat a hack.

I was part of a collab where one of the creators had never even played kaizo at the time of creation, but the level was playtested to the team's satisfaction. I would like to know if this submission is going to be disallowed in the future, because that really does not speak to the values of SMW Central, in my opinion.

It's not a requirement, evidence need not be presented to show that a hack as been beaten. Again, the guidelines are basically reiterating the common courtesy expectation that if a hack is to be submitted to the toolless Kaizo section that it indeed be toolless kaizo. The instances where a hack gets rejected for being not-RTA kaizo are rare and usually are cases where the setups don't work in succession because, for example, a savestate was used to build the section, as you well know it's easy to throw off timings if setups were based on things on a global timer that are only consistent with a savestate.

This is the current state of that guideline:


tl;dr if someone does end up submitting something that mods suspect is impossible/unviable the team needs a written guideline to cite as the grounds to reject it.



Was not in the past and will not be in the future, the guidelines haven't changed. The revamp here is the old stuff made more public and better explained.