I see some people are pitching in to help transfer over to the new layout -- thanks.
This is not what this blog is about, however. I'm not naming names or pointing fingers, but most of the time I have to go around fixing up tiny mistakes that the converter should've done if they'd actually read my original blog post. For the sake of currentness, I shall go through the things you may have overlooked (in no particular order, I might add). Please pay attention to this blog. It's quite evident that people didn't properly read through my other blog, otherwise I wouldn't need to do this.
Capitalisation of certain words[]
- Applies to: entire wiki
I know, I know. In the past I've probably complained at you for capitalising "Power" when used as a property, or just in general for words like "Special" and "Hyper". Forget everything I said about that. Stats should be capitalised and so should technical words like "Special", "Hyper", "Normal" ("attack" should be capitalised when referring to either of those three, like "Special Attack"), "Super Jump", "Super Armo(u)r", etc. No need to capitalise things like "run", "jump" and "stand", though. Don't capitalise words if they're not in the correct context for capitalisation; if a move was called Super hyper Jump armour Run, do not "fix" the capitalisation.
Move names in italics[]
- Applies to: entire wiki (typically character articles, character version articles and full game articles)
Self-explanatory; move names should be written in italics. Hadouken, Sneaky Scythe, Naughty Hook, Overdrive Pulse Cannon, etc. Move names are automatically written in italics in the CommandList template, so you don't have to do this there.
Table of Contents and spacing (1)[]
- Applies to: character version articles
To make sure the gameplay header doesn't overlap with the infobox, please put the following code underneath the infobox:
{{TOC}}
What this does is generate the Table of Contents in the place it should be while making sure the header goes below the infobox.
Table of Contents and spacing (2)[]
- Applies to: entire wiki (excluding stage articles and character version articles)
While character version articles have the Table of Contents and spacing template directly underneath the infobox, other articles (excluding stage articles because the stage infobox is centred) have text in between the infobox and the first header, meaning that if one were to put
{{TOC}}
directly below the infobox, that text would display underneath the infobox as opposed to alongside it, leaving a very prominent gap at the top of the page. The Table of Contents and the spacer should be placed above the first header to ensure everything displays correctly, though while {{-}} should always be used (it functions like {{TOC}}, but doesn't place a Table of Contents), {{TOC}} should only be used if there are three or more headers in the article; nothing bad will happen if you do use {{TOC}}, but the Table of Contents will look really small with two or fewer headers.
Victory quotes[]
- Applies to: character version articles
Inserting victory quotes is much easier now. Instead of using *''"This is my victory quote"'', use {{Quote|This is my victory quote!}}. For character-specific victory quotes, use {{Quote|This is my victory quote!|vs. opponent}}.
- "This is my victory quote!"
Becomes...
| “ | This is my victory quote!” |
Or in the case of a character specific victory quote...
- "This is my victory quote!" [vs. Kung Fu Man]
Becomes...
| “ | This is my victory quote!” |
| — vs. Kung Fu Man |
So much easier, no?
So with the differences between the new and old victory quote layout out of the way, what about really specific victory quotes that display as a result of a perfect victory or by winning the last round with low Life? Heck, what about palette-specific, character-specific, life-specific victory quotes?
Win while using palette 4:
| “ | Win quote 1” |
| — Palette 4 |
Win while using palettes 5 and 9:
| “ | Win quote 2” |
| — Palettes 5 and 9 |
Perfect victory:
| “ | Win quote 3” |
| — Perfect victory |
Perfect victory while using palettes 6 and 11:
| “ | Win quote 4” |
| — Perfect victory; palettes 6 and 11 |
Bear in mind that we still only use general and character-specific as headers, so the above would go under general because they can still appear against any opponent.
Perfect victory against a specific character:
| “ | Win quote 5” |
| — vs. Character; perfect victory |
Perfect victory against three different characters while using palettes 2, 3, 4, 5 and 6:
| “ | Win quote 6” |
| — vs. Character 1, Character 2 and Character 3; perfect victory; palettes 2, 3, 4, 5 and 6 |
As these go under the character-specific header, naturally the name of the opponent required to activate the quotes goes first, followed by Life requirement and then anything else.
Categories[]
- Applies to: character version articles
I haven't seen much trouble with this one, fortunately. Still, please go here for a full list of categories relating to version articles. Always use [[Category:Character versions]].
Brief descriptions[]
- Applies to: character articles and character version articles
Yes, the piece of italic text you see above the version infobox, or the non-italic text you see on the main article underneath the header of a specific version. It slightly bugs me when people either don't write one, or copy the text from the character's gameplay section; I've said before that the brief description doesn't have to be as formal as the rest of the article, just so long as you avoid writing opinions and in first-person (me, myself, I). They don't have to be very lengthy, just three-four lines will do it; write about the character's sprites, source-accuracy (if available), bugs, play style, etc. Really condense it. Here, have a few examples:
This creepy-looking humanoid Pikachu is quite the powerhouse, having an array of different moves that can be used to start powerful juggle combos or simply dish out massive amounts of damage on their own, though the unconventional button layout takes a while to get used to. Kick it into Overdrive to make juggling the opponent a breeze and then finish them off with a mighty Warlock Punch, providing you've got a maxed-out powerbar.
Arguably the most well known version of the iconic moustachioed plumber, this Mario has a moveset that takes heavy cues from his Super Smash Bros. incarnation, topped up with attacks based on actions that Mario can do in various games of the Super Mario series. If Mario gets fed up with being super, he can enter the battle in one of three alternate modes, each one with its own advantages and disadvantages.
Using the sprites from Kurogane's version, Flandre takes the term 'glass cannon' to the extreme, sporting a high damage output and nasty juggle combos while being unable to take take too many hits due to her meagre 666 Life stat, which is not as beastly as it may sound. Flandre can choose from a selection of nine spellcards at the beginning of the match, though as the total 'level' cannot exceed 9, Flandre must choose carefully.
Is it a Bison? No, it's a Falcon. This version of Captain Falcon's gameplay is inspired by both the Guilty Gear series and the BlazBlue series, with Kamekaze's own style thrown into the mix. Being a character coded by Kamekaze, his A.I. is very challenging and has a habit of throwing the opponent into a corner and comboing their Life away.
Nothing to it. Just remember that the text should be italic on the character version articles, obviously following the rule on italic text, and unformatted on the character articles. Oh, and make sure both brief descriptions are the same.
Rectifying certain elements[]
- Applies to: character version articles
Because the version branch articles don't share the same article as other character versions any more, you don't need to let the reader know whose version it is in the gameplay or trivia sections; as an extension of this, gameplay sections labelled as "X's Charactername" should be renamed to "Gameplay".
Character comparisons[]
- Applies to: character articles and character version articles
While this fault existed before the layout change, I'd still like to drive it home; do not compare character versions to each other by saying one is better than the other, as I tend to see this sort of thing take up the majority of Gameplay descriptions. You can compare character versions to gauge differences, but don't name names, and keep it to the brief descriptions as opposed to the Gameplay sections ("While all other known versions are heavily based on the character's appearance in Flying Spaghetti Monster 2, this version is entirely custom blah blah blah...").
The only instance you can probably get away with comparing versions in a Gameplay section is if you're comparing the character to other characters made by the same author ("Pew Pew Laser is a character that varies heavily from other characters made by Hugh Jarse, using all six buttons as opposed to four, and using different mechanics like Counters, Focus Cancelling and EX Moves blah blah blah...").
Gameplay descriptions[]
- Applies to: character version articles
Again, this is a thing that existed long before the new layout, but bear with me here. Gameplay descriptions should be just that -- a few paragraphs worth of text (if you can squeeze that much out of it) that lists information about how a character plays, both when being played as and when fought against, as well as any notable bugs and issues with the character regarding how it plays. Many people seem to deviate from this entirely and write about how its sprites and animations are stiff, how its sounds don't work properly, whether its better or worse than another version (see the previous section), and how its portraits were fixed in later updates (even saying the update added more moves is pushing it if you don't explain how they affect the character). I'm not even kidding; look at the difference between the original version of WlanmaniaX's Mr. Bean's gameplay description and the current one I wrote:
Original:
"Due to multiple requests, WlanmaniaX updated his version to a "better" state than before. This Mr. Bean has some new supers and hypers, as well as his sprites looking a little bit more 3D. Despite the character looking somewhat better, Mr. Bean has many problems that affect his gameplay, his AI constantly spam his Headbutt Bash, Boombastic Combo and his first helper, this also doesn't help that his Sleepy Punch Blaster move is very glitchy."
Current:
"Mr. Bean is a six-button character with semi-inconsistent damage outputs and strange hitboxes. Comboing is slightly difficult to pull off, but is possible, though the combos are typically quite short and don't deal a particularly large amount of damage overall. Perhaps as a slight inspiration from the Marvel vs. Capcom series, Mr. Bean has a Launcher (
while crouching), though it is entirely ineffective, as the opponent falls too quickly.
Though Mr. Bean has three Hyper attacks, only one of them needs to be used, given its superiority over the other two. Chicken Rampage is only effective if the opponent is lying down, otherwise only one of the chickens will hit the opponent, dealing about the same amount of damage as 
; even if it hits a downed opponent, it is still considerably less damage than the other two Hypers at 224 damage, making it entirely useless. Dizzy Glove Cannon + Car deals 388 damage, providing the car doesn't miss the opponent for an unknown reason, which despite being more than Chicken Rampage, uses 3000 Power as opposed to 2000, and is still less than Boombastic Combo, which deals 420 damage for just 1000 Power.
Mr. Bean's A.I. is somewhat spammy and has a habit of using Boombastic Combo, though not always making the most out of it, either using it at a distance, which causes it to miss, or while the opponent is falling, which causes later parts of the attack to miss entirely."
The only part of the original that even remotely mentioned how the character plays states that its spammy A.I. affects its gameplay. The rest is absolute rubbish.
Section headers[]
- Applies to: character version articles
All version articles should have a level 2 Gameplay header, a level 3 Stats header, a level 3 Movelist header, a level 3 Palette Gallery header, a level 3 Victory quotes header, a level 2 Videos header and a level 2 Edits header, in that order.
In case you're wondering, a level 2 header looks like this in Source mode:
==Gameplay==
Whereas a level 3 header looks like this:
===<u>'''Stats'''</u>===
Do remember that we have templates for characters that lack things, so just because they don't have palettes or victory quotes, or haven't been edited, don't exclude those respective headers. For characters with no Specials or Hypers, insert {{Nomoves}} (this automatically categorises the article under Category:Characters with no Specials or Hypers). For characters with no palettes, insert {{Nopals}} (this automatically categorises the article under Category:Characters with no palettes). For characters with no victory quotes, insert {{Noquotes}} (this automatically categorises the article under Category:Characters with no victory quotes). For characters that haven't been edited, insert {{Noedits}} (this automatically categorises the article under Category:Characters that have not been edited).
In case you were wondering, the Trivia section goes below the Videos section and above the Edits section. It is not a mandatory header, and should not be added if the character has no trivia associated with it.
More italics[]
- Applies to: character version articles
On version articles, the brief description at the top of the page is written in italics. Certain words may have already been written in italics, such as a move or video game, so when placed in another italic piece of text, they look like unformatted text. This is correct, so don't change it. If my stupidly confusing description confused you, here's what I mean:
Don't change...
...Its gameplay takes cues from the Marvel vs. Capcom series, particularly the second entry.
To...
...Its gameplay takes cues from the Marvel vs. Capcom series, particularly the second entry.
The only exceptions to this are infobox captions, which are automatically written in italics. Trying to put italic text within an infobox caption generates an additional apostrophe for some reason.
Read more...[]
- Applies to: character articles
There is a template for this. Please don't do this:
[[Kung Fu Man/Elecbyte's tenth version|Read more...]]
Instead, do this:
{{Read|Kung Fu Man/Elecbyte's tenth version}}
In fact, you can actually get away with doing this:
{{Read|/Elecbyte's tenth version}}
Internal names and display names[]
- Applies to: character version articles
Perhaps some people are left wondering, "Wait, what's the internal name? Where do I find this?". All of this can be found within the character's .def file. "Name" is the internal name, while "Displayname" is the name you see in M.U.G.E.N. The |Name parameter of infobox version should be written as "Displayname (Name)" (without the quotation marks). For a better view of what this looks like in source mode...
|Name = Displayname ''({{Tt|Name|Internal name}})''
The mouseover text should always be "Internal name", unless the character has no internal name; should this be the case (certain characters like A-Bomb spring to mind), use:
|Name = Displayname ''({{Tt|None|This character does not have an internal name}})''
Portrait size[]
- Applies to: character version articles
Certain characters have portraits that exceed the regular size of 120x140 (like Kung Fu Man 720). Rather than leave them to take up way too much space on the article, downscale them to 120px using {{!}}120px, which you would place after the image filename (File:Iunderstandthetruthoftheholypie.png{{!}}120px). Do not upscale portraits; if they're smaller than 120x140, then leave them that way.
A.I. patches and soundpacks[]
- Applies to: character version articles
Unlike palettes and edits which get their own respective sections, A.I. and soundpack patches should be placed on the same page as the character version itself, underneath the download link for it. Please label them as "Creatorname's A.I. patch" and "Creatorname's soundpack" (if the soundpack changes the character's language, list it as "Creatorname's Languagename soundpack". In case I've confused you again...
|Downloadlink = [http://example.com Example Domain]<br>[http://example.net X's A.I. patch]<br>[http://example.org X's soundpack]<br>[http://example.fr Y's French soundpack]
Header/download link capitalisation[]
- Applies to: entire wiki
Unlike the days of old where "X's Version", "Y's Version" and "Z's A.I. Patch" were the way to write things, there's no need to do that with the new layout (in fact, you shouldn't). The big offender here is the word "version" which seems to get capitalised both as a header name and as a page title; don't capitalise it. Don't capitalise the words "patch" and "soundpack", either.
Attack attributes[]
- Applies to: Character version articles
Just because a creator says an attack is a Special or a Hyper in the ReadMe or wherever, or if an attack appears to be one, it doesn't automatically mean it is. M.U.G.E.N only treats a Special as a Special, or a Hyper as a Hyper if it is attributed correctly (SA, SP and ST for Specials, and HA, HP and HT Hypers); just because an attack pauses the screen during startup and uses Power, it does not automatically mean it's a Hyper.
In case anyone was wondering, here is a list of attributes and what they mean:
- NA - Normal Attack
- NP - Normal Projectile
- NT - Normal Throw
- SA - Special Attack
- SP - Special Projectile
- ST - Special Throw
- HA - Hyper Attack
- HP - Hyper Projectile
- HT - Hyper Throw
There is no other way that M.U.G.E.N identifies attacks, so no amounts of Super Pauses, Hyper Portraits and Power usage can sway the engine to believe an attack is a Hyper if it's attributed as a Normal. Attributes are located under the HitDef, by the way, but if you have trouble finding them, K.O. the opponent with the move you're trying to identify and see what win icon shows up.
Palette names[]
- Applies to: Character version articles
You've seen them before, yes? Underneath each palette in a palette gallery, there's a small caption -- this caption is the filename of that specific palette, sans ".act"; yes, the caption should be the palette's filename without .act on the end of it.
For palettes that are integrated into the sprite file (common with 1.0-only characters), use the palette's group and index (1,1, 1,2, 1,3...1,12).
Version article titles[]
- Applies to: Character version articles
After deeming article names were too long visually, we decided to use {{DISPLAYTITLE}} to shorten them to just the sub-page name (Kung Fu Man/Elecbyte's second version becomes Elecbyte's second version, for example). It's incredible stuff because the page's URL stays the same.
As for the actual implementation and how to go about doing it, place {{DISPLAYTITLE:{{SUBPAGENAME}}}} at the bottom of the page underneath the categories. What this does is allow the page title to be affected by the page's current name should the page ever be moved, removing the need to manually update the DISPLAYTITLE template every time.
Please keep in mind that the article's name appears in its original form in the editor. Only when viewing the article outside of the editor will the name appear differently.
Uses Power vs. Requires Power[]
- Applies to: Character version articles
A common sight in movelist sections (particularly for Hypers) is the 'Uses n Power' property, though I sometimes see people put 'Requires n Power', which in itself isn't wrong, but it's not completely correct either.
To elaborate, to use a set amount of Power is for that amount of Power to be drained from the Power bar when the move has been activated, whereas to require Power is for that amount of Power to be in the Power bar in order for the move to be activated. It is completely possible for an attack to require Power but not actually use any, just as it's possible for an attack to use a set amount of Power but not actually require any (the move can be activated with 0 Power in the Power bar even though it uses 2000, for example).
So what does this all mean? Basically, 'Uses n Power' should be used by default, but if the Power requirement is different from the Power usage, then 'Requires n Power' should be added alongside 'Uses n Power', unless it doesn't use any Power.
| Power usage and requirement are the same | |||||
| |||||
| Power usage and requirement are not the same | |||||
| |||||
| Move doesn't require Power, only uses it | |||||
| |||||
| Move doesn't use Power, only requires it | |||||
| |||||
Power requirement should always go before Power usage. Both should always be the last properties in the properties section.
Anything else?[]
Feel like I've forgotten something? Post a comment below.