Template talk:PS2 Classics Emulator Compatibility List Rules
This is the place to discuss the details about how we are organizing the PS2 compatibility list, please all the people that was activelly editing it since many time ago join the talk, i know we still have some small disagreements but please let those for the ending and help into making this template something usable
in the last months we have someone modifying the names of the WRC games and deleting others repetitivelly just because she/he considers we are doing it wrong, i thought most of this details was self explanatory but it seems there is people that doesnt gets it, so this template will clarify what to do or not to do. Please lets organize this talk in sections, there are too much details that deserves a description--Sandungas (talk) 11:27, 1 October 2022 (UTC)
The fact is we never had a "list of rules", the first time someone wrote something related with the compatibility lists game names style was roxanne in this post. She was making a resume of what some wiki editors was doing previouslly, and at the same time she was making some suggestions about what to do with the most problematic game names. Im quoting some senteces from that post because it was the last time (and i guess the only) someone was talking about the game names style, and because some of that suggestions was taken literally by other wiki editors, but it was not an strict "list of rules"--Sandungas (talk) 19:46, 7 October 2022 (UTC)
Alternative game names[edit source]
Roxanne wrote (in 2018)
If a Game has a different Name for each region, I would add them as follows ...
Both the Names for the PAL and NTSC-U/C Release can be added at the "Name" tag while I recommend to choose one as the first and the second one is titled "(bracketed)".
Example: "Bully (Canis Canim Edit)" --> http://www.psdevwiki.com/ps4/PS2_Classics_Emulator_Compatibility_List#B
"Bully" is the Name for the NTSC-U/C release and "Canis Canim Edit" is the Name for the PAL release
You can choose which one you want to name it first and which one gets "(bracketed)".
If a Game has an additional Release like a "Limited Edition" for example, then please don't add the Game twice. You can use the same trick with "(brackets)" like above mentioned.
Example: "Final Fantasy XII (International Zodiac Job System) " --> http://www.psdevwiki.com/ps4/PS2_Classics_Emulator_Compatibility_List#F
Here we have even both, the "International Zodiac Job System" was an additional Release for NTSC-J only.
I guess roxanne suggested to enclose the alternative game name in between parentheses because she was thinking in displaying all the game names in a single line, so there was a need to separate the game names with some additional characters, as example. "Name 1 / Name 2 / Name 3" or "Name (Alternative Name)" or something like that. But after many months experimenting with it someone (im not sure who) started replacing the parentheses by a <br> (in other words, "one line per name") and this style became more popular for other wiki editors because: 1) is a lot more clear and readable 2) Is a rule easyer to remember 3) is partially failproof to prevent the "autowrapping" of game names incase we was displaying all them in a single line 4) Is not restricted because allows to add as many names we want. I hope at this point roxanne agrees that using the <br> is a better solution, is just when she wrote that post (in 2018) she was really trying to figure how to display everything in a single line in the better way posible (in other words, she never considered the alternative we are using now with the <br>) but since we are using the <br> at "Game Name" column there are different arguments to consider--Sandungas (talk) 19:46, 7 October 2022 (UTC)
- It was exactly like that. My goal was to display all Games in a single line but only if the name from all two or even three regions can fit with a output resolution of 1920x1080px or now working with 2560x1440px. If a Name from a Game Title was way to long, then I split it also within <br> code (pretty sure I did this even when I posted my suggestions on PSX-Place back in 2018). But I am of course open for using the <br> syntax everytime, especially when the "Notes" section from a Game Title needs more text anyway due to compatibility issues and/or how to fix those. In fact you guys doesn't need to ask me in general since this is NOT my list like some people assume. You can edit them and make changes as much as you want. I might not like every decision you guys take but this is a wiki for everyone and everyone is allowed to bring their ideas and suggestions as they like, so just go ahead. --- Roxanne (talk) 00:15, 8th October 2022 (GMT+1)
- I know you are not mantaining the compatibility list but i still appreciate your oppinion because when you created it we was discussing a lot of small details of the design (and we agreeded in up to 95% of them), you also know some wiki tricks that could help to solve an specific problem. Everyone of this small details follows some reasoning and the way how the compatibility list is build was the consequence of dedicating some minutes to think in all this details, the alternatives, the counterarguments from other people etc..., for a newcomer some of that details could not be so obvious, but you know them very well. In this case the dilemma can be summarized by thinking in the "wasted space" of the compatibility list page (empty areas). When we add one or more <br> in the "Game Name" column we are stretching vertically the region compatibility {{tags}} and the "Compatibility Notes" unnecesarilly, this stretchings looks bad visually, i know, it would look a lot more pretty to have all the table rows with the same height. But as you said... the goal of having all the table rows with the same heigh is defeated by the big wall of texts that appears in some games (and that walls of texts are needed, actually should be considered a feature of the compatibility list). So... in my oppinion this is one of the times when the visual look is not prioritary, the height of the table rows needs to be variable because the walls of texts needs it, so using the <br> trick in the "Game Name" column is not making it any bad (and we are already doing it since months ago, im not completly sure who did it first btw, if it was you, mrjaredbeta or me but is the kind of thing that happened naturally without need to discuss it, wiki evolution :D). The only way i see to have all the table rows with the same height would involve to hide the big walls of text and the alternative game names into "collapsable" windows (similar to the OFW2CFW list) but i dont like that, is excessive, problematic, and tricky for wiki editors--Sandungas (talk) 17:55, 8 October 2022 (UTC). Btw, the main problem of the "collapsible" elements is you need to configure its default state (collapsed or uncollapsed), im used to search in the web browser by pressing the keyboard shortcut CTRL+F (and typing the game name), if we enclose the alternative game names into a element collapsed by default this trick searching texts in the web browser is not going to work (because the alternative game names would be hidden so the web browser cant find them), otherway... if we configure them as uncollapsed the result is pretty much the same we have now (it would be pointless)--Sandungas (talk) 18:09, 8 October 2022 (UTC)
- I guess this talk can be summarized into two rules: 1) We are not hiding the alternative game names into collapsible elements (and configured as collapsed by default) because it doesnt allows to search for the game names using CTRL+F web browser searchs. 2) Years ago we was displaying the alternative game names in between parentheses in the same line than the main game name, but is problematic and we are not doing it anymore --Sandungas (talk)
- I know you are not mantaining the compatibility list but i still appreciate your oppinion because when you created it we was discussing a lot of small details of the design (and we agreeded in up to 95% of them), you also know some wiki tricks that could help to solve an specific problem. Everyone of this small details follows some reasoning and the way how the compatibility list is build was the consequence of dedicating some minutes to think in all this details, the alternatives, the counterarguments from other people etc..., for a newcomer some of that details could not be so obvious, but you know them very well. In this case the dilemma can be summarized by thinking in the "wasted space" of the compatibility list page (empty areas). When we add one or more <br> in the "Game Name" column we are stretching vertically the region compatibility {{tags}} and the "Compatibility Notes" unnecesarilly, this stretchings looks bad visually, i know, it would look a lot more pretty to have all the table rows with the same height. But as you said... the goal of having all the table rows with the same heigh is defeated by the big wall of texts that appears in some games (and that walls of texts are needed, actually should be considered a feature of the compatibility list). So... in my oppinion this is one of the times when the visual look is not prioritary, the height of the table rows needs to be variable because the walls of texts needs it, so using the <br> trick in the "Game Name" column is not making it any bad (and we are already doing it since months ago, im not completly sure who did it first btw, if it was you, mrjaredbeta or me but is the kind of thing that happened naturally without need to discuss it, wiki evolution :D). The only way i see to have all the table rows with the same height would involve to hide the big walls of text and the alternative game names into "collapsable" windows (similar to the OFW2CFW list) but i dont like that, is excessive, problematic, and tricky for wiki editors--Sandungas (talk) 17:55, 8 October 2022 (UTC). Btw, the main problem of the "collapsible" elements is you need to configure its default state (collapsed or uncollapsed), im used to search in the web browser by pressing the keyboard shortcut CTRL+F (and typing the game name), if we enclose the alternative game names into a element collapsed by default this trick searching texts in the web browser is not going to work (because the alternative game names would be hidden so the web browser cant find them), otherway... if we configure them as uncollapsed the result is pretty much the same we have now (it would be pointless)--Sandungas (talk) 18:09, 8 October 2022 (UTC)
I never understood the rules some of you have been using to decide if the game name is displayed at right column, please someome explain, it needs to be a description the shortest and most explicit posible. I dont even know if what i wrote in this edit is completly correct because is someway related, actually... if you ask me i would say to simplify this rule by displaying 100% of the game names at most left column and remove all game names from the most right column --Sandungas (talk) 12:28, 1 October 2022 (UTC)
Roxanne wrote (in 2018)
If a Game has also a different Name for the NTSC-J region, then I would add them as follows (but this is only a bonus - there is no necessary but it's always welcome) ...
If the Game has a NTSC-J release only, than the "Name" has to contain the Game Title in "Latin Capital Letter" but the "Kunrei-Shiki" System can be added additionally "(bracketed)" again in "Romaji Letters".
If the Game has a NTSC-J release but also one for PAL and/or NTSC-U/C, then we choose the "Name" from the "Western Releases" and the NTSC-J Release can be added at the "Notes" section.
If you want to add the Name at the "Notes" section, then the "Latin Capital Letters" are minimum but if you have both, then better.
Example: "Wild Arms 3" --> http://www.psdevwiki.com/ps4/PS2_Classics_Emulator_Compatibility_List#W
The "Notes" section contains: "Known in Japan as Wild Arms Advanced 3rd (ワイルドアームズ アドヴァンスドサード)"
This is also a bit related with the concept of displaying the games in a single line... or... in several lines with the <br>. I think the main reason why roxanne suggested to move some game names to the "Compatibility Notes" right column was because in some games the amount of texts in the "Game Name" column at left was going to be excesive, so adding also the names in japanese was going to be overkill (and autowrapped for sure, more than 3 game names in the same line, it was inviable). So, the desperate solution was to move the japanese game names to the "Compatibility Notes" column at right, but resulted in something tricky to understand and remember, is a bit like the logic of a programming language with a lot of "if-else" statements. But... the <br> trick is actually solving this problem, with it we dont have any clustered texts at left. We can move all the game names to the "Game Name" column (as it should, the table was designed that way, it doesnt makes much sensense conceptually to write a game name outside of the "Game Name" column). The only payback is there will be some table rows with an excesive height caused by the <br>'s of the "Game Name" row, but that's just a tiny visual annoyance (in this case the visual look is not prioritary). In my oppinion the priority is to simplify the "list of rules" for everyone (and specially to new wiki editors) to know what to do--Sandungas (talk) 19:46, 7 October 2022 (UTC)
- Again exactly like you wrote. For me I did the hard work to add the japanese Title names but only for games either when:
- They had a NTSC-J release only
- When it's from a japanese Developer and the name differentiate strongly compared to NTSC-U/C and/or PAL (Example: The "Fatal Frame" entries)
- And only if the "Notes" section wasn't already full of other text like mentioned above
- So for instance, Games from US/EU Developers which also saw a NTSC-J release, I avoided the japanese name at all, even when it has a complete different name since it is mostly known in public from it's NTSC-U/C and/or PAL counterpart. But again if you guys feel more comfortable to add the japanese Names using <br> again, feel free to do so. I think PCSX2 wiki also does this but I didn't liked it to be honest, therefore I decided to add them in the "Notes" section in the past. --- Roxanne (talk) 00:15, 8th October 2022 (GMT+1)
- I agree that I should had create some "rule book" way before. In fact I had some ideas in the past but due to less time, this never happened. So my suggestion is as described as before. Use the <br> syntax for Games when there is already a lot of text included within the "Notes" section. Then it shouldn't matter if there are three or even four names for the same Game. If there is less text within the "Notes" section, then I recommend to use only two Names at maximum (example an NTSC-U/C and PAL name) since two rows still looks okay in my eyes. I did this mainly even when having a japanese Title naming (as written below) but moved it to the "Notes" section when there wasn't that much text before. And yes I don't recommend using collapsable tables as well. For me the search function (CTRL-F) was also very important, especially with the japanese Title names in both latin characters and romaji so better not using collapsable tables. --- Roxanne (talk) 20:12, 8th October 2022 (GMT+1)
- I see i have not convinced you because you are still trying to optimize the amount of "wasted space" at the cost of complicating the "list of rules". Basically, you are saying the height of the texts at right determines how many game names are written at left (and by doing this you are creating a dependency in the "list of rules" in between left and right columns). The first problem i see of that dependency is the amount of text at right are going to change eventually because in a optimistic future a lot of the walls of text are going to be replaced by a short "Use the custom config available to fix all the problems". It could also happen a probematic game that doesnt have a wall of text now but eventually someone will debug it and will consider is needed to add a big wall of text. In both cases a change in the height of the texts at right would require to review if the game names needs to be relocated at left or at right to optimize the "wasted space" resulting of the new heights. Keep in mind also that the height of the walls of text depends of the screen resolution (the bigger the resolution, the smaller the height). The descriptions of the "list of rules" should be short, explicit, and intuitive, but if we had to write some descriptions of what you said it would be something like this (it requires at least 3 sentences) "If there is a lot of text in the Notes column you can locate all the names at left, but the height of the Name column should not exceed the height of the Notes column", "If there is not a lot of text in the notes column you can locate a max of 2 names at left, and the other names at right", "japanese names always goes to right" (this is a discrimination btw)--Sandungas (talk) 21:40, 9 October 2022 (UTC). I had a new idea, this new Template:Altnames is optimizing the heights, automatizes the <br> insertions, configures the font, and i even added an small visual effect with a vertical bar at left to create a horizontal displacement. With this template we can display around 4 names in the space previouslly taken by 2 names (so your preference to display only 2 names changed a bit ?, i guess at this point probably you consider 4 is not so bad), i think it solves that problem partially anyway, but additionally i extended it to display up to 10 alternative names because i dont want to lock it, there are some superproduction games (like disney ones) where they translated everything to the country language and was published for many countries, if at some point someone wants to add a lot of alternative game names i think is not so bad, i agree a long list would cause a lot of "wasted space" in the other columns of the row but after all having a lot of alternative names is an improvement (the info in wiki grows, thats usually always good), except in extreme cases where could be cummulated too much i would not tell that wiki editor to dont add the game name released in a specific country--Sandungas (talk) 00:58, 10 October 2022 (UTC)
- After some time thinking in it, and minor changes and experiments with the Template:Altnames i think this style solves all the problems that was making me doubt, is simple enought and unrestricted, i dont mind how many names are going to be displayed there, the point is we have room to display a lot in a simple but good looking way, and personally im fully opened to change the small visual details, that vertical line at left, the "bulleted" list style, or even the italic font style, if some of you have a suggestion just tell, my main goal always was to "cleanup" the right column of the compatibility list tables, and this style allows it, so im tempted to start updating the PS2 compatibility list with it soon (it will take several edits and long editing sessions), there are some details that worths to be discussed, like the suffix (PS3 port) i used in this sample that is supposed to be a generic suffix added to all the game names that requires it, or the other generic sentence "PS3 port available" that is often mentioned in the current list with different grammar, we need to "standarize" this indications of the PS3 release names--Sandungas (talk)
| Zone of the Enders: The 2nd Runner • Anubis: Zone of the Enders • アヌビス ゾーン オブ エンダーズ • Zone of the Enders HD Collection (PS3 port) |
Playable | Available | Available | Minor FPS drops but they are frequent, heavy slowdown during the fifth Anubis fight. |
Game Name
Compatibility Notes
Game names automatic sorting[edit source]
So far we have been ordering game names (table rows) strictly alphabetically, following the preferences of a plugin installed in this wiki that does the work automatically when we click in the arrow icons at top/header of the tables, i tryed to explain it here https://www.psdevwiki.com/ps3/Talk:Emulation but today an anonimous editor reorganized some of them following the release sequence. Lets say in the same franquise the first game never was given the sufiix "1" but the next games probably have the suffix "2" or "3" so wiki locates the first game as last. This problem is recurrent and personally i dont have a preference of doing it one way or the other, but right now the sorting mechanics are partially broken, and the only way to fix it is either returning back or cheating the plugin this way by using data-sort-value --Sandungas (talk) 11:27, 1 October 2022 (UTC)