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)
 * The main other language title I can think of adding is one for the PAL region. They do tend to have differing titles and this could be helpful for clarifications (and quicker to find then in the main description). If a distributor ever differs from the publisher then I do find that information helpful. --Zaiqukaj 11:01, 20 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.
 * Since the controls columns are mostly images anyway, I don't think the bolding really matters. Wanderer 00:08, 19 October 2009 (UTC)
 * I agree. I prefer them center-aligned, but could care less about the bolding. It would be nice if we could put together something that would make the wiki code cleaner, though. -- 22:27, 19 October 2009 (UTC)
 * I suppose Skizzerz's idea of making a template and CSS classes for it could work, and it would let us change the styling rules later if we wanted to. But I see no reliable way to apply the different styling rules to the description columns without putting a class attribute on each description cell. Even if the last-child selector were sufficiently well-supported, we'd run into problems with tables that have multiple description columns (example) and possibly ones where the description cells cross rows (example). Maybe a second template could be made for description cells to add the class attribute? Wanderer 03:45, 22 October 2009 (UTC)
 * I wish someone besides myself and Wanderer would opine on whether it's worth the hassle to have center-aligned control images. Speaking as the person who will be fixing all these complicated tables new users attempt to make, it's in my own personal best interest to keep things simple, which, by the way, is a pervasive maxim in nearly ever endeavor existant. — najzere T 06:40, 22 October 2009 (UTC)

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)
 * I on the other hand do have a major problem with hosting these games on the site, and would like to have Super Mario 63 deleted. The work is done and shouldn't be lost (transwiki somewhere) but I strongly believe that does not fit our scope at all. -- Prod (Talk) 05:19, 20 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)
 * So lets include board games too. -- Prod (Talk) 05:19, 20 October 2009 (UTC)
 * We could, but none of us seem to be board game enthusiasts. -- 05:22, 20 October 2009 (UTC)
 * The game "not being illegal" seems like an excuse, not a reason. Let's put it to a vote then. Right on this page (not on the forums... any case anyone suggests that, because most of those people don't even edit this site from what I know at least). We should establish a consensus on this, because I'm sure this wont be the last time some fan-made nonsense will be posted here. RobJ1981 06:57, 20 October 2009 (UTC)
 * @Prod: The one thing our scope has always been clear on is that we host video game walkthroughs, so board games are obviously outside our scope. The reason scope was relaxed was due to the number of non-notable/non-commercial games that were being made or requested and the support for them, mainly from administrators. Maybe you could state your reason why you have a problem with them. If it's simply because they're out of scope, we fixed that by changing the policy.
 * @RobJ1981: I vote keep.
 * — najzere T 07:10, 20 October 2009 (UTC)
 * Prod was being sarcastic, but my comment hinted that this site reflects the community, not a strict policy. Now, that's not really a good way to go about things, as a flimsy structure will only hasten SW's demise. However, for Super Mario 63, I vote keep (it's a great game; try it). I see no reason why we can't include awesome games like these. Also, I am without my forum/IRC password for another month, so this is a great place to do it. -- 07:29, 20 October 2009 (UTC)
 * Why are we voting for it here? I agree that it shouldn't be in the forums, but shouldn't we put a VfD on the page? (We don't have a VfD?)  Pro  cyon  13:23, 20 October 2009 (UTC)
 * Because we aren't anal about overly bureaucratic nonsense like Wikipedia is, that's why. Also, it's called delete here :). Also, I say keep. -- 06:17, 21 October 2009 (UTC)
 * Delete. I think we need a very well-defined line of what games are within scope and what games are not.  I think that allowing ROM hacks, flash games, etc. while not allowing others is wrong.  That leaves two options, in my opinion.  Allow every game or only commercial games.  My vote goes to commercial games.  I think there is a need for a wiki dedicated to flash games and such, but that isn't here.-- Duke  Ruckley Talk 13:04, 21 October 2009 (UTC)
 * Of course people are voting keep. I figured voting wouldnt help because people would rather use this site to promote illegal and/or fanmade things rather than elsewhere. I decided to give it a shot because I thought people would have listen to logic. Why can't the content just be moved elsewhere? This site should strictly be for legal and official games, not fanmade nonsense that you think is "notable" for inclusion just because lots of people play it. That's it, I'm done. RobJ1981 21:27, 21 October 2009 (UTC)
 * Actually, Rob brings up an interesting point. These guides are valuable, but our scope is already broad enough without including unlicensed games.  We could perhaps look into a secondary site that hosts guides for these kinds of fan-made games.  Now to go a bit further than that and address the legality issue.  Super Mario 63 takes copyrighted materials (the character images and textures) and reuses them, I'm certain without permission.  I wouldn't bet on them being able to use a fair use defense in their case. -- Prod (Talk) 01:56, 22 October 2009 (UTC)
 * As much as it pains me to admit it for my own reasons, I have to agree with Prod on this one. Just because Nintendo hasn't gone after them to take it down, doesn't mean that what they're doing is right, no matter how well made the game is.  And let's face it; if you took Mario out of the game, and put some generic no-name character, people would be faaaaaar less interested in playing around with it.  Although agreeing with Prod on this will have further ramifications for the site that I am less enthusiastic about, I think Prod's point is valid.  There is a delete template on the page now.  Please take this discussion over there.


 * P.S. Rob, if you're reading this, you were a very valuable contributor, and I would really hate to see you retire from the site over such a disagreement. The matter isn't settled yet.  I hope you reconsider.   Pro  cyon  02:31, 22 October 2009 (UTC)
 * I agree. However, back on the discussion, I don't remember seeing anyone arguing Super Mario 63's notability (although Naj requested some outside sources from the main editor of the guide on Super Mario 63's talk page). It's not notable, it's just a great game (which is why it shows up in search results). Plus, if we were to exclude unlicensed games, we would have to flesh out all of the independent games and clones for the NES and other consoles. These games are legitimate, but they are illegal. What do we do then? As long as we don't provide actual downloads of games, there's nothing wrong with hosting the information. Information is not illegal, but its use can be. Therefore, it should be realized that it is not our job to be biased or to censor the internet. -- 03:25, 22 October 2009 (UTC)
 * That also brings up the issue of personal bias: why do I support any game? Why do I not support all games? I support all commercial games, as SW does, but my personal bias in turn supports games that I like. We have to choose to either be extremely anal (a commercial business), or be a community of gamers. As my previous view of this community was not-for-profit (I don't know what to think about it now; we seem to be in limbo at the moment), an open, flexible ruleset seemed optimal. If we were to be ruled by a business, however, I would say we should be including whatever will gain us profits (i.e. all games). Argh so complicated. -- 03:30, 22 October 2009 (UTC)


 * I've grabbed an XML dump of SM63, and should it be deleted, can be transwikied to other suitable wikis (which has a tight scope). --Sigma 7 03:37, 22 October 2009 (UTC)
 * NotMyHandle, I disagree: we can be a community of gamers, but we certainly shouldn't be promoting unofficial games. The games aren't official and in many cases are illegal. Just because we aren't providing how to get them, doesn't make them correct for the site. We should be bias, because there is no excuse to list things that aren't official. This site shouldn't promote illegal (or unofficial and fanmade) games just because you personally enjoy them and/or need a guide for it. RobJ1981 04:30, 22 October 2009 (UTC)
 * NMH, I just want to clear. On a personal level, I agree with you in principal.  But my choice to agree with Prod has more to do with what is best for the site in general.  One statement that you made which I don't feel holds a lot of weight is that by not hosting a guide for SM63, we are censoring the internet.  We're not.  We're just saying that such a guide doesn't belong on this site.  As Sigma7 just suggested, the work done so far should be preserved and it should find an appropriate home.  There are guides on this site that I am going to be unhappy about losing if I we institute a commercial-only policy (which hasn't been fully decided upon yet) but that's something I'll have to accept.  I mean, look at what we're saying.  We're denying a number of games that's in the hundreds, compared to the number of games we are including which is in the hundred of thousands.  We're really only talking about a percent of a percent of the games that are out there.   Pro  cyon  04:35, 22 October 2009 (UTC)


 * I edit conflicted with Rob, but now that I've read his comments, I just thought I'd put my $0.02 here too. Rob, if the only argument for not including them is because you don't want to see support for games that you consider objectionable, that argument alone is not sufficient.  If that were the basis for the argument, the amount of visitors that such guides attract alone would be just cause to continue hosting them.  Prod's argument is far more supportable, and it has to do with scope creep and the maintainability of the site.  That's what his joke about including board games was trying to illustrate.  Someone could easily reply "this site will never host board games, that's ridiculous," but I'm sure someone a long time ago said, "this site will never host fan-made games, that's ridiculous," and look where we are.  It's not about moral object, or censorship.  It's about the good of the site, and having clear cut guidelines so that arguments such as this can be avoided.   Pro  cyon  04:42, 22 October 2009 (UTC)
 * Right right, if the guide were not present, there would be no negative effect. What I'm saying is that our principles should not reflect antagonistic views of net neutrality. That is all. I apologize for not being clear - I don't want this to be a moral issue, and I feel that since SM63 retains fair use rights (non-commercial work of art), there's nothing wrong with it.


 * I also agree with the scope issue, I don't want a policy that includes every flash game. That would be a ridiculous undertaking. I have no issue with having an extremely restrictive policy. It would actually be perfect for us - we need a more rigid scope, one that we can't skirt around like we've been doing. The only issue I have, the reason we are all jumping on this subject, is because one or more of us have invested our time into some of these guides. We should probably just set up a Wikia wiki for stuff outside of our scope if there isn't one that already fits it. -- 05:55, 22 October 2009 (UTC)
 * I don't think this site should be about championing game developer's rights and being advocates of strict intellectual property protection. Whatever your individual notions are as an editor, the site itself should only be interested in these legalities insomuch as to follow them. Nothing we host is illegal, and ensuring it remains so is the full sum of our legal obligation. We have neither the expertise nor the mandate to judge the legality of games and emulators – we are not lawyers and if I've ever seen something outside our scope, that is it. After legal necessities, aren't we here for users? Or is StrategyWiki's purpose to reach moral consensus about a political issue? I prefer to think it's the former, and in that regard, if there is a person who is interested in a video game, I want the information to be here for them. Likewise, if an editor wants to write about how to beat a video game, I want to provide an accessible, friendly venue for him to do so. Some games are illegal, derivative works and the player of the game must accept the responsibility for using them, not us. When game guides for illegal games become illegal, then I will heartily support the removal of all such guides. Until then, I'll petition my congressmen if I want to weigh in on a copyright law.
 * On a side note, SM63 is an unambiguous copyright infringement, as it is a derivative work using copyrighted properties. Non-commercial = fair use is one of the biggest copyright myths out there. — najzere T 06:40, 22 October 2009 (UTC)
 * So Najzere: basically we help people play illegal and unofficial games? I don't think that's the correct way to go at all. Just because we aren't linking to where to find the games, doesn't mean the guide is suitable for this site. Basically you are saying we should ignore all laws because we aren't lawyers? Yeah right. We are here to help gamers, but we shouldn't be ignoring things just because someone needs help. We aren't the only site to get help with games, so people can easily find help if they look elsewhere. We aren't above every other website out there. Anyway..as for the flash game argument mentioned above your post: I wouldn't mind either way. There is many flash games, but there is many console and handheld games as well. Perhaps if we could get more editors, this site could have more content. I've brought up ideas in the past, and basically they have been ignored. This site could be a lot better, but people apparently don't even care to help promote it. We should have a hell of a lot more than 3157 guides now. RobJ1981 04:08, 23 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)
 * My vote would be to leave things the way they are, because I find it justifiable. Fire Emblem is another one I can think of that can cause some problems, but I think we handled that pretty well, too. The Final Fantasy games work the way they do because all of the games in the series were eventually re-released under their original Japanese titles, whereas the later releases of the SMB2 games (USA in Japan and Lost Levels in US) were under different titles and therefore wouldn't show up where people would expect them to.-- 13:55, 18 October 2009 (UTC)
 * I've been hoping to get rid of that whole disambiguation category and fix everything in it. We don't have the same kind of disambiguation that wikipedia does since most things just link to a category or only one other similarly named game.  Final Fantasy II has a similar problem, but is resolved in an "obvious to users" way.  These should be split to separate names, with one getting the regular name and a disambig link to the other.  Our general strategy has been to put the first game released first, but as this game was released in Japan first, it doesn't really need to follow that. I'm ambivalent of which way we go, but this disambiguation page should be removed.  -- Prod (Talk) 17:22, 18 October 2009 (UTC)
 * While I don't agree that the problem here is the same as FFII, since SMB2(J) has never been released as a stand-alone title outside of Japan, if the purpose is to completely get rid of all disambiguation pages, just pick one and do it. Either one is going to confuse someone, but I think the US game would be the least confusing of the two choices, just because the game had a wider release than the Japanese version. However, it's always good to follow whatever standard is already in place for other choices, so I have no problem with putting the Japanese version down as the default redirect for Super Mario Bros. 2, either. I just feel that it's one of the few games on this site that actually justifies an actual redirect page, if we're going to have them. -- 18:23, 18 October 2009 (UTC)

OK, this is obviously a topic that no one feels particularly strong about, and we can go around and around on the subject. The fact that Prod and Naj want to remove the current disambiguation page is enough for me to support that decision. Which means one game needs to get the title. I will vote for the US version because: Truth be told, I'm only about a month away from really digging into the SMB2US guide. So if we're all comfortable with this decision, leave the pages alone for now, and I'll start straightening them up when I get to Doki Doki Panic.  Pro cyon  20:15, 18 October 2009 (UTC)
 * That's the game that WP gave it to,
 * That's what most of our English speaking audience will think of when it comes to that title, and
 * The way we've incorporated the Lost Levels into the SMB1 guide sort of precludes the need to give it it's own title.
 * Hell, I'm close enough to it already... I might as well just jump ahead and start it now. I'm more interested in working on that guide than the one for Dr. Chaos anyway.   Pro  cyon  20:17, 18 October 2009 (UTC)
 * I've put some info for each below. However, we should consider this in the general case of JP vs. US releases, and in that case, I'm somewhat leaning towards giving the US game the name for the reason bolded below. -- Prod (Talk) 21:10, 18 October 2009 (UTC)

Which should get the title?

 * Let's make this less complicated: Does anyone object to giving the title to the USA version?  Pro cyon  21:56, 18 October 2009 (UTC)

Collapsible infobox
Here is a mockup: User:Najzere/Sandbox. It came up in a different discussion that some of the fields in the infobox can become quite long, and collapsing them was mentioned. I've seen this used on Wikipedia, but I can never seem to find a usage of it when I want one. The current WP infobox doesn't seem to have the ability to collapse individual fields, but rather one big parameter to collapse the entire infobox down to the image and title.

If this functionality is deemed useful, I see two ways to incorporate it: either as part of the infobox template or as a separate template of its own, to be used within infobox parameters. The former method would be very complicated in an already complicated template, so I would recommend a separate template to handle this. The title could be decided on once, e.g. "Click link to expand", or it could be left up to the user, if there's a benefit to that.

Another option would be to use WP's whole-infobox collapsing, perhaps even by default, so main pages would just have the title and box art. Some additional parameters that would be good to leave out of collapsing might be the preceded by, followed by and series parameters. Anyway, I'm interested to see what people think of this, as finding a way to shorten lengthy infoboxes would make a lot of guide main pages look cleaner. — najzere T 19:49, 19 October 2009 (UTC)
 * I like the general idea, but I'm somewhat in favour of the WP method. I figure most of the information will be looked at once (if even), and then never again.  I think the most important ones to make unhideable would be expansion packs and series.  After that would be preceded/followed by, but with the series link, I don't think those are that necessary.  -- Prod (Talk) 05:31, 20 October 2009 (UTC)
 * I actually prefer the whole-infobox collapse as well, but didn't think such a radical change would meet with much enthusiasm. Also, as you say, with the series parameter, preceded by and followed by aren't all that necessary as non-hideable fields. — najzere T 07:10, 20 October 2009 (UTC)
 * My only real issue with hiding is that we lose the "many eyes" benefit of the open content. If nobody sees the mistakes, nobody corrects it.  Based on that, I'd say we're probably a bit too early to implement that.  I'm sure we've got more infoboxes <100% accurate than infoboxes that are 100% accurate. -- Prod (Talk) 05:04, 22 October 2009 (UTC)
 * Naj, those are both great alternatives. There's also the issue Prod brought up. Perhaps we should start a SW todo list to keep track of future implementations. I feel that if and when we choose to implement this, this sort of thing should be a part of user preferences, as it affects the standardized view. We're used to large ToC's that are of relatively the same length; for instance when we set up the main page layout standard, ToC length was ignored because we had maybe 1 or 2 super large infoboxes (i.e. it wasn't apparent at the time that we would need to deal with it). -- 05:44, 22 October 2009 (UTC)
 * @Prod: Every edit gets patrolled, so if they haven't been fixed by now, it's going to take a long time (by this I mean years) before a random user comes around who can fix it. In the meantime we're not implementing something which at least the three of us deem useful. Personally, I don't see much benefit to waiting. Having looked at every edit to the wiki for at least the last six months, I don't think I can recall even one infobox fix from a non-admin to an existing guide main page. 'Course, that's not very scientific. :P
 * @NMH: User preference would be ideal, if harder to implement. I'm sure Prod or Skizzerz could come up with a way to do it though.
 * — najzere T 06:40, 22 October 2009 (UTC)
 * If we hide it, that random user will never come along. Patrolling the edits for vandalism is one thing, but correcting minor inaccuracies is quite another. Can you link to an example of this infobox hiding somewhere? -- Prod (Talk) 14:18, 22 October 2009 (UTC)
 * collapsible=yes search string reveals many. For illustration purposes I'd say by leaving infobox open, you'd improve your odds of a random person fixing it from 1/1,000,001 to 1/1,000,000. The only people who change infoboxes are people who contribute to the guide, and if they're interested in checking the main page for accuracy, I don't think a show/hide link is gonna stop 'em. — najzere T 15:24, 22 October 2009 (UTC)
 * That's a good point. Random contributors cannot be relied upon to fix infoboxes. I like the collapsible elements, particularly for multi-line entries such as the Release Dates and System requirements (as Naj simplified in the first example). I don't like the third example as much because a lot of the quickness of the infobox is lost; people browsing the site, even myself, will not be aware of all of the possible data on the page. Collapsing only a select few boxes is useful, as it cuts down on whitespace, but tells people that there is something there. However, I don't think we will have a problem if we implement either form of this; people learn. -- 15:59, 22 October 2009 (UTC)