Video games Template‑class

This template is within the scope of WikiProject Video games, a collaborative effort to improve the coverage of video games on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.Video gamesWikipedia:WikiProject Video gamesTemplate:WikiProject Video gamesvideo game articles Template This template does not require a rating on the project's quality scale. Summary of Video games WikiProject open tasks:

Archives

Previous and next game in a series fields discussion

This page has archives. Sections older than 100 days may be automatically archived by Lowercase sigmabot III when more than 6 sections are present.

{{editprotected}} Some time ago there was a discussion on changing the look of "system requirements" field by User:LOL. This seems to have gotten stale. On editor's behalf, can this be implemented? The code is here. —  Hellknowz  ▎talk  11:11, 8 May 2010 (UTC)[reply]

 Done — Martin (MSGJ · talk) 22:51, 8 May 2010 (UTC)[reply]

{{editprotected}} It looks like this might have slightly broken the syntax. A lot of pages use bulletpoints for system reqs. The current revision uses "<br/>" instead of a newline. Due to this, next paragraph started with "*" to produce bullet-point will not do so. See this. New source is here.—  Hellknowz  ▎talk  13:04, 9 May 2010 (UTC)[reply]

 Done, next time please test it :) — Martin (MSGJ · talk) 14:16, 9 May 2010 (UTC)[reply]

Thanks! Actually, the original version did not support bullet-points either. And, excuses aside, I wasn't the original author. xD —  Hellknowz  ▎talk  14:37, 9 May 2010 (UTC)[reply]

1. Given recent name change — should old template's names ("Infobox Arcade Game", "Infobox Videogame", "Infobox cvg", "Infobox Arcade game", "Infobox arcade", "GameInfobox", "Infobox CVG", "Infobox vg", "Infobox Video Game", "Infobox VG") be corrected when editing the articles? Or is there any separation planned for future?

2. The "released" field accepts the "release" as a name as well. Should the "release=" be changed to "released=" when editing the articles? —  Hellknowz  ▎talk  19:25, 15 May 2010 (UTC)[reply]

{{editprotected}} Payment method for MMORPGs is quite a big reason for people to choose one game or the other. Shouldn't this be included in the Infobox as well? If the game has a subscription/is 'buy-once-play-forever'/is freeware? --84.26.78.183 (talk) 10:31, 17 May 2010 (UTC)[reply]

FYI, admins typically like requesters to supply the code they actually want added.--Rockfang (talk) 09:06, 19 May 2010 (UTC)[reply]

You'll also need to get a consensus for adding this field to the infobox. — Martin (MSGJ · talk) 10:46, 19 May 2010 (UTC)[reply]

{{editprotected}} Please add an hProduct microformat, and remove the event microformat, by changing:

infobox vevent

to:

infobox hproduct

then:

class="summary" | ''{{#if:{{{title|}}}|{{{title}}}|{{PAGENAME}}}}''</includeonly>

to:

| ''<span class="fn">{{#if:{{{title|}}}|{{{title}}}|{{PAGENAME}}}}</span>''</includeonly>

and finally:

'''[[Video game publisher|Publisher(s)]]''' {{!!}} {{{publisher|}}} }}

to:

'''[[Video game publisher|Publisher(s)]]''' {{!!}} <span class="brand">{{{publisher|}}}</span> }}

No visible changes will be made. For background, see WP:WF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:59, 17 May 2010 (UTC)[reply]

I'm not an admin, but I don't see any reference to this sort of change on the link you provided. Why is this change requested?--Rockfang (talk) 16:21, 17 May 2010 (UTC)[reply]

 Not done: no response from proponent. — Martin (MSGJ · talk) 15:35, 18 May 2010 (UTC)[reply]

Apologies; typo for WP:UF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:48, 18 May 2010 (UTC)[reply]

The whole microformat thing should really, really get some wider discussion. I have no problem with decorating some of our data with semantic metadata, but I for one am not sure at all that µformats are the best approach. If there is project-wide consensus to add them we could make a far more concerted effort to update our templates. Or to do something else. As it is, I see Andy regularly popping up on my watchlist, and keep seeing the same questions and discussions following most editprotected requests. Amalthea 15:45, 18 May 2010 (UTC)[reply]

The wider discussion occurred over three years ago. Wikipedia already emits over a million microformats, from hundreds if not thousands of templates. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:48, 18 May 2010 (UTC)[reply]

Where? –xeno^talk 15:58, 18 May 2010 (UTC)[reply]

On various talk, VP and project pages - I don't have them bookmarked. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:01, 18 May 2010 (UTC)[reply]

When I tried getting behind the intended use of microformats a while ago I looked through WP:UF and some other pages, but I saw no link to such discussions. I searched the pumps, but they might just not be old enough. I have no idea where things like that were discussed at the time. An RFC? Amalthea 16:03, 18 May 2010 (UTC)[reply]

If you're going to claim three-year-old consensus, the least you could do is give us a link. –xeno^talk 16:13, 18 May 2010 (UTC)[reply]

WP:UF. The existence of hundreds of templates emitting millions of microformats, as documented there, is ample evidence of a de facto consensus. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:21, 18 May 2010 (UTC)[reply]

I'd say that's nothing more than evidence that you've managed to go around piecemeal to various templates and convince admins to fulfill editprotected requests. –xeno^talk 16:24, 18 May 2010 (UTC)[reply]

You may indeed say that. You'd be wrong, and in breach of WP:AGF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:29, 18 May 2010 (UTC)[reply]

I don't doubt you have a good-faith belief that these microformats are useful. Is that belief shared by the wider community? That remains to be seen. –xeno^talk 16:31, 18 May 2010 (UTC)[reply]

No, it's been amply demonstrated; but you appear to have nothing to say about the current proposal for this template, and this is veering widely off topic for this talk page. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:36, 18 May 2010 (UTC)[reply]

Where? –xeno^talk 16:36, 18 May 2010 (UTC)[reply]

Thank you for the link. I've just read WP:UF. The idea of microformats seems just as dumb as WP:PERSONDATA to me. That being said, I'm not going to oppose the "microformat cause."--Rockfang (talk) 19:45, 18 May 2010 (UTC)[reply]

Agree. A lot of extra code with little practical reason. No need to through it in an infobox. Der Wohltemperierte Fuchs^(talk) 20:16, 18 May 2010 (UTC)[reply]

You misunderstand; and misrepresent; and we already have hundreds of infoboxes with microformats. If you wish to lobby for their removal, please raise an RFC, rather than blocking an individual implementation. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:30, 18 May 2010 (UTC)[reply]

Yet you've been unable to point us to a discussion where the community agreed having these added is a good idea in the first place. Fait accompli? –xeno^talk 20:32, 18 May 2010 (UTC)[reply]

 Not done: I am declining this request due to lack of consensus. — Martin (MSGJ · talk) 10:31, 19 May 2010 (UTC)[reply]

There have been no objections to this proposal; only off-topic discussion of the wider matter of microformats. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:43, 19 May 2010 (UTC)[reply]

I suggest you try to resolve the wider issue first before pressing ahead with this. — Martin (MSGJ · talk) 12:45, 19 May 2010 (UTC)[reply]

The status quo is that we add microformats. Surely it is for anyone wishing to change that to make a case to do so? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:10, 19 May 2010 (UTC)[reply]

Status quo is that you add microformats to unprotected templates and sometimes get admins who don't really understand what's going on to add them to protected templates. However, you've been unable to point to a discussion where the community decided these were worthwhile to add in the first place. –xeno^talk 13:16, 19 May 2010 (UTC)[reply]

That's a gross misrepresenattion of the truth. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:19, 19 May 2010 (UTC)[reply]

Oh? So where was it that you pointed us to a discussion where it was decided these were a good idea? –xeno^talk 13:22, 19 May 2010 (UTC)[reply]

Pigs, people disagree with you on microformats in general and on this template in particular. Deal with it. You can't claim de facto consensus when there's never been a meaningful discussion, and we certainly don't go ahead and add stuff because other people in other venues have not objected. Der Wohltemperierte Fuchs^(talk) 13:35, 19 May 2010 (UTC)[reply]

• FYI: Wikipedia:VPP#Microformats. –xeno^talk 13:37, 19 May 2010 (UTC)[reply]

• FYI again: Wikipedia:Requests for comment/Microformats. –xeno^talk 15:49, 10 August 2010 (UTC)[reply]

{{editprotected}}

Add framerate option to write (like 60 fps in the game).

/Heymid (talk) 22:11, 21 May 2010 (UTC)[reply]

You need consensus first. BOVINEBOY2008 :) 22:40, 21 May 2010 (UTC)[reply]

Firstly, trivial info. Secondly, FPS usually does not depend on the game itself. —  Hellknowz  ▎talk  00:06, 22 May 2010 (UTC)[reply]

The list of media for a games with many re-releases are confusing. For example when looking for the cart size of Final_Fantasy_(video_game), you have to guess what platform goes with what cart size based on your knowledge of platforms. I fail to think of how Media is useful to any type of user if they can't identify the platform. Any thoughts? Ryanbgstl (talk) 07:16, 1 June 2010 (UTC)[reply]

Personally I've never been 100% happy with having re-releases and PSN/Wii Store/XBLA releases mixed in with the initial release. I'd favour a small sub section of the template to state the re-release year, platform etc. The information of primary importance is the initial release and that is getting diluted and confused by the re-release info. - X201 (talk) 08:20, 1 June 2010 (UTC)[reply]

{{Editprotected}} Please add the following new lines:

• Predecessor
• Successor
• Tagline

/Heymid (talk) 23:18, 18 June 2010 (UTC)[reply]

I think tagline is unnecessary. Pred and Suc might be useful. However, to make a full edit request, you need to show the changes necessary in the template (per the editprotected template's instructions; you also need to show consensus for the changes). I disabled the EP until someone (you?) has done so. --Izno (talk) 01:41, 19 June 2010 (UTC)[reply]

Let me try:

Add the following new lines at the bottom of the code:

• |{{#if:{{{predecessor|}}}| {{!}} '''Predecessor''' <nowiki>{{!!}} {{{predecessor|}}} }}
• |{{#if:{{{successor|}}}| {{!}} '''Successor''' {{!!}} {{{successor|}}} }}
• |{{#if:{{{tagline}}}| {{!}} '''Tagline''' {{!!}} {{{tagline|}}} }}

/Heymid (talk) 08:56, 19 June 2010 (UTC)[reply]

There's been some past discussion on this

1, 2, 3, 4, 5 and 6

I don't think there's been any change in consensus on this issue from these last discussions, but if you want to properly try, I'd recommend starting a thread at WP:VG. -- Sabre (talk) 13:10, 19 June 2010 (UTC)[reply]

I've deactivated the request again. Heymid: if you'd like to proceed with this, please take up the invitation to discuss it. — Martin (MSGJ · talk) 18:40, 19 June 2010 (UTC)[reply]

There are no use guidelines for the Platform section of the template. On the video game project talk page, I was having a discussion regarding which (if any) ports go on the platform section, and was told that standard use prefers ports to be presented in prose, rather than in the infobox. I do, however, see the usefulness of an exhaustive port list in the info box, rather than searching the article, which may not have enough info on a particular port for inclusion. Therefore, I propose the following: The Platform section should refer to the platform the game was first designed for, or the platforms, if done so contemporaneously. Later ports should have a new section in the infobox called "ports". The Ports section should be collapsible, and collapsed by default. Each port should be listed, and linked if appropriate. The entire section should be optional. This would keep the infobox tidy, but convey important info at a glance. In any case, there should be usage guidelines for the platform section on the template's page. What say you? - superβεεcat  21:25, 1 July 2010 (UTC)[reply]

Okay, the discussion down has been going for a while now. I'll add a request to update the template with the changes that are basically agreed upon.

• removal of aspect ratio
• removal of engine
• removal of input method
• removal of license
• removal of resolution
• small image captions

If people recognize these changes and disagree, they can still raise their voice here. The fields that are still under discussion are media, modes, series, and system requirements. Prime Blue (talk) 19:40, 14 August 2010 (UTC)[reply]

Edit request

{{editprotected}} As mentioned right above. I prepared the code in the sandbox, simply copy all that over to Template:Infobox video game. I'll update the documentation afterwards. Prime Blue (talk) 19:40, 14 August 2010 (UTC)[reply]

 Done — Martin (MSGJ · talk) 20:55, 14 August 2010 (UTC)[reply]

Thank you, updating the documentation now. Prime Blue (talk) 21:35, 14 August 2010 (UTC)[reply]

Notability-based restrictions for infobox credits?

I checked up on the VG infobox guidelines after I was notified of the criteria for including developers and think the current guidelines might be more counterproductive than helpful: As long as the infoboxes do not just turn into some really long credits lists, I see no reason for restricting the inclusion of key personnel down to their notability. The film infoboxes and the featured articles they are used in seem to be fine even though non-notable people are included (not to mention how only a handful of game professionals meet the current notability guidelines, though that is to go somewhere else). And not allowing the latter opens up a whole new can of worms as well: What about games where certain fields are filled by several people, some of them notable, some of them non-notable? Having to drop some credits and rendering the attribution incomplete and/or faulty seems much worse than not having the fields in the first place. Personally, I would find a discussion about the importance of certain fields in the infobox much more helpful. Prime Blue (talk) 23:05, 14 July 2010 (UTC)[reply]

I'll just provide a starting point to keep the discussion rolling:

• "Publisher": This field almost feels like it has gotten out of hand in some articles. I guess it might be more reasonable to just list the publishers in the infobox, and then to include the individual versions they published in the article text: "The game received several ports later, among them an XXX version published by XXX, and [...]"
• "Programmer": While games might have had only a single programmer twenty years ago (see Final Fantasy II or Final Fantasy III), this field is pretty useless nowadays where that individual part of the development team will often comprise dozens of people.
• "Artist": I think this field should be elaborated on. What exactly does a game artist do? Is it the character designer, or the person drawing concept art and the like?

Prime Blue (talk) 11:33, 18 July 2010 (UTC)[reply]

Ok, lets have a lookie:

• The idea of limiting it to people who meet our notability standards was the compromise for those who didn't want the fields to be included, or feared that the infoboxes would become credits lists. I still hold that that is a good idea, it allows for better context and for readers to find out more about a particular person as we usually have an article for them if they are notable. A list of names of no note with no links really doesn't do a lot for readers.
• The fields are meant to have the lead person in a particular area of development (lead designer, game director, etc), not everyone who was involved. Usually this is only one person. In the event that it is two or, even more rarely, three in such a position, and one is not notable, I tend to run that its prudent to include the non-notable one as it otherwise misattributes the lead development work to the notable ones alone. Case in point: the design of Sam & Max Save the World was led by three people: Steve Purcell, Dave Grossman and Brendan Q. Ferguson. Ferguson isn't notable, but the development sources show he was just as involved as the other two in this area, and we discuss him at various points in the article, so he should be listed to reflect that the game's design wasn't led by only Purcell and Grossman.
• The programmer field is indeed more useful for older games than newer ones. A lot of new games don't have a lead programmer, and those that do are rarely notable, so this field isn't really needed for new games. But our coverage is also historical, and its a very useful field for big names in games from previous decades. Take John Carmack, much of his work can't be listed as designer, director, etc, yet he is intimately involved in the direction of a lot of games' production. Having the programmer field for the games from the 1980s and 1990s happily solves that problem.
• The artist field, like the others, means the lead artist, the chief honcho, the person responsible for defining the art direction for the entire game. That person will probably have done concept art and character design, but their overall goal is to make everything consistent with the chosen artistic direction.

-- Sabre (talk) 12:42, 18 July 2010 (UTC)[reply]

I've researched a bit, and it seems to me like the old discussion (and the consensus it yielded) was almost solely based on the assumption that non-notable people should not be mentioned, which goes directly against several established guidelines:

• WP:NNC says the only case where non-notable people are to be excluded are in stand-alone lists where editors agreed on limiting the article in question to notable people. Mentions of non-notable people in regular articles are governed by due weight and other content policies.
• WP:NLIST affirms the above and says that inclusion of people in lists contained within articles should be determined by...
• WP:Source list, which in turn points to three of the content policies again, their criteria easily fulfilled.

Thus, mentions of people in article infoboxes must not be based on their notability: The only real discussion to be had here is if the infobox should include credits or if it should not (and, if the credits are kept, which fields are reasonable and which are not).

As to your elaborations on the fields:

• My experience has shown that the designer and director fields will often be populated by two to three people for modern games. I guess that in the majority of cases, the development process will not have been covered significantly enough to determine which of the directors/designers were responsible for what part of the game.
• I underestimated the amount of classic video games where the programmer field would be utilized, so I'll gladly take that concern back.
• Hmm...for the articles I recently edited, there often were individual character designers and conceptual artists/artwork creators. Might be just a Japanese thing, though. In any case, it would be nice to know what to go with then.

Two additional proposals for the template documentation:

• Do not include directors and producers of simple ports (it would clutter up things unnecessarily).
• Have separate infoboxes for remakes if they are significantly covered in their own section of an article (just makes things tidier).

Prime Blue (talk) 17:08, 18 July 2010 (UTC)[reply]

Artist was added because of issues raised when we had so few items when Dragon Quest went up to a FAC. Not mentioning Akira Toriyama in the infobox would have violated WP:NLIST and WP:UNDUE because the series has been largely a creative team. There was no place to add him nor Koichi Sugiyama because there weren't enough fields. If we do remove any fields, we should add the ability to add custom ones.

The problem with remakes being always in a seperate infobox comes also as an example with DQ main article. Main series articles have only one infobox, but it is relevant to list the remake designers/publishers if they are different.陣内_Jinnai 21:12, 18 July 2010 (UTC)[reply]

It's nice to know the origin, but with whom should we go if the tasks are done by separate people? The concept artists or the character designers?

Concerning the infoboxes: I'd rather have two tidy ones (if there is a good place for the remake one to go) than a single confusing one. At least I could not find anything that suggested only one infobox should be used per article. It just seems right for remakes that had so many things changed they are basically new games (like Final Fantasy III and Resident Evil, even though the section for the latter one is rather lackluster). Prime Blue (talk) 20:46, 19 July 2010 (UTC)[reply]

The concept artist and character designer are both artists, so the generic term of "artist" can apply here. The prose can distinguish what their actual roles are陣内_Jinnai 01:14, 21 July 2010 (UTC)[reply]

I'll just say that all of these fields should be replaced by dynamically inclusive wildcard fields that can be tailored to who would indeed be notable for each particular game. In a music video game like Guitar Hero and Dance Dance Revolution a music group or "sound producer" would be notable while in a game like IDOLM@STER voice actresses would be notable. Setup the infobox to accept several customisable fields that any title can be entered into instead of static PRODUCER and DIRECTOR tags. And then have each entry support itself when it comes to notability on a case by case basis.  æronphonehome  17:08, 20 July 2010 (UTC)[reply]

Sorry, I think this is just piling more unneeded items into a more-and-more unwieldy item. While I appreciate the sense to present equality and fairness to the roles of those involved in making the game, I feel it is not conducive to make up listings that will further intrude into the article, pushing text to the left and images further down. I dare say that several Infoboxes (not just the video game articles) are taking up at least 1/2 of the article height on the growing numbers of large displays, presenting an unsightly mess.

I had lots to rant, but on re-examining what I had typed, I shall simply say I am beginning to agree with several points in the WP:DISINFOBOX essay. We should concentrate on fleshing out the text and content, which should be the main focus of all articles. If an Infobox ends up having more information than the article text itself or taking up 50% of the total editing (and discussion) time for that article, there is something way wrong about that. Instead of asking for more entries, the Infobox should start looking for less fields; it should present items to support the article than to rob attention from it. Jappalang (talk) 21:20, 20 July 2010 (UTC)[reply]

Not in favor of more or custom fields here either, though I must admit that I have yet to come across a reasonably long article (so, disregarding stubs and unreleased games) where the length of the infobox gets in the way, let alone where the credits provided in them are responsible. I guess Ocarina of Time might be the absolute maximum credits-wise, and I still consider that one somewhat unintrusive. Prime Blue (talk) 01:16, 21 July 2010 (UTC)[reply]

Offhand, I'm not in favor of expanding the number of fields. But as far as unwieldy/lengthy crediting of teams, or issues with games that have a slew of releases, I suggest we adopt the collapsible model (a la release date), where the primary release date is always visible and you can click to show the dates of subsequent releases. Final Fantasy (video game) is a good example; make NES the primary release platform, since it was the original platform, and put all the others into a collapsible area. We want the most important, most relevant info always visible, and any other meaningful but clearly secondary info in that category can be in a collapsible area (e.g. original release date/publisher/platform/media vs. subsequent release dates/publishers/platforms, lead/headlining composer vs. supporting composers, lead designer vs. assistant designers, etc.). My suggestion is to keep standards the same, except employ more collapsible areas. - Liontamer (talk) 05:25, 21 July 2010 (UTC)[reply]

I have notified those who formed the original consensus and linked to this discussion on the talk page of WP:VG, and a good week has passed without any objections or counterarguments to the issues I've raised. I guess it is okay to move boldly forward and remove that notability restriction for the fields from Template:Infobox video game/doc, Template:Infobox video game/doc/syntax guide and Wikipedia:WikiProject Video games/Templates#Infobox. Prime Blue (talk) 19:47, 27 July 2010 (UTC)[reply]

I have been following this discussion with interest. For Sid Meier's Alpha Centauri, I have two infoboxes. If you look at the References (Reynolds and Train), you will see that the game has 5 designers (3 notable) and the expansion has 7 designers (3 notable). Originally, I had listed them all, but then saw the notability requirement and pared them back to the notables. I thought this discussion would allow me to list them all (which I think is more accurate than selectively listing only a few, particularly when the lead designer on the expansion is non-notable). However, this sentence put in by Prime Blue is puzzling: "However, their inclusion should be carefully measured not to make the infobox overly long." Could someone please elaborate on the factors to be considered to be "carefully measured"? Thank you. Vyeh (talk) 19:23, 28 July 2010 (UTC)[reply]

Ah, I put that sentence in to address the concerns of the original discussion. Basically, it means editors should be careful not to turn the infobox into a giant credits list (say, list ten artists with their different tasks, or how Fragile Dreams: Farewell Ruins of the Moon actually has a good 20 writers who worked on the short stories included in the game but it would be insane to list them all). If you have an idea on how to word this better, feel free to change it. :-) Prime Blue (talk) 14:46, 29 July 2010 (UTC)[reply]

Break

Actually, if the issue is space, I am more in favor of trimming fields in the infobox than inserting collapsible lists. Maybe it's just me, but I don't like collapsible lists as I think the additional click to see the information is kind of annoying. Just my two cents and an example infobox on the right:

• Developer: I know this is important information, but if we want more space, I think this field should be removed. The developer is always mentioned in the lead as far as I know, unlike publishers and secondary/regional publishers. If there are multiple versions of the game, the developers are also always mentioned in the lead. So is the Developer field in the infobox really necessary?
• Series: as with the developer, I think this information is redundant with the lead.
• Aspect ratio: isn't this redundant with "Resolution"? Even if it's not, can both fields be merged?
• Engine: not essential for an infobox. I doubt the engine is among the first things the average reader wants to know about a particular game. The "Development" section should be enough.
• Version: isn't this the same thing as "Latest release"?
• Genre: again, redundant with the lead.
• Mode: again, redundant with the lead.
• Media: is this really necessary? If the game is a cartridge-based game, this field is totally unnecessary and redundant with the "Platform" field. I think this field should only be used for disc-based games and computer games.
• Input methods: Not essential for an infobox. The input methods should be obvious from the "Gameplay" section.

If we remove all the useless stuff, I think there will be more room to focus on the personnel and the release dates. Jonathan Hardin' (talk) 13:26, 21 July 2010 (UTC)[reply]

I dont think you should get rid of developer. Regardless of it being mentioned in the lead its still a key part, and an infobox is there to list all key parts of an article. It would be like getting rid of the director from a film infobox. Salavat (talk) 14:53, 21 July 2010 (UTC)[reply]

Personally, I think the VG infoboxes should provide the "key facts" on a game (disregarding if the information is repeated in the article), though – as evidenced by putting the term in quotation marks – the importance of fields is highly subjective and will vary greatly between readers. That said, I qualify "Developer(s)" and "Genre(s)" as such "key facts" and think they should stay. I support the removal of the following fields mentioned by Jonathan Hardin':

• Series: self-explanatory for almost all articles, others like Final Fantasy Adventure only throw up problems on categorizing.
• Aspect ratio: either 4:3 or 16:9 (though Ikaruga could perhaps be classified as something different). If this has some effect on the gameplay or was an important design decision (as in Resident Evil 4), it should go in the development section.
• Mode(s): Should be explained in greater detail in the gameplay section.
• Media: The "Platform(s)" field might suffice to determine which media the game is published on.
• Input methods: Mostly just controllers or the respective handheld console. If it is something different (e.g. Wii Fit), it should go in the gameplay section.

Fields mentioned by Jonathan Hardin' I think should stay but be restricted in its use:

• Engine: While I personally do not care for this much, I think it might be very important for some PC gamers visiting Wikipedia to look up a game engine quickly. However, I think this field should only be used for engines that have received a title from its developers (and, probably, are available to other developers?).
• Version: Will not be used for console games anyway. But I think that, again, it might be important for PC gamers wanting to look up the newest patch for a game (where there is already a plethora of them available).
• Native resolution: Should always have a reference. I've seen some console games use this field with the wrong resolution.

By the way...if fields are removed from the template, will it create a massive amount of work? Or will the unused ones simply not show up anymore and can be removed by bots? Prime Blue (talk) 21:13, 21 July 2010 (UTC)[reply]

Not show up. Followed by bot tidy-up if necessary or just let nature take its course and they'll get removed over time. - X201 (talk) 21:40, 21 July 2010 (UTC)[reply]

Ah, I see. Thank you! Prime Blue (talk) 19:47, 27 July 2010 (UTC)[reply]

I'd like to propose that the Native Resolution field gets the bullet. To obtain citable information on the "Rendering resolution" of a game engine is nigh on impossible for the vast majority of games, and the only ones that do have info available are the big titles that are multi-platform and even then its from a minority of sources (usually Digital Foundry and Toms Hardware) that do pixel counting and other analysis on the games. Even with citations from these two trustworthy sources the Resolution field is still the site for regular fan boy battles. Resolution is yet another field that should be mentioned in prose if its so important - although I have never seen it mentioned in the prose section of an article. - X201 (talk) 21:39, 21 July 2010 (UTC)[reply]

• Developer: The developer is an essential aspect akin to the director or author and should always be on there.
• License: Generally not so important, especially when compared to some other info. Akin to usefulness of distributor.
• Series: Essential aspect like author, director. You always note if the title is part of a larger work.
• Engine: Unessasary
• Aspect Ratio: Trivial and unessential.
• Native Resolution: Trivial and can be merged with System requirements (native is almost always=minimum)
• Version: Possibly useful in some instances. Rename and link: Newest Version.
• Previous release: should be removed. The only releases that really need to be noted are intial and perhaps latest.
• Genres: Should stay as they are in other infoboxes. The genres should have RSes backing them up though.
• Modes: trivial and unessential.
• Media: Merge with System requirements.
• Input method: the few exceptions from non-standard inputs can be noted elsewhere.陣内_Jinnai 21:37, 21 July 2010 (UTC)[reply]

Assessment

This has been up for a while so rather than let this die with the status quo I think we should start where there is common agreement:

• Developer - an essential item, even if its redundant.
• Publisher - ditto
• Distributor - ditto
• [Key People] - that's why we're having this discussion....
• Engine - seems to be general agreement that this isn't needed, though Prime Blue seems more neutral.
• Aspect Ratio - General Agreement that this should be removed.
• Native Resolution - Nothing clear here, but imo given that this needs citation and its relevance as "essential" is doubtful, it should be removed.
• License - no consensus
• Series - an essential item.
• Platform - keep as essential.
• Version - since its not the same as "last release" it should be kept and linked to Newest Version or merge with Previous/Last Release.
• Genre - should stay as essential (but documentation should be cited to clarify genres require RSes backing them up although it can be in the body).
• Modes: given the recent unrelated comments on info in the body for modes being generally unimportant, I would say that given arguments here that it should be removed.
• Ratings - keeping
• Release dates - obvious essential
• First/Previous release: should be removed. The only releases that really need to be noted are intial and perhaps latest. If version is kept, these should probably be removed.
• Media - there is consensus to merge this, just not where to.
• System requirements - no requests to remove.
• Input method - agreement to remove/merge this one too.

It looks like there are at least 5 fields that can be merged/removed which is about the same number added to list the major contributors. Possibly more. The issues with remakes and multiple infoboxes might be moot if we can find a way to trim this down further.陣内_Jinnai 03:17, 3 August 2010 (UTC)[reply]

I am in general agreement and agree this is better than the status quo. Vyeh (talk) 09:42, 3 August 2010 (UTC)[reply]

Although nice effort has been made to summarize this up, the individual fields should be considered individually, with enough editors commenting each. I wanted to comment on per-field basis, but had no idea how to reply to existing arguments without making another list of my own. But most editors are thrown off by lengthy debates; so, as should have been done initially, I sub-sectioned the fields under review below for convenience. It would be appreciated if the editors could place their !votes on per-field basis below (even if you just copy what you already said). Then clear per-field consensus can be reached and proper closure done. —  HELLKNOWZ  ▎TALK 10:18, 5 August 2010 (UTC)[reply]

Kudos to Jinnai and H3llkn0wz for taking the initiative here. This discussion is long overdue. Prime Blue (talk) 17:11, 6 August 2010 (UTC)[reply]

Seconded. Has been needed for ages. Well done for giving the template the kick up the backside that it needed. - X201 (talk) 17:21, 6 August 2010 (UTC)[reply]

Individual field discussion

"Aspect ratio" field

Resolved

"Developer" field

Resolved

"Engine" field

Resolved

"Genre" field

Resolved

"Input method" field

Resolved

"License" field

Resolved

"Resolution" field

Resolved

"Media" field

• Week Remove. This does not seem very important. This separates digital/physical, what cartidge/optical disk/etc. was used. But this is prose material, if significant at all. —  HELLKNOWZ  ▎TALK 10:18, 5 August 2010 (UTC)[reply]
  • After a look around some games, I see this is over-abused and unnecessary. Apparently, the medium of Travian is "text and images". If it's not clear to editors, it will most certainly not be clear to readers, what this "media" really is. —  HELLKNOWZ  ▎TALK 15:07, 5 August 2010 (UTC)[reply]
• Remove. Vyeh (talk) 12:53, 5 August 2010 (UTC)[reply]
• Weak Remove Usually covered by the release date in a round-about way. Games are listed as PC/Xbox/PS3 (so they must be physical media) PSN/XBLA/Download (Download) That then negates the need for a Media field - X201 (talk) 13:13, 5 August 2010 (UTC)[reply]

• Willing to go with the Limit option. - X201 (talk) 19:33, 7 August 2010 (UTC)[reply]

• Remove. Its the except that once the platform is mentioned that the media type cannot be figured out. The rare cases where it is not obvious can be described in the body. --MASEM (t) 14:25, 5 August 2010 (UTC)[reply]
• Remove. If you know the platform, chances are you know the media. If the choice of media is significant, that can be mentioned in prose. Reach Out to the Truth 15:06, 5 August 2010 (UTC)[reply]
• Limit by syntax to: cartridge, disc & download. It is still essential info in understanding games in many instances, especially as more content on consoles becomes download only.陣内_Jinnai 21:36, 5 August 2010 (UTC)[reply]
• Weak keep; there's little benefit for typical off-the-shelf games, but I'm skeptical about any other way to convey a digitally distributed game quickly and efficiently. Relying on that information being in the release date field as X201 suggests doesn't quite cut it for me. -- Sabre (talk) 21:57, 5 August 2010 (UTC)[reply]
• Remove Weak remove. Explained above. Salavat raises a good point, though. If kept, I'd like this to be restricted to games where the platform leaves the distribution method ambiguous (e.g. "Windows"). Prime Blue (talk) 13:35, 6 August 2010 (UTC)[reply]
• Keep, as Sabre said for digitally distributed games its quick and efficient. Take a Windows game for example, it makes it a quick solution to look to the media section to see if it was released on a CD or as a download. Also consoles are also becoming multi-pathed, eg PlayStation 3 and PlayStation Network. Salavat (talk) 14:53, 6 August 2010 (UTC)[reply]
  • Can we limit it to preset values? Such as "cartridge", "download", "CD", "DVD", etc.?—  HELLKNOWZ  ▎TALK 15:06, 6 August 2010 (UTC)[reply]
    • Or even to "cartridge", "download", and "disc", maybe? Salavat (talk) 15:25, 6 August 2010 (UTC)[reply]
      • Realistic example: should MDK now be listed as a digital download since you can get it off a couple different services even though at the time of its release it was a retail product?
      • That said, this might prompt a new field, I don't know how to name it, but it would be something that includes targets of "Retail", "Digital Sale", "Freeware", "Shareware", etc. to explain the nature of the game's physicality or the like. --MASEM (t) 15:51, 6 August 2010 (UTC)[reply]
        • As mentioned above, we can limit it to basically 3: Cartidge, Disc, Download. Maybe we could divide disc into floppy and optical, but that's all. The only exceptions to this would be stand-alone games like Game & Watch or arcade games.

          Masem: That is what license field should do. If we have that we should retool it to reflect that.陣内_Jinnai 18:42, 6 August 2010 (UTC)[reply]

• Keep, per Sabre's rationale. While we don't need to delve into deep specifics, I've found it useful and better than sandwiching it in somewhere else where it won't fit. Der Wohltemperierte Fuchs^(talk) 16:56, 7 August 2010 (UTC)[reply]
• Keep, while PCs and consoles are making increasing use of downloads, it's the older systems that I think this field is important for. For example, MSX games could have been available on cassette, floppy disk, cartridge, or a combination of the above, and most home computers at the time (I'm thinking ZX Spectrum, Commodore 64, MSX, Amstrad CPC, BBC Micro) had more than one media each on which games were commonly available. Some PC games were available on either 5.25" or 3.5" floppy disc, and later when CD first took off it wasn't uncommon to see the same title available on both floppy disc and CD. Miremare 23:23, 7 August 2010 (UTC)[reply]

Proposal (Media)

Okay, since "download" is not really a type of media, I will make a suggestion for changing this field to "Distribution", and to limit its usage to articles where at least one platform's distribution method is not clear (e.g. "Windows"). The only two values possible for the field are "digital" and "physical". See example 1 and example 2.

Everything beyond that, like the MSX example, are niche cases and can be mentioned in prose if it is substantial information (for example, The Secret of Monkey Island mentions the floppy and CD versions in the article). Any objections? Prime Blue (talk) 16:15, 17 August 2010 (UTC)[reply]

Well, I'd say that renaming to distibution is fine, but limiting it to those to scopes is too much. Using MS Windows is as your example is not good because it being an OS can only ever be done like that. Their is no option like cloud-computing (something more software is now using), which isn't really download in the traditional sense people denote downloading with and defiantly not physical and as its increasing definitely not niche. Then you have to remember Windows was never meant for a console system. Xbox doesn't use Windows. Finally there is a major difference between disc and cartridge-based games: the former can add things into the cartidge like ability to save games (requires separate piece of hardware with discs) or extra components to enhance gameplay beyond the console's normal ability. When you're talking about Windows, an OS, that's not a concern.陣内_Jinnai 22:28, 17 August 2010 (UTC)[reply]

If cloud computing is not as niche as I assume it to be currently, we can add that as a third option. But keeping the media field just for the difference between cartridges, discs, etc. is not reasonable as that will still be obvious with the consoles mentioned in the platform field, and the deeper-down stuff can still be included in the article if deemed important. Additionally, the save feature is not a cartridge/disc-based issue (see all Nintendo 64 games requiring a Memory Card), and I've even seen the system requirements describing what exactly is needed to save a game (number of blocks etc.). While I still feel the "distribution" field would be superfluous for the "obvious" platforms, I am willing to give up that restriction. Prime Blue (talk) 00:03, 18 August 2010 (UTC)[reply]

For modern systems, there is generally one type of physcial media, either discs or catridges. However older consoles had both. Several even used floppy discs, which are arguably different enough than digital ones to warrant their own seperate distinction as it is an essential difference for PCs. For dealing with consoles though, those were mostly add-on devices, but they are generally merged into the main article, the exception being the Sega CD, which looking at the article probably could be. Noting thse distinctions helps give the reader essential information about the game simply by its physical media.

I do realize this does have some overlap with system requirements, but I think that section could be dissolved and merged into this and other parts if we allow for slightly narrower classifications.陣内_Jinnai 00:22, 20 August 2010 (UTC)[reply]

We can add the "distribution" field then (always used) and restrict the "media" field to games on these old platforms with the only options being "Floppy disk", "Cartridge", and "Optical disc" (and combinations thereof). This will even cover the media of old games that got ported to newer platforms, while at the same time preventing people from delving into trivia-esque specifics like cartridge types and sizes. Prime Blue (talk) 01:39, 20 August 2010 (UTC)[reply]

"Modes" field

• Remove as trivia that should be placed in lead (introducing mode, like "single-player" or "co-op") and gameplay (expanding, like "up to 4-player co-op"). No need for infobox entry. —  HELLKNOWZ  ▎TALK 10:18, 5 August 2010 (UTC)[reply]
  • Limit to strict pre-defined usage. This includes "single-player", "multiplayer", or "single-player/multiplayer". If this is not satisfactory for some special cases, then the field can be left blank and the mode explained in prose. After all, infobox is to provide clear categorization for things like these. Unless there is a very good reason for including more values, we should stick to minimum necessary. —  HELLKNOWZ  ▎TALK 21:54, 6 August 2010 (UTC)[reply]
• Remove. Vyeh (talk) 12:53, 5 August 2010 (UTC)[reply]
• Keep but restrict to some set values. I think it is important to establish "single player" "multiplayer", and a few other terms in the infobox (again, that's at-a-glance); it shouldn't list out unique modes or the like though.
  • Many games have multiple modes, even "at a glance", like, Starcraft. I guess hard-coded values can work if defined properly. The current problem is that there are too many various values editors place there. How many are there besides the obvious "single-player", "multi-player", "co-op", and combinations, such as, "single-player/multiplayer"? For instance, MMO, which seems to be treated differently than multiplayer. —  HELLKNOWZ  ▎TALK 15:03, 5 August 2010 (UTC)[reply]
    • Basically, I see 5 basic definitions for mode: Single Player, and Multiplayer that is either/any of "co-op", "competitive", "local", "online". Nothing else. There may be many different types of competitive modes (ala MW2 for example), but we don't need to spell out exactly the details the number of players or anything else. Local would include same console/unit and same LAN (but not WAN). --MASEM (t) 15:06, 5 August 2010 (UTC)[reply]
      • May be even that is too much. How about simply "single-player", "multiplayer", and "single-player/multiplayer". Multiplayer includes co-op, competitive, local, etc., explained in prose. Though I can see users shouting multi-player isn't co-op on talk pages already :) —  HELLKNOWZ  ▎TALK 15:18, 5 August 2010 (UTC)[reply]
        • Well, if we want to reduce it further, I would say there are then only 3 necessary fields that quickly assert the nature of the game: single player, multiplayer-local, and multiplayer-online. I think it is important to quickly clarify games that can be played with others remotely. The Co-op vs Competitive can be described in the article, but that's still a possibility to add. --MASEM (t) 15:32, 5 August 2010 (UTC)[reply]
          • I would add a fourth one - multiplayer-other. I can think of at least one type that doesn't fit one of those 3 categories: games that were designed for players to take their turns compile a savegame and send it to someone else via email. There weren't too many like this, but they aren't local multiplayer, nor online multiplayer (as generally defined) and since they played competitively with other players its not single player.陣内_Jinnai 21:01, 5 August 2010 (UTC)[reply]
• Keep, limiting only to single-player and multiplayer as field options. Those two options cover all that is needed. -- Sabre (talk) 21:57, 5 August 2010 (UTC)[reply]
  • What about "single-player + multiplayer" then. Surely Worms Armageddon or OpenTTD are both multiplayer and single-player, depending on who you ask. —  HELLKNOWZ  ▎TALK 22:04, 5 August 2010 (UTC)[reply]
• Remove. Explained above Prime Blue (talk) 13:35, 6 August 2010 (UTC)[reply]
• Remove or rename not clear what this is supposed to be. If it is about players then make the field about players and restrict it to a few options. (Single Player / Multiplayer / Both). Shooterwalker (talk) 14:40, 6 August 2010 (UTC)[reply]

Proposal (Modes)

I still feel it's redundant, but oh well... Keep the field, and limit the values to "Single-player", "Multiplayer", and "Single-player, multiplayer". Covers every case, anything beyond that goes to prose. Prime Blue (talk) 00:37, 18 August 2010 (UTC)[reply]

Should be done via syntax and it should be allowed for both then for games with both types of gameplay.陣内_Jinnai 17:18, 18 August 2010 (UTC)[reply]

Just forgot to add that. Could you explain what you mean by syntax, though? Prime Blue (talk) 17:24, 18 August 2010 (UTC)[reply]

Basically if "single-player" (or a common alternative like singleplayer or SP) or ditto for "multiplayer" is not input, nothing is displayed. If those are the only alternatives we wamt, we should code those in. The code should allow for both to be displayed though and a decent way to separate them.陣内_Jinnai 00:27, 20 August 2010 (UTC)[reply]

"Series" field

• Keep, notable enough to be part of infobox. Granted, this is always in prose, but so is the title. —  HELLKNOWZ  ▎TALK 10:18, 5 August 2010 (UTC)[reply]
• Keep. Vyeh (talk) 12:53, 5 August 2010 (UTC)[reply]
• Keep, same reason as Hellknowz. - X201 (talk) 13:17, 5 August 2010 (UTC)[reply]
• Keep, absolutely necessary. --MASEM (t) 14:25, 5 August 2010 (UTC)[reply]
• Keep Chimpanzee - User | Talk | Contribs 18:18, 5 August 2010 (UTC)[reply]
• Remove. I'm going to dissent on this one. This one's position in the infobox order doesn't make it that obvious, unlike definitely essential info like developer. The series is usually referred to and linked to within the first two sentences of an article. It just feels redundant in my mind. -- Sabre (talk) 21:57, 5 August 2010 (UTC)[reply]
  • Not disagreeing, but I would like to know if anyone can think of any examples where the "series" is not relatively obvious by the simple naming of the game. I could argue Band Hero and DJ Hero, part of the Guitar Hero series, aren't intuitive, but that's a weak example. --MASEM (t) 22:00, 5 August 2010 (UTC)[reply]
    • Just to go devil's advocate against my own argument, Portal comes to mind, it being part of the Half-Life series. -- Sabre (talk) 23:11, 5 August 2010 (UTC)[reply]
      • I see, so perhaps series is not the correct tag for every case. I assumed Half-Life 1,2,e1,e2 was Half-Life series, TF,TF2 is TF series and Portal would be Portal series when P2 comes out. Perhaps we need 2 exclusive fields - "series" and "franchise", and allow only one, franchise being priority. This would solve any ambiguity, but restrict editors to one well-defined field.—  HELLKNOWZ  ▎TALK 08:25, 6 August 2010 (UTC)[reply]
        • Perhaps we need to be stricter in this use; I'd certainly rather only see "Franchise" listed there, and only include games that have a franchise, rather than people saying "Oh there's a sequel, therefore it's a series!". And moreso only in cases where the title of the case does not make it explicitly obvious (Band Hero as a GH title, or Portal as a HL title for example); "Final Fantasy XIII" does not need to be stated to be part of the Final Fantasy franchise by definition. --MASEM (t) 13:45, 6 August 2010 (UTC)[reply]
          • I still find this is the most redundant and at the same time the most problematic field. In the one case (the overwhelming majority of game articles), the game title alone will suffice to determine the series, thus making the field completely redundant (this is the case for numbered entries, like Resident Evil 2 or Final Fantasy IV, where it is obvious that they are part of the Resident Evil and the Final Fantasy series respectively). In the other case, a game is too ambiguous to place in just one series. Final Fantasy Adventure leans more towards being part of the Mana series, but it's a spin-off from Final Fantasy and still contains elements of it. Super Mario World 2: Yoshi's Island is even worse. Or Donkey Kong. Is Resident Evil: Dead Aim part of the Resident Evil series, or more accurately part of the Gun Survivor subseries? The series field is more problematic than helpful in these cases. And a franchise field avoids the subseries issue, but I still think it is redundant as per the game titles itself. Prime Blue (talk) 16:50, 6 August 2010 (UTC)[reply]
            • If you looked at the title of Dragon Warrior it would not be obvious to the average reader who did not know of the series that Dragon Warrior is part of a series named Dragon Quest, without substantial reading in the article. In addition, it would not be obvious for 95% of the Megami Tensei titles that they are connected to the average reader. Indeed some of the remakes remove the Shin Megami Tensei grouping from the artwork in order to emphasize the sub-francize. This is particularly true with the Persona games. Finally, as a last major example, there is the Tales or Tales of series. While they all start with the same name, for someone not familiar with this naming convention, they wouldn't realize there was an overarching franchise as very few of the games are numbered and because it is common litterary convention to begin many stories, especially adventures or epics, with the phrase "Tales of..." or something very similar, such as A Tale of Two Cities.陣内_Jinnai 18:55, 6 August 2010 (UTC)[reply]
              • But those Megami Tensei remakes that drop the series title do not seem to have their own articles, do they (I am not familiar with the series)? The only games I see this happen with are in the Persona series, and that falls in the subseries issue (Persona 2 mentions both series). And I have to say that I think the Tales of games are obvious in their naming, too. The only potential problem could arise with Dragon Warrior, but I find a whole template field for these few niche cases a bit overblown. :/ Prime Blue (talk) 19:31, 6 August 2010 (UTC)[reply]
                • As stand alones, no, just the remakes and the anime. We have yet to see what Atlus does with their next Persona title though. Other than it being in production, there hasn't been much news.

                  Tales of series is obvious to you because your familiar that it is a series. You have a biased perspective. This has to be from someone who knows nothing of the series, ie the most we can assume is that the person has heard of that title and thus those from the tales series would not register to newbies. Indeed, when I first played Tales of Destiny years ago I did not realize it was part of a series.陣内_Jinnai 21:54, 6 August 2010 (UTC)[reply]

                  • I still don't think it is that important, but I guess I'll give in here if the others feel just as strongly about keeping it. :-) Prime Blue (talk) 16:20, 7 August 2010 (UTC)[reply]
                    • We would be alone in all the major media infoboxes that do not have a series grouping, or equivalent thereof, in our infobox meaning I do not think the wider body of wikipedia would condone this removal if it was brought to them, especially for cases I brought above.陣内_Jinnai 21:25, 8 August 2010 (UTC)[reply]
• Remove. Explained above Prime Blue (talk) 13:35, 6 August 2010 (UTC)[reply]
• Remove. Sabre's right: any good video game article should make it clear what the series is in the first sentences, if not the first paragraph. Der Wohltemperierte Fuchs^(talk) 17:00, 7 August 2010 (UTC)[reply]
  • That isn't a justifiable reason for exclusion as the first sentance also has the title and by your logic we shouldn't include the title because the first sentance will have that.陣内_Jinnai 21:21, 8 August 2010 (UTC)[reply]

Proposal (Series)

How about we limit that field as well? Only use it for games where the series is not apparent (like the ones Jinnai mentioned above), and drop it for the obvious (like Resident Evil 4) and ambiguous/problematic (like Final Fantasy Adventure) cases. That should take care of anyone's concerns. Prime Blue (talk) 16:23, 17 August 2010 (UTC)[reply]

Maybe, although in the examples above, I'd also say if its necessary for 1 entry, then it should be in all related entries for that series. Thus Dragon Warrior would denote that it is part of the Dragon Quest series, but for consistency across the media, so would Dragon Quest IV: Chapters of the Chosen.陣内_Jinnai 22:17, 17 August 2010 (UTC)[reply]

That seems a bit overkill. After all, it is still not needed for these articles – the purpose of keeping the series field was explained in this discussion to be able to mark games which would otherwise not be recognized as part of a series. Prime Blue (talk) 00:14, 18 August 2010 (UTC)[reply]

I think the most simple choice is to either use this field for all series entries or not to use it at all (and thus remove it from the template). Using it only for some series entries and not others will only lead to confusion as Jinnai pointed out. We should either use it all for series entries (for clarity) or remove it from the template (on the basis that the prose is enough). Jonathan Hardin' (talk) 12:10, 18 August 2010 (UTC)[reply]

The problem with "always use the series field" or "remove the series field" is that both of these solutions would ignore the redundancy concerns of the "remove" proponents, as well as the confusion concerns of the "keep" proponents. Limiting the field in its usage just seemed like the logical middle way to address everyone's concerns. Prime Blue (talk) 16:27, 18 August 2010 (UTC)[reply]

It isn't any more redundant than Title or Developers. Infoboxes are meant to provide a summary of information and easy-to-access wikilinks. A wikilink to the series article in the infobox is useful. And there is no confusion concerns; Final Fantasy Adventure is part of the Final Fantasy series and the Mana series. Super Mario World 2: Yoshi's Island is part of the Mario and the Yoshi series, etc. This is clear and verifiable. Stating it clearly actually helps to prevent confusion. Jonathan Hardin' (talk) 18:05, 18 August 2010 (UTC)[reply]

Yes, but no one disputed the inclusion of the title and developer fields – the series field, however, did have a few voices wanting it to be removed. You misunderstood what I meant with "confusion", though: The confusion issue is a concern of the ones who want to keep the field: It means that the proponents of the field are concerned about articles like Dragon Warrior VII which could not be easily identified by casual readers as part of the Dragon Quest series (which is the primary reason for the field being kept). Prime Blue (talk) 18:30, 18 August 2010 (UTC)[reply]

True, there was no real opposition to those, however I'd say the arguments against series are basically redundancy. The arguments for it are essential info you'd expect to find out about a title (if its part of a larger body of work that's defiantly something as essential to knowing as who the publisher is) and of those 2, when you put them together for anything else it would be clear what wins: essential info. Furthermore, there are problems with removing it or partially implementing it. Finally, I still say this would go against the larger consensus of Wikipedia to include series/franchise/etc (in some form) in the infobox. The bottom line is that those opposing it haven't come up with another good reason other than redundancy to remove it and I shouldn't have to remind everyone Wikipedia isn't just about vote-counting.陣内_Jinnai 00:31, 20 August 2010 (UTC)[reply]

• 1. The argument that the series field is essential directly clashes with the argument that it is redundant for a plethora of articles – "it would be clear what wins" is not a very good basis for a discussion.
• 2. What are the problems with partially implementing the field (that is, dropping it for the obvious cases)?
• 3. Please link to the guideline and the discussion where that alleged "larger consensus of Wikipedia to include series/franchise/etc (in some form) in the infobox" came from. Unless this exists, we are the ones to form a consensus here. Prime Blue (talk) 01:20, 20 August 2010 (UTC)[reply]

1. No it doesn't. A title is redundant (it's listed as the first words in a sentence. Redunant in this sense uses the meaning of repetitive. I can alter the phrasing if that helps any as that was the intended meaning I was using redundant as.
2. The problem with partially implimenting it is that it'll just create more confusion and will either bring long-drawn-out debates, continually questions for clarrification, or the most likely scenerio (given what i've seen elsewhere with unclear statements) blatanly ignored or e-laywered.
3. Most recent and ongoing one (it is primarly about navboxes, but there is a lot of discussion about uniformity, which includes series. Wikipedia talk:Categories, lists, and navigation templates#Guidance for sidebar navboxes (navigation templates). It was linked from WT:Manual of Style (infoboxes) because of questions about "belonging to a series" type issues we are discussing here.

As such, I say we put this on hold as that discussion is likely to supercede the local consensus here and possibly direct people to this discussion.陣内_Jinnai 02:04, 20 August 2010 (UTC)[reply]

1. If you feel the title field should be removed because it is redundant, you can start a discussion on it. But it would have no impact on the discussion about the series field: this is not a "keep everything or remove everything" issue.

2. We're all here to cooperate. I certainly won't oppose using the field for, say, the Tales of games. If there are honest concerns about a game not being identifiable as part of a series, then the field will be used. It all comes down to common sense and assuming good faith.

3. You misunderstood that discussion. It is about article series (like the link in Template:Love table), not about media franchises.

Prime Blue (talk) 02:38, 20 August 2010 (UTC)[reply]

"System Requirements" field

Previously: [1] [2] [3] [4] [5] [6] [7] [8] [9], probably more

• Modify, from the discussion in the "Genre" field, I suggest that we change this field to "Operating System" or "System" and limit the information to Windows (or possibly Vista), Mac (possibly Intel Mac), Linux, PSP, etc. I think there are similar arguments to the ones under "Input Method." In addition, for Windows, there are issues where there are minimum system requirements, where the game's performance may be degraded, and recommended system requirements. (And sometimes reviewers complain the recommended system requirements understate the real requirements for optimal performance.) Vyeh (talk) 18:10, 5 August 2010 (UTC)[reply]
  • (edit conflict) Isn't that platform? Bah, syntax guide doesn't even describe that. System requirement issues (too low, too high, don't match) is really reception (marketing, criticism) material. Anyway, I never quite understood why we need system reqs. Sure, to inform the reader about the minimum/required specs they need to play the game, but isn't that available from publisher and/or all the review sites. This is extensive technical info and I'm unconvinced of its encyclopaedic value. The field got a nice face-lift when the contents got spanned into both columns some time ago making it easier to read, but it may still eat up load of space, like, Starcraft. —  HELLKNOWZ  ▎TALK 18:33, 5 August 2010 (UTC)[reply]
    • The point is that there may be different system requirements depending on the RS. Having looked at Starcraft, I too am unsure of its encyclopedic value and certainly question its value in an infobox. Vyeh (talk) 21:10, 5 August 2010 (UTC)[reply]
• Comment - how is non-game software dealt with in the infobox for system requirements? I think we should check, given the wide-ranging variable of this can be used, before we decide on something that could upset a number of people who think knowing what the amount of HD space required to play a game is "essential information".陣内_Jinnai 21:06, 5 August 2010 (UTC)[reply]

  Neither {{Infobox software}} nor {{Infobox OS}} include system requirements. I don't know about other templates, but I believe those would be the primary ones. Reach Out to the Truth 21:17, 5 August 2010 (UTC)[reply]

  (edit conflict) Yeah, I was typing pretty much that. Archives also didn't show any proposals for them. —  HELLKNOWZ  ▎TALK 21:25, 5 August 2010 (UTC)[reply]

  Thanks for finding those. I will say while they don't have a system requirements, there is a "size" category in the former which indicates that we probably should include it for anything being installed on a hard-drive. If we get rid of Media (which as it is currently used i'm in favor of), we do not have a way of distinguishing for consoles/pcs how the content is primarly distributed, which is an essential aspect. Historically the use of minimum space required denoted that it was a disc-based distribution, but that is no longer the case as we have digital distribution lacking any info that can give a reader an at-the-glance idea is missing an essential element.陣内_Jinnai 21:33, 5 August 2010 (UTC)[reply]

  Is that not what |platforms= is for? Media is for stuff like CD-ROM or DLC.—  HELLKNOWZ  ▎TALK 21:43, 5 August 2010 (UTC)[reply]

  Not for HD space.陣内_Jinnai 18:56, 6 August 2010 (UTC)[reply]

  I don't see how required HD space is more important than any other requirement field. For whatever reason we would keep the system requirements, it should not be that the HD req field occasionally helps to clarify if the game is installed or played directly. —  HELLKNOWZ  ▎TALK 19:23, 6 August 2010 (UTC)[reply]

• Keep if for no other reason than having an alternative way of dealing with requirements than the quite space-consuming and poorly designed {{VG requirements}}. -- Sabre (talk) 21:57, 5 August 2010 (UTC)[reply]
• Keep. But possibly make it collapsible. Prime Blue (talk) 13:35, 6 August 2010 (UTC)[reply]
• Collapse to battle the huge infoboxes. Possibly make the font <small>. If we are to actually reduce the average infobox in size, it has to start here. If we agree to hide/collapse/minimize the whole field, we can then discuss what information it should hold. This should satisfy both camps — those wishing to trim the info to minimize space and those wishing to preserve the info. —  HELLKNOWZ  ▎TALK 21:49, 6 August 2010 (UTC)[reply]
• Keep, as with the "media" field, this is arguably more relevant to older systems where memory was at a premium and was usually the system requirement. Games on the ZX Spectrum for example would have required 16K, 48K, or 128K of RAM, and the huge relative difference between those requirements made them quite a defining factor. Miremare 23:44, 7 August 2010 (UTC)[reply]
  • Its arguable that it isn't the purpose of Wikipedia to tell you if your piece of software will run on a particular system. That said, at least basic info is probably justified.陣内_Jinnai 22:13, 17 August 2010 (UTC)[reply]

Proposal (Sys-Req)

Enclose system requirements with {{hidden begin}} {{hidden end}} if they get too long. Example. Also, wikilinking the field title to System requirements. Prime Blue (talk) 00:29, 18 August 2010 (UTC)[reply]

This feels to me to more be sweeping a problem under a collapsible carpet rather than dealing the issue of what causes them to become long. That example looks to me like a reasonably straight copy-and-paste of what's on the back of the box. In my view, editors should show some initiative in listing requirements, boiling down what is officially said to what is actually needed. Chipsets, particular brands of hardware recommended because of some promotional marketing deal, and other things like that aren't needed. Take a look at the Tales of Monkey Island or StarCraft requirements field, they're nice and short, but still convey the necessities of the hardware requirements stated on the back of the box. -- Sabre (talk) 12:44, 18 August 2010 (UTC)[reply]

I agree with Sabre per WP:NOTAMANUAL. Jonathan Hardin' (talk) 13:14, 18 August 2010 (UTC)[reply]

I would also agree with keeping the "key requirements" and dropping the collapsing. I'm just not that much of a PC gamer to determine what these are (I guess processor frequency, system memory, video card memory, and possibly one OS-specific value like the DirectX version).

Also, because I see it frequently in console articles (like Eternal Darkness: Sanity's Requiem): Does the memory card usage belong in that field? That seems to be very "copied that from the manual"-y. I mean, it's not really a system requirement either as you can start up and beat the game without saving. It makes more sense to use the field for real "system requirements", like an Expansion Pak for Donkey Kong 64. Prime Blue (talk) 15:48, 18 August 2010 (UTC)[reply]

The problem with stuff like processors and GPUs is not all items are created equal. There are a number of studies that have shown that for gaming a slower AMD processor is as good as the usually used intel processor specification (the exact number eludes me at the moment). Similar issues arise with GPUs. Memory and OS are probably one of the few exceptions, except that even here the use of generic "windows" is also not helpful given the many versions of Windows out there. Those specs listed on Starcraft amount to original research because they ignore those details.陣内_Jinnai 17:17, 18 August 2010 (UTC)[reply]

Accounting ourselves for supposed differences in processors or GPUs by applying generalised studies to for individual games is far more in the realms of synthesis and original research than stripping down the official specifications to more basic levels ever is. Unless some other source comes to light specifically dealing with processor difference, the requirements given in the StarCraft article are both accurate and verifiable; being based straight off the official ones, they are not original research. The simple addition of "or equivalent" deals with any other issues that arise from unequal hardware. -- Sabre (talk) 22:09, 18 August 2010 (UTC)[reply]

Okay, nobody cleared up so far what the key requirements would be, so I'll just make a proposal with the values above. If you feel something should be added, just leave a comment:

• for PC games: processor frequency, system memory, video card or video card memory, and one OS-specific value like the DirectX version, processor can also use brand name if given in the official specs
• for console games: keeping it to the equipment which is required to run a game (e.g. Expansion Pak for Donkey Kong 64, required PS3 HDD space for Resident Evil 5) and dropping what is needed to save a game (mentioning memory card, memory usage etc.) and to "enhance" the experience (e.g. Rumble Pak for Metroid Prime Hunters, optional Xbox360 HDD space for Resident Evil 5)

I am unsure about including required HDD space for PC games, would be nice if someone cleared up whether that should be mentioned. Prime Blue (talk) 00:12, 20 August 2010 (UTC)[reply]

• • If we go with generic ones like Starcraft it violates WP:OR for most of the info on there.
  • However, I'd say this whole field could be quashed either split into specific items or removed entirely as even with suggestions it will be rife with people putting whatever they want more than any other field on the template.陣内_Jinnai 00:53, 20 August 2010 (UTC)[reply]

There is also Template:VG Requirements to use instead of the infobox field. Prime Blue (talk) 01:44, 20 August 2010 (UTC)[reply]

"Version" field

What is the use of that field? For example, telling me that a game I've never played is version 1.22 doesn't mean anything to me. Game engine field was much more useful and that was removed so why not this as well. --Mika1h (talk) 20:50, 18 August 2010 (UTC)[reply]

• Weak keep. Explained above: "Will not be used for console games anyway. But I think that, again, it might be important for PC gamers wanting to look up the newest patch for a game (where there is already a plethora of them available)." Is there another place in the article where the newest version could be mentioned in a natural way? Prime Blue (talk) 23:49, 19 August 2010 (UTC)[reply]
  • There usually is not much info on latest patch in articles, but unless they are major ones. Sometimes in development section, but it actually makes it hard to distinguish when its in the pros. Generally its not needed though as many games might only have 1-2 patches.陣内_Jinnai 00:56, 20 August 2010 (UTC)[reply]
• Weak delete - I've done several PC game articles with released patches and I've never seen a use for it. I'd say a link to the game's website, where you can usually download the patch, would be more relevant and useful.陣内_Jinnai 00:58, 20 August 2010 (UTC)[reply]

Standardization for field contents

While we are all here, I'd also like to kick off a discussion on making the infoboxes more standardized, because they are horribly disorganized across articles. Some proposals to add to the documentation (and/or template)...

Note: I used Template:Collapsible list for some proposals below, but if there is a template that does not change the font size and style, I would go with that one. Prime Blue (talk) 20:27, 6 August 2010 (UTC)[reply]

Did the same thing here and updated the syntax guide. Changes:

• development tasks for companies and people are to be mentioned in prose, not the infobox (put credit fields in a subsection so we don't have to mention this for every credit field)
• collapsible lists for publishers and release dates where appropriate
• included note about using bolded section titles without colons for these fields

I also made two changes that were not discussed in their own section but should not be controversial:

• writer order is scenario/script writers before story writers: it's the way it is done in the film infoboxes
• producer field only for the actual game producer, no executive or assist producers

Now, the changes still to be discussed are the three unresolved issues at the bottom of this section. Prime Blue (talk) 23:51, 15 August 2010 (UTC)[reply]

Small image captions

Resolved

Generally keep "development tasks" to prose

Resolved

Exceptions for "development task" credits

Resolved

Only include references for uncredited people/tasks

Resolved

Colons after bolded section titles?

Resolved

Collapsible release dates

Resolved

Collapsible publishers list

Resolved

How to separate developers/publishers/genres/platforms

• Commas for genres and platforms(with nowrap used for all multi-word terms and proper names), line breaks for developers and publishers. Two possibilities: commas (example 1, example 2) or line breaks (example 1, example 2). Prime Blue (talk) 20:27, 6 August 2010 (UTC)[reply]
• Depends. The best way is probably commas, but if this leaves "Action-adventure, real" on one line and "time strategy" on the second, I think everyone can agree they are best divided into 2 lines. I think mentioning commas as preferred is best, but not a requirement. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)[reply]
  • Non-breaking spaces can be used for this.陣内_Jinnai 22:03, 6 August 2010 (UTC)[reply]
  • Yep, nowrap solves this problem. Prime Blue (talk) 22:44, 6 August 2010 (UTC)[reply]
    • Commas then as a suggestion of preferred style and break into lines/use nbsps if necessary. —  HELLKNOWZ  ▎TALK 07:19, 7 August 2010 (UTC)[reply]
• Genres with commentscommas, developers and publishers with colons (being proper names) --MASEM (t) 21:57, 6 August 2010 (UTC)[reply]
  • "Comments"? "Colons"? You definitely have me confused. I assume you meant genres with commas and devs/pubs with semicolons? Although I don't see how being proper nouns should change how they should be separated. —  HELLKNOWZ  ▎TALK 07:19, 7 August 2010 (UTC)[reply]
    • That's the English language for you. It's been pointed out in prose for me as well. It is probably to help denote that they are proper nouns.陣内_Jinnai 21:04, 8 August 2010 (UTC)[reply]
    • Yea, meant commas, my bad; but the idea is that proper names should be given their own lines; genres don't need that. --MASEM (t) 16:59, 9 August 2010 (UTC)[reply]
      • Could you elaborate on how to use colons for developers and publishers? That still confuses me. Prime Blue (talk) 17:44, 9 August 2010 (UTC)[reply]
        • Forget the colons. They should be on separate lines. --MASEM (t) 17:48, 9 August 2010 (UTC)[reply]
          • Ah, okay. Seems good, changed my opinion (will not get too long anyway if collapsible lists are appropriately used). Prime Blue (talk) 17:54, 9 August 2010 (UTC)[reply]

I completely forgot about platforms, where this would also apply. I'm leaning towards commas for that field as well, using nowrap for all multi-word platform names like "Nintendo 64". Although these are all proper names, line breaks would simply be too long for port-heavy games. Prime Blue (talk) 09:37, 15 August 2010 (UTC)[reply]

Exclude port developers

• Support. It feels better to me to just give the developer of the original version in the infobox. Port developers can be mentioned in prose. Same goes for directors and producers of ports, which should not be included in the infobox either. Prime Blue (talk) 20:27, 6 August 2010 (UTC)[reply]
• Support only listing the original developer. Any port developers/studios go into prose. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)[reply]
• Depends on the nature of the ports. Ports made within the same few months or year are notable to be mentioned, ones made 20 years later are not. --MASEM (t) 21:57, 6 August 2010 (UTC)[reply]
• Actually, I'd say the opposite of masem. A port within the same timeframe is generally not notable enough to mention, unless there is clear evidence that they had a completely separate development process. Those down the road are notable, especially if they had to do some retooling.陣内_Jinnai 22:11, 6 August 2010 (UTC)[reply]
  • If Masem still feels they should be included, we could make that field collapsible as well. Original developer as title, the port developers collapsed. Prime Blue (talk) 17:48, 9 August 2010 (UTC)[reply]

Proposal (Port Dev)

The solution to every problem we ever had on this planet: collapsible lists. Original game developer(s) as title, port developers below. Example. Prime Blue (talk) 00:45, 18 August 2010 (UTC)[reply]

Separate infoboxes for remakes

• Support. If a remake of a game is significantly covered in a section of the article for the original game, it should have its own infobox. See Final Fantasy III with a separate infobox and with just one infobox. Prime Blue (talk) 20:27, 6 August 2010 (UTC)[reply]
• Support but with discretion. If the remake only has 1 or 2 differing fields (date or something), then there is no need. Although this would rarely be so, we don't want and infobox just to have an infobox. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)[reply]
  • Totally agree. Prime Blue (talk) 16:16, 7 August 2010 (UTC)[reply]
• Avoid at all costs This will encourage readers to add in images for each remake, and as these are non-free, it will make them too long. On the other hand, I can support the idea of making a modular infobox to have a main game and ports section. --MASEM (t) 21:57, 6 August 2010 (UTC)[reply]
  • Not if its done correctly with header/footer infoboxes such as {{infobox animanga/header}} and its subdivisions. Making 2 new template [{tl|Infobox video game/header}} and {{Infobox video game/footer}}, moving this to {{Infobox video game/original}} (or some equivalent) and having another new template {{Infobox video game/remake}}. This would also allow for easier expansion in the future, if deemed appropriate.陣内_Jinnai 22:17, 6 August 2010 (UTC)[reply]
    • That sounds nice, it seems like the easiest way to avoid more images. I'd keep the current name for the main infobox and add an additional Template:Infobox video game remake. That way, we don't even have to create header and footer templates: the remake infobox is identical to the normal one, it just does not have the image and caption fields. What do you think? Prime Blue (talk) 16:14, 7 August 2010 (UTC)[reply]
      • The header and footers were also made to link to the portal page so a footer might still be appropriate so it could link to Portal:Video game.

        The header is used to put the basic info on all the items usually for large media franchises. It may be useful for titles where there is a media franchise, but the offshoots like movies and novels might be important enough to note in the lead, but not notable enough for their own article. Also the name/title field is kept in all the infoboxes because of the possibility of alt names.陣内_Jinnai 21:01, 8 August 2010 (UTC)[reply]

        • Still think header and footer templates are "not needed", though, as they are simply embedded into the main template. I mean, the link to Portal:Video game can also be included in the (original game) infobox template itself, and the only differences between Template:Infobox video game and Template:Infobox video game remake would be the omission of the portal link, the image, and the caption for the latter. Don't know what you mean with movie and novel notes. Prime Blue (talk) 21:51, 8 August 2010 (UTC)[reply]
          • There is be a way that we can have this template be used without any further inclusion if there are no notable ports while an option for ports, and that is to create a "port_subsection=" argument. If empty, nothing is done, but if present, we include these port subtables as part of the infobox which basically is the same info sans title, image, genre, etc.) The header/footer idea is nice but that would require too much change; this makes it easy to be backwards compat with existing infoboxes. --MASEM (t) 15:10, 10 August 2010 (UTC)[reply]
            • Masem, this is about remake infoboxes. The only port section so far is here. I've been thinking about such a "remake=yes/no" field in the current infobox template not to display images and captions. But the problem with that is that the code for the fields would still be there. People may still upload pictures and include them in the image field of the infobox for the remake: It's not displayed, but it's still there. Prime Blue (talk) 15:31, 10 August 2010 (UTC)[reply]
              • Regardless of being a port or remake, the idea that I'm trying to say is this: in the main infobox template we can provide a parameter that allows use to include one or more additional specialized templates for dealing with ports and remakes that 1) can be contained in the main infobox , 2) be present as a collapsible section within that box and 3) provide only those details that are expected to be significant different for a port/remake (platform, release dates, people involved, but not things like cover images, titles, or genres). This can be done via a modification of the current main infobox template without disrupting any existing use of that template. --MASEM (t) 15:51, 10 August 2010 (UTC)[reply]
                • There are technical issues with that: You can have that include/exclude parameter for collapsible port/remake sections in the infobox, but you still have to specify the field contents for those somewhere, which makes the include/exclude parameter effectively useless. Going that route, there are only two ways: 1. Put all port/remake fields in the main infobox (calling them "portplatform", "remakeplatform", "portrelease", "remakerelease" and so on) and include code that tells the infobox to automatically show a collapsible section for those extra fields if one of a kind of them (port/remake) is filled out. 2. Duplicate the required fields in external port/remake templates and include a field at the bottom of the main infobox template where the additional template is then added by a user and automatically parsed as a collapsible section. (e.g. port={{Infobox video game port|developer=???|publisher=???|...}}). Prime Blue (talk) 16:43, 10 August 2010 (UTC)[reply]
                  • It may be possible Masem, but I think seperate templates will be easier to impliment and maintain.

                    @Prime Blue: I think you could include those items in the main template. The only reason Anime/Manga one is split is because sometimes there is no anime and sometimes there is no manga so there is need to deal with both cases. For individual video game articles there should always be a video game associated with it. The only real issue I have with not allowing 2 images is for games like Dragon Quest IV where both images in the infobox are relevant and massively diffrent enough to qualify as an exception for the 1 image per infobox exception. If remakes are shoved to a different box and not allowed their own image this could cause with articles like that.陣内_Jinnai 01:09, 11 August 2010 (UTC)[reply]

Okay, the remake template nesting that Masem suggested would look something like that (probably fully fitting into the main template, though). Usage of individual remake fields in the main template (as described above) would be a usability nightmare, so the easiest solution for that would be to have a remake= field that would then be filled with a remake template without the fields image and caption.

However, I have to admit that I'd highly dislike it that way. The repeated fields don't look very good, and are probably not the easiest to read either due to the repeated field titles (unless you scroll down). Therefore, my proposal below. Prime Blue (talk) 19:59, 18 August 2010 (UTC)[reply]

I'm still sticking to the original plan, just creating a separate Template:Infobox video game remake without the caption and image fields, and using that in the section the remake is covered in. For the small sections, we can still slap a |collapsible=yes |state=collapsed on it. Prime Blue (talk) 19:59, 18 August 2010 (UTC)[reply]

(←) This is what I had in mind. Note that the main template, User:Masem/ivgmain is basically the current Infobox Template but needs a few back end fixes, but with this, one can add "remake1", "remake2" (or we could use "port", whatever). The argument for these parameters is a call to this template: User:Masem/ivgport, which you'll see right now is mostly the same as the main infobox text. However, we can prune stuff out of here, or instructed that only significant details like new developer, release dates, platforms should be included. --MASEM (t) 21:36, 18 August 2010 (UTC)[reply]

Strongly oppose using this for ports: It's just more convenient to keep those differences in the main template with collapsible lists. For example, you want to know the developers, publishers, release dates, and ratings of the Final Fantasy IV ports. One simple click each, and it's all there. Using the other solution for ports (could only include two ports as there are no remake3/remake4/remake5/... fields currently), however, you have to click once to know the developer of that version, then click again to expand that other port, then collapse all to know all developers, but no, you have to recollapse some again because one port table is out of your view, and so on. And it's not only the readers that suffer: I needed ten minutes or so just to settle over two ports from the old format to the new style – it's a nightmare for editors, especially for gazillion-platform games. For ports, it's creating more work than need be.

However, I find it acceptable for remakes (I still like separate boxes better, but this is fine with me as well). Prime Blue (talk) 22:40, 18 August 2010 (UTC)[reply]

Remakes and ports have to be treated in the same - internally to VGs we know the difference, externally most don't know that.

As to the format I provided, that's what I had in mind on my original comment, but I can see the individual line collapses as well - but only for elements where there are 3 or more ports - or basically when there are 6 or more lines that would be in that field. --MASEM (t) 04:05, 19 August 2010 (UTC)[reply]

We don't "have to", that is what we have guidelines for – most casual editors will never even look at them and just do their thing. And it is still an editing nightmare, actually far worse for casual editors than what we currently use. See the second paragraph.

My point still stands, I will give the use of this style for ports an absolute 100% as-hard-as-it-gets oppose. It took me almost half an hour to change the Resident Evil 2 infobox from the current format to the proposed style. You have to be so careful not to make any mistakes in the process – there is no way this is easy to use for casual editors when I'm struggling myself. And it would have to be done manually for hundreds, if not thousands of articles. With that example, I can also show what I meant earlier: If you want to know the release dates of all versions quickly, you just have to make a single click and you have it all there. The proposed style lets you make an abundance of clicks, is hard to read due to its fractured nature, has you recollapsing things when something is out of your view, looks ugly when everything is collapsed, and so on. Therefore: Use it for remakes, I'm okay with it – but for ports I'll have to voice an honest and irrevocable no. Prime Blue (talk) 11:11, 19 August 2010 (UTC)[reply]

It really depends on what the general use of the infobox is expected to be. It may be what you suggest - a means to compare between the original and its ports/remakes in a single shot, for example. Some have suggested they'd like to see separate infoboxes for ports/remakes which then this other means work. Selecting one way makes the other impossible/impractical. We have a way to do both, so now its just a matter of consensus to determine what should be the standard. --MASEM (t) 13:15, 19 August 2010 (UTC)[reply]

Again, it is not just about accessibility and readability when comparing information or wanting to know several pieces of information at once, but the current format also looks "sleeker" for games with many ports, and having to change all infoboxes to the new format with the editing time ranging from 5–30 minutes per articles would be a humongous task, especially for how little we gain. :/ I guess I won't be the only one who thinks that way. Though it might be more understandable if you try an example yourself: Group the ports of Final Fantasy IV with the new format, using {{User:Prime Blue/Sandbox}}. It really is a chore. Prime Blue (talk) 14:12, 19 August 2010 (UTC)[reply]

If a game has many ports (which I would argue is 5 or more, possibly even 4 or more) populating the infobox with all those details is the wrong place for it. Case in point: Lemmings (video game). There's probably so many different teams and companies involved in each port that fitting them all into the infobox would be stupid. When you get that many ports, a detailed table in the body of the article is a better means of representing the data. --MASEM (t) 14:20, 19 August 2010 (UTC)[reply]

I still don't see what is wrong with the current format of putting the original developer/publisher/release date/etc. first and the rest in a collapsible list: it is the easiest way to read and edit, and it is unintrusive, too. Though I also thought the point of your proposal was to have the information in the same infobox – at least I don't understand why you would want ports separate now but not the remake. *shrug* However, some more opinions would be helpful. Prime Blue (talk) 15:06, 19 August 2010 (UTC)[reply]

How to separate grouped platforms in the "developer", "publisher", and "release dates" fields

• Slashes. Two possibilities, slashes and commas. I'm going with slashes as commas look weird for the release dates field and give off a sentence-ish vibe. And the documentations for the infobox and Template:Vgrelease also use slashes to separate grouped region flags (e.g. "^{JP / NA} October 25, 1985" instead of "^{JP, NA} October 25, 1985"). Prime Blue (talk) 01:13, 18 August 2010 (UTC)[reply]

Adding a link to the Video games Portal

Oppose. This was suggested by Jinnai. I put together one possible example (look at the bottom of the infobox). I think this is more of a job for the template {{Portal|Video games}}, to be put pretty far down (somewhere around the external link sections). In the infobox, it seems to get in the way too much. And the anime and manga project is the only project I know that has the link in their infobox. Doesn't seem to be common practice to put it there. Prime Blue (talk) 17:18, 18 August 2010 (UTC)[reply]

• Add - per my comments above.陣内_Jinnai 01:03, 20 August 2010 (UTC)[reply]

Add link to the publishers' or games' website

This would default to English-language ones should both Japanese and English exist. Other templates have links to the relevant website, including the software ones, which are the closest examples. If we add this, we can possibly remove fields for version and system requirements which there is controversy over as the latter the way it has and probably will continue to be used is bloated and possibly violates WP:GUIDE while the former is mostly to let people know if a new version is out (as far as i can tell), which is what the publisher, not wikipedia, should do.陣内_Jinnai 01:03, 20 August 2010 (UTC)[reply]

• Oppose. Version and requirement fields deleted or not, this is what the "External links" section at the bottom of a video game article is for. Prime Blue (talk) 01:49, 20 August 2010 (UTC)[reply]

Can we have these fields added to the template? They would be applicable to many if not most video games, and would allow for convenient access to any previous or successive game on any game article. — CIS ^(talk | stalk) 01:12, 19 July 2010 (UTC)[reply]

Been proposed many times and each time we don't add it. Do we add these chronologically? By release date? By "official" series releases? There's so many different ways of interpreting what the "next" or "previous" game in a series that we will otherwise constantly fight over these fields. --MASEM (t) 07:50, 19 July 2010 (UTC)[reply]

I agree with Masem. His concerns were the first that came to my mind upon reading the suggestion. Taking remakes, spin-offs and things like non-notable mobile games into the equation, this will just cause edit wars and constant debates. Prime Blue (talk) 21:00, 19 July 2010 (UTC)[reply]

I think this has been proposed before too many times. The problem was and is the ambiguity of this - spin-offs, non-canons, etc. For every clear case, there will be 10 unclear. This belongs in prose, instalments, or see also. —  HELLKNOWZ  ▎TALK 09:24, 5 August 2010 (UTC)[reply]

I have noticed a user going through many many video game articles and removing non-English speaking countries (particularly South Korea) from ratings and release dates because they "aren't notable on English wiki". That seems very inappropriate to me. Is there any policy regarding this? If the user has made a mistake, it will be hell to correct. Some guy (talk) 10:04, 19 July 2010 (UTC)[reply]

Its in the documentation of this template, however, I think it is inappropriate as well. Just because we are an English wiki doesn't mean we give weight to English-speaking countries. It means the information should be presented in English and that is it. BOVINEBOY2008 10:08, 19 July 2010 (UTC)[reply]

I'm the user that's been removing the non-English data. As Bovine points out, it's in the documentation for the template, under ratings "The game's censorship rating most widely accepted in the game's country of origin (and any English-language censorship ratings)." and under release "Use the first public non-festival release in the game's country of origin, as well as any English-language release dates available". Data for releases in non-english speaking language countries simply isn't terribly useful to the mass audience of the English-lanugage wikipedia. Thanks! Fin©™ 10:15, 19 July 2010 (UTC)[reply]

Ah, yep, I should have read that better. I'm half-asleep, I have a bad habit of checking my watchlist right before I go to bed. That policy entirely discounts the possiblity someone from Korea, for example, might read English and be interested in something related to his or her country. We have articles on South Korean holidays. At the very least, it is sometimes interesting to compare how different countries rate the same game. Some guy (talk) 10:16, 19 July 2010 (UTC)[reply]

If we used that logic, we would need to include the ratings for every country of release, and that's well beyond being indiscriminate. The ratings field is not meant to provide data to inform consumers, but instead to provide an idea to readers of what the content level is in general for an english-speaking-based game. --MASEM (t) 14:07, 19 July 2010 (UTC)[reply]

For the infobox it isn't needed. If there are special exceptions to be noted they can be done in the prose on a "Release" section.陣内_Jinnai 20:35, 19 July 2010 (UTC)[reply]

I propose we add an alternate title= field to this template. Many video games have different titles when the game is released in both North America and Europe or when it's ported to different platforms or released by different companies for varying reasons, where it's the exact same game except the title screens are different, and sometimes the box art as well. For example, some well-known ones are KULT: The Temple of Flying Saucers and its American title Chamber of the Sci-Mutant Priestess; Alpha Waves and its North American counterpart Continuum; Another World is "Out of this World" in America; also Brutal Sports Football is known as "Crazy Football" in Germany; then there's Ultrabots (aka Xenobots); Stunts (aka 4D Sports Driving); and 4D Sports Tennis actually has TWO alternate titles: World Tour Tennis AND Compaq Grand Slam Cup. There's many others.. I actually have a list here of most of them if anyone's interested.. -- œ^™ 03:04, 20 July 2010 (UTC)[reply]

The thing is that it's not uncommon for there to be other changes in those cases as well: my fave example has always been Magical Flying Hat Turbo Adventure, even if most are a little less extreme. :) It might be worth considering a more substantial re-think to how we present the releases section (possibly splitting it into rows properly: Region / Name / Date). Chris Cunningham (not at work) - talk 09:13, 20 July 2010 (UTC)[reply]

Almost every Asian game seems to have alternative titles for Western market. Many are known differently between Europe and US. But this information belongs in prose, in lead. I don't think repeating this in infobox makes the presentation any better. —  HELLKNOWZ  ▎TALK 09:26, 5 August 2010 (UTC)[reply]

The bulleted list in the release section seems to be intefering with the video game infobox, see Star Wars: The Force Unleashed II for example. Or maybe it's just my browser. I've raised this concern on the VGrelease talk page, with no response. Perhaps other people don't notice it.--The Taerkasten (talk) 14:49, 27 July 2010 (UTC)[reply]

The problem is that the bulleted list does not align properly, thereby causing it to overlap the Release date(s) field.--The Taerkasten (talk) 14:58, 27 July 2010 (UTC)[reply]

The list doesn't appear bulleted to me and it's using the template {{unbulleted list}}. —Ost (talk) 16:30, 27 July 2010 (UTC)[reply]

I guess it's just me then. It's not a big problem.--The Taerkasten (talk) 17:45, 27 July 2010 (UTC)[reply]

Indeed. Might be a custom style sheet issue on your end? Der Wohltemperierte Fuchs^(talk) 18:08, 27 July 2010 (UTC)[reply]

It doesn't appear to happen when using FireFox, I mainly use IE.--The Taerkasten (talk) 18:17, 27 July 2010 (UTC)[reply]

The "Programming language" property would be nice to have info I think. Above the "engine" property?

|{{#if:{{{Programming language|}}}| {{!}} '''[[Programming language|Written in]]''' {{!!}} {{{Programming language|}}} }}

--Johnny Bin (talk) 17:49, 4 August 2010 (UTC)[reply]

Nice perhaps, but completely unknown (or just assumed to be C/C++) for the vast majority of games. Thanks! Fin©™ 18:12, 4 August 2010 (UTC)[reply]

Actually, on modern games a whole host of languages might be used; the game engine will probably be in C++, but much of the logic will be in scripting languages (either standard ones like Lua or Python or in-house ones). But this just makes the attribute a trivia dump, and we shouldn't have them. I agree that this is better left out of the infobox. Chris Cunningham (user:thumperward: not at work) - talk 09:10, 5 August 2010 (UTC)[reply]

This definitely is trivia and unknown/unpublished for majority of games. Scripting languages are still dependent on their host (C or whatever), whereas C compiles to mc/executable, so the main language would still be C. Anyway, the language carries little significance most of the time, and if it does, then it should be explained why in the prose. —  HELLKNOWZ  ▎TALK 09:19, 5 August 2010 (UTC)[reply]

Third opinion turned it down, so I'm going that way. Basically, WP:LEADCITE hinders the discussion of new guidelines from progressing (current one and older one). To sum it up, what does WP:LEADCITE say?

• 1. Avoid references and descriptive footnotes in the lead section.

or

• 2. References for uncontroversial material are not mandatory in the lead section.

Prime Blue (talk) 14:58, 10 August 2010 (UTC)[reply]

In the same way that the infobox for a song or album can show alternate covers, would it be possible for us to add an alternate cover parameter to this infobox? – PeeJay 22:58, 12 August 2010 (UTC)[reply]

There's already issues with alternative covers for albums and non-free content. I strongly recommend against; if an alternative cover is significantly covered (see Okami's Wii version) it can be included in the prose. --MASEM (t) 23:04, 12 August 2010 (UTC)[reply]

The documentation for the developer field currently says:

The popular name(s) of the game developer(s), e.g. Konami Computer Entertainment Japan. This field is for the company that developed the game, as opposed to any individual staffers. In the case of a game made entirely by one designer, use the designer field instead. The name(s) can be wikilinked. Individual development tasks handled by different companies (e.g. scenario, programming) should not be mentioned in the infobox but in the article text instead.

I think it should changed to say "This field is for the name of the company or development team (...)", because some of the larger companies have names for their development teams and the current, unchalleged usage is to use these more precise names instead of the name of the general company. See for instance Final Fantasy VII or Devil May Cry 2. Thoughts? Jonathan Hardin' (talk) 12:25, 18 August 2010 (UTC)[reply]

Agree. That is the way it is used in many articles anyway. However, development studios/teams need references if they are not mentioned in the (English version of the) game. For example, Nintendo R&D1 is not mentioned to be the developer in the staff credits of Super Mario Land 2: 6 Golden Coins, therefore it can be considered original research and has to be changed to simply "Nintendo" unless a reliable source is provided. Another example: Final Fantasy VII mentions Square Product Development Dept. #1 as the development studio, but it does so only in the Japanese credits: therefore, it is not common knowledge in an English speaking country and needs a reference not to be considered original research and to be changed back to simply "Square".

Now, there are some sites out there that list the games a specific development studio/team has allegedly created, but these are never 100% accurate...actually more (un-)educated guesses. For example, IGN claims Capcom Production Studio 4 to be the developer of Dino Crisis for PlayStation (which was released in July 1999), although the development team was only ever assembled in October 1999. I'm just saying everybody should be careful when using such lists as a reference. Prime Blue (talk) 16:14, 18 August 2010 (UTC)[reply]

To sum it up: If the (English version of the) game does not mention the development studio/team or if no reliable source (developer interviews, behind-the-scenes looks, other regional release of the game, etc.) exists, go with the company name only. Prime Blue (talk) 16:14, 18 August 2010 (UTC)[reply]