StrategyWiki:Staff lounge

__NEWSECTIONLINK__

Welcome to all users! This page is where people can ask StrategyWiki-related questions to the staff and senior community figures, and they will do their best to answer. If you want to raise a topic for discussion (rather than just ask about it), please use community issues instead. New issues are entered here, with the most recent at the bottom of the page. If your question does not pertain to editing StrategyWiki (i.e. asking for hints or game-specific information), please ask on the guide's talk page or on the forums.

Please review the Table of Contents to see if your issue has already been raised; also check the archives (to the right) in case it was discussed some time ago.

To facilitate ease of browsing and replying, please:
 * 1) Place your question at the bottom of the list
 * 2) Title the question (by placing the title between equals signs: ==title==)
 * 3) Sign your name and date (by adding two hyphens and four tildes: --~ )

Main page templates
Above are suggestions for cleaning up and making some of these templates more useful. Please add your opinions and ideas. The only one that may not be very straightforward is the change to sys. This is helpful in circumstances where the redirect is getting the system category, but there's some information you want to put in the main page's infobox. This may be a usage issue rather than anything lacking in the template. I know I've created mock "sys" divs in the infobox before, but I can't think of any examples at the moment. — najzere T 21:46, 1 October 2009 (UTC)
 * 1) infobox: Get rid of some parameters.
 * 2) *japanese: redundant, should be in the main writeup in the nihongo template
 * 3) *distributor: who cares, rarely used
 * 4) *media: noted elsewhere, rarely used correctly
 * 5) *input: noted elsewhere, rarely used correctly
 * sys: Add a parameter to not include the category, or to go even further, make a new template that just has the formatting so you can specify your own system name and icon.
 * co: Add a parameter for alternate link text.
 * I only have a strong opinion about the japanese parameter. While I agree that, in some cases, it can be redundant, it isn't always.  For example, it would be a little strange to nihongo something like "Donkey Kong" or "Super Mario Bros." because they're not Japanese names.  Yet, having the katakana in the infobox is a handy way to have something to copy/paste into Google if you wanted to see what searching in Japanese would reveal.  For me personally, this is a handy research tool, and I would hate to see it leave.  Since it's an optional parameter, if it doesn't get filled then it doesn't get filled.  But I would argue that it has a useful purpose, even if not always 100% of the time.   Pro  cyon  00:22, 3 October 2009 (UTC)
 * We might as well leave the others in, considering the future scope of SW. -- 00:48, 3 October 2009 (UTC)
 * @Procyon: Donkey Kong (ドンキーコング) looks strange? That's how I've always seen the template used, as a way to get that "?" link at the end of the Japanese. For the japanese parameter, I'm suggesting moving it out to the main body if it's not there already, so it would still be usable for searching (I use it all the time too, I definitely don't want to see the Japanese go). I always wondered why, if the japanese parameter is there, there's no "european" parameter, as there are tons of games that have an alternate PAL name. Those work just fine noted in bold in the writeup as well.
 * @Notmyhandle: Do you mean the inclusion of non-commercial and/or non-notable games? Could you elaborate on how the other parameters will be used?
 * — najzere T 06:33, 3 October 2009 (UTC)
 * I wouldn't mind seeing the |japanese go, as long as the information wasn't lost. Just because |distributor is rarely used, doesn't mean we should get rid of it.  If the information is found, include it.  How are media and input noted elsewhere?.  I don't understand your reasoning for changing sys and co.  Additionally it's too complex and widely used to complicate and increase the load on the servers. -- Prod (Talk) 15:09, 3 October 2009 (UTC)
 * The distributor has no impact or say so in the development of game, they're just a glorified middleman, so I'm not sure why anyone ever thought a field for a purely business-related item would be relevant, except that our infobox seems to be modeled heavily after WP's (meaning encyclopedic). For media and input, they're being used to show highly obvious and redundant material, such as Nintendo 64 games play on cartridges, or Windows games use keyboards. I can't even think of why we need a media field – is there a system that doesn't just play its own standard media? Input is useful if used correctly, when the input is non-standard, like when a game uses a floor dance pad or something, but it's mainly being used to display the standard controllers, or even worse, a list of all types of input that work with the game. By and large these two fields mirror what's found on the game's WP page, but I think WP's approach to articles is different than ours. The problem with all these extra parameters is that people want to fill them. We don't include them in the preload, so it's not like we want them to do that. Especially when they're mostly used incorrectly, as with media and input.


 * I remembered why I needed the formatting from sys: when a game has an alternate name/release on PC, the redirect gets categorized, but the pc requirements are found on the main page. If sys is needed in the requirements field, it will erroneously categorize the main page with the system category. Also concerning the requirements field, I've seen the formatting mocked up so we could distinguish between Windows Vista and XP, for example.


 * The co template I thought was pretty obvious and didn't expect to find any opposition to it. As it stands you have to put in the full category name, so in the case that a category link redirects to a category with a different name (e.g. Psygnosis), you wouldn't be able to put the name of the developer at the time at which the game was developed. Of less importance, you also can't use it to shorten the link name (e.g. SCE) or use an alternate name (e.g. Bally Midway). In short, there's no way to use our helpful category redirects.


 * About the server load, I'd hate to see that reasoning become an excuse not to clean things up and make the site better. Can the job queue be controlled in any way? Such as allowing the servers to perform certain tasks at designated times? I know that during the week in the middle of the day (PST), there aren't a whole lot of edits being made, though what that says about viewership, I don't know. — najzere T 16:01, 3 October 2009 (UTC)


 * We would probably just make the changes at night, or lock the database while it's working. My previous comment was referring to the possible domain changes and non-game information inclusion (i.e. "encyclopedic"). However, I'm not educated/aware of the current status of the discussions among the management involved in this endeavor.


 * The main issue with the japanese parameter, as previously stated by Naj, has always been about "why japanese and not other countries?" Pages will be fine if we remove it, and if we change it to include other regionalizations, that works just as well. It comes down to how we want to standardize our pages. Should we make the infobox lengthy and inclusive? I always prefer the infobox to hold as much information as possible, because the infobox is concise and makes it so you don't have to skim an article for quick facts. At the same time I can see how lengthy infoboxes create excess white space, so there's that aestheticism to be concerned about. -- 23:03, 3 October 2009 (UTC)
 * As I was working on this page earlier today, I was thinking that we could use expandable fields in the infobox for excessively long stuff like multi-system, multi-country release dates and huge PC requirements. I know I've seen that on some of WP's video game infoboxes, and I think it looks pretty sleek. — najzere T 23:28, 3 October 2009 (UTC)
 * I would rather not remove media, because there is a lot more useful information that can be included there, especially for PCs (I don't have a blu-ray drive or a floppy drive). Just because it's included on WP, doesn't mean we shouldn't have it here as well.  Input is somewhat redundant to our own Controls pages, so it's only true purpose is as a summary, which doesn't seem that useful.  I don't remember any of the games that have a distributor listed, what companies usually show up there?
 * Your issue with sys I believe brings up a deeper problem, that we don't really have a proper standard to tell when to use a redirect with categories vs. a shared main page (like Pokemon Yellow). The co issues that you bring up will affect any company where they changed the name, without being bought out.  However, the template is already fairly complex, and it's usage would need to be made even more complex to support alt-text.  How many companies are affected by this? -- Prod (Talk) 23:44, 3 October 2009 (UTC)
 * This reminded me of the issue with company categories and names. Because older games use the archaic versions of company names, I have a feeling that sometimes we have changed the links on a page to reflect the newer versions of a company's name. I can't think of an example page, but I don't agree with this method of displaying information (if it's not on the packaging/in game, our pages should not include present day information/references because it does not present it in a factual, historically accurate way; redirects and excluded ). -- 00:13, 4 October 2009 (UTC)
 * @Prod: If you say a field is useful, then that's all I wanted to know. I was just listing ones I don't find to be of any use. As for distributors, they're usually publishers as well if they're big enough (Nintendo, Sega, Midway, etc.), in which case they'd be listed twice in the infobox. The difference from the other things we note, is that you can go to the developer or publisher category and reasonably expect to find other games you might like (although not so much for huge publishers). For distributors, it's just business, they have no influence over the game's development (unless they're the publisher as well), and they'd be just as happy to ship Princess Maker games as Diablo games. For sys, you're right there are other issue to think about which might help the situation. For co, it didn't appear to be very complicated to me. I think we can get away with just putting  |  in the category link.
 * @Notmyhandle: Totally agree. It's best to have the name of the company that's on the box, rather than the third or fourth copmany down the line that's currently owning their name. — najzere T 01:34, 4 October 2009 (UTC)

Well, discussion seems to be over, so here is my takeaway. The infobox parameters aren't hurting anything, as they don't have to be used. It's not clear why we have a Japanese field and none for other languages, so maybe that will come up again in the future. The sys template has brought up a different issue, which is how we handle categorizing redirects and different versions, so that could probably be its own discussion (what wasn't mentioned was the effect this has on the Guide completion page, where category counts used to determine how many guides we have are overstated). For the co template, the notion that we should be using the company name at the time the game was released seems to be most accepted, and the template's (apparent) complexity isn't a compelling reason not to fix it. (It's an administrator's job anyway, as the template is protected.) So I'll update the co template and leave everything else the way it was. Thanks everyone. — najzere T 20:34, 17 October 2009 (UTC)

Control table styles
Here's an issue I once brought up on the forums, which didn't seem to get much attention there.

Currently, the common format for control tables is to make the control cells center-aligned and the description cells left-aligned. I'm wondering, what should be the preferred way to go about this? There are two methods of applying such formatting:


 * 1) Set all the control cells as header cells (TH elements) instead of regular cells (TD elements). (Example) This is the method used in the example in StrategyWiki:Guide.
 * 2) Set the "|text center=1" option on prettytable, then set an "align='left'|" or "style='text-align: left'|" option on all the description cells. (Example) This is how I usually do it.

The example in the guide uses the first method, which implies (but never explicitly states) this method to be a guideline. However, there is a problem with this method. For compatibility and accessibility reasons, Web standards recommend keeping content separate from presentation, and using header elements for cells that actually contain data instead of headers breaks that rule. How the control information can be defined as "headers" is beyond me. Making the control images center-aligned and the text left-aligned is a presentational attribute and should not be implemented through semantic markup. Unless there is a valid reason to classify the control images as "header cells" (and "It's easier" doesn't count), the second method works better from a functional perspective. Yet the guide seemingly recommends the first method.

I see three possible courses of action:


 * 1) Leave the guide unchanged, and enforce usage of the first method.
 * 2) Change the guide to recommend, or at least allow, the second method, then optionally enforce that instead.
 * 3) Disregard the whole thing and leave the matter up to the individual editor's preference.

What say you all? Wanderer 02:04, 6 October 2009 (UTC)
 * Anything but number three. I prefer not to use header cells for the controls, but I don't know why we need to center-align them anyway. If we make a change, I'd be for using the plain prettytable with no embellishments and having the whole table left-aligned except for the header row. The major concern with changing something like this fixing all the ones that are currently using the style outlined in the guide. If everyone thinks it's worth changing every control table to match a new style, then I'm for a non-header cell format. If it's not worth the work, then I'm fine staying with the current guideline. Whatever the outcome, our controls table style should be uniform, not used at the editor's discretion. — najzere T 03:05, 6 October 2009 (UTC)
 * We could make a new template like prettytable meant to go on top of control tables. This template could employ CSS that automatically bolds all cells and center-aligns them, and then unbolds and left-aligns the description cell. -- 04:59, 6 October 2009 (UTC)
 * That would still require putting a class attribute on each of the description cells, though. Wanderer 05:51, 6 October 2009 (UTC)
 * Method #1 was not initiated on a web standard train of thought, but rather it was a simple solution to center the text and exclude the use of css/html in the page's code. Now, this may or may not be the best course of action, but I haven't seen any issues with it in Internet Explorer, Firefox, or Google Chrome. -- 16:07, 6 October 2009 (UTC)
 * @Wanderer: no it wouldn't. We could use the tr:last-child pseudo-selector to get the last element. It doesn't work on older browsers (IE6, Safari 3, etc.), but nobody cares about them anyway. -- 00:23, 7 October 2009 (UTC)
 * That's been reported not to work in even IE8. Wanderer 01:12, 7 October 2009 (UTC)
 * No problem, let's just leave the whole table left-aligned. — najzere T 03:59, 7 October 2009 (UTC)
 * But it looks nicer with the buttons centered. Wanderer 04:56, 7 October 2009 (UTC)
 * The control images are row headers, which are a perfectly acceptable use of the th tag per the W3C recommendations. There are further recommendations that are not implemented here which would make them more useful for accessibility reasons (compatibility isn't an issue here because people have been misusing tables since day one due to the lack of actual layout tags in HTML, and therefore all relatively modern browsers understand some very maligned tables), but such things would be better handled by the template than by the users (for example the recommendations mention using an id for each header and then enumerating the column and row headers that apply to each cell within the markup for the individual cells).


 * Look at it like a multiplication table, the contents of each cell are only so useful with just the column header, until you've learned multiplication and division well enough to generate the tables yourself. Otherwise, you use both the column header and the row header to find the cell that corresponds to the result of multiplying the two values. In turn, you use the row header for the system on which you are playing the game and the column headers (in most cases Description or Action is the only column header in use, but this is not always the case) to determine how to perform each action. -- 09:34, 8 October 2009 (UTC)
 * By this reasoning, it sounds more like the description cells would be the headers. There's only one description cell per row, and you cross that with the column for the platform you're playing on to find which button to press. Wanderer 05:13, 9 October 2009 (UTC)
 * That would be a reasonable way of looking at it, too, which is why I mentioned that it's possible to have more headings, we just usually consolidate them into a single column rather than spreading them out. Final_Fantasy_X/Controls is an example of a single-console release (therefore not having control images for multiple systems) using multiple columns (and notably not using the headers for the control images). -- 20:13, 9 October 2009 (UTC)
 * A column header in addition to a row header indicates that the rest of the row is dependent on that metric, such as in experience tables where the character's level is a column header showing that you can change your level but not the stats received at each level directly. It's already implicit in a table with a header row that the data in each row are related, so unless you wish to impart extra information by making a column a header as well, it's not needed. In a controls table, you can look at it either way: do you want to know which button makes you jump, or do you want to know what the X button does? Basically, I don't think any column should be a header, and the tables are so simple they would be understandable even without a header row in most cases. As far as formatting goes, the guide says not to use center-aligned content unless the table contains mostly images. Our guideline for all other tables (as shown in multiple talk pages over years) is to leave it (defaulted) to left-aligned, so I think that's the best way to approach control tables as well. — najzere T 06:32, 10 October 2009 (UTC)
 * Except that the control tables do contain mostly images. True, there's also text columns for the descriptions, but nobody was suggesting centering those as well. Wanderer 06:56, 10 October 2009 (UTC)
 * Which just takes us back to the beginning, where option #2 would seem to be recommended by another portion of the guide, since it states that the text center option should be used. -- 14:09, 10 October 2009 (UTC)
 * Hard to say what was intended with that vague sentence, but I always took it to mean a single image in a cell. Besides the fact that controls often contain more than one control image, they also often contain some explanatory text, usually just a word or two ("hold", "while jumping", etc.). A blanket centering of the contents won't always fit our guideline, while left-aligning always will. — najzere T 15:45, 10 October 2009 (UTC)
 * The occasional word or two doesn't really matter; the focus of those cells is on the images, so those columns do contain "mostly images" — especially if there's more than one control image to a cell — and they do "look better center-aligned", so left-aligning them actually wouldn't fit the guideline. Wanderer 16:43, 10 October 2009 (UTC)
 * Left aligning is the guideline. Centered control images looking better is an opinion, and I disagree. Beyond style though, don't forget that if we decide to implement centered control images, it will be more complicated to produce those tables than to simply use the prettytable template and be done with it. — najzere T 18:21, 10 October 2009 (UTC)
 * Left-aligning is the guideline for text, not for images. And let's not sacrifice quality for laziness. Wanderer 20:07, 10 October 2009 (UTC)
 * It's the guideline for all tables, images were used as an example. It should be noted that the example was to center the entire table, not certain columns.
 * It's not laziness to make the wiki easy for every user. We have enough trouble getting users new and old to learn the myriad ways we do things here. You and I know how to use prettytable and add cell attributes, but why should we make it complicated for every other user to make something as ubiquitous as a controls table? Once again, "quality" is a subjective term, which you're applying to style anyway. — najzere T 20:20, 10 October 2009 (UTC)
 * That's not at all what the guideline says. It says "Usually, text should be left-aligned in a table" (emphasis mine). That's not a recommendation of left-aligning everything, including images. That only says text. The guideline then proceeds to explicitly allow for centering image-heavy tables, which control tables certainly qualify as.
 * If being easy to edit took priority over quality, then there wouldn't be any guidelines at all. I'm not saying we should add as much needless complication as possible for no good reason. I'm saying that easiness does not and should not take priority over quality. Wanderer 21:57, 10 October 2009 (UTC)

Update: Surprisingly, no one has really said we shouldn't move away header cells, so it seems that Wanderer's proposal has been accepted by consensus. What remains to be worked out are styling issues with the new table format. To boil down the above discussion, the two primary style proposals are: I'm assuming everyone's fine with keeping controls on the left, explanatory columns on the right and using a header row, as no one has mentioned changing those aspects. The style would already have been decided, except for a disagreement between the aesthetics of center-aligning controls and the ease of creating the table. Please voice your opinions, thanks. — najzere T 20:34, 17 October 2009 (UTC)
 * 1) Controls column(s) center-aligned (not sure if bolded was wanted as well), explanatory text column(s) left-aligned
 * 2) All columns left-aligned.

Why exactly does this site have fan games listed?
Most recent example (that I know of): Super Mario 63. In my opinion, we shouldn't be promoting unofficial (and I would bet in many cases: illegal) games. The games are also most likely copyright infringements (Mario is owned by Nintendo) and I somehow doubt people legally can just release these types of games. Even if they are free, it's still a legal issue I believe. Promoting hacking and so on: a big mistake. If this site ever wants to compete with bigger sites, this isn't the way to do so. I see no good reason for even so called "notable fan games" to be listed here. If people want to get help on illegal games and hacks: they should do so elsewhere. This issue has came up in the past I believe, and people just shrug it off as not a big deal. However I think it is a big deal and should be addressed here. RobJ1981 19:35, 8 October 2009 (UTC)
 * Also on the subject of things that aren't suitable: MAME (as well as Category:Emulators). It's bugged me for a while, and I havent seen a good reason for why it's here either. So basically the site is promoting roms by telling people how to play them on the computer but not telling people where to get them. How does that make sense? Both aspects are illegal. Game makers spend their money and time on a game, so there is no good reason to rip it off. I know the excuse of "I own a hard copy, so I'm entitled to a version on my computer" comes up a lot in rom/emulation discussions. However that's just an excuse for this poor behavior. Personally you wouldn't want something you worked hard on ripped off by people, so why do it to others and then promote it here? RobJ1981 19:44, 8 October 2009 (UTC)
 * A couple of points... I personally am a big supporter of emulation. Although programs such as MAME can be abused by users who pirate ROMs, MAME in and of itself is not illegal in any way, and many older (read: retired) arcade developers have praised MAME for the spirit that it espouses; namely to keep the memory of older games alive.  Yes, I was a former game developer, and no, I wouldn't necessarily like to see my games being pirated, but I have, and they are, and that's nothing SW should get involved with, but I don't feel that hosting a guide on how to use MAME is promoting piracy in any way.  If anything, it's providing users with a way to understand how to enjoy some of the games that we host guides for that they could not otherwise play.  I know Pac-Man has been on numerous Namco classics discs, and Donkey Kong is on the Virtual Console, but when's the last time you ever saw Q*Bert out on the market?


 * Now I agree that Super Mario 63 is very gray and very questionable, but I leave these matters up to the community. If the community feels that SM63 is not worth supporting, than I am only too happy to enforce that.  But the decision has not been made.  On the other hand, I feel that a guide for games such as Mario Adventure should be welcome on this site, and I realize that I'm splitting hairs when I say that.  At the end of the day, there will always be differences of opinions, but I have always felt that SW was a democracy, and if the community at large feels that something is inappropriate for this site, than we are obligated to comply.  That said, if there are others who feel the way that Rob feels, please voice your opinion.  Likewise, if you disagree, please share your thoughts as well.   Pro  cyon  01:05, 9 October 2009 (UTC)
 * Games not being out seems more like an excuse, not a reason. There is many several TV shows I would like on DVD, but that doesn't mean I will find bootlegs of them or whatever. Also not being on the market doesn't make playing it online legal in all cases. Pretty sure the game must have no copyrights anymore or be labelled freeware and so on. RobJ1981 22:28, 9 October 2009 (UTC)
 * I have no problem with hosting guides for any game, as game guides are entirely legal. I also have no problem treating emulators as any other system, as they are also (for the most part) legal. I'm a purist when it comes to this site: I'm interested in making a guide for a game; I don't ask where the game came from or how the reader obtained it. I will say that all links either directly to illegal games or to resources for obtaining them should be removed. It's sketchy right now to link to copyright infringements (if you've been following digital rights news, you should be well aware of this), and at any rate it's outside our scope. Our content should start from the reader having the game playing on his system. Linking to legitimate game signup sites is fine (like in the infobox), but for illegal content such as all derivative works (ROM hacks, games using copyright characters), we would do well to steer clear. — najzere T 06:32, 10 October 2009 (UTC)

There's no consensus to get rid of fan-made games or emulator information, so unless there is something actually illegal on the site, these things will remain. This subject may come up in the future, in which case hopefully more people give their feelings on it so we can have a more satisfying conclusion. — najzere T 20:34, 17 October 2009 (UTC)

Super Mario Bros. 2 naming
Moving this conversation here for opinions. Basically a non-standard (from my experience) disambiguation page resides at Super Mario Bros. 2, and in an effort to move one game to that location with a game disambig to the other, we require some input on what should go where. The two schools of thought on this are that the earliest game should get the "main" name or that the most common game should get it. I'm not sure if the second one is used in any instance, or just English vs. non-English games. Anyway, does anyone have an opinion (assuming it is correct to get rid of the disambiguation page) on whether to move Super Mario Bros. 2 (Japan) or Super Mario Bros. 2 (US) to Super Mario Bros. 2? — najzere T 18:18, 14 October 2009 (UTC)
 * All right, this must not be very interesting, so I'm just going to move the Japanese version to Super Mario Bros. 2 and leave the US version as Super Mario Bros. 2 (US), to conform to the "first-released, first-named" rule. I mentioned on Procyon's talk page that I prefer doing it the other way, but the release standard is not subjective and therefore fairer. I'll do this sometime next week, so please do object in the next couple of days if you disagree. — najzere T 20:34, 17 October 2009 (UTC)
 * Although non-standard, I think the current set up works quite well, as it does not favor either regionalization (U.S. would be our primary choice based on native advertising) nor initial game date (Japan in 1986 versus U.S. in 1988). I'm for changing it to be "standardized", but I dislike our options here. -- 02:23, 18 October 2009 (UTC)
 * In my mind, only a few games would ever be eligible for this kind of non-standard disambiguation, and they would be games that must fit such a confusing criteria, that it only makes sense to make such a page to remove the confusion. SMB2 was one of them, and the only other two I could think of was Final Fantasy 2 (Japanese Famicom, or US SNES) and Final Fantasy 3 (ironically, the same choices).  At the moment, I can't think of a single other game that would fit this criteria, but when in doubt, I say follow WP.  In case, SMB2 = US, and FF2 and FF3 = Japan.  Pro  cyon  02:27, 18 October 2009 (UTC)
 * I don't think we should be following WP standards unless we're talking about featured articles. Most of English WP page names appear first instead of being redirected because of their regional audience (i.e. English WP will primarily choose the English title because English speakers are more comfortable with that; they type that in first because its marketed for them). I think this type of disambiguation should be reserved for, as Procyon noted, conflicting criteria. -- 02:42, 18 October 2009 (UTC)