Character Submission Guidelines
Basic guidelines
Characters should be DM'd via Discord to Arxos#4832. Click here for an invite to SpriteClub's discord.
  1. Please verify if your character runs correctly on MUGEN version 1.1a4 with OpenGL renderer and 4:3 resolution. Generally speaking just testing if it runs on 1.0+ should be enough.
  2. The folder name for each character should match it's .def file. Do NOT expect me to search through the character folder or settings to activate the AI.
  3. ZIP all the characters into a single archive and mail/DM the download link.
  4. If you have the know-how, remove permanent timer slows or stops from your submissions. Removing this is very simple though, so don't worry about this step too much if you don't know how.
  5. Your character should really at least beat standard Kung Fu Man, given that it's not a joke character.
  6. If the character needs palette locking please include a message regarding it in your submission.
  7. You can use this page to see all characters on the roster. Please check for duplicates.
Additionally, you can also send character updates to, though processing them isn't high on my priority list right now so I recommend only sending major updates (e.g. crash fixes or AI patch on a character with otherwise no AI).

Low quality warnings
This is just a list of things we consider low quality, and likely to lead to rejection:
  • Characters that almost exclusively kill in a single hit, in particular if they're not interesting or varied in the process.
  • Unbeatable characters (it's OK to not die, as long as you can lose).
  • Clone type characters (unless there is a thematic reason).
  • Characters with extremely limited movesets (unless there is a thematic reason).
  • Sadclaps edits and the likes. If you want to make such a character, some originality in its moves/style is greatly appreciated.
  • For certain characters that are prone to low quality edits, the barrier to entry may be raised, since there are too many low quality edits of these characters out there to accept all. For example, characters such as Orochi, Donald and Veku qualify for this (Veku in particular, we honestly recommend not making edits of, as many of the moderators have a dislike towards him).
This post is primarily for local authors to customize their characters for SpriteClub. If you're submitting other peoples characters, you can skip this post.

Character info
There are three special lines that it'll check for in the .DEF file's [Info] section:
;SC;Author="Arxos" ; this will set the author field on SpriteClub to the given value. This can be used to keep the internal author field the same for things like intro's (many of them check the author field), but still have it shown up as you want it to on SpriteClub.
;SC;Idle=0 ; this will tell the parser to use the given animation as the idle. Feel free to make custom animations if you so desire. Please do make sure that this animation loops cleanly (it will start from LoopStart if its present, otherwise it will start from the first frame).
;SC;Preview=0,0 ; this will tell the parser to use the given (group,index) of the SFF file as the preview sprite.

These commands are NOT case sensitive and you may place any number of spaces in the lines, as long as ";SC;<command>" is exactly like that.
;SC;Author = "Arxos"
;SC;Idle = 9001
;SC;Preview = 1234,5

All commands are entirely optional, although note that if you set an idle without setting a preview, it'll use the first sprite of the animation as the preview. If this isn't what you want, you'll have to also set the preview.

Betting behaviour
In SpriteClub, some measures are taken to attempt to prevent characters from attacking each other during betting. These measures can, in turn, be used to make a reliable detection for when you're in a betting state
The main thing to prevent disrespect is changing the "ctrl.time" value in fight.def to -1. This means that ctrl is never given to characters on round start. As such, you can simply check for a betting state via a trigger along the lines of "roundstate=2 && stateno=0 && !ctrl". Note that you may need to assert this for multiple frames, as I am uncertain if normally roundstate becomes 2 exactly when ctrl is given, as such I recommend experimenting with this yourself. In the actual match, ctrl.time is set to 30.
Alternatively, you may check if your health is equal to 1000000. This can be used to detect a betting state prior to round start (i.e. for an intro), however unlike the above ctrl method this will NOT work during turns matches, where health will be standard values.

Sound timing
SpriteClub runs at a speed of +5, meaning 85 frames per second instead of the default 60. This means that characters are faster, but sound is not played faster! This can cause misalignment of voice clips. Now you can fix this by simply timing everything according to a speed of +5, but there's a better solution!
The following line of code can be used to wait a certain amount of real-time, instead of game-time:
trigger1 = time > DESIRED_TIME * TicksPerSecond / 60
So for example, if the sound clip takes 5 seconds, DESIRED_TIME should be set to 300 (5 times the default speed of 60 frames per second).
Using this, regardless of the speed at which mugen is running, the trigger will only be true after 5 seconds of real-time have passed.
NOTE: This post is primarily about the handling of edits/patches when multiple versions exist that are fit for the roster. If the original has no AI, and no other patches/edits exist that are fit for the roster, then you essentially have free reign and can do whatever you like to the character. Furthermore, feel free to bring up a discussion about a character if you feel it is not sufficiently different to another character. We might have simply missed the similarity!

Handling of edits/patches to existing characters
One of the things we strive for with our roster on SpriteClub is to give different characters equal opportunities to show up in matches. This means that we want to minimize the number of very similar characters on the roster.
What we mean by this is, for example, say a character is on the roster twice, with two different AI patches. This essentially makes this character twice as likely to show up. We consider this unfair to the other characters, and want to make sure that this either does not happen, or has a good reason behind it. Judging characters as "very similar" can be a bit difficult though, so in this post I'll try to explain what I consider as very similar.

The easiest two distinctions are as follows:
  1. Two characters are NOT similar if the base of the characters were made by different authors (i.e. even if two authors both make, from scratch, a source accurate version of the same character, they are not considered similar).
  2. Minor updates, fixes and pure AI patches for the same character are considered very similar.
After these two rules, it gets more difficult however. We essentially need to make a decision whether the changes made to the existing character were sufficient in order to warrant taking up another slot on the roster. In this case, we look towards various aspects, such as:
  1. Changes to the characters moveset.
  2. Changes to the characters AI behaviour.
  3. Changes to the strength of the character.
These points can be regarded as ranked in terms of importance. For example, if the only change is the strength of the character, it will almost certainly be categorized as very similar.

Picking the best
If two characters are judged as being very similar, we need to decide which character will actually be on the roster. This can be a difficult choice, and can end up being a bit of a subjective choice. Here are some guidelines that we try to follow for these:
  1. If available, the original version is typically preferred.
  2. A pure AI patch is typically preferred over a strengthening/weakening patch.
  3. A stronger patch is typically preferred over a weaker patch, unless this greatly conflicts with #4.
  4. The more interesting patch is typically preferred. Interesting is pretty subjective, but one of the most important things is the extent to which the character uses its entire moveset.
Again, all of these are a case of "typically". We may not follow these guidelines exactly in all cases. My best advice to anyone looking to create an edit of a character already on the roster, is to just try and avoid having it get to this stage in the first place. By ensuring that your edit provides something new, we can ensure your edit can get its own spot on the roster.

Major updates/remakes
This is a bit of a footnote to this topic. In case a character receives a very major update or remake, the character can fall under more or less the same categories as above. Assuming that the new version does more or less the same things as the old version though, the latest version will typically be preferred. Furthermore, it may warrant the old version being removed and having the new version added separately, in order to properly show off the update and adjust its rating/division placement.
Major updates/remakes are generally defined as updates in which the character was recreated from scratch by the same author, a majority of its moves were replaced, or the power level of the character was significantly altered (>150 rating).