Before You Post

This guide explains how to write clear, useful suggestions in the SFMB #request channel. The [[sfmb_betatest_community_rules]]{Community Rules} still apply and take precedence over this guide.

Use #request when you want to suggest a new feature, object, option, or intentional change to existing behavior. If SFMB currently behaves incorrectly, crashes, or produces an unexpected result, use #bug and follow the [[sfmb_bug_reporting_guide]]{Bug Reporting Guide} instead.

Who Can Post

You must hold at least one Special Role to post in #request. See [[sfmb_community_roles/#special-roles]]{Community Roles — Special Roles} for the current roles and requirements.

Check for Existing Requests

Search #request and check the [[sfmb_roadmap]]{Roadmap} before posting so that you know whether the idea has already been discussed.

You may post a request that has already been requested when you want to emphasize continued interest in the idea. When possible, reference the earlier request and add current, clearer, or otherwise useful context. Every repeated request must still follow the complete request format. Do not flood the channel with the same request repeatedly.

Do not ping the Developer just to get attention, pressure staff for a decision, or use the Developer's status reactions yourself.

What Makes a Useful Request

A useful request follows the official five-item format:

  1. The element you want to add to the game. Name the requested element or feature clearly.
  2. An explanation of the element. Explain how it works and what it looks like. Images or footage may be included.
  3. Its origin. State where it first appeared in the series. Use None or Original when it has no existing origin.
  4. The reason you want it in SFMB. Explain why it would improve the game or help players and creators.
  5. How it will work in SFMB. Describe its in-game behavior, Map Editor behavior, options, and important interactions.

References, edge cases, related Roadmap items, and comparisons with the current SFMB behavior are useful optional additions, but they do not replace the official five items.

What Makes a Request Easier to Accept

Requests that remove work and uncertainty from implementation are stronger candidates for acceptance. This does not guarantee acceptance, but the following preparation counts positively when a request is reviewed:

  • Prepare all sprites needed for the requested element, including its states, directions, and animations. If it should appear in multiple Game Themes, state which themes are covered.
  • Attach ready-to-use sprite image files whenever possible. A correctly configured .sprite file in addition to the images is an extra advantage because it makes the resource easier to test in SFMB.
  • Concept art or sketches also count positively, even when finished sprites are not available. They help communicate the intended appearance, proportions, animation, and behavior clearly.
  • For an item, power-up, or enemy, describe its behavior in detail rather than only naming it.
  • Record the expected result of every relevant interaction. Explain what happens both to the requested element and to the player, projectile, enemy, block, or other object that interacts with it.

Sprite preparation does not replace the five required request items. Attached resources must also be usable by the project and follow the [[sfmb_contribution_agreement]]{Contribution Agreement}. See [[sfmb_tutorial_sprites]]{How to work with sprites} for .sprite configuration guidance.

Scope and Clarity

Keep one main idea per request. Closely related options may stay together, but unrelated objects or features should be separate requests so that each can be reviewed independently.

Be specific without prescribing unnecessary implementation details. Describe the visible behavior and desired result. The Developer decides whether, when, and how an accepted idea is implemented.

Avoid vague requests such as “add more enemies” or “make the editor better.” Name the feature, explain its behavior, and state why it would improve SFMB.

Weak:

Add more Koopa options.

Better:

Add a Map Editor option that makes a Koopa turn around at platform edges. The option would help creators reproduce enemy behavior used in later Mario games without building extra walls around a platform.

Interaction Worksheet

For an item, power-up, enemy, projectile, vehicle, or other interactive object, you may copy the worksheet below after the official five items. It is based on interaction categories used by the current game. Remove irrelevant questions or answer Not applicable. If you do not care about a result, write Developer decides instead of leaving an accidental gap.

The worksheet is not a substitute for describing the element in normal language. Its purpose is to make missing decisions visible and let the Developer review the request like a questionnaire.

Copyable interaction worksheet 
A. Classification and resources

1. Element type (choose one):
   [ ] Item
   [ ] Power-up
   [ ] Enemy
   [ ] Projectile
   [ ] Vehicle
   [ ] Other: ___

2. Sprite coverage (check all that apply):
   [ ] All intended Game Themes
   [ ] All movement and action states
   [ ] All required facing directions
   [ ] Damage, defeat, transformation, or effect frames
   [ ] Wing, carried, frozen, or other attached-state frames
   [ ] Not applicable

3. Attached resources (check all that apply):
   [ ] SD sprite image(s)
   [ ] HD @2x sprite image(s)
   [ ] Configured .sprite file(s)
   [ ] Editable source file(s)
   [ ] Concept art or sketch(es)
   [ ] Reference image or footage only
   [ ] No resource yet

B. Spawn, movement, and lifetime

4. How does it appear?
   [ ] Placed directly in the Map Editor
   [ ] Comes out of a block
   [ ] Dropped or spawned by another object
   [ ] Generated repeatedly
   [ ] Other: ___

5. Initial and idle behavior: ___

6. Movement (check all that apply and give speeds or timing when important):
   [ ] Stationary
   [ ] Walks or moves horizontally
   [ ] Jumps or bounces
   [ ] Flies or floats
   [ ] Swims
   [ ] Chases the player
   [ ] Follows a fixed or custom path
   [ ] Other: ___

7. At an edge, wall, ceiling, or slope, does it fall, turn, stop, bounce, attach, or do something else? ___

8. In water, lava, poison water, or outside the stage, what happens? ___

9. Can it respawn or return after leaving the screen?
   [ ] Yes: ___
   [ ] No
   [ ] Use normal SFMB behavior

C. Player contact and attacks

For each relevant interaction, choose a result:
Ignore / Block / Bounce or deflect / Damage / Defeat / Freeze / Transform / Trigger / Custom

10. Player touches it from the side or below: ___
11. Normal stomp: ___
12. Spin jump or equivalent special jump: ___
13. Player slide: ___
14. Invincible, giant, or otherwise powered player: ___
15. Can the player stand on it? [ ] Yes [ ] No [ ] Conditional: ___
16. Can the player carry, kick, throw, or release it? [ ] Yes: ___ [ ] No

D. Projectile and object interactions

17. Fireball: ___
18. Iceball: ___
19. Super Ball: ___
20. Boomerang: ___
21. Moving shell: ___
22. Thrown, sliding, or otherwise moving object: ___
23. Other requested projectile or attack: ___

For every non-ignored hit above, also state:
* Is the attacker consumed, reflected, stopped, or allowed to continue? ___
* Is the requested element damaged once, defeated, frozen, transformed, or made invulnerable temporarily? ___

E. Yoshi, enemies, blocks, and stage systems

24. Yoshi tongue or eating:
   [ ] Cannot grab or eat it
   [ ] Holds it in the mouth
   [ ] Swallows it
   [ ] Spits it out with this result: ___
   [ ] Other: ___

25. Yoshi stomp or shockwave: ___
26. Contact with other enemies: ___
27. Contact with blocks, including hitting a block from below: ___
28. Can it be placed in a block or carried by an enemy? [ ] Yes: ___ [ ] No
29. ON/OFF, P-Switch, event, key, goal, or other stage-system behavior: ___

F. Damage, defeat, and rewards

30. Number of hits or damage states: ___
31. Temporary invulnerability after a hit: ___
32. Defeat animation, effect, and sound: ___
33. Score, coin, item, key, or other drop: ___
34. Does defeating it affect a boss fight, clear condition, counter, or event? ___

G. Power-up-specific behavior

35. Result when collected by Small, Super, or already-powered characters: ___
36. Controls and abilities granted: ___
37. What happens when the player takes damage, collects it again, or changes character? ___
38. Character-specific or underwater differences: ___

H. Map Editor behavior

39. Palette category and placement rules: ___
40. Options and their default values: ___
41. Variants, direction, size, wings, contents, or attachments: ___
42. Copy, resize, multi-select, preview, and test-play expectations: ___

I. Anything not covered

43. Other important interaction or edge case: ___
44. Behaviors intentionally left for the Developer to decide: ___

Request Template

This is the official request format. Replace each prompt.

1. Element to add to the game:

2. Explanation of the element:

3. Origin:

4. Reason for adding it to SFMB:

5. How it will work in SFMB:

You may add reference images or videos, a related existing request or Roadmap item, the current SFMB behavior, and optional enhancements after the five required items.

For an interactive element, you may also append the Interaction Worksheet above. It is optional, but a complete answer to the relevant questions makes the behavior easier to evaluate and reduces the need for follow-up clarification.

After Posting

The Developer uses status reactions to indicate that a request was accepted, denied, is already on the Roadmap, needs clarification, is under development, or is complete. Moderators may reject requests that do not follow the required format or are otherwise unsuitable for the channel. Do not add these status reactions yourself.

Acceptance is not a promise of a release date. Do not repeatedly ask when an accepted request will be implemented. If clarification is requested, respond with the missing information clearly and concisely.

For a small correction or clearer example, edit the original request or add one concise follow-up. You may create a new duplicate request later to emphasize the idea again, but it must use the complete format and must not become spam.

Final Checklist

Before sending a request, confirm that:

  • You have permission to post in #request.
  • If the idea was posted before, repeating it is intentional and not spam.
  • It contains one independently reviewable idea.
  • The requested feature or change is named clearly.
  • Its origin and original behavior are described when applicable.
  • Its expected SFMB and Map Editor behavior are explained.
  • For an item, power-up, enemy, or other interactive element, all relevant interactions have an expected result or are explicitly left for the Developer to decide.
  • The reason it would improve SFMB is specific.
  • All available sprites, concept art, and sketches are attached, and any included .sprite files have been checked in SpriteEditor.
  • Links and reference files are accessible.
  • The whole request is readable as one organized message.

Related Documents

  • [[sfmb_betatest_community_rules]]{Community Rules}
  • [[sfmb_bug_reporting_guide]]{Bug Reporting Guide}
  • [[sfmb_community_roles]]{Community Roles}
  • [[sfmb_roadmap]]{Roadmap}