Jump to content

Template talk:Infobox video game/Archive 9

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 5←Archive 7Archive 8Archive 9Archive 10Archive 11→Archive 15

Box art from different regions

I assume everyone who watches this page also watches the project talk page but I just thought I'd bring your attention to this discussion as there is a suggestion that the syntax guide for this template be altered slightly. ChimpanzeeUK - User | Talk | Contribs 13:21, 2 September 2008 (UTC)

Please change

Ideally, the most recognizable English-language cover or a promotional flier, in the case of an arcade game. Failing that, a logo or foreign-language cover can suffice. When the game was released on multiple platforms, the PC cover is preferred over console covers to avoid bias towards a certain console...

to:

Ideally, an English-language cover or a promotional flier, in the case of an arcade game. Failing that, a logo or foreign-language cover can suffice. When different cover designs are available for different regions, the one from the region in which the game has been developed should be used, unless this is not English-language in which case the first-available English-language cover should be used. Where a game is released on multiple platforms, the PC cover is preferred over console covers to avoid bias towards a certain console...

Per the discussion mentioned above. Thanks. ChimpanzeeUK - User | Talk | Contribs 13:51, 5 September 2008 (UTC)
 Done - X201 (talk) 14:05, 5 September 2008 (UTC)
Too bad we can't include all versions of a game's boxart and the ability to rotate among them, similarly to how MobyGames does it. Personally, I would consider this as falling under fair-use, as it is being used to "identify" the game. SharkD (talk) 21:05, 17 September 2008 (UTC)

Addition of 'Preceded by' and 'Followed by'

I think it would be useful to add these fields to the template as they would allow the reader to quickly see where in a series a particular game lies. For example Grand Theft Auto: Vice City would show Preceded by: Grand Theft Auto III and Followed by: Grand Theft Auto: San Andreas. ChimpanzeeUK - User | Talk | Contribs 20:40, 9 September 2008 (UTC)

Just spotted a similar discussion above. In response to X201's comment, The same applies to television programmes such as 24 but the articles relating to specific seasons include similar information in the infobox. I think it would be beneficial to have the same information available for video games. ChimpanzeeUK - User | Talk | Contribs 20:43, 9 September 2008 (UTC)

Also, see here. SharkD (talk) 01:54, 10 September 2008 (UTC)
Oppose as I always do when this comes up. Pagrashtak 05:30, 10 September 2008 (UTC)
Agreed. It can easily present a wrong idea in cases where a series of games is not an actual chronological order. Also such a subject can just as easily be covered by the article itself.--Kung Fu Man (talk) 09:49, 10 September 2008 (UTC)
Not to mention this should be covered in the prose of the article. Der Wohltemperierte Fuchs (talk) 12:51, 10 September 2008 (UTC)
I agree with the others, many game series have erratic time lines. With sequels, prequels, midquels, and spin-offs, there are too many ways to interpret preceded and followed. For instance, how would this be applied to the Final Fantasy series? By release dates, Dirge of Cerberus: Final Fantasy VII is followed by Final Fantasy XII, while story-wise something like the Devil May Cry series is 3, 1, 4, 2. (Guyinblack25 talk 16:17, 10 September 2008 (UTC))
I'd have to weakly oppose this, as unlike the more clear-cut nature of television or game show series, most video game franchises (e.g. Final Fantasy) are not is any neat order. It may confuse the reader, first off, and then there might be some potentially ugly edit warring over having such a box in the first place and/or what precedes or proceeds a game. MuZemike (talk) 18:07, 10 September 2008 (UTC)
TV shows aren't necessarily any better. See Caprica (TV series), not to mention all the flashback webisodes/straight-to-DVD movies in the BSG series. SharkD (talk) 02:22, 11 September 2008 (UTC)
It does seem ridiculous for video games to be one of the only entertainment articles not to have chronology. Maybe a solutipn to confusion would be to have more than on chronology: release date, story events, remakes and related games immediately spring to mind. --jamdav86 (talk) 18:11, 9 November 2008 (UTC)

I propose that infoboxes be stored in Template space and transcluded into articles, similarly to navboxes. This would allow us to add 'view', 'talk' and 'edit' links to the infoboxes, as well as--more importantly--edit the infoboxes in isolation. Currently, in most cases you have to open the entire article in order to edit the infobox, as they don't appear in sections that have an 'edit' link. This is annoying and slow. SharkD (talk) 01:52, 10 September 2008 (UTC)

I don't think this is a good idea; that means each game would need its own template to do this and that might be a bit heavy on the space. Mind you, there is a javascript bit floating around that you can add to your monobook that will place the lead section (including infobox) as a single section to edit. --MASEM 05:08, 10 September 2008 (UTC)
You can actually just activate the "Add an [edit] link for the lead section of a page" option in the "Gadgets" tab in "My preferences". --Silver Edge (talk) 10:35, 10 September 2008 (UTC)
Agree with this being a bad idea, per above. Just another page to watchlist for vandalism and crap. Der Wohltemperierte Fuchs (talk) 12:52, 10 September 2008 (UTC)
Also agree with bad idea. If you don't want to add the gadget or .js, you can simply append ?action=edit&section=0 to any url. --Izno (talk) 16:02, 10 September 2008 (UTC)
I agree with the others mainly because the disadvantages of this outweigh the advantages. And as Silver Edge points out, editing the lead is available via gadgets. I've found enabling the lead gadget and some others to be very useful and am glad I did it. (Guyinblack25 talk 16:23, 10 September 2008 (UTC))
Is there a way we could add the ?action=edit&section=0 link to the infobox? SharkD (talk) 17:55, 10 September 2008 (UTC)
There's no guarantee that the infobox will be in section 0. Seriously, there's no real need for this. Chris Cunningham (not at work) - talk 08:10, 11 September 2008 (UTC)
I also disagree. I'm not sure that's what the template space is supposed to be used for. And yes, you can easily edit, for large articles, the lead/infobox under the "Gadgets" portion of "My preferences." MuZemike (talk) 17:57, 10 September 2008 (UTC)

{{editprotected}}

Unlink "scriptwriter" because it goes to a disambiguation page, and there isn't a page appropriate for the context that this word is used in. So:

Find: 

|{{#if:{{{writer|}}}| {{!}} '''[[Scriptwriter|Writer(s)]]''' {{!!}} {{{writer|}}} }}

Replace with: 

|{{#if:{{{writer|}}}| {{!}} '''Writer(s)''' {{!!}} {{{writer|}}} }}

Done Gary King (talk) 02:44, 14 September 2008 (UTC)

 Done Thanks for the clear and detailed edit request. —EncMstr (talk) 03:38, 14 September 2008 (UTC)

Website parameter

Many games have dedicated websites. Can a "website" parameter be added, similar to what is in {{Infobox Company}}? Yngvarr (t) (c) 23:37, 16 September 2008 (UTC)

What's wrong with having it at external links (as it is currently). Der Wohltemperierte Fuchs (talk) 03:01, 17 September 2008 (UTC)
The video game infobox is long enough as is, the external links seems to work just as well. Salavat (talk) 05:03, 17 September 2008 (UTC)

There's already a discussion about this further up the page - X201 (talk) 08:41, 22 September 2008 (UTC)

Game producer

Since this is an article on Wikipedia, I think Game producer should be added to the infobox, alongside designer and music composer, because I've seen quite a few game producers in the designer section, which I think doesn't make any sense, therefore it should be added to the infobox. --EclipseSSD (talk) 19:43, 17 September 2008 (UTC)

Personally, I think all the designer/composer/writer/producer/etc. info should fall under the "Developer(s)" heading. If a second template is needed to organize all this (such as {{vgrelease}}), then so be it. SharkD (talk) 21:02, 17 September 2008 (UTC)

New color

I think there should be a parameter that allows you to change the color and have the parameters called "color1" and "color2". If not, change the color of the infobox to the previous "television color" witch was present when the infobox had borders. Mythdon (talk) 01:35, 29 September 2008 (UTC)

Urgh. No. The random ihclusion of colour is contrary to our guidelines on when templates should use it, and this was already discussed exhaustively on the VG WikiProject talk page. Chris Cunningham (not at work) - talk 13:07, 29 September 2008 (UTC)
Show me the discussion. Mythdon (talk) 14:00, 29 September 2008 (UTC)
Wikipedia talk:WikiProject Video games/Archive 33#Changes to Infobox CVG. Chris Cunningham (not at work) - talk 14:07, 29 September 2008 (UTC)
(ec) There's discussion at Wikipedia_talk:WikiProject_Video_games/Archive_33#Changes_to_Infobox_CVG, Template talk:Infobox VG/Archive 6, Template talk:Infobox VG/Archive 7, and probably a few dozen other places. Past discussion aside, strong oppose to customized colors in the infobox. Pagrashtak 14:11, 29 September 2008 (UTC)
Colors would kinda destroy the effect of consistency. In my opinion, not a good idea. Salavat (talk) 14:15, 29 September 2008 (UTC)

Just out of interest, what purpose would this serve? ChimpanzeeUK - User | Talk | Contribs 14:28, 29 September 2008 (UTC)

hide

editing planescape:torment, I saw a little need for improvement:

can't "hide" be exchanged for something more descriptive (like "details" or "more info") ?

also, would someone more knowledable please make it possible to collapse parts of the table (such as "ratings" or "system requirements") ? (or is it and I just dont know about it ?) —Preceding unsigned comment added by Cold Light (talk • contribs) 20:35, 2 October 2008 (UTC)

"hide/show" cannot be changed because it is determined in MediaWiki:Common.js. ---Majestic- (talk) 20:47, 2 October 2008 (UTC)
Which really means we can't change it. You'll have to take it up on mediawiki talk:common.js. --Izno (talk) 21:25, 2 October 2008 (UTC)

You can collaspe stuff using {{collapsible list|title=[[Title Here]]|}} Salavat (talk) 03:19, 3 October 2008 (UTC)

Bypass redirect

This is to bypass a redirected link. Find: 

[[Computer platform|Platform(s)]]

Replace it with: 

[[Computing platform|Platform(s)]]

And you're done! Gary King (talk) 04:09, 6 October 2008 (UTC)

 Done--MASEM 04:12, 6 October 2008 (UTC)

Use a wikitable-style title

{{editprotected}}

Simple conformity one here, to match {{infobox computer}} / {{infobox software}} / {{infobox OS}} et cetera. Change: 

|-
! colspan="2" | <div style="font-size:110%; text-align:center;" class="summary">{{#ifeq:{{{collapsible|}}}|yes|{{pad|5em}}}}''{{#if:{{{title|}}}|{{{title}}}|{{PAGENAME}}}}''</div>

To 

|+ class="summary" | {{#ifeq:{{{collapsible|}}}|yes|{{pad|5em}}}}'''''{{#if:{{{title|}}}|{{{title}}}|{{PAGENAME}}}}'''''

Sandbox at {{User:Thumperward/VG}} to try before buying, but this is pretty trivial. Chris Cunningham (not at work) - talk 21:22, 11 October 2008 (UTC)

Ach, floating titles! Destroy! Changing visual styles on this infobox is never trivial, remember the attempts to move to this overall visual style? I preview tested the new version on a couple of articles, the floating title looks really bad against the box art, I'd much rather prefer to keep the title the way it is at the moment, with the title inside the box as opposed to floating outside of it. -- Sabre (talk) 21:40, 11 October 2008 (UTC)
IIRC, the visual style debate did eventually decide in favour of maoving towards the style favoured by other modern infoboxen, and even leads the way in using alternatively striped fields (something which is desired for {{infobox}} but is proving hard to implement). Do you have example articles where this is evidently detrimental in comparison to the current design? Chris Cunningham (not at work) - talk 22:29, 11 October 2008 (UTC)
Personally, I'd be more fan of moving to change the other infoboxes to emulate this one, rather than the other way around. However, this stuff mostly comes down to personal opinion, there's no particularly solid technical reason for going for either title style. I tested the infobox on StarCraft, StarCraft: Brood War, The Orange Box and Team Fortress 2 and it just looked wrong to me, especially if there's some sort of disambiguation hatnote at the top, as it pushes the start of the box itself quite a way down the article. Otherwise, having the top of the box so close to the top of the box art images also just looks wrong. I really don't like what it does to presentation, particularly as this will be the first thing a reader sees when viewing an article. -- Sabre (talk) 00:35, 12 October 2008 (UTC)
Agree with the above users; in many ways our infobox leads the way (Infobox film, for example, crushes content by being too small, while the comics infoboxes are just garish PoS.) Let them change! :P Der Wohltemperierte Fuchs (talk) 03:21, 12 October 2008 (UTC)
But this time the infobox isn't "leading the way"; it's using the older styling, which is less distinctive and doesn't match the way that other tables are styled. Hell, even {{VG reviews}} now uses an external title. (I should also note that there are only two other commenters on this thread, me and Sabre, and I'm for and he's against the change.) Chris Cunningham (not at work) - talk 12:14, 12 October 2008 (UTC)
Not exactly. {{Infobox book}}, for example, uses the same contained style. And the derivative episode/album infoboxes are inside the frame as well. -Der Wohltemperierte Fuchs (talk) 13:44, 13 October 2008 (UTC)
{{Infobox book}} isn't exactly a progressive template: it's seen ten edits over the last year. There are plenty of high-profile examples either way, but as almost all of the ones in the games/computing space use the floating title style I think that's the one we should be emulating. Chris Cunningham (not at work) - talk 14:02, 13 October 2008 (UTC)
A floating title to me justs seems like a title that doesnt belong to anything. Where as when it in the infobox it gives a better impression that it belongs to the infobox. Salavat (talk) 14:09, 13 October 2008 (UTC)
If you don't mind me upending the tea table, here's another idea—we already have the title in large letters at the article head, and in bold at the article start. Why not remove the title from the infobox altogether? Do we really need the title listed three times in one inch of screen? Pagrashtak 18:21, 13 October 2008 (UTC)
There's no guarantee that the infobox will occur at the start of an article on the same subject. I'd rather we moved closer to modern template designs and not further away from them, anyway. Chris Cunningham (not at work) - talk 19:52, 13 October 2008 (UTC)
True, but that's not what I was discussing, I'm talking about infoboxes at the top of an article. I don't understand this "modern" argument. If I made the template red, that would be a modern design, right? Because I just did it? Pagrashtak 20:03, 13 October 2008 (UTC)
If it sticks and people like it enough to copy it around in other templates, yes. That's what I'm rolling with here. As for optionally omitting the title, I'm sure it's possible using a floating title and conditionals - {{infobox}}-based templates allow for this, so we could perhaps crib code from {{infobox}} to allow it. Chris Cunningham (not at work) - talk 20:07, 13 October 2008 (UTC)

Another problem—the proposed change appears to disable collapsibility. I'm disabling the edit request. Pagrashtak 14:43, 16 October 2008 (UTC)

Um, on a sidenote, is there any reason why the infobox and related tables have all suddenly lost their formatting and borders? Der Wohltemperierte Fuchs (talk) 19:00, 16 October 2008 (UTC)
I don't see that. Pagrashtak 19:14, 16 October 2008 (UTC)
Huh. Now it's back. Strange. Der Wohltemperierte Fuchs (talk) 20:26, 16 October 2008 (UTC)

Serial Number

For Example SLES-54030 for the ps2 version of Criterions´Black, would be a good thing to have. People often search for info on PS games on their serial numbers. —Preceding unsigned comment added by 213.243.133.127 (talk) 09:37, 13 October 2008 (UTC)

We aren't a directory- what use is this to a general reader to understand the work? Der Wohltemperierte Fuchs (talk) 13:38, 13 October 2008 (UTC)
Well, we do include ISBN numbers for books. Scapler (talk) 21:08, 16 October 2008 (UTC)
I don't see how it would do any harm. --jamdav86 (talk) 18:14, 9 November 2008 (UTC)
ISBNs and game serial numbers really aren't comparable, as ISBNs are designed to be an international standard way of identifying a book; last time I checked, you don't search for games by plugging in a serial number. Der Wohltemperierte Fuchs (talk) 20:40, 9 November 2008 (UTC)

{{Editprotected}} Wouldn't it be wise to link the "arcade system" field to the arcade system board article? I'm not completely familiar with the subject matter, but the article is already covered in this template's documentation. Haipa Doragon (talk • contributions) 01:10, 29 November 2008 (UTC)

 Done --CapitalR (talk) 01:07, 31 March 2009 (UTC)

Release dates

Just a question as I don't have the patience to sift through the archives. According to the syntax guide, Japanese release dates should not be included for any game not developed in Japan. I find this ridiculous as Japan is such a huge gaming market. Would it be possible to change the language in the syntax guide or is there a reason for leaving out the release date for the second largest gaming market? Bovineboy2008 (talk) 02:30, 31 December 2008 (UTC)

Here is one related discussion. MrKIA11 (talk) 21:09, 31 December 2008 (UTC)
Thanks! I think this should be discussed in more depth but I am all for what was discussed. Bovineboy2008 (talk) 21:39, 31 December 2008 (UTC)

Default Collapsible State

{{editprotected}}

Please change: 

{| class="{{#ifeq:{{{collapsible|}}}|yes|collapsible {{{state|autocollapse}}}}}

to 

{| class="{{#ifeq:{{{collapsible|}}}|yes|collapsible {{#if:{{{state|}}}|{{{state}}}|autocollapse}}}}

so that having a blank state parameter will default to autocollapse. MrKIA11 (talk) 18:33, 8 January 2009 (UTC)

Don't most infoboxes not have this filled it, so it would collapse them? Der Wohltemperierte Fuchs (talk) 19:33, 8 January 2009 (UTC)
They would only collapse if {{{1}}}. MrKIA11 (talk) 19:35, 8 January 2009 (UTC)
Done. --Elonka 19:48, 11 January 2009 (UTC)

Producer

I still think it makes more sense to put a game producer in a Producer section instead of designers. This infobox already has a designer, composer, artist and writer, so why shouldn't there be a producer. Again, I think it makes more sense that way.--EclipseSSD (talk) 20:36, 25 January 2009 (UTC)

Er, I'd like a response please. --EclipseSSD (talk) 20:08, 11 February 2009 (UTC)

Padding

Most of Wikipedia's nav/info boxes have a slight gap around the edges. I was wondering if you could add on to this one. I think it looks better. SharkD (talk) 11:56, 9 February 2009 (UTC)

Basically I think if it looked more like the project front page it would be better. I liked this version more. SharkD (talk) 12:22, 9 February 2009 (UTC)
AFAIK, the current version has a 3px padding, which is the same as that link. The main page has a 5px padding, which I guess could be done. MrKIA11 (talk) 23:11, 9 February 2009 (UTC)
I meant the padding of the outer-most HTML element. Since the outermost element is a table, the property to change is the table's "cellspacing" attribute which is currently set to zero. SharkD (talk) 23:28, 9 February 2009 (UTC)
Here's an example of what I am talking about. SharkD (talk) 01:20, 18 February 2009 (UTC)

It's high time someone figured out how to get alternating bands of colour for successive data fields working in {{infobox}} and just migrated this over to the template everyone else is using, to be honest. It's silly to have to maintain a separate fork of the infobox code for the sake of some trivial aesthetics. Chris Cunningham (not at work) - talk 22:06, 9 February 2009 (UTC)

Image size in infobox: 256px

{{editprotected}} In keeping with the discussion at Wikipedia talk:WikiProject Video games/Archive 64#Image size in infobox, the template should be modified. The first line of the template code, which is... 

{| class="{{#ifeq:{{{collapsible|}}}|yes|collapsible {{#if:{{{state|}}}|{{{state}}}|autocollapse}}}} infobox vevent" style="float:{{{align|right}}}; width:{{#if:{{{width|}}}|{{{width|}}}|264px}}; font-size:90%; text-align:left;" cellspacing="0" cellpadding="3"

...should be changed to... 

{| class="{{#ifeq:{{{collapsible|}}}|yes|collapsible {{#if:{{{state|}}}|{{{state}}}|autocollapse}}}} infobox vevent" style="float:{{{align|right}}}; width:{{#if:{{{width|}}}|{{{width|}}}|268px}}; font-size:90%; text-align:left;" cellspacing="0" cellpadding="3"

And in the documentation, this...

To avoid stretching the Infobox overlarge, avoid using images with a width greater than 250 pixels. Where possible use 250px, as it gives the best fit. Wiki: [[Image:name.ext|250px]]

...should be changed to...

To avoid stretching the Infobox overlarge, avoid using images with a width greater than 256 pixels. Where possible use 256px, as it gives the best fit. Wiki: [[Image:name.ext|256px]]

Thanks! Megata Sanshiro (talk) 08:37, 11 February 2009 (UTC)

Personally I'm not bothered which size is used but I think it needs broadcasting more so that everyone is singing from the same hymn sheet. Only yesterday I had the image in a new article reduced from 256 to 250. - X201 (talk) 09:02, 11 February 2009 (UTC)
...Because we have what's on this page as recommendation vs. actual practice. --Der Wohltemperierte Fuchs (talk) 12:41, 11 February 2009 (UTC)
Why not keep it at 250px, a nice round number? MrKIA11 (talk) 13:28, 11 February 2009 (UTC)
Im up for this idea but only if its made wide spread knowledge, so that it stops people constantly reverting changes to 250 back to 256. And then this should be highlighted in the guidelines as something to reference back to if reverting happens. Salavat (talk) 13:51, 11 February 2009 (UTC)
28 is pretty round to me... --Izno (talk) 14:04, 11 February 2009 (UTC)
Yeah, but you don't put [[File:...|28]]. MrKIA11 (talk) 14:13, 11 February 2009 (UTC)
256 is a standard computer thing, going from the number two. File sizes, processor speeds, your screen's resolution, the resolutions cameras take pictures at, its all done in factors of two from the number eight: 8, 16, 32, 64, 128, 256, 512, 1,024, 2,048, all the way up to and past 1,073,741,824 (the amount of 1GB). Having it at 256 makes more sense from the technical viewpoint, making 250 seem more arbitrary. -- Sabre (talk) 14:22, 11 February 2009 (UTC)
I understand the significance of 256, but when it comes to this, why does it matter? We can make the infobox 256px wide, with 3px padding, which would leave 250px left for the pic. Perfect. MrKIA11 (talk) 14:27, 11 February 2009 (UTC)
having the width be a power of 2 is cute, but I don't see that it has any other advantage. Chris Cunningham (not at work) - talk 15:07, 11 February 2009 (UTC)
There's no intrinsic advantage. It's just that the majority of current cover art images are 256px wide. As said in the archived discussion, it's already the de facto standard. If we decide to make 250px the standard in the guidelines, that would not automatically affect all these images. They would still be 256px wide in the articles, but they would basically go against a (de jure) standard. Megata Sanshiro (talk) 18:56, 11 February 2009 (UTC)

Edit request disabled. Please achieve consensus before re-enabling. --- RockMFR 19:36, 11 February 2009 (UTC)

this infobox really needs a section for DRM

Since DRM has become such an issue with video games it should be predominantly displayed alongside the system requirements and other quick facts normally found in this infobox. I propose an addition of a DRM handler within this infobox. Thesazi (talk) 19:02, 15 February 2009 (UTC)

I would agree to this. SharkD (talk) 03:25, 16 February 2009 (UTC)
Oppose - Any problems with it being an issue should be dealt with in the relevant article(s) about copy protection and its various trade names. The infobox is meant to be a brief overview of the prose of the main article and not, as it has started to become, a simple form that people fill in and think that the job is done. If the form of copy protection used on a piece of software was notable and of such massive importance as to warrant an infobox field, the form of copy protection would already be in the prose of the vast bulk of VG articles but, apart from a few high profile cases, its not. - X201 (talk) 09:20, 16 February 2009 (UTC)
Also oppose. The method of DRM is not always known - and I will say, knowing how people are about it, they will want to know the version and the brand, which requires some bit snooping which may be in violation of the DMCA, if not just WP:OR. If DRM affects the game's reception (ala BioShock or Spore) then an appropriate section should be included in the article, but an infobox entry begs too much. --MASEM 13:55, 16 February 2009 (UTC)
Will the snooping no longer be in violation of the DMCA if it is mentioned in the prose instead of an infobox? Also, if game A and game B both have DRM type X, will the effect on reception be different somehow? SharkD (talk) 01:22, 18 February 2009 (UTC)
In some cases, the copy protection comes to light by a long string of findings, ending with notice by reliable sources; by this point, it's moot if it's a DMCA issue, but we'd clearly not be citing original research to include it. And yes, there are games with the same copy protection but have different impacts, but that's namely due to a more popular or highly anticipated game having issues over one less popular (see BioShock, Spore (2008 video game) for examples). Most of the time, the copyprot isn't a major issue. --MASEM 20:13, 18 February 2009 (UTC)
Oppose also. A similar idea was proposed at Wikipedia talk:WikiProject Video games/Archive 61#Infobox VG: Copy protection field? and rejected. Pagrashtak 19:24, 18 February 2009 (UTC)
Oppose - Not all games have DRM and though many do, it is not applied in the same way. If the infobox says a game uses Securom DRM, what does that really mean for the end user? It's something a reader would have to look into, which defeats the purpose of the infobox. 98.71.195.184 (talk) 08:24, 8 August 2009 (UTC)

Collapsible Padding

{{editprotected}} Apparently something was changed somewhere, but now there is no need for the {{pad|5em}} in the code. Please change 

! colspan="2" | <div style="font-size:110%; text-align:center;" class="summary">{{#ifeq:{{{collapsible|}}}|yes|{{pad|5em}}}}''{{#if:{{{title|}}}|{{{title}}}|{{PAGENAME}}}}''</div>

to 

! colspan="2" | <div style="font-size:110%; text-align:center;" class="summary">''{{#if:{{{title|}}}|{{{title}}}|{{PAGENAME}}}}''</div>

I also changed the sandbox, and the change can be seen with the test case. Thanks, MrKIA11 (talk) 17:51, 18 February 2009 (UTC)

Done. Cheers. --MZMcBride (talk) 18:50, 18 February 2009 (UTC)
Thanks for the quick response. MrKIA11 (talk) 18:53, 18 February 2009 (UTC)
Are you sure? Look at the first example in the template docs: the title looks to me as if it is in need of padding. SharkD (talk) 19:12, 18 February 2009 (UTC)
It seemed like it didn't need any padding anymore, but it might be that it just needed less. Does the test case look better now? I changed it from the original 5em padding to 2em. MrKIA11 (talk) 20:26, 18 February 2009 (UTC)
That's better, except that the title shifts slightly to the right and left when you hide/show the template. The {{navbox}} code however doesn't require any padding at all, and also doesn't "jitter" when you collapse/uncollapse the template, so you might try and copy the code from there. SharkD (talk) 00:11, 19 February 2009 (UTC)

Small change

| aspect ratio   =<br />
| resolution     =

Neither of these relate to the PC platform. Suggest: 

| console aspect ratio   =<br />
| console resolution     =

—Preceding unsigned comment added by NutterguyIrl (talk • contribs) 10:54, 26 February 2009

Not only would this break existing deployments, but it isn't strictly true. Until very recently most PC games assumed a resolution and many still assume an aspect ratio (Command and Conquer Generals, for instance, has no widescreen resolutions). Chris Cunningham (not at work) - talk 18:24, 5 April 2009 (UTC)

Minor style edits

{{editprotected}}

Requesting sync with the sandbox for some minor syntax tweaks. Should be no impact on deployed templates. Chris Cunningham (not at work) - talk 18:27, 5 April 2009 (UTC)

Done. --CapitalR (talk) 22:10, 5 April 2009 (UTC)

Maximum level

I'd like to suggest we add another (optional) field to the template for maximum level. A lot of games have a level cap and it'd be convenient to include it in an infobox. Vicarious (talk) 00:58, 3 May 2009 (UTC)

Not an appropriate piece of information for an infobox, as it is only useful to gamers, not the general reader. --MASEM (t) 01:07, 3 May 2009 (UTC)

Add another field

{{editprotected}}I think we should add Reviews to the infobox like the music one has. I think it would be a good addition. You know the 4 out 5 stars thingy.--Fire 55 (talk) 03:59, 4 May 2009 (UTC)

Reviews at the bottom of the article are where they should remain, to be honest. --Izno (talk) 00:13, 5 May 2009 (UTC)
Please get consensus before using editprotected. —TheDJ (talk • contribs) 00:27, 5 May 2009 (UTC)

But what makes it ok to for Music to have it in the infobox box than Video Games. It's useful info that everyone who looks up the video games would like to know, so shouldn't it be in the INFObox since it's useful INFO.--Fire 55 (talk) 03:33, 7 May 2009 (UTC)

Reviews of music aren't generally as forthcoming as reviews for videogames, hence shoving a couple into the music infobox is acceptable. Shoving the entire contents of {{VG Reviews}} into the infobox would either make a mess, or if only a few were added, be accused of cherrypicking reviews (a charge already levelled at {{VG Reviews}} by some). The template in the reception section does the job well enough. -- Sabre (talk) 10:23, 7 May 2009 (UTC)

Add series next and past

In a videogame serie we should add whic comes before and after, like:

|series = The Legend of Zelda |past = A Link to the Past |next = Ocarina of Time

What do you think? Can somebody add this? OboeCrack (talk) 11:11, 15 May 2009 (UTC)

This has been discussed many times 1, 2, 3, 4, 5 and 6--SkyWalker (talk) 11:42, 15 May 2009 (UTC)

Sequel / predecessor

Since a lot of games (in fact: countless) have a sequel and/or predecessor (right word?), it may a good idea to add those lines to this template.
An example is given in Template:Infobox Film, like Shrek 2.
In its template on its article, it says:

Preceded by Shrek
Followed by Shrek the Third

Examples of video games with sequels and predecessors are The Sims 1-3, GTA 1-4, almost all of them! I think it's right to remain the series articles, but it wouldn't be of much costs to add those lines, right? And it would be very informative on the games articles. Maybe it would even be wise, to create a bot for all games in %game name% (series) to add the info.
Dr. F.C. Turner - [USERPAGE|USERTALK] - 11:00, 9 July 2009 (UTC)

Never mind, read above. BUT: a lot people DO want this. It's just that it MAY run out of hand. We should treat that, then. Not by not creating this, in my honest opinion. Dr. F.C. Turner - [USERPAGE|USERTALK] - 11:03, 9 July 2009 (UTC)

Tag for copy protection

Regarding the fact that this was discussed years ago (since '07 if i remember) it was already added around january '08 or so and finally once more rewiped.

I think a tag for copy protection (e.g. "protection", as it was before) is existential as "version" or "licence". Concerning the problem of a bloating infobox in general - there cold be the (tag-) box divided into to sections. One for the game version, the other for the copy protection.

Every time i take a look at this one i must shake of my head, cause it's even so far not implemented. In the german wikipedia it's heavily used.

Just remember; This is an encyclopedia. ;-) That means you could/should any information related to that what you're looking for - and that's include also ways of distributions (therefore as well a/or existing copy protections).

That's what i think ...


In this sense Smartcom5 (talk) 16:02, 9 July 2009 (UTC)

So you're arguing that we should add a field for copy protection schemes? --Der Wohltemperierte Fuchs (talk) 17:21, 9 July 2009 (UTC)
That's what i've tried to ask for, yes. :-) A copy protection tag in general, no matter how it turns out. Smartcom5 (Talk ?) —Preceding undated comment added 00:29, 10 July 2009 (UTC).

Website field

{{editprotected}} There really ought to be a website field, what with the popularity of the internet these days.

75.36.145.219 (talk) 00:28, 11 July 2009 (UTC)

Websites for video games are notoriously unstable and very often cease functioning soon after a game is released. We have them in external links, I don't see any great benefit in adding it to the infobox. --Der Wohltemperierte Fuchs (talk) 02:12, 11 July 2009 (UTC)
Not done: please establish a consensus for this alteration before using the {{edit protected}} template. — Deon555talkI'm BACK! 12:38, 11 July 2009 (UTC)
I vote to include a website field. 88.148.214.15 (talk) 21:25, 12 October 2009 (UTC)
This should be included. Just because it does not work for every game it does not mean that it should not be an option for the ones it does work. Not every actor has a spouse does that mean that we should remove it from the infobox?--Sgv 6618 (talk) 20:58, 14 December 2009 (UTC)
And what's wrong with linking to it in the external links section? Such a field is entirely redundant. -- Sabre (talk) 21:46, 14 December 2009 (UTC)

For MMOs: Status and/or shutdown dates

It really should have these fields for MMOs that have been discontinued. Smurfy 15:00, 2 August 2009 (UTC)

I agree. A "Discontinued" field would be nice. SharkD  Talk  06:26, 29 November 2009 (UTC)

Use the new infobox meta-template

{{editprotected}} This infobox needs to be updated so that it uses the new Infobox template. I'm aware that a consensus is usually required, but I believe that this is an acception, since it will make the template easier to edit in the future. --Josh (Meph) (talk) 10:37, 20 August 2009 (UTC)

Please use a sandbox to prepare the new code. Editprotected it is a call to execute a specific action, not an attention beacon. —TheDJ (talk • contribs) 11:03, 20 August 2009 (UTC)
Furthermore, this was already discussed in the past and rejected, mostly because {{infobox}} doesn't currently support the row-striping that this version does. Mephiles602, please note that even if a request is uncontroversial it should always be accompanied by clear instructions when using the {{editprotected}} template, and this one wasn't. Chris Cunningham (not at work) - talk 12:20, 20 August 2009 (UTC)
I see. I apologise for making that mistake. --Josh (Meph) (talk) 17:46, 21 August 2009 (UTC)

I'm not sure if I like it or not, but I changed the sandbox to use the template. MrKIA11 (talk) 12:24, 20 August 2009 (UTC)

The main differences that I see are the row-striping, and more importantly, collapsibility. MrKIA11 (talk) 12:37, 20 August 2009 (UTC)
I would also like to see an example of it in action. I.e. an actual article. SharkD  Talk  06:28, 29 November 2009 (UTC)
IMO it looks fine on articles: I tested an {{infobox}}-based variant over a year ago on articlespace. But consensus in any previous discussion has been that until {{infobox}} supports row-striping this template will probably use custom code. Ideally efforts would be spent getting row-striping to work in {{infobox}}, but sadly this is by no means trivial. Chris Cunningham (not at work) - talk 11:58, 3 December 2009 (UTC)

CPU

{{editprotected}} [[CPU]] needs to be changed to [[Central processing unit|CPU]]. No point in having a redirect across dozens, maybe hundreds, or articles for no reason. Just this simple change will fix that. TJ Spyke 02:44, 7 September 2009 (UTC)

 Done - you would've had a much quicker response had you not used "tl" to nullify the edit protected template. –xenotalk 22:55, 26 September 2009 (UTC)

number of players on the same map

The number of players on the same map interests me. For example in the case of Battlefield Heroes There could be players = 16. Or multiplayer = 16 players on the same map in 2 teams.

I would be interested in knowing the number of "simultaneous players" too; but I don't think it will likely fly with anyone else here. SharkD  Talk  06:25, 29 November 2009 (UTC)

Producer, director

{{editrequested}}

I think there should be seperate parameters for game producer and game director, because it doesn't make sense them being in the designer parameter. They are seperate jobs, therefore they should have their own parameters. --TaerkastUA (Talk) 13:47, 18 October 2009 (UTC)

OK, put the {{editrequested}} tag up once there is a complete and specific description of the change needed, and consensus for its implementation. Mahalo,  Skomorokh, barbarian  11:07, 20 October 2009 (UTC)
To specifiy, I think there should be new parameters added for game producer and game director, because those specific jobs are different to game designer. --TaerkastUA (Talk) 10:55, 24 October 2009 (UTC)
In the end the changes would look like this:
| designer     =
| director     =
| producer     =
| writer         = 
| artist         =
| composer       =

I can't put it clearer than that. I think game director and game producer should have their own parameters. --The Taerkasten (talk) 19:47, 16 November 2009 (UTC)

While we're at it, there's no parameter for programmers. Shouldn't there be, if there's artist and composer? Amalthea 01:36, 20 November 2009 (UTC)

So the code that would need to be put in would be this: -- Sabre (talk) 21:29, 21 November 2009 (UTC) 

|{{#if:{{{director|}}}| {{!}} '''[[Game director|Director(s)]]''' {{!!}} {{{director|}}} }}
|{{#if:{{{producer|}}}| {{!}} '''[[Game producer|Producer(s)]]''' {{!!}} {{{producer|}}} }}
|{{#if:{{{designer|}}}| {{!}} '''[[Game designer|Designer(s)]]''' {{!!}} {{{designer|}}} }}
|{{#if:{{{artist|}}}| {{!}} '''[[Game artist|Artist(s)]]''' {{!!}} {{{artist|}}} }}
|{{#if:{{{writer|}}}| {{!}} '''Writer(s)''' {{!!}} {{{writer|}}} }}
|{{#if:{{{composer|}}}| {{!}} '''[[Video game music|Composer(s)]]''' {{!!}} {{{composer|}}} }}

User:S@bre/Infobox VG/Test This would produce this --------------------------------->
I suppose Taerkaste does have a point here: increasingly, producers and directors aren't designers, so when these people are important to development and notable in their own right, it is innaccurate to lump them as "designers", especially if they haven't actually done any design work. Take Psychonauts, which I've used for testing purposes here. Tim Schafer is a designer by trade; however, in this case, he's credited creative direction and writing. He's not credited for any of the design work, so its not really fair to put him down as the game's designer: he wasn't, Erik Robson was. I'm less convinced about the need for a programmer field, but I've included it in the example anyway.

Note that in practice, the Psychonauts example would not use the producer, programmer or designer fields, as the individuals for them aren't notable in their own right. If we're going to include these, we need to hold them to the same stipulations as the other creative individual fields: they should only be used if the person concerned is notable by our standards. I've only included them for this to demonstrate all the creative individual fields in use.

For those who will worry that this just turns the infobox into a credits list, I'd firstly say that linking notable people in this fashion is probably more useful to the general reader, as {{Infobox film}} is all the better allowing similar people-navigation for these sorts of fields, than the more technical stuff such as "aspect ratio", "version", "media", or the omnipresent-yet-actually-worthless field that is "input methods". I'd also point out that its very unlikely that all these fields would be used at once in most articles—as such, overly lengthening the infobox isn't likely to be a problem either.

Feel free to debate the best order to put them in, I didn't really put them in an order, beyond thinking that "director" should be first. -- Sabre (talk) 21:29, 21 November 2009 (UTC)

I agree with the fact that only notable-enough people should be included. In terms of the order, it wouldn't really matter too much, but director should come first.--The Taerkasten (talk) 14:03, 22 November 2009 (UTC)
Tweaked the order slightly, trying to keep broadly related jobs together, so director and producer are together, so are designer and programmer, with the in-between job of artist linking to the less technical writer and composer fields.-- Sabre (talk) 18:37, 23 November 2009 (UTC)
It doesn't look too bad, although I think most people will be used to seeing things like "Publisher(s)", not "Published by", but I think it works.--The Taerkasten (talk) 19:08, 26 November 2009 (UTC)

I think that listing all this info in an infobox is somewhat excessive. SharkD  Talk  12:19, 3 December 2009 (UTC)

Care to explain why? Do bear in mind that the average article isn't going to list all this information at once, only when appropriate. -- Sabre (talk) 17:06, 3 December 2009 (UTC)
Infoboxes aren't necessarily accessible to all of our users, so they should never contain information which isn't in the article body. They are not just statistics dumps. This template is already suffering from triviaitis as it is. Chris Cunningham (not at work) - talk 18:16, 3 December 2009 (UTC)

If the producer(s) and/or director(s) are notable enough they should definitely be included as in film articles. Like Sabre said, many of the producers and directors aren't notable and therefore don't need to be included. I'm in favour of adding these parametres for better organisation, but I think it should be Director(s), not Directed by, Producer(s) not Produced by etc. Programmers are generally not notable, so they can be excluded. In the example you've provided, the producer and designer don't have articles, so they should probably be removed. The Prince (talk) 18:35, 3 December 2009 (UTC)

Exactly. The only reason all fields are used in my example on this page is to demonstrate them in use, not any statement of intent that every article should use them. In the Psychonauts example, only one field of the new ones would be used: "Director". That would be used in place of the "designer" field, since Schafer is key to the game's development but is not the designer—in this case, Chris, his role cannot be categorised as trivia (or a statistics dump, which completely loses me, since people aren't statistics) and in any comprehensive coverage would certainly have to be mentioned in the body of the article. I cannot think of a single example where more than one of the producer, designer or director fields would have to be used, so there is really no effect on length or accessibility; it merely allows us to label the jobs properly. If you want to get rid of trivial fields that very rarely get any prose mention, fields like "input methods", "license", "version", "cpu" and even "ratings" come to mind far more than the fields for people. -- Sabre (talk) 18:47, 3 December 2009 (UTC)
That's something which should be discussed. In particular, "input method" is utter cruft in almost every case and yet it's included on practically every infobox. But let's get back to that later. Chris Cunningham (not at work) - talk 09:01, 4 December 2009 (UTC)
The programmer field—which unlike the designer/producer/director fields isn't about getting accurate nomenclature and is going to add an extra length in practice—is the one I still remain skeptical about myself, for much the same reasons as Prince. Its only in the current test version for the purposes of disussion. -- Sabre (talk) 18:55, 3 December 2009 (UTC)
Some game articles, such as those of the Final Fantasy series do list their directors and producers (in the designer field), so I think those are relevant. As for programmer, I think that might be pushing it a bit in terms of numbers, e.g. a game probably has many programmers, so I don't think that should be included.--The Taerkasten (talk) 20:14, 3 December 2009 (UTC)
Alright, I've removed the programmer field from the sandbox, since its clear that one in particular isn't popular. -- Sabre (talk) 21:23, 3 December 2009 (UTC)
"Programmer" is covered by "developer" for any instances where it's notable anyway (basically for 8-bit games with one-person development). Chris Cunningham (not at work) - talk 09:01, 4 December 2009 (UTC)

Given that only one person has solidly spoken out against this, I'm going to add director and producer to the infobox on Saturday if no-one else comes into the discussion with objection. I think this discussion's been going long enough; I've informed the project on two occasions, so there's been plenty of opportunity for others to comment. When added, I'll make sure to update the documentation to make clear that the fields are only to be used when the entry is for some of significant note whose role is key to development. -- Sabre (talk) 23:17, 10 December 2009 (UTC)

 Done. -- Sabre (talk) 12:48, 12 December 2009 (UTC)


Oops, didn't keep track of answers here, sorry for that. I kept expecting to find John D. Carmack's name in the infoboxes of Wolfenstein 3D and the Doom series, which is why I came here when I wanted to list him. Now that I took a look, I would have expected to find others like Dave Grossman (game developer) and Tim Schafer, who have both done work as programmers in their early days, to be listed in infoboxes in that capacity as well in a number of games.
We actually have a number of notable video game programmers, see Category:Video game programmers for a bunch. If you want to get down to numbers, we have far more articles on notable game programmers than on notable Category:Video game artists or Category:Video game directors. Amalthea 00:32, 16 December 2009 (UTC)

Any opinions? Amalthea 10:15, 5 January 2010 (UTC)
I've added it to the template. Amalthea 18:00, 12 January 2010 (UTC)

Please, add section: Related Games Vilnisr (talk) 18:42, 10 December 2009 (UTC)

We have navboxes at the bottom of articles for that, we don't need it in the infoboxes as well. -- Sabre (talk) 18:47, 10 December 2009 (UTC)

Edit protecte

{{editprotect}} Apparently whoever added these a few days ago didn't bother to put the right links in and I can't fix it since the template is fully protected. "Game director" needs to be changed to "Video game director" and "Game producer" needs to be changed to "Video game producer". TJ Spyke 23:50, 15 December 2009 (UTC)

This is a fix I can get behind.  Done [1] –xenotalk 23:58, 15 December 2009 (UTC)
To be fair, I did change the director field when I realised. It wasn't a case of "didn't bother" as you insinuate, just "didn't know" as far as the second field is concerned. -- Sabre (talk) 00:28, 16 December 2009 (UTC)

No documentation for 'genre' field?

There seems to be no mention of the 'genre' field in the documentation. Is it supposed to be "general" like "Real-time strategy" or can it be specific like "Dungeon crawler"? --Remy Suen (talk) 03:52, 5 January 2010 (UTC)

Media field

Can someone write a definition for the media field, or is it deprecated?  æronphonehome  03:03, 19 January 2010 (UTC)

standardization of input methods

Sometime ago I started a discussion topic on the Video games wikiproject that should have probably been addressed here instead of there... It's about the standardization of input methods on the Infobox VG template, and you can find it here. If anyone would care to comment or shed some light on the topic, please do as we are in somewhat of a standstill with diverging opinions. NeoGenPT (talk) 00:02, 12 February 2010 (UTC)

Name

I propose a rename of this template to Template:Infobox video game. This would more in line with other infoboxes and would be a clearer and more descriptive name. It is not clear from the name what Infobox VG is for. — Martin (MSGJ · talk) 09:14, 6 March 2010 (UTC)

I have no problem with it, but I think a suggestion like this should be discussed on WT:VG. MrKIA11 (talk) 15:32, 6 March 2010 (UTC)
Wikipedia talk:WikiProject Video games#Infobox VG name and subtemplate. MrKIA11 (talk) 22:08, 6 March 2010 (UTC)
Respectfully disagree - we are discussing this template and the correct place for the discussion is here. Of couse you are welcome to advertise the discussion over there though. — Martin (MSGJ · talk) 08:52, 7 March 2010 (UTC)
There seems to be no oppositon to this move, so I'll probably do it shortly. — Martin (MSGJ · talk) 19:36, 7 March 2010 (UTC)
 moved — Martin (MSGJ · talk) 13:00, 8 March 2010 (UTC)

MSGJ also moved {{vgratings}} to {{Infobox VG/ratings}}, on the basis that it is only used for that, so it should be a subtemplate, but I'm not sure if I agree with that. If the template was called internally, it would make sense, but it's not. This already causes thousands of redirects, and the number will continue to increase unless we start typing {{Infobox VG/ratings}}, which is long as it is, but will become even longer if the above proposal is accepted. And if having a subpage is the consensus, it would also make sense to move {{vgrelease}}. MrKIA11 (talk) 22:07, 6 March 2010 (UTC)

If you would like me to revert while we discuss this, please let me know. I understand the you don't want to increase what people have to type (and {{vgratings}} to {{Infobox VG/ratings}} is quite a bit longer) but what is the harm in continuing to use the redirect? Agree that {{vgrelease}} that should be moved as well, but I'll hold fire on that till we hear from others :) — Martin (MSGJ · talk) 08:50, 7 March 2010 (UTC)
The VG → video game renaming sounds reasonable. I'm indifferent to the moving of the ratings template. However, I should note that {{VGtitle}} uses the release template in a similar manner as the infobox. (Guyinblack25 talk 15:37, 7 March 2010 (UTC))
Is there any benefit of it being a subtemplate? I can't think of a single good thing. Is there even a guideline or something that would suggest it should be a subtemplate? MrKIA11 (talk) 16:37, 7 March 2010 (UTC)
I don't believe there is any guideline about this. When a template is used exclusively in conjunction with another template I believe it is more logical to use the subtemplate system for the following reasons:
  • It is immediately clear from the name that it is part of the {{Infobox VG}} system.
  • You've got that handy link at the top back to the main template.
  • The subtemplate talk pages can be redirected to the main template talk page, {{Central}} can be used, and discussion about the templates is centralised at one location. Then editors don't need to watchlist several different templates and do not miss relevant discussion taking place on other pages.
As I mentioned there is no reason to stop using the shorter name as a redirect. Anyway I've reverted the move for now as there was opposition to it. Regards — Martin (MSGJ · talk) 19:34, 7 March 2010 (UTC)
PS, I've just digested Guyinblack25's comment about {{Vgratings}} being used by another template, and this definitely weakens my argument. — Martin (MSGJ · talk) 19:38, 7 March 2010 (UTC)
{{VGtitle}} uses {{Vgrelease}}, not {{Vgratings}}. The ratings are excess detail in lists, so there are no plans to use the ratings template in them. Release dates, on the other hand, are more vital for lists. (Guyinblack25 talk 16:31, 8 March 2010 (UTC))
Redirects are generally bad for the server, aren't they? SharkD  Talk  02:49, 10 March 2010 (UTC)
Not significantly. Redirects are cheap. Reach Out to the Truth 03:37, 10 March 2010 (UTC)
The first link also says, "Redirects for templates can cause confusion and make updating template calls more complicated. For example, if calls to T1 are to be changed to some new template TN1, articles must be searched for {{[[Template:{{{1}}}|{{{1}}}]]}} and a separate search must be made for each of its aliases (including T2 in this example)." And, I think the other pages mainly deal with articles, not templates. SharkD  Talk  20:26, 20 March 2010 (UTC)
Which rarely happens. That's just saying "please make life easier for those of us who want to rename a template and want to replace each redirect to this template with the new one". If I move a template, I just leave all the redirected templates in place; usually no reason to change them, unless the old template name is being used for an entirely different template. I use redirected template names just as much as redirected article names, since it's often easier to type a more memorable template name than to remember some arcane template name that a techie came up with. Gary King (talk) 17:56, 8 April 2010 (UTC)

Which 'released' fields to use?

I'm still kind of confused as to which 'released' fields to use. Take for example a hypothetical freeware game whose first public release was in 2005 at version 0.6, but did not reach version 1.0 until 2009. Also, which release date category should I use, Category:2005 video games or Category:2009 video games? SharkD  Talk  20:23, 20 March 2010 (UTC)

...Whichever? If the 0.x versions were alphas/betas, I assume we wouldn't count it as the "official" release, but it depends on the developer; sometimes I think they just throw in numbers to make them sound more legit (v. 1.4.3 Build 2401A6 and whatnot). Der Wohltemperierte Fuchs(talk) 18:10, 8 April 2010 (UTC)

System requirements

{{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)

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

{{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)

 Done, next time please test it :) — Martin (MSGJ · talk) 14:16, 9 May 2010 (UTC)
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)

Couple questions on name change and released field

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)

As per Guild Wars 2 Talk

{{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)

FYI, admins typically like requesters to supply the code they actually want added.--Rockfang (talk) 09:06, 19 May 2010 (UTC)
You'll also need to get a consensus for adding this field to the infobox. — Martin (MSGJ · talk) 10:46, 19 May 2010 (UTC)

Edit request from Heymid, 21 May 2010

{{editprotected}}

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

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

You need consensus first. BOVINEBOY2008 :) 22:40, 21 May 2010 (UTC)
Firstly, trivial info. Secondly, FPS usually does not depend on the game itself. —  Hellknowz  ▎talk  00:06, 22 May 2010 (UTC)

Media Section Improvements

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)

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)

Edit request

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

  • Predecessor
  • Successor
  • Tagline

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

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)
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)
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)
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)

Proposal on Platform section of infobox

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)

Notability by Country

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)

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)
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)
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)
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)
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)

"Preceded by" and "Followed by" fields?

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)

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)
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)
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)

Vgrelease bullets

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)

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)
The list doesn't appear bulleted to me and it's using the template {{unbulleted list}}. —Ost (talk) 16:30, 27 July 2010 (UTC)
I guess it's just me then. It's not a big problem.--The Taerkasten (talk) 17:45, 27 July 2010 (UTC)
Indeed. Might be a custom style sheet issue on your end? Der Wohltemperierte Fuchs(talk) 18:08, 27 July 2010 (UTC)
It doesn't appear to happen when using FireFox, I mainly use IE.--The Taerkasten (talk) 18:17, 27 July 2010 (UTC)

programming language

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)

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)
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)
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)

Add hProduct microformat

{{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)

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)
Not done: no response from proponent. — Martin (MSGJ · talk) 15:35, 18 May 2010 (UTC)
Apologies; typo for WP:UF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:48, 18 May 2010 (UTC)
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)
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)
Where? –xenotalk 15:58, 18 May 2010 (UTC)
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)
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)
If you're going to claim three-year-old consensus, the least you could do is give us a link. –xenotalk 16:13, 18 May 2010 (UTC)
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)
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. –xenotalk 16:24, 18 May 2010 (UTC)
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)
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. –xenotalk 16:31, 18 May 2010 (UTC)
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)
Where? –xenotalk 16:36, 18 May 2010 (UTC)
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)
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)
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)
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? –xenotalk 20:32, 18 May 2010 (UTC)

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

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)
I suggest you try to resolve the wider issue first before pressing ahead with this. — Martin (MSGJ · talk) 12:45, 19 May 2010 (UTC)
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)
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. –xenotalk 13:16, 19 May 2010 (UTC)
That's a gross misrepresenattion of the truth. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:19, 19 May 2010 (UTC)
Oh? So where was it that you pointed us to a discussion where it was decided these were a good idea? –xenotalk 13:22, 19 May 2010 (UTC)
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)

RfC on references in the lead section

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)

Infobox overhaul

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)

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)

 Done — Martin (MSGJ · talk) 20:55, 14 August 2010 (UTC)
Thank you, updating the documentation now. Prime Blue (talk) 21:35, 14 August 2010 (UTC)

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)

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)
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)

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)

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)
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)
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)

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)

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)
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)

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)

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)
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)
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)

Break

Okay
Developer(s)Redundant with lead?
Publisher(s)Okay
Director(s)?
Producer(s)?
Designer(s)?
Programmer(s)?
Artist(s)?
Writer(s)?
Composer(s)?
SeriesUnnecessary?
EngineUnnecessary?
Platform(s)Okay
ReleaseOkay
Genre(s)Redundant with lead?
Mode(s)Redundant with lead?
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)
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)
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)
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)
Ah, I see. Thank you! Prime Blue (talk) 19:47, 27 July 2010 (UTC)
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)
  • 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)

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)

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

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)

Kudos to Jinnai and H3llkn0wz for taking the initiative here. This discussion is long overdue. Prime Blue (talk) 17:11, 6 August 2010 (UTC)
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)

Individual field discussion

"Aspect ratio" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Developer" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Engine" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Remove - I've seen many cases where the engine is not known that users attempt to fill this in with something. If the engine the game uses is notable, it should be in the development section, but it is not a factor that people need to know "at a glance" at the box. --MASEM (t) 14:25, 5 August 2010 (UTC)
    • There is no requirement to fill in all the fields. If the engine is non-notable or unknown, the field should not be filled in, definitely no guessing. Then again, importance of engine is usually minimal. —  HELLKNOWZ  ▎TALK 14:48, 5 August 2010 (UTC)
    • And the fact that some inexperienced editors fill in the field is not much of a factor against having the field. It isn't hard for experienced editors to remove. However, there is merit in the argument that people don't need to know the game engine at a glance. I think there is a general feeling that the infoboxes have become too large. Vyeh (talk) 15:11, 5 August 2010 (UTC)
      • The point here is not so much the unknown engine factor, but that = we're in the infobox - this is the most general way of presenting information for a game. While a gamer may recognize "Source" or "Unreal Engine 3.0", these are not common terms for a general reader (unlike most of the other terms like Genre, which are not difficult to interpret). If we are removing things like Version, Input Method, Media, and the like, this seems like a natural choice to remove as well. The engine, if notable, should still be discussed in body of the article regardless. --MASEM (t) 15:38, 5 August 2010 (UTC)
  • Remove - the engine is essential info in understanding the game. If it is important, it will either be in the developer section.陣内Jinnai 20:48, 5 August 2010 (UTC)
  • Neutral on this one. Masem makes a good point, but I still like how H3llkn0wz is thinking with his opening comment for this section. -- Sabre (talk) 21:57, 5 August 2010 (UTC)
  • Neutral. Explained above Prime Blue (talk) 13:35, 6 August 2010 (UTC)
  • Weak Remove per points made by Masem. On top of that, I've seen several articles where editors take an educated guess as to what the engine is. If the name is notable enough it'll be in the development section. This opens up another can of worms though, as there are several game engines that aren't particularly of note that have articles. Odds are the game article only mentions them in the infobox, meaning once its removed it's an orphaned article nobody'll know to delete. --Teancum (talk) 14:02, 6 August 2010 (UTC)
    • I have a feeling it won't be that much of a problem if we shift sources around. If the engine is noted (and more than just, say "Havok" on the box side) it should be mentioned in the development section; it's a throwaway line but completely correct there. On the engine articles, we probably need to look at a different set of sources or border range of them. --MASEM (t) 15:58, 6 August 2010 (UTC)
  • Weak remove per Masem. For most games this isn't public knowledge and leads to errors. For games where the engine is significant they can always add it in the body of the article. Shooterwalker (talk) 14:38, 6 August 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Genre" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Keep. This is infobox material, this is why we have infobox. —  HELLKNOWZ  ▎TALK 10:18, 5 August 2010 (UTC)
  • Remove Keep. There is a degree of subjectivity in determining genres and games can straddle genres. Hellknowz persuaded me. Vyeh (talk) 12:53, 5 August 2010 (UTC) Vyeh (talk) 17:53, 5 August 2010 (UTC)
    • I don't think it has been a major problem determining game genres, even for unclear ones, there are always reliable sources that list it one way or another. If all comes to worst, this field can be omitted and explained in prose. —  HELLKNOWZ  ▎TALK 13:03, 5 August 2010 (UTC)
      • And if there is a disagreement among reliable sources? Once we see where there is a consensus for elimination, we can look at the remaining fields. Once issue that is hard to discuss in this format is the length of the infoboxes. Vyeh (talk) 15:20, 5 August 2010 (UTC)
        • Any field can have disagreements in sources, that's when we put it in prose. The field is not required if we cannot decide on what to put there.
          I think once we remove some of the current clearly unnecessary fields, the sources of length issues will become more apparent. Besides, for every field we remove here, there are 10 lines of system requirements present. —  HELLKNOWZ  ▎TALK 16:12, 5 August 2010 (UTC)
          • Maybe we should be discussing whether those ten lines really belong in an infobox! Perhaps only the OS is necessary (e.g. Windows, Mac, Linux, PSP). Anyway if what you are talking about is the genre mentioned by a RS and not the numerous WP categories (e.g 4X, strategy, computer, science fiction for Sid Meier's Alpha Centauri), then I'll change my vote. Vyeh (talk) 17:53, 5 August 2010 (UTC)
            • Well, we probably should discuss other fields and what goes in them. I only added so many headers here; there is no problem adding as many as we need.
              Anyway, "Turn-based strategy" would have probably sufficed for SMAC. This is just one of poorly filled examples. Netherthless, I bet enough sources list it as being that. I agree WP has far more division and splitting of genres than reviewers care to mention; I still wouldn't sweep those away. Common sense should prevail, I suppose. —  HELLKNOWZ  ▎TALK 18:12, 5 August 2010 (UTC)
              • I was trying to figure out why it was poorly filled example, so I went to the template to read the syntax guide for the "genre" field. It isn't there. Could I suggest that is something that could probably be corrected without waiting for the outcome of the discussion on the other fields? Vyeh (talk) 18:22, 5 August 2010 (UTC)
  • Keep - Necessary, but should reflect exactly what is in the article and sourced. --MASEM (t) 14:25, 5 August 2010 (UTC)
  • Keep Indispensable. -- Sabre (talk) 21:57, 5 August 2010 (UTC)
  • Keep. Explained above. Should of course only be used for the game genre (not for the story, because I've seen someone adding science fiction to the genre for Resident Evil 4). Prime Blue (talk) 13:35, 6 August 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Input method" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"License" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Resolution" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • The problem is getting the citation. The field states that it should be the "The native resolution that a game is rendered at.". That info is rarely published by the developers/publishers. In the main, we are relying on three trustworthy people for this info; Richard Leadbeater at Digital foundry (via Eurogamer) and Al_Strong and Quaz51 from the Beyond 3D forum (these two only become notable when a reliable third party publication runs with their posts). I want to repeat, in no way am I questioning their competency at what they do, my problem comes with the fact that their expertise is only available for high profile releases. The vast majority of games haven't got, and never will have, citable information for the resolution field. - X201 (talk) 17:45, 6 August 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Media" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • 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)
    • 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)
  • Remove. Vyeh (talk) 12:53, 5 August 2010 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
    • Can we limit it to preset values? Such as "cartridge", "download", "CD", "DVD", etc.?—  HELLKNOWZ  ▎TALK 15:06, 6 August 2010 (UTC)
      • Or even to "cartridge", "download", and "disc", maybe? Salavat (talk) 15:25, 6 August 2010 (UTC)
        • 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)
          • 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)

  • 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)
  • 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)
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 values possible for the field are "Download", "Physical", and "Cloud computing" (and combinations thereof). 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)

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)
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)
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)
We can add the "distribution" field then (always used) and restrict the "media" field to games on these old platforms where the media of at least one platform is ambiguous (e.g. MS-DOS, Windows, MSX, etc.) with the only options being "Floppy disk", "Cartridge", "Memory card", and "Optical disc" (and combinations thereof). This will even cover the media of old games that got ported to newer platforms with only one type of media, 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)
That's fine as long as the download and cloud are added for newer forms of distribution.陣内Jinnai 21:43, 20 August 2010 (UTC)

{{editprotected}} No objections to the "distribution" field, so I added it. New code is in the sandbox. Prime Blue (talk) 15:18, 24 August 2010 (UTC)

 Done — Martin (MSGJ · talk) 18:30, 24 August 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"Modes" field

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • 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)
    • 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)
  • Remove. Vyeh (talk) 12:53, 5 August 2010 (UTC)
  • 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)
      • 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)
        • 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)
          • 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)
            • 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)
  • 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)
  • Remove. Explained above Prime Blue (talk) 13:35, 6 August 2010 (UTC)
  • 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)
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)

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)
Just forgot to add that. Could you explain what you mean by syntax, though? Prime Blue (talk) 17:24, 18 August 2010 (UTC)
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)
I'll restrict it to the two values for now. I don't know the exact scheme you have in mind for making it more automatized, but that can still be implemented once there is something more concrete. Prime Blue (talk) 00:22, 25 August 2010 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

"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)
  • Keep. Vyeh (talk) 12:53, 5 August 2010 (UTC)
  • Keep, same reason as Hellknowz. - X201 (talk) 13:17, 5 August 2010 (UTC)
  • Keep, absolutely necessary. --MASEM (t) 14:25, 5 August 2010 (UTC)
  • Keep Chimpanzee - User | Talk | Contribs 18:18, 5 August 2010 (UTC)
  • 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)
    • 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)
      • 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)
        • 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)
          • 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)
            • 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)
              • 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)
                • 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)
                  • 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)

                    • 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)
                      • 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)
  • Remove. Explained above Prime Blue (talk) 13:35, 6 August 2010 (UTC)
  • 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)
    • 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)
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)

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)
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)
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)
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)
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)
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)
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)
  • 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)
  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)
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)
  1. I was talking about the opposite, applying it to all articles.
  2. See #1
  3. Read further. There is a discussion (however improper that its there) talking about applying standards for series in infoboxes in addition to navboxes. It's not apparent unless you start reading down some though.陣内Jinnai 03:13, 20 August 2010 (UTC)
1. The first time you answered to point 1, you justified keeping the series field with keeping the title field. You mentioned applying the series field to all articles in point 2 – you are mixing your arguments up.
2. Did not address what I brought up in my answer at all, you merely repeated yourself.
3. Again, this discussion is about links to article series, not links to series articles. If you don't believe me, ask Noleander. Prime Blue (talk) 15:04, 20 August 2010 (UTC)

I'm still for keeping the field as my concern "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." remains unchallenged. Jonathan Hardin' (talk) 10:14, 20 August 2010 (UTC)

For easy-to-access wikilinks, we use navboxes. See Help:Infobox as well: "An infobox is a fixed-format table designed to be added to the top right-hand corner of articles to consistently present a summary of some unifying aspect that the articles share and to improve navigation to other interrelated articles." What the field currently does is link to an overarching series article, it does not improve the navigation to other interrelated articles. This also ties directly in with point 3 mentioned above. Prime Blue (talk) 15:04, 20 August 2010 (UTC)
We use many items for ease-of-access.
As to the previous point, neither of those conflict for point #1. Series is justified in the same way the title is justified in being there and that applies to all articles which are part of a series.陣内Jinnai 17:21, 20 August 2010 (UTC)
Jinnai, repeating your previous arguments without replying to my answers makes a structured discussion impossible. Prime Blue (talk) 20:11, 20 August 2010 (UTC)
You're points have mostly been seen as an essential aspect and that it could be left in and used on a case-by-case basis. My point is that it is essential and that that making case-by-case needlessly complicates something because its not always apparant what should be done. I gave a good example of how their can be conflicts with Dragon Warrior and Dragon Quest 4 where the former would have the series title and the latter would then be under dispute because some people will think "hey it says Dragon Quest, so it should be obvious what the series is" and others will argue the point of conforminality so things look the same, ie "since Dragon Warrior needs it, then regardless of whether Dragon Quest 4 is obvious, for the sake of keeping the templates between series titles similar, they should all have the series listed".
In essence, making it so that some have it and some don't only complicates things and brings more room for e-lawyers to manuver.陣内Jinnai 21:34, 20 August 2010 (UTC)
You can stop arguing that the field is "essential" for every case, as I do not think so – and I don't think either of us will change our minds on this. For the rest, see point 2 here.
Keeping a field for all cases for the sake of conformity is not the best reason either: There will always be articles where some fields of the infobox are not used. Actually, limiting a field is the exact same thing we did for "media" above. You agreed with it there, so I don't see why it should be a problem here. It won't be the decline of the west. Prime Blue (talk) 14:55, 21 August 2010 (UTC)

"System Requirements" field

Previously: [2] [3] [4] [5] [6] [7] [8] [9] [10], 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)
    • (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)
      • 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)
  • 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)
    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)
    (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)
    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)
    Is that not what |platforms= is for? Media is for stuff like CD-ROM or DLC.—  HELLKNOWZ  ▎TALK 21:43, 5 August 2010 (UTC)
    Not for HD space.陣内Jinnai 18:56, 6 August 2010 (UTC)
    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)
  • 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)
  • Keep. But possibly make it collapsible. Prime Blue (talk) 13:35, 6 August 2010 (UTC)
  • 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)
  • 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)
    • 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)
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)

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)
I agree with Sabre per WP:NOTAMANUAL. Jonathan Hardin' (talk) 13:14, 18 August 2010 (UTC)
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)
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)
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)

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, required HDD space (if given), 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)

    • 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)
There is also Template:VG Requirements to use instead of the infobox field. Prime Blue (talk) 01:44, 20 August 2010 (UTC)
Stay away from depending entirely on {{VG Requirements}}. Its not exactly the most space-saving template out there. I'd want to see something of a redesign (or at least an optimisation) of that before its considered a standard way of dealing with requirements. Whats nice about this field is that it allows for a quick and neat requirements section when you don't want to clutter up the article with an additional {{VG Requirements}} in the development section; regardless of Jinnai's baseless OR claims for information that is verifiable and adapted directly from official sources, the streamlined approach allows for even neater presentation. As for what you should be covering, I think you've nailed it pretty well. Hard drive space requirements is one extra one that could be added to bits to consider for the PC, though its not always available in the given requirements. -- Sabre (talk) 10:41, 20 August 2010 (UTC)
I think Jinnai says the requirements in the StarCraft article are original research because they dropped the processor brand name although it is on the back of the box. I'm not well versed enough to judge if these studies he mentioned got it right, that is why I said "video card or video card memory" and "processor can also use brand name if given in the official specs". I'll add HDD space as per your comment. Maybe we should code the template so that a reference for the official specs appears next to "System requirements"? It would fight OR claims and we don't have to use a reference for every single line of the field.
And a question: What to do for games like Sanitarium that received up-ports? List only the Windows 9x requirements or the Windows XP requirements as well? Or only the latter? Prime Blue (talk) 13:07, 20 August 2010 (UTC)

"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)

  • 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)
    • 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)
  • 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)

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)

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)

Small image captions

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Issue resolved, has already been added to the template. Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Generally keep "development tasks" to prose

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Support. Using bolded section titles (see developers here or writers here) or parentheses (see composers here) to credit developers and team members with individual tasks looks very ugly and clutters things up. Keep that stuff to prose. Prime Blue (talk) 20:27, 6 August 2010 (UTC)
  • Either key people or empty. These fields should list key people, which means, lead programmers, lead artists, lead writers, etc. If such cannot be identified, the fields should be left empty, no guessing. More than 1 person should only be listed for important roles (designer/programmer) and only then for special cases, like, only two people developing or famous designers working together, etc. Again, with discretion, and if in doubt, rather leave empty. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)
  • Only for notable people - if we're putting unlinked or redlinked names, it's not helpful. --MASEM (t) 21:57, 6 August 2010 (UTC)
    • Even if a redlinked person is in the lead role? Just because they aren't notable on their own, doesn't make including them for their role somehow less significant. Of course it is helpful to put their name, they did the lead role. —  HELLKNOWZ  ▎TALK 07:10, 7 August 2010 (UTC)
    • To Masem: Redlinks are okay if the person is expected to get their own article. In the specific case of VG infoboxes, it is almost always reasonable to remove redlinks as most people in there will probably never meet Wikipedia's notability criteria to get their own article (in most cases, this is pretty easy to determine, too). The majority of redlinks which still are in the VG infoboxes will point to deleted composer articles (there have been many deletions regarding this a few months ago) and should of course be removed, too. Prime Blue (talk) 15:50, 7 August 2010 (UTC)
      • This is incredibly biased. A person in a lead role for a game is just that. It does not matter if they are notable or not. This is a development role, a job they did; just because they aren't notable enough for own their article on WP, they suddenly are not worthy of being listed for their key role? We don't remove developer or publisher fields just because the companies are red-links. —  HELLKNOWZ  ▎TALK 16:27, 7 August 2010 (UTC)
      • My problem is that when you start getting into large multi-teamed/studio games, you gain a lot of people that are at so-called "lead" positions that develop the game, and if we start trying to include them all, the infobox becomes very bogged down, and furthermore with more modern games, where the credits are self-contained on disc, it can be difficult to source properly. I would be for a very limited list of people that should be credited, which would be "Executive producer", "Lead director", "Lead programmer", "Lead designer", "Lead writer", "Lead art director", and "Lead music director" (and consider that some of these could be "co-directors" for example. Anything beyond a list like this is an invitation to bloat these lists depending on how an editor interprets a role. --MASEM (t) 17:06, 9 August 2010 (UTC)
        • I've already added a warning not to turn the people fields into a long credits list some time ago, so don't worry about that too much – we're all still here to take care of users who try to make Wikipedia a second MobyGames. For example, as noted above, the programmer field will be omitted basically for all new games as there are just too many programmers. By the way, MobyGames should be used with care anyway: It is a user-edited site and I've often seen completely erroneous credit lists there (especially for games with big teams where lazy users simply omit half of the people, as well as for classic games where acronyms are simply identified as the wrong people). In general, the credits list of the game itself should be used to add credits (watch a YouTube video, etc.). The problem with crediting only the "lead (insert field)" is that we almost never know who did what in games, so it is next to impossible to determine who was the most important person in doing their particular tasks (and it is also highly unbalanced when you consider the development process as a whole). Also, the "task-directing" guys (executive producer, art director, music director) are generally those the most removed from the actual development who do the least of the tasks we consider key parts of game developing, e.g. composing, character design, concept art, etc. For example, Satoru Iwata (Hiroshi Yamauchi before him) is executive producer for the overwhelming majority of Nintendo games: it's just a title for the "coin counters" who gave their go for the development. The only one in an overseeing role in game development (still having direct influence on the team and the director) is the "producer", which is why assist producers and executive producers are not mentioned. But, well, I'm already getting too much into detail for something this section did not propose. ;-) This is what I wanted to propose here. Prime Blue (talk) 18:42, 9 August 2010 (UTC)
  • Keep lead people - they are just as essential as items like release dates, if not more so. Fortunately, games aren't like movies where people can get contracts to be listed as producers when all they did was act.陣内Jinnai 22:01, 6 August 2010 (UTC)
    • Just to clarify: The people themselves would stay, but the tasks would be mentioned in prose, like this. I explained above that the people fields cannot be limited by notability, per WP:NNC, WP:NLIST, and WP:Source list. We can only discuss which fields to drop. Prime Blue (talk) 22:13, 6 August 2010 (UTC)
      • The people should be mentioned in prose in any case, that's why the prose is there. I agree that field cannot be limited by notability. Discussion of which fields to drop would probably be on case-by-case basis. —  HELLKNOWZ  ▎TALK 07:10, 7 August 2010 (UTC)
        • I guess dropping certain credit fields for one article and including it for others is not viable either, as per the infobox MoS. By including fields in the template, we basically say "these are the key people in creating games/the lead people in creating that particular game". What we can do, however, is discussing which people fields to drop from the template. Though personally, I feel the current people fields are those most relevant in a game's development. Prime Blue (talk) 15:50, 7 August 2010 (UTC)
          • Why is it not valid to omit a field which cannot be accurately filled? The infobox MoS specifically mentions that inconsistencies can and will arise (i.e. Feature inconsistency). We should not lose our heads in style manuals that impede both us and readers. We want these fields to be concise, that means lead roles, and not a list of known people in this role. —  HELLKNOWZ  ▎TALK 16:27, 7 August 2010 (UTC)
            • Same here, I think this is all just a misunderstanding. For example, the director field can of course be dropped for a game where there was no director. What I was opposing is dropping e.g. the composer field from Alan Wake because "the guy's not important" but keeping the field for Silent Hill 2: Both fields should be kept in their respective article because these are the lead people in creating their respective game. Prime Blue (talk) 16:54, 7 August 2010 (UTC)
            • What I meant with the proposal in this section was "don't mention development tasks in the infobox but in prose", so changing the writers field in the Twilight Princess example from this to this. And the developers field in Super Metroid from this to this. Prime Blue (talk) 17:06, 7 August 2010 (UTC)
              • The prose should always list these, should they be important. Infobox in principle shouldn't have info that is not available in prose. If something is not important enough for prose, then it surely doesn't qualify for an infobox. But this is really a VG content issue outside the scope of this Talk page. —  HELLKNOWZ  ▎TALK 17:32, 7 August 2010 (UTC)
                • I've just seen individual tasks too often in one field not to propose to keep those out of there. At least I don't think there is an overarching guideline (unlike here) to keep that to prose. That is why I still feel this should be mentioned as a "don't" in the infobox documentation. Prime Blue (talk) 17:47, 7 August 2010 (UTC)
                  • I agree we don't need indivisual tasks. I think the current ones can be used for virtually every known type. We could always add 1 custom field for something that could arise that should be noted (such as if the original concept/story is notable enough to be talked about).陣内Jinnai 21:19, 8 August 2010 (UTC)

The actual issue I brought up here was resolved unanimously: no development tasks in parentheses or bolded section titles of the infobox, but only in prose. Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Exceptions for "development task" credits

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Support. I'd say go with bolded section titles "if you have to", that is in rare exceptions. For example Animal Crossing, where the Japanese version and the English version are completely different games script-wise. In that case, go with bolded section titles as they just look better than parentheses. Colons only if decided below. Prime Blue (talk) 20:27, 6 August 2010 (UTC)
  • Don't list at all as per overall opposal to listing more than 1, max 2 people for special cases. There is never a case when you "really have to" list more than 2, 3 people. If game has somehow many people that need to be mentioned, then that is for prose. Infobox is here to single out the key people who can be identified as such, not to credit everyone. The field usage for those examples resembles full credits than an actual useful piece of overview. Again, if there is no key person for role, then leave it empty. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)
  • Don't list unless notable --MASEM (t) 21:57, 6 August 2010 (UTC)

Resolved as well: no exception here to mention development tasks. Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Only include references for uncredited people/tasks

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Support. (HELLKNOWZ changed my mind, this is governed by the general verifiability guidelines and is a given) There should be no need to give references for developers/people mentioned in the infobox if they were credited in a game's staff roll or manual. This is uncontroversial information not likely to be challenged, and it would be overkill to do so. There are many featured articles where people credited in the material itself come without sources in the infobox (such as for feature films). On the contrary, people that are not credited in the game (Sakamoto was not credited under his real name in Metroid) or people that did tasks they are not credited with in the game (Miyamoto and Koizumi as writers for Ocarina of Time) should always have references. Prime Blue (talk) 20:27, 6 August 2010 (UTC)
  • Oppose making this a requirement. Referencing something unordinary is the basic principle of verifiability. This goes without saying. Not referencing something uncontroversial is just as straight-forward. I don't see why this is so much more important for people and roles (than, say, titles, genres, media) that the field needs additional instructions for referencing. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)
  • We should avoid having references in the info box. If the information needs to be references, then it should also be in the prose, and if its not important there, then we probably shouldn't have it in the first place. --MASEM (t) 21:57, 6 August 2010 (UTC)
    • That is also a good point, references should be in prose, infobox is just a quick overview of the most important things. It should not in principle list things that aren't in proper prose. —  HELLKNOWZ  ▎TALK 07:14, 7 August 2010 (UTC)
    • To Masem: It is only natural to have references in the infobox, though. For example, we will often need one for the developer field. See Resident Evil: The Umbrella Chronicles, where cavia went uncredited in the game though they basically developed the whole game (with only the design and writing done by Capcom). Or development studio names, like in Super Mario Land. Prime Blue (talk) 16:01, 7 August 2010 (UTC)
      • The infobox is still covered by WP:LEADCITE which says to avoid references in the lead for reasons already mentioned. This is just a common sense extension of that.陣内Jinnai 21:07, 8 August 2010 (UTC)
        • For the last time, Jinnai, I think you are severely misinterpreting WP:LEADCITE. ;-) I think it does in no way prohibit references in the lead section and that it says you don't need to use them for generally known things. There are hundreds of featured articles with references in the lead section, like Dominik Hašek. If references were forbidden in lead sections, these would all be demoted. But I'm starting an RfC seeking a third opinion just to keep this from becoming an issue in the future. Prime Blue (talk) 21:27, 8 August 2010 (UTC)
          • No it doesn't prohibit them. It says use some common sense and don't tag every little factoid and sentance with a reference. Only tag truely controversial items and items like quotes which always require citations. The lead is used differently than the body and that's why it says that.陣内Jinnai 01:13, 11 August 2010 (UTC)
            • Sure, but that is not what we are doing here: We are including infobox references for material that is not commonly known, likely to be challenged, and not easily verifiable (or else someone might come along and go "Never saw that guy in the credits and there is no reference either, I'll remove him"). See the previous discussions and here for more information. Prime Blue (talk) 12:03, 11 August 2010 (UTC)

Resolved per revocation, this is governed by other guidelines. Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Colons after bolded section titles?

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Resolved, no colons. Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Collapsible release dates

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • Support. Where companies went a bit trigger-happy with ports and re-releases, giving only the original release date and making a collapsible list for all subsequent releases seems reasonable (see Resident Evil 4). Use {{collapsible list|title=original release|'''Platform 1(:)'''<br />{{vgrelease|NA=X|JP=X|PAL=X}}'''Platform 2(:)'''<br />{{vgrelease|...}}}}. Colons only if decided above. Prime Blue (talk) 20:27, 6 August 2010 (UTC)
  • Support. Should release date span over 3 lines, use collapsible. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)
  • Avoid at all costs Collapsed text is not appropriate per WP:FAC, and thus we should not be encouraging it. --MASEM (t) 21:57, 6 August 2010 (UTC)
    • MOS:COLLAPSE encourages it, but it seems you got the wrong link there if you found another guideline. Prime Blue (talk) 22:24, 6 August 2010 (UTC)
      • Well, there's no worded statement, but I know that the Featured Article process will not accept collapsed sections due to accessibility reasons. the MOS notes we have support for it, but it really is something discouraged about it. --MASEM (t) 23:24, 6 August 2010 (UTC)
        • Are you sure this is not just a limitation for prose text? Chrono Trigger has been using a collapsible list for the release dates for one and a half years and it does not seem to affect its featured status. At least I think it would have been re-assessed since its promotion in August 2006. *shrug* Prime Blue (talk) 23:46, 6 August 2010 (UTC)
          • Actually yes, here we are WP:ACCESS, Section "Style and Markup Options". Hiding text that is part of the article (which would include infobox parts) should not be done; it's ok in the Navsection , but not elsewhere. --MASEM (t) 00:46, 7 August 2010 (UTC)
            • I find that hard to believe, I think if this meant "text should only be hidden in navigational boxes", it would read just that. Especially since that very section again links to MOS:COLLAPSE. Prime Blue (talk) 01:12, 7 August 2010 (UTC)
              • Prose is accessible to all readers, with or without Javascript. Prose should contain all the information in the first place. Infobox is a nice addition of an overview of the game. MOS:COLLAPSE does not forbid from collapsing anything in an infobox. WP:ACCESS forbids collapsing main article content — prose. —  HELLKNOWZ  ▎TALK 07:34, 7 August 2010 (UTC)
    • Ok, I've checked with the FAC area, and collapsible text in infoboxes is ok; prose is the problem but not here. --MASEM (t) 16:55, 9 August 2010 (UTC)
  • Support if there are more than 3 or so dates. A modern game releases in 3 regions at slightly different times does not need a collapse. --MASEM (t) 16:55, 9 August 2010 (UTC)
  • Qualified support - If there is a way to list the original release and original English release for the (mostly Japanese) non-English titles without having the first of either collapsed and without users having to move items around in order to make certain of that (ie its intuitive and adaptive for the average user who doesn't feel like looking up the documentation).陣内Jinnai 22:08, 6 August 2010 (UTC)

Resolved, will be used for cases where there are more than just a few release dates. Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Collapsible publishers list

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Resolved, will be used for cases where there are more than just a few publishers (or where a list of the regional publishing would get too long). Prime Blue (talk) 13:20, 15 August 2010 (UTC)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Exclude port developers

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
  • 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)
  • Support only listing the original developer. Any port developers/studios go into prose. —  HELLKNOWZ  ▎TALK 21:45, 6 August 2010 (UTC)
  • 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)
  • 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)
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)

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

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

Resolved
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

How to separate developers/publishers/genres/platforms

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)

Seems like nowrap and non-breaking spaces only work if they are restricted to terms that will not "blast" the table. Meaning: We cannot use it for terms that span more than one line ("Family Computer Disk System", "Nintendo Entertainment System") because it would force it into one line and make the table wider. Prime Blue (talk) 01:29, 25 August 2010 (UTC)

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)
  • 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)
  • 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)
    • 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)
      • 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)
        • 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)

          • 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)
            • 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)
              • 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)
                • 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)
                  • 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)
                    • 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)

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)

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)

(←) 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)

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)
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)
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)
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)
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)
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)
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)

For ports that's probably acceptable. For remakes, that's probably isn't, especially if the remake is substantially different and many years down the road.陣内Jinnai 18:26, 20 August 2010 (UTC)

My words exactly. For remakes, I am fine with the format proposed by Masem.
However, Masem: The template seems to have a bug. As soon as one of the remake fields is used, there will be an empty space beneath. You cannot see it in your main template, but it is in my version with more fields. I just duplicated the remake fields at the bottom, so this has to be in your version as well (just less noticeable).
Another suggestion: The italics should be removed from the "porttitle" field of User:Masem/ivgport if we use the field with things like "GameCube remake". I guess those make sense for the majority of remakes that will keep the original title. And for the few ones that don't, like Castlevania: The Dracula X Chronicles, we can use that in the "porttitle" field (manually italicizing the title then). Prime Blue (talk) 21:24, 20 August 2010 (UTC)
Okay, until the bug is fixed and we can use that version, I'd suggest we just use a collapsed infobox for remakes (which is basically the same). Prime Blue (talk) 01:33, 25 August 2010 (UTC)

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)

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)

  • 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)
  • Comment I read this and immediately thought it was a great idea. Other articles do have links to the official website in both the infobox at the the top of the article and the external links section WAY below at the bottom (see Microsoft, Nirvana (band), etc.). It could indeed kill two birds with one stone by removing the need for version and requirement fields. However, I think this is not a viable solution; I expect many edit wars over which site (the US or the UK one) should be listed for games that were not developed in an English country. Jonathan Hardin' (talk) 10:11, 20 August 2010 (UTC)
  • I'm with Prime Blue on this. Official links should be restricted to references and the external links sections, if possible, and I certainly don't think we should institutionalize external links, if possible, outside of those two places. --Izno (talk) 17:58, 20 August 2010 (UTC)
    • There's nothing against them being elsewhere. Even discussions in EL are not against it.陣内Jinnai 18:22, 20 August 2010 (UTC)
      • WP:EL acknowledges that they can be placed in the infobox, even, but I'm still left with the opinion that links should be in external links section and not in the infobox. --Izno (talk) 18:46, 20 August 2010 (UTC)
      • Same notion here, it may not be forbidden, but it does not mean we have to use it. Prime Blue (talk) 18:56, 20 August 2010 (UTC)
        • True, but as mentioned before, it could alleviate any reasons for version the exhaustive system requirements fields.陣内Jinnai 19:02, 20 August 2010 (UTC)
          • Multiple sites even if only the English ones is still overkill IMO as some games have different sites made by different sources (developer, publisher, platforms, etc.). This can make for lots of websites to put in the infobox. This would make some infoboxes shorter of only a few lines at most, and many infoboxes longer than now (for example consoles games that don't even use version and requirement fields in the first place). Jonathan Hardin' (talk) 19:27, 20 August 2010 (UTC)
          • The external links do that already, Jinnai – and we can remove the version and system requirements as well (not that this is a proposal) without adding a website link. I just find that unconvincing as the sole reason for adding one or multiple website links. Not to mention that multiple links would immediately clutter up the infobox again, as Jonathan Hardin' said. Prime Blue (talk) 19:32, 20 August 2010 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Template_talk:Infobox_video_game/Archive_9&oldid=1131842380"