Template talk:Infobox video game/Archive 15

Archive 10

←

Archive 13

Archive 14

Archive 15

Archive 16

missing fields

Hi, several fields which exist in the good infobox software (https://wiki.riteme.site/wiki/Template:Infobox_software) are notable missing in this box: website, license, first vs current release. Adding them would lead to more consistency & I think these fields of the general software box help makign the video game infobox better fitting to the whole range of video games, e.g. also open source, community driven and indie games. Shaddim (talk) 13:12, 18 May 2017 (UTC)

They were deliberately removed from this template as a result of discussions here and at WT:VG. -- ferret (talk) 13:15, 18 May 2017 (UTC)

Can you please link to these discussions? I think it was a mistake. Shaddim (talk) 13:41, 18 May 2017 (UTC)

Since this is brought up every couple months, may be we should find the primary discussions and put them in a "commonly proposed fields" header or something? —  HELLKNOWZ  ▎TALK 13:54, 18 May 2017 (UTC)

I'm sure we used to have an FAQ - X201 (talk) 13:56, 18 May 2017 (UTC)

Oh yeah, there's Template:Infobox video game#Field changes. Though it's not complete. I searched "website" and nothing came up, so I assumed there was no FAQ of sorts. —  HELLKNOWZ  ▎TALK 14:10, 18 May 2017 (UTC)

Searching the archives here for "license" I found several instance of discussion and also re-inclusion of the field. The removal argumentation was basically that for the many commercial/propriatary games (the majority, but not overwhelming) the field would offer no benefit. Therefore, the proposal was then (and also now) to have an optional field which would be just be filled in case of deviation from the standard: share, freeware, open source, public domain etc. About the "website" field, I thnik I remember as the original argumentation against it that these websites go away after some years often, but due to the webarchive this counter argument it not valid anymore, the URL is now archived and has value. ("release date" differentiation might indeed not important enough for the infobox and can be represented in development/history sections ... on the other hand country specific release dates are deemed important enough for the infobox)Shaddim (talk) 14:18, 18 May 2017 (UTC)

The problem with optional fields is that newer editors will want to fill in everything in infobox fields, including redundant optional fields, leading to infobox kudzu. If there was a solution that limited what license fields could be used that would assure the field did not show up in you average non-free commercial game, that might work, but then the problem is that the number of potential license fields is not very limited, and thus difficult to narrow down. The website might be archived by archive.org but a lot of the functionality may not be there since archive.org doesn't capture javascript or the like. (And with release dates, we strive to keep those limited to major regions - NA, EU, AUS, and JP and avoid country specific unless there is a good reason to highlight that) --MASEM (t) 14:25, 18 May 2017 (UTC)

re. websites "this counter argument it not valid anymore" You've picked the wrong place to make that claim. This project has lost more references due to whole websites vanishing from web archives without notice, than any other project on Wikipedia. Websites still vanish without trace, even from web archiving sites. - X201 (talk) 14:27, 18 May 2017 (UTC)

Interesting, what cases do you mean? robot.txts added later? Also, as far as I know the webarchive contemplates about changing the handeling of later added robot.txts (the stuff is still archived but just not delivered) Shaddim (talk) 15:02, 18 May 2017 (UTC)

If the site had been once indexed by archive.org prior to the addition of a robots.txt, then robots.txt was added, then as up to a few months ago, archive.org respected that and blocked access to the cached versions. (This was a problem with 1up.com sites, iirc) But now it will ignore that later-added robots.txt and show the cached stuff. However, if robots.txt was on the site all along, archive.org never cached the site, so those sites that are no longer active are gone to the ether. --MASEM (t) 15:07, 18 May 2017 (UTC)

thanks for the infos. This means that now even more websites are archived. From my practical expierence I would guess with the old behaviour that 20 to 30% of websites were blocked, now even some more are available. So the majority is findable in the archive.org, so a website field would offer in the majority of cases a benefit. Shaddim (talk) 15:13, 18 May 2017 (UTC)

But that still leaves us the case of that 20-30% sites being gone forever, editors want to fill in the blank (it's a natural draw to include something) and these then get filled with fan sites or wikia or other sites not associated with the original but considered the defacto site with the absence of the original. And that's not good, that's infobox kudzu again. --MASEM (t) 16:02, 18 May 2017 (UTC)

Frankly, this seems to be minor/cosmetic issue. all the fields have not a 100% perfect fill propability, encouraging infromation only 100% "true" (overall, to remind anyone, our goal is verfiabilty not truth). The release dates are notoriously shaky and should be removed from the infobox with this argumentation. Shaddim (talk) 16:15, 18 May 2017 (UTC)

Release dates should always be sourced in the body of the article (and they don't need to be exact particularly from pre-5th gen type games, a "1998" release date is acceptable as long as it can be sourced). And I do agree that we shouldn't want to fill in all the empty lines, but new editors do do that, its a natural human thing to want to provide something they know where there's a field for it, and it is hard to ween editors from doing this. --MASEM (t) 16:19, 18 May 2017 (UTC)

Can you show cases where this became a serious problem? Many other info boxes have optional fields and I'm not aware of any serious problems with that approach. About novice users, I would be happy if would have again many new users, regardless if the fill out some fields not perfectly... Shaddim (talk) 19:47, 18 May 2017 (UTC)

It's difficult to remember specific cases since the parameters have been removed for so long but I do know website, as well as the preceeding= and succeeding= parameters were no end of trouble. But even today, I can point to Nintendo Switch and the attempt roughly once a week to fill in the generation= infobox line despite the comment there that we have no way to classify it yet. It happens far too frequently to be a problem to consider. --MASEM (t) 20:24, 18 May 2017 (UTC)

Thanks for the exmaple but this example seems to be more about "correct filling" in general of fields and not a weakness of "optional fields". Also, the {{Infobox information appliance seems to be filled with too much stuff. The case here is different: our box has to few fields, some crucial ones are missing which are needed to address significant segments of the video game ecology. There is already the practice that sometimes authors use therefore the general software box instead, can that be a wanted solution? I guess not. Shaddim (talk) 08:43, 19 May 2017 (UTC)

The other side of the issue is that video games no longer are treated with the same type of careful attention to such detail as software; yes, back in the days of DOS and UNIX gaming, video games and software overlapped heavily in the sense of tracking version numbering, licenses, etc., but very few games today that matters anymore. We could add these fields, but they would only apply to a small fraction of the games out there, as noted the potential for well-intentioned misuse is far too high to justify supporting that small a fraction of games with those fields. We want editors to write these articles for the non-gamer, and most of those details you are asking for are more geared towards the gamer side, which is another reason why they were removed. --MASEM (t) 14:08, 19 May 2017 (UTC)

Well, I would argue what I'm asking for is exactly for the non-gamers: licenses are not in-game trivia but real world aspects. The same for the games' websites, which have far greater importance for a scholar who wants to learn about context and history of a software than a gamer. Shaddim (talk) 18:59, 19 May 2017 (UTC)

Again, with the license, of the games published up to today, a tiny fraction have something other than a standard commercial license, so this field doesn't make sense in the larger picture, and incorporating a parameter that is only used by a small fraction of qualifying topics really doesn't make sense. In terms of websites, I looked back at past discussions, and the consensus there is that, beyond their tendenancy to disappear after a few years from a game's release, is that most are written from the perspective of gamers and consumers interested in the game, and not non-gamers; there is more effective information about a game from the video game journalism side which has in-depth interviews, etc. When a game's website does have useful information like developer's blogs, those should be integrated as references or external links in the article to highlight them. As such, they don't provide any value short of being something akin to a catalog page of where to buy the game, and thus not appropriate as an infobox piece. --MASEM (t) 19:12, 19 May 2017 (UTC)

Just putting in my two cents that so far, I agree with Masem on the above points. -- ferret (talk) 19:13, 19 May 2017 (UTC)

I'm not convinced so far... but if there is a consensus I will not resist but use the software infobox in cases where it makes more sense. About "small fraction" : have we amechanism for extracting hard numbers out of our categorization? E.g. how many of our games are freeware/free-to-play or open source? Currently I would do it manually over category content counting... Shaddim (talk) 19:25, 19 May 2017 (UTC)

We have somewhere in the realm of 500 open-source video games; juxtaposed to many times more than that. --Izno (talk) 20:39, 19 May 2017 (UTC)

I counted 760 Freeware games. I counted roughly 18.000 games overall from the year lists. 1260/16740 7.5%. Which is small but not insignificant. Also, don't we have better tools at hand? I thought wikidata was meant for such things?Shaddim (talk) 20:51, 19 May 2017 (UTC)

A note: we cannot group "free to play" alongside "open source". Free to play is not a license issue, that's a cost; a free-to-play can be covered by a commercial license. So it doesn't make sense to group those together.

Category:Open-source video games has a total of 479 according to Petscan. The total number of games under Category:Video games by year is 26,163. So we're talking 2% of all games. That's trivial to include. --MASEM (t) 02:54, 20 May 2017 (UTC)

Infobox open source video game

One potential solution would be to create a hybrid {{Infobox open source video game}} template. New users would most likely never encounter this template (since it would be used so infrequently in articles about commercial games), but "experts" would know about it and most likely use it correctly. And I don't think creating one extra template would cause a big maintenance issue. SharkD  Talk  21:36, 19 May 2017 (UTC)

Yes, potentially a subtemplate (I think the anime infobox uses this approach) for games that are treated more like software rather than games ala Nethack or Dwarf Fortress. --MASEM (t) 02:56, 20 May 2017 (UTC)

{{Infobox_animanga}} for reference. --MASEM (t) 03:01, 20 May 2017 (UTC)

Could be a solution possibility. But on the other hand, we have already the general software infobox, which addresses all problems already fine for freeware and open source games. And multiple games already use the general infobox, so maybe better stick to this solution and not adding a third approach... and maybe marking the commercial/proprietary games as exception from the general software case with an own box is maybe not a bad idea. ;) Shaddim (talk) 19:09, 20 May 2017 (UTC)

{{Infobox software}} is missing several fields, however, such as "Genre" and "Mode". These are important and specific to video games. SharkD  Talk  02:12, 21 May 2017 (UTC)

the software infobox has "genre" (written then "type") which can cover "Mode" too, as e.g. "Single-player & multiplayer Real-time strategy" Shaddim (talk) 11:59, 24 May 2017 (UTC)

Can I go ahead and create this template? SharkD  Talk  01:53, 24 May 2017 (UTC)

As mentioned above and in discussions prior, non-standard license video games make up only a small percentage of the games. We don't create a field for licenses because it's not standard info compared to other fields. Making a new template is the opposite - giving prominence to the tiny subset. All it does is bypass this template's consensus to not include licenses. At best, the current template would have a license field for only non-standard-proprietary ones. —  HELLKNOWZ  ▎TALK 16:40, 24 May 2017 (UTC)

There seems no consensus (anymore? ever? this topic crops up regularly), as there are improvement solution proposals from several authors on the table, to address also the other ~10% of games. I can say I have a problem in marginalizing these parts of the gaming ecosystem, every thenth game, as not being worth being properly addressed in the info box. But on the other hand, I'm fine with using the general infobox. Shaddim (talk) 18:37, 24 May 2017 (UTC)

It's not marginalizing, it's pretty much the opposite -- it's giving undue attention to a small subset with a specific characteristic. If anything, we should list proprietary licenses, because those are the common ones, not the open source of similar. But it's unsourcable. We don't even list things like graphics or controls in infobox -- which almost every game has. So listing something not even a third of the games have has always been excessive. The infobox already had many fields once that were hardly ever used or misused heavily. We don't really need to go back to that. —  HELLKNOWZ  ▎TALK 21:13, 24 May 2017 (UTC)

Hence why if we can create an optional sub-infobox like the animemanga one that is only needed for the small number of cases but don't otherwise influence/affect existing ones, that's a possible solution. I know where Shaddim is coming from in that one could arguably just replace the infobox vg with the infobox software for those games where there may be more value as a software entity than a game, but the vg infobox is arguably better for documenting all aspects of a video game. An optional box that editors have to manually add would help resolve the lack of this information for games-as-software as well as limit how much infobox kudzu we'd get from inexperienced editors. --MASEM (t) 21:24, 24 May 2017 (UTC)

I guess I just don't see why open source video games are special to warrant their own infobox so they can have a license field when none of the other kinds of games would have one. —  HELLKNOWZ  ▎TALK 21:53, 24 May 2017 (UTC)

I agree with Hellknowz, creating a sub infobox for such a minor problem is pointless. Discuss anything necessary in the body text. Darkwarriorblake / SEXY ACTION TALK PAGE! 21:59, 24 May 2017 (UTC)

every thenth game is minor? also, this is about more fields (website!)...and the general software infobox has no problems in providing these fields. Shaddim (talk) 22:37, 24 May 2017 (UTC)

I'm not seeing where you are getting 10% from; my checked showed less than 3% of game articles are freeware or open-source titles. If it were something like 10%, you'd have a point, but it's definitely not that high. --MASEM (t) 23:53, 24 May 2017 (UTC)

see my calculations above 7.5% for FOSS + freeware. And from the historical perspective, the proportions for software were different before 1990 (Public domain) and for software/games from that period we would nee also a license tag. Shaddim (talk) 11:20, 26 May 2017 (UTC)

@Hellknowz: Quote: "If anything, we should list proprietary licenses, because those are the common ones, not the open source of similar." That's quite literally marginalizing parts of the gaming ecosystem. Not sure why you are having a hard time understanding this. SharkD  Talk  23:21, 5 June 2017 (UTC)

Because all games have licenses. Because being in minority is not by itself notable. Only listing open source games because we think they're special or different -- that's marginalizing. That's like deciding that we'll only list budget for indie games, but not for other games. Even if 10% are open source, that's 90% we are ignoring then. What makes a "regular" proprietary license unworthy of inclusion when it's by far the most common? If someone can back up the reasoning with industry sources that discuss open source licenses but not "regular" licenses, then there would be precedent. But besides occasionally mentioning open source games, the media mainly covers IP licensing and who owns and buys what. And this license field proposal isn't even about IP. P. S. Ping doesn't work unless you add a full sig in the same edit. —  HELLKNOWZ  ▎TALK 09:53, 7 June 2017 (UTC)

It's not a matter of *whether* we include the license. It's a matter of *which* template we use to show the license. As templates like {{infobox software}} already do this. And I'd rather not put *both* infoboxes in each article just because one WikiProject is whining about having to do so. SharkD  Talk  11:10, 7 June 2017 (UTC)

It is important to note that WP:VG is not the only WikiProject having a stake in these articles. There are also Wikipedia:WikiProject Free Software, Wikipedia:WikiProject Software and Wikipedia:WikiProject Computing. We shouldn't base our actions simply on the fact that it's inconvenient for WP:VG. SharkD  Talk  11:31, 25 May 2017 (UTC)

I agree, I have the feeling too that the field selection in infobox VG is catered too strongly to the gamer audience, ignoring the software aspects. Shaddim (talk) 11:22, 26 May 2017 (UTC)

Isn't that the point? ~ Dissident93 ^(talk) 17:52, 6 June 2017 (UTC)

Not really. The audience of Wikipedia is not just limited to gamers. And WP:VG is not the only WikiProject on Wikipedia. SharkD  Talk  19:59, 17 June 2017 (UTC)

Where are the reliable sources coming from for the contents of the licence field? Everything in the infobox should be a reflection of sourced info in the prose. - X201 (talk) 11:53, 26 May 2017 (UTC)

primary sources are fine for non-controversial, non-personal, verifable facts. (this complete binary "reliable" source thing went out of control in the last years). Also, why do you think this is harder to back up than other fluky gaming related fields like "genre"? If I would start to look if the given genres in the game's infoboxes are being backed literally by "reliable sources", we would have a hard time with many, many articles... as many conventions and disagreements exist here and are NOT the one we use here.... Shaddim (talk) 12:23, 26 May 2017 (UTC)

Most open source software is hosted at repositories like GitHub or SourceForge. Descriptions of licenses are readily available. SharkD  Talk  23:24, 5 June 2017 (UTC)

Another alternative

What if we were to have a "license" field that would only accept certain terms (eg "public domain", "open-source", "freeware") and not display if none of those terms were used. And particularly making sure "commercial" or the like is not one of the allowed terms? In otherwords, we are treating the assumption the game is commercial by default by not displaying it (the case for most games) and only showing when it is non-commercial? This is by far the simplest and least disruptive approach (grandfathers all uses). We'd just need to set what are the allowed license fields. --MASEM (t) 14:05, 7 June 2017 (UTC)

As much as I think license field is fluff that's irrelevant most of the time and--when relevant--should be in prose, I wouldn't oppose it if enough editors think that non-standard licensing is an important point to cover in the infobox. Restricting it to specific cases and requiring it to be sourced would be a compromise I can get behind. But the infobox doc should be very clear that it is consensus to highlight "non-standard" licensing (as a side point "commercial" is not a license; at best we could broadly call it "proprietary" in that private individual(s) or corporation(s) have full rights to the product by whatever internal IP rights agreements they have). —  HELLKNOWZ  ▎TALK 18:15, 7 June 2017 (UTC)

This is a better proposal, but what games are considered something other than commercial? Can somebody make a list of games that would even use these fields? If it's not a substantial list (say at least 50 games), then I have to question the purpose of this. ~ Dissident93 ^(talk) 21:09, 7 June 2017 (UTC)

As I noted above, Category:Open-source games has 479 members. I haven't counted things like freeware or the like, but we're talking somewhere between 2 and 10% of all video games. --MASEM (t) 21:17, 7 June 2017 (UTC)

The vast majority of articles on open source games have shitty sourcing and aren't notable anyway. It's just that nobody can be asked to go through and AfD them all, so that figure should probably be <1%. We don't need any more fields especially for a trait that reliable sources don't even cover significantly. And to add, for the suggestion above, we absolutely do not need a separate infobox/subinfobox like {{Infobox_animanga}}. {{Infobox_animanga}} is a giant clusterfuck that goes completely against WP:INFOBOXPURPOSE. --The1337gamer (talk) 21:36, 7 June 2017 (UTC)

@The1337gamer: There are plenty of articles from reliable sources discussing open source video games and engines. For instance IGN says, "Some of the most rewarding PC games out there were built by indie developers using open source code." You can see the important distinction these articles are making is not genre, or country of origin, or game mode, but the software license. So, yes, there is significant coverage. SharkD  Talk  19:58, 17 June 2017 (UTC)

I seemed to have missed that, but I agree with 1337 as well. How many notable games are included there? Can you name one well known title that is without looking through the category? ~ Dissident93 ^(talk) 06:31, 9 June 2017 (UTC)

well, while freeware and FOSS gamign does not get the broad coverage in magazines (as there is no /little money involved) gaming for free is a big thing world wide. Freely downloadable games, while good statistic is hard to find, is downloaded million times and played by millions. Also, we should not forget the sharewawre games of the yesteryears.... this was big and everywhere. We should not get stuck in the bubble created by the commercial content industry, there are other notable (e.g. notable by impact on people's life) domains too. Shaddim (talk) 11:04, 12 June 2017 (UTC) PS: as well documented examples https://wiki.riteme.site/wiki/Flow_(video_game) https://wiki.riteme.site/wiki/The_Battle_for_Wesnoth https://wiki.riteme.site/wiki/Cave_Story and https://wiki.riteme.site/wiki/Diamond_Trust_of_London https://wiki.riteme.site/wiki/Colossal_Cave_Adventure

You increasingly sound like you're trying to right some great wrong. --Izno (talk) 11:42, 12 June 2017 (UTC)

Not really, its about fine-tuning the balanced representation of the whole video gaming landscape we have already in WP (well, the infobox VG could be a little bit broader but we have the generla software infobox). Freeware, shareware and open source are notable part of it, I think there is no serious discussion about that. Shaddim (talk) 18:06, 12 June 2017 (UTC)

• It looks like discussion is dying out, but FYI, I'm also against the addition. It doesn't affect enough articles, in my opinion. Sergecross73 msg me 16:32, 25 June 2017 (UTC)
• The category is sufficient for identifying these works. The open source status isn't important enough in our articles that readers should expect it to be covered in the infobox. Keep it simple. Also almost every article I open in Category:Open-source video games is a candidate for redirection if not outright deletion.  czar 04:25, 26 June 2017 (UTC)

  Maybe through your glasses only. Many of them have a great impact on the live of people, shown by usage not by paid reviews of "reliable" sources like MC.... that they fit only unwieldy our self-defined criterias, defined tightly around commercial developed games, is mostly a problem of our definitions and our own glasses, not the games. The prejudice against Freeware, PD, open source and other community developed software seems structural, with the infobox only one example. Shaddim (talk) 11:08, 9 July 2017 (UTC)

Release for emulation

Platform: "This includes dedicated ports, but not games in emulation or services. " I'm curious about this, maybe it would be useful for the readers to let them know the game is available for some recent platform on older titles using the infobox. 179.7.213.60 (talk) 05:35, 18 July 2017 (UTC)

For games like old Sonic or Mario titles, this would make for a huge huge list. We avoid inclusion of emulation in the infobox, but you're free to include emulation information in the body of the article. --MASEM (t) 12:46, 18 July 2017 (UTC)

Distributor

I'm not entirely advocating this, but I've been pondering it and wanted to see what everyone thought. Distributor is a field that has long caused issues, and in modern days become more and more antiquated as digital distribution has become a bigger player. Should we even have this field? In most cases, we've already slapped a rule that when it matches publisher, hide it. And in the rare cases beyond that, it is almost always unsourced and unmentioned in prose. Beyond that, is this field of any true encyclopedic value? -- ferret (talk) 15:50, 22 June 2017 (UTC)

I agree it can be very muddied and misused, but I also think particularly for some indie games that if there's a retail version, the existence of a distributor field will quickly tell us that a retail exists, and avoid having the previously removed "distribution" field. It shouldn't be there for digital-only games, and shouldn't be there if the publisher also distributed. A question to consider is how this affects games pre-digital era, how many had distrubitors that weren't publishers? --MASEM (t) 15:57, 22 June 2017 (UTC)

Honestly from a reader view point, I would find "distribution" (Online, retail) much more useful than "Distributor". Readers don't know the arcane rules we have for this field such as "Only if it doesn't match publisher" and "Only if brick and mortar". In your example of a distributor field indicating that an indie game has a retail version, only us in the know will understand that. And because we only populate it if publisher is different, it doesn't reliable demonstrate "Retail version available". The reader is left without a clear understanding. -- ferret (talk) 16:19, 22 June 2017 (UTC)

Well, we voted to remove the type of game's media a while back, and I find this to be pretty similar to that. Does a game being digital only actually matter? Any retro game would already be assumed to have been available at retail (as are most modern AAA games still), so I'm not sure how much this actually helps. ~ Dissident93 ^(talk) 18:48, 22 June 2017 (UTC)

• I said before that it should be scrapped Template talk:Infobox video game/Archive 14#Regional publishers. The infobox's purpose is to summarise key facts in the article. Retail distribution is rarely mentioned because it's not really significant or covered by reliable sources, especially these days with the prevalence of online and digital distribution. Also the field is constantly miused in more than one way. I frequently see Steam, Google Play Store, GOG, etc because people assume it includes digital store. I also frequently see stuff like Marvel, Disney because some people assume it means license holder. --The1337gamer (talk) 16:36, 22 June 2017 (UTC)
• I'd argue in favor of removing it as well. For the vast majority of games, both retro and modern, the publisher doubles as the distributor. And for the rare games that do use a separate distributor, that info could just go in prose instead. It also causes a lot of issues too, per 1337's comment. ~ Dissident93 ^(talk) 18:45, 22 June 2017 (UTC)
• Ha, I just removed this field on The Witcher 3 as superfluous. The distributor doesn't matter, there's no award for best distributor, you have the people who make the game, and the people who put the game out there (which is nowhere near as important), but the people who print the discs or upload the data or whatever? Not important at all, and incredibly region specific. Darkwarriorblake / SEXY ACTION TALK PAGE! 13:37, 25 June 2017 (UTC)
• I have no problem with its removal. It's only caused issues in my experience. Sergecross73 msg me 16:29, 25 June 2017 (UTC)
• I started this, but to be clear, I'm also in favor of removal. As to the cases noted above, see this diff that @AdrianGamer just reverted. -- ferret (talk) 11:27, 27 June 2017 (UTC)

  These cases where uninformed users put licensors in place of the distributor are actually not that uncommon, and they often also come in mass-additions from singular users. Although I am rather neutral on this, I think deletion would ultimately resolve this problem, but we should likely put up a bot that removes |distributor=—or all deprecated fields in general (I often see |media= still used in old articles). Lordtobi (✉) 12:15, 27 June 2017 (UTC)

  There should be no articles with Media parameter. Category:Pages using infobox video game with unknown parameters is currently empty. -- ferret (talk) 19:19, 27 June 2017 (UTC)

  Was this recently cleaned up? Because I know for a fact that I've had to manually remove the field in some of the more obscure retro game articles within the past few months. ~ Dissident93 ^(talk) 19:26, 27 June 2017 (UTC)

  November 2016, by @Zackmann08. See template history, you'll spot where they cleaned up depreciated parameters and removed them. -- ferret (talk) 19:30, 27 June 2017 (UTC)

  I don't think that category tracks articles with unknown parameters if the entry is empty. e.g. Alpine Ski has a media field but the entry is empty so it doesn't show in the category. --The1337gamer (talk) 19:52, 27 June 2017 (UTC)

  That's because it has ignoreblank=y set. If we remove it, the category will populate with blank fields. Since the category is empty, we can try that. -- ferret (talk) 21:11, 27 June 2017 (UTC)

  @The1337gamer: The category will start to populate with blank invalid parameters now. Will take a while to refresh, probably be a couple weeks before everything is in there. -- ferret (talk) 14:20, 1 July 2017 (UTC)

• I have no problem with its removal either. As Dissident93 previously explained, it's not practical to have an infobox field that is only used in very rare instances. --Niwi3 (talk) 19:14, 27 June 2017 (UTC)
• I support its removal. Just look at the edits by this IP editor, who didn't really know what a distributor is and fill the field with the licenser. AdrianGamer (talk) 05:27, 1 July 2017 (UTC)

• Comment Seems like a clear consensus is developing. I have removed Distributor from the sandbox version of the template. Will wait a little longer before moving it live. -- ferret (talk) 14:22, 1 July 2017 (UTC)

@Ferret: You think this okay to update template and deprecate now? I could probably remove a decent proportion of them as I work through my current AWB list.--The1337gamer (talk) 18:37, 12 July 2017 (UTC)

@Primefac is going to run a bot JanuaryJuly 17. Will remove from template at that time. If you want to start AWB'ing them, might lower the run time for his bot. -- ferret (talk) 19:03, 12 July 2017 (UTC)

Bot proposal

See Wikipedia:Bots/Requests for approval/PrimeBOT 18. I have suggested the removal of other previously supported parameters while the bot is running. What I wrote at the BRFA is: It may be helpful to remove other previously supported parameters at the same time. It looks like the main offenders in Category:Pages using infobox video game with unknown parameters are |media=, |ratings=, |requirements=, |show image=, and |version=. – Jonesey95 (talk) 13:10, 16 July 2017 (UTC)

• Makes sense to me. Kill two birds? Primefac (talk) 13:18, 16 July 2017 (UTC)
  • @Jonesey95 and Primefac: Sounds good to me. Please remove those 5 as well. I have found a lot of typos in that category that just need to be fixed. Removing the depreciated parameters will make it a lot easier to find them. You can start any time Prime. -- ferret (talk) 13:56, 16 July 2017 (UTC)
    • What about |collapsible= and |show italics=? I can't think of a single article that uses these. Are they there just for legacy support or something? ~ Dissident93 ^(talk) 03:36, 18 July 2017 (UTC)
      • |collapsible= is for if you want to hide bits of the IB (like if it's as a module in another IB). It might not be used but it has usefulness. |show italics= isn't a parameter in this template currently. Primefac (talk) 20:04, 16 July 2017 (UTC)
        • collapsible is used a bare 120 times out of 21k template uses (0.6%). It might be reasonable to refactor the pages upon which it is used and to delete the parameter. --Izno (talk) 04:19, 17 July 2017 (UTC)
          • It's typically used when IBVG is a sub-infobox, i.e. in an article about a film with a non-notable video game merged in. -- ferret (talk) 11:21, 17 July 2017 (UTC)

I have finished cleaning out the maintenance category, including a few cases the bot missed Distributor. Should be easy for us to watch over it for invalid parameters now. -- ferret (talk) 16:50, 19 July 2017 (UTC)

Programming language

Can someone please add a field for the programming language (as in Template:Infobox software)? Might be useful for certain games, especially if they are written in exotic or custom languages. --194.118.192.35 (talk) 18:32, 23 August 2017 (UTC)

This has been proposed before and basically there is no consensus to add this very rarely sourcable field. —  HELLKNOWZ  ▎TALK 18:40, 23 August 2017 (UTC)

For 95% of games, it's either going to be unknown (and therefore unsourcable) or in some sort of C language (and if most of them are, why do we need to point this out?) For the games that aren't, it could simply belong in prose. The engine is more relevant to the game anyway. ~ Dissident93 ^(talk) 18:46, 23 August 2017 (UTC)

I thought primarily of older games, i.e. from a time when they were written in things like BASIC, Pascal or assembly. For newer ones its usually C++ anyway. The scripting languages used might be interesting and sourceable though. --194.118.192.35 (talk) 19:11, 23 August 2017 (UTC)

Not wrong, but that still would fall under the example of them being either too common to even warrant being mentioned at all, or you need to see the code yourself and verify it as its not stated anywhere, which kind of falls under WP:OR. And for the games that don't fall under these two examples, the engine its using is almost always considered more notable and/or relevant, as it has to use a language anyway. So for example, Half-Life 2 was written in C++ and allows for Lua scripting, but all of this is handled by the Source engine article. ~ Dissident93 ^(talk) 19:36, 23 August 2017 (UTC)

Improve formatting to be on pair with other Infoboxes

Could it be possible to improve the formatting of this Infobox, with a better formatted title, and maybe with automatic field separation in categories? (not limited to only those 2 improvements). To explain myself better, Here is an example of a page using the television Infobox (used in 40,000 pages). Here is another example. I think it's important to have this widely used Infobox (used in 20,000 pages) visually and categorically robust like the rest of the popular ones. ~ posted by Genoskill (talk) 04:28, 24 September 2017 (UTC)

• What, like a colored box where the title is displayed? I don't see how that would improve anything. The film infobox also doesn't use special formatting there, so I don't see your point, unless I misunderstood. ~ Dissident93 ^(talk) 06:41, 24 September 2017 (UTC)

Wikidata tracking categories

We have a pair of categories defined here at Category:Articles with infoboxes completely from Wikidata and Category:Articles using Infobox video game using locally defined parameters that IMO should categorize based on parameters which the templates allows us to pull from Wikidata rather than all parameters in the template. --Izno (talk) 11:39, 5 July 2017 (UTC)

Added in this diff by @Mike Peel. -- ferret (talk) 12:58, 5 July 2017 (UTC)

@Izno and Ferret: Ideally all parameters should be fetchable from Wikidata. I'm happy to help with parameters that aren't yet fetched from Wikidata, or need improvements in how they are fetched. Thanks. Mike Peel (talk) 13:28, 5 July 2017 (UTC)

@Mike Peel: At this time, only five or so fields are not pulled. We don't pull image because they are almost never free and on commons, though I suspect we could add it for the few that have it. (Most cover images are fair use and on enwiki). The remaining fields relate to CPU, graphics, sound, etc, for arcade machines. If you know suitable hardware related properties we can use, that'd be great to get those finished. The final unimplemented field is the release field, which is not implemented due to issues with trying to address the current consensus on which dates and regions to list, as well as how to output platforms. That field needs to be discussed separately from any other efforts. -- ferret (talk) 13:46, 5 July 2017 (UTC)

Ideally, yes. But as ferret describes, some properties aren't particularly available at present. And then there's release date. I'm mostly interested in removing the categories' reliance on release date, since that's a) the most important field still un-implemented here and b) may never be implemented to pull from Wikidata. --Izno (talk) 14:01, 5 July 2017 (UTC)

I still think the best solution is a stop gap to pull "earliest" available date. This will still require a custom module to handle since Module:Wikidata has nothing suitable. Easily done, if we can agree on that solution. Unfortunately ANY date output field requires supporting a df parameter too, but that's a nit. -- ferret (talk) 14:08, 5 July 2017 (UTC)

I've made a few edits this evening to the documentation (to match the formatting I've been using in other Wikidata infoboxes), to the template to add wikidata support for the image and caption where available (matching code used in other infoboxes), and to the tracking categories so that locally-defined images cause the article to be included in Category:Articles using Wikidata infoboxes with locally defined images (and if it's only the image that is locally defined, then the article will be included in Category:Articles with infoboxes completely from Wikidata). Please let me know if I've caused any problems with these edits. It would be good to change the code from Module:Wikidata to Module:WikidataIB at some point, as that module has extra functionality (particularly with suppressing lines fetched from Wikidata). I'll look into the other parameters that could be fetched from Wikidata another eve. Thanks. Mike Peel (talk) 01:17, 6 July 2017 (UTC)

@Ferret: It would be good to use the sandbox to make further changes and test them, but I see there's a pending change there at the moment. Should I set up a sandbox2 for now, or will the pending change be made live soon? Thanks. Mike Peel (talk) 22:43, 6 July 2017 (UTC)

@Mike Peel: Planning to move the sandbox live week of JanuaryJuly 17. Feel free to overwrite it, it's not a difficult change to repeat. -- ferret (talk) 23:40, 6 July 2017 (UTC)

@Ferret: We have to wait a half year for that change? :) --Izno (talk) 02:37, 7 July 2017 (UTC)

Fixed. :) -- ferret (talk) 11:19, 7 July 2017 (UTC)

@Mike Peel: Sandbox is all yours. -- ferret (talk) 14:01, 16 July 2017 (UTC)

Revised version

@Izno and Ferret: I've put together a revised version of the template at Template:Infobox video game/sandbox that uses Module:WikidataIB, which supports using preferred Wikidata values, not showing rows from Wikidata through suppressfields, and only fetching referenced Wikidata values through onlysourced. I've added support for the rest of the parameters through has part(s) of the class (P2670) -> arcade cabinet (Q1349717)/arcade system board (Q631229)/sound chip (Q1418253)/video display controller (Q1852898) -> instance of (P31), as well as CPU through CPU (P880) (although as this is noted in the current infobox code, perhaps there's a reason why this isn't used?), and release date through publication date (P577) (although I understand this needs discussion, this looks like the most natural property to use, and perhaps setting a preferred value would resolve Izno's concern above). I've also added support for references from Wikidata (which can be disabled through refs=no). I've also added support for a embedded parameter, so that other infoboxes can be embedded in this one if needed, as well as some tidying of the wikitext formatting. Please have a look, test it in your favourite articles, and point me towards problems! :-) Thanks. Mike Peel (talk) 01:23, 8 August 2017 (UTC)

@Mike Peel: Note in the current version the formatting (Lowercasing labels except for first character) and shortvalue in use for mode and genre. Not sure if WikidataIB has that function. RexxS added it to Wikidata for us. The purpose is to display say "Single-player" as the link label, rather than "Single-player video game". Likewise with genres, "Adventure" instead of "Adventure video game". Regarding P880 for CPU, we had identified that property but left it out since we were missing a solution for the rest of the arcade fields at the time. -- ferret (talk) 01:27, 8 August 2017 (UTC)

@Ferret: Can you point me to an example article that uses shortvalues so I can see it in action, please? Thanks. Mike Peel (talk) 01:29, 8 August 2017 (UTC)

I've raised the question about short names at Module_talk:WikidataIB#Short_names. Thanks. Mike Peel (talk) 01:36, 8 August 2017 (UTC)

As a test case, see Space Invaders, also a sandbox version fetching the data through a QID (useful for sandbox/draft articles). Thanks. Mike Peel (talk) 02:09, 8 August 2017 (UTC)

@Mike Peel: Banished (video game) and Space Run are both nearly entirely Wikidata. Only image, caption and release date I think, which we previously didn't support for Wikidata. -- ferret (talk) 12:21, 8 August 2017 (UTC)

Please do not add support for image, caption, or release date. The former two will almost-never be appropriate to get from Wikidata and the latter still does not have a reasonable implementation route. We need to talk about that but I haven't seen a dedicated thread on this page about how to do so. (You should treat this comment as an explicit "consensus against" comment.) --Izno (talk) 12:43, 8 August 2017 (UTC)

As for embedding, we already have that functionality in the "universe" parameter. Please establish consensus for that suggestion/request. --Izno (talk) 12:44, 8 August 2017 (UTC)

What "universe" parameter? -- ferret (talk) 12:47, 8 August 2017 (UTC)

Oh, I was thinking of Template:Infobox video game character. --Izno (talk) 13:41, 8 August 2017 (UTC)

That aside, I'd like to see consensus for that parameter still. --Izno (talk) 13:41, 8 August 2017 (UTC)

Sounds like a possible solution to the open source game snafu though. Embed infobox software for the few fields they want? I'd also like to see the arcade fields moved out/split. -- ferret (talk) 13:50, 8 August 2017 (UTC)

It's up to you all to decide. I've found the embedded parameter useful elsewhere, so I tend to add it by default. Fetching images and captions are also normal for the infoboxes I work on, hence why I added them too. But I don't work on video game articles, so it's up to you. It's easier to remove features than to add them, so I'll leave them in the sandbox until you come to a conclusion. Thanks. Mike Peel (talk) 23:27, 8 August 2017 (UTC)

I personally have no issue with them. I think in our case they will very rarely be used, due to almost all our infobox images being ineligible for Commons (mostly fair use stuff), but there's no reason not to fully implement. As for release date: I pretty much find myself in the camp of "if you don't like whats coming from wikidata, specify local value", which will be the case in 99.9% of articles anyway. -- ferret (talk) 23:32, 8 August 2017 (UTC)

I don't want to encourage users to go to Wikidata, find that Wikidata has uploads disabled, inevitably end up at Commons, only to upload non-free files. No-one wants that. I think that's a pretty significant reason not to implement. For the few articles it is relevant, we can specify the page locally. As for release dates, I simply want a new section with an invitation extended to the typical editors to see if there is even a basic implementation of release date that we can make that will have easy and obvious consensus. --Izno (talk) 11:36, 9 August 2017 (UTC)

@Izno and Ferret: So, where are do things stand here? I think I've found a solution to the release date issue - try using {{Infobox video game/sandbox}} at Banished (video game) and see this Wikidata edit. The formatting could be improved, though (particularly if multiple release dates are applicable), but feedback on the data format would be useful first. Aside from that, I think you need to decide on the approach you want to take with the images and embedded parameter. It would be nice to merge the sandbox into the main template soon, though, once we resolve the outstanding issues. Thanks. Mike Peel (talk) 01:58, 19 September 2017 (UTC)

@Mike Peel: Formatting needs work for sure. If you can feed into Vgrelease, that would be best. Or, as an alternate idea: Wikidata-enable {{Vgrelease}} when no parameters are supplied. If no |release is supplied in the infobox, transclude a default VGR. Note, you'll need a df parameter. I recently converted VGR to a module. You might find some useful parts in Module:Video game wikidata too. I'd also perhaps suggest just using "platform" as the qualifier, instead of "applies to part". Note that current formatting is essentially Vgrelease by itself for single or all the same platforms. If platforms differ, it's the platforms in bold, line break, then vgrelease for those platforms, followed for subsequent platform groups. See Half-Life 2 for an example of a "full, complex" format case. -- ferret (talk) 02:06, 19 September 2017 (UTC)

OK, that's getting a bit too complex for me right now (I don't follow the acronyms, I don't currently speak Lua, and it's getting late). I've made a few more changes to the sandbox code for the release info, though. Would it be useful if we rolled out the rest of the code soon (leaving out the parameters in dispute), or should we wait until these issues are resolved? Thanks. Mike Peel (talk) 02:17, 19 September 2017 (UTC)

I'm personally ok with the changes outside of the release field. Switching to WikidataIB brings new function without changing the default behavior we already have, from what I can tell. You'll need to update the documentation to reflect the new parameters available and how to handle the arcade fields. WP:VG/WD may need updates as well to reflect WikidataIB usage and how to suppress fields, source only, etc. I will look into making a sub-template for releases when I have some time. Our formatting expectations are extremely specific and I'm just not sure we'll be able to solve it. I will likely take the topic to the broader WP:VG talk page later. -- ferret (talk) 12:46, 19 September 2017 (UTC)

I'm not okay with the image/caption changes, nor the release change. The others seem fine. Please start an RFC about these things. --Izno (talk) 14:38, 23 September 2017 (UTC)

@Izno: The image/caption change has been live for a while. Should that be undone? I'll make the rest of the changes, leaving out the release change, later today. Thanks. Mike Peel (talk) 15:37, 23 September 2017 (UTC)

@Izno and Ferret: OK, the new version is now live. Please let me know if there are any problems. I've left the image and caption code in there for now, but it can easily be removed if needed. Thanks. Mike Peel (talk) 22:04, 23 September 2017 (UTC)

@Mike Peel: Please make sure you update the template documentation for the new fields. I think you might also need to add the WikidataIB fields (suppress, qid, commons, ref, source only, etc) to the valid parameter check. -- ferret (talk) 22:05, 23 September 2017 (UTC)

@Ferret: Done, thanks for the reminder! Mike Peel (talk) 22:14, 23 September 2017 (UTC)

@Mike Peel: Added a few more parameters to the check, and synched sandbox. We still need some documentation on the WikidataIB fields. -- ferret (talk) 22:15, 23 September 2017 (UTC)

@Ferret: The WikidataIB documentation is now there. Thanks. Mike Peel (talk) 22:23, 23 September 2017 (UTC)

• The addition of the logo (data1) seems to be cluttery overkill, e.g. see Grand Theft Auto III. The problem is that the infobox now displays two different images, one above and one below the caption. This is alike the Infobox company template, but does not quite nail the point. I suppose this was meant to include a screenshot of sorts, but our guidelines here even say that we should not include those there. Could it be removed again, please? Lordtobi (✉) 09:55, 24 September 2017 (UTC)

  Oops, I had forgotten that I'd added the logo code. As it wasn't discussed here, and it seems to be causing problems, I've commented it out. Thanks. Mike Peel (talk) 11:57, 24 September 2017 (UTC)

  Well, uh, let's just say I don't see the point in having the logo in either way. Per our doc, we would only use a logo as secondary replacement for a missing cover, and "avoid [...] multiple images (per WP:FUC #3)"; plus I wouldn't say that the logo besides the cover (which in 99% of cases already includes the logo) is utterly pointless. Unless I'm not proven mistaken, I believe it would be best to just knock it out again. Lordtobi (✉) 12:06, 24 September 2017 (UTC)

  The only logos that were being added were those on Wikimedia Commons - so the Fair Use Criteria don't apply there. Or, you could argue that the logo should be shown instead of the fair use image. ;-) Thanks. Mike Peel (talk) 13:15, 24 September 2017 (UTC)

@Mike Peel: A few editors have stated that blank local values no longer suppress Wikidata, which was how Module:Wikidata functioned. Is that to be expected? My "go" vote on this was based around expecting the existing suppression to work, that is, there would be no change to current data pulls, just more available functionality. This is most commonly brought up in regards to the engine field. Please see WP:VG/WD and let me know if those instructions for suppression are no longer valid. If not, we may need to fall back, in part or whole, for a wider discussion. -- ferret (talk) 14:26, 24 September 2017 (UTC)

@Ferret: I thought that way of coding it would support blank local values suppressing wikidata, but apparently not. I've modified the code so that this now works. Thanks. Mike Peel (talk) 14:59, 24 September 2017 (UTC)

@Mike Peel: That appears to have worked to suppress engine at Wolfenstein 3D. -- ferret (talk) 15:02, 24 September 2017 (UTC)

Arbitrary break - new issues?

Please add new issues here. The inclusion of a logo, and non-suppression of blank local values, have been fixed. -- ferret (talk) 15:02, 24 September 2017 (UTC)

• Dissident93 voiced on WP:VG a concern regarding the Commons link now given at the bottom of the infobox. This wasn't discussed, so I guess it should be? Lordtobi (✉) 15:23, 24 September 2017 (UTC)

• It seems out of place and doesn't really relate to the infobox specifically, so I don't see why it belongs there. ~ Dissident93 ^(talk) 18:36, 24 September 2017 (UTC)

• Not directly part of the major change, which was switching to Module:WikidataIB. I have removed it pending further discussion. -- ferret (talk) 21:39, 24 September 2017 (UTC)

• Can there be a way to suppress citations from Wikidata? The ones on Dota 2 are either outdated or not even relevant to what it's being sourced to. This is not to mention that infoboxes aren't supposed to have citations anyway, as they are all preferred to go in prose. ~ Dissident93 ^(talk) 18:39, 24 September 2017 (UTC)

• @Dissident93: At the moment, refs can be disabled per article by setting refs=no. We could make that the default if needed, however my understanding was the opposite of yours - that the infoboxes should have references in, and it's bad that we have so many unreferenced infoboxes at the moment... Thanks. Mike Peel (talk) 18:57, 24 September 2017 (UTC)

• No, any well written article doesn't do that, and should have all of its sourcing in prose instead. And if an article doesn't have that, it most likely will not have any sources in its Wikidata either. And even if we need citations in the infobox for some reason (it's not forbidden), then I'd personally rather it be local, because Wikidata is shared by all the Wikipedia languages, and perhaps a non-English one uses one we considered non-reliable, making this more of hassle than it helps. ~ Dissident93 ^(talk) 19:11, 24 September 2017 (UTC)

• I think it would be fine to default to refs=no. It's good to have the functionality, even if we don't normally use it. -- ferret (talk) 21:38, 24 September 2017 (UTC)

• OK, the default is now 'refs=no'. Set 'refs=yes' to enable in any given article. Thanks. Mike Peel (talk) 22:22, 24 September 2017 (UTC)

• Thanks. ~ Dissident93 ^(talk) 05:48, 25 September 2017 (UTC)

Unwanted Wikidata results

Astroneer: the previous version (18 August) had no Wikidata references (it had a probably unnecessary "edit on Wikidata" in the infobox, but no values were taken or sourced from Wikidata). Since then, the only thing done to the article was adding one cat with no impact on Wikidata or the infobox[1].

The Wikidata item for the game also hasn't been changed since June, so that also can't explain the difference. So it must come from either this template directly, or an underlying template.

The problem is that now the modes "Single-player, multiplayer" and the platforms "Microsoft Windows Xbox One" are sourced to Steam, Wikidata Q337535. That it is useless to get the Wikidata number for Steam instead of the enwiki link is a different issue (dependant on CiteQ, which is up for deletion anyway); that Steam is a shop and not the kind of source we want here is partially a problem of Wikidata (they shouldn't allow it) and partially a problem here (which Wikidata source should we port to here, and which not). But that this template adds Wikidata sources a) even though the values are locally added, not through Wikidata, and b) even though the actual value (i.c. XBox) is not even included in the Wikidata item, is a huge problem: basically, you are now taking local values and adding Wikidata sources for the same field, without any consideration whether they have the same value. This is a big nono of course. In general, when we have locally added values, like here, for these fields nothing from Wikidata (values, source, ...) should be imported. Fram (talk) 13:20, 25 September 2017 (UTC)

@Fram: This was already addressed, page needed a purge. Refs=Yes was the case when the template was first updated to the new module, but it was changed to Refs=No as the default, following similar feedback. -- ferret (talk) 13:24, 25 September 2017 (UTC)

Thanks. If we now could also get rid of the "edit on Wikidata" for infoboxes where nothing is shown from Wikidata anyway, like in this case... Fram (talk) 13:29, 25 September 2017 (UTC)

@Fram: I think its more valuable to always have that link, than to have it missing when values are being pulled. Will explore options though. @RexxS and Mike Peel: Do you have any ideas for causing {{EditOnWikidata}} to be hidden if Module:WikidataIB provides no values on a given page? -- ferret (talk) 13:32, 25 September 2017 (UTC)

Doing it automatically may be hard, having a "nowikidatalink=yes" parameter may be easier. Fram (talk) 13:33, 25 September 2017 (UTC)

I'm not sure I see the benefit of removing it. Even if nothing currently shown in the infobox is from Wikidata, that doesn't preclude adding info to the infobox by editing it on Wikidata... It would be possible to enable the 'noicon' parameter, which doesn't show the edit on wikidata link at the bottom when the pencil icons are present, if that would be better. (See the documentation at Template:EditOnWikidata for details.) Thanks. Mike Peel (talk) 14:53, 25 September 2017 (UTC)

@Mike Peel: Sandbox is synched to prod and ready, give it a go and let's see how it would look. -- ferret (talk) 15:02, 25 September 2017 (UTC)

@Ferret: I've added the code to the sandbox, give it a go and see what you think. Thanks. Mike Peel (talk) 15:07, 25 September 2017 (UTC)

@Fram: I need to test, but my understanding is that this parameter Mike has added to the sandbox, noicon, works like thus: If set to yes, WikidataIB does not output edit icons, and the "Edit on wikipedia" displays at the bottom. If set to no, WikidataIB will put little edit pen icons next to Wikidata values, and the link at the bottom will be hidden. Does that fit what you're looking for? Which would you prefer as a default? -- ferret (talk) 15:17, 25 September 2017 (UTC)

That seems like a good solution, and the current can stay as the default as far as I am concerned. Fram (talk) 15:24, 25 September 2017 (UTC)

@Fram and Mike Peel: Implemented as Mike wrote it, with default of noicon=no. This means the pen icon will be shown next to values populated from Wikidata. If none were, then no icon or link will be shown. Alternatively, setting it to yes will hide the pens, and display the single Edit link at the bottom. This might be preferable for infoboxes that are entirely Wikidata, as the pen will be displayed repeatedly. (Like so)-- ferret (talk) 01:03, 26 September 2017 (UTC)

Prequel and Sequel

It would be really nice if someone changed the infobox to contain an option for prequels and sequels, thanks.

XCoduster (talk) 14:25, 10 October 2017 (UTC)

Won't happen, they were previously removed. See Template talk:Infobox video game/GameSeries. -- ferret (talk) 14:48, 10 October 2017 (UTC)

Sometimes a game isn't either (a spin-off), so how would they be handled? A series navbox for the more notable ones normally exists on these pages, filling the same general role. ~ Dissident93 ^(talk) 22:14, 10 October 2017 (UTC)

Note that navboxes don't appear on mobile devices, while infobox content does. Thanks. Mike Peel (talk) 22:51, 10 October 2017 (UTC)

While that's a shame that it doesn't (due to technical reasons?), my opinion on the matter hasn't changed. Even in the navboxes, games are listed in non-subjective chronological order and not on prequel/sequel status. ~ Dissident93 ^(talk) 23:51, 10 October 2017 (UTC)

@Dissident93: See phab:T124168. Thanks. Mike Peel (talk) 23:57, 10 October 2017 (UTC)

Not personally an issue for me as I don't browse/edit Wikipedia on mobile devices, but it's still good to know. ~ Dissident93 ^(talk) 23:58, 10 October 2017 (UTC)

Add a game version information

Hello everyone, I was wondering what are the opinions around here about adding a "game version" info for the games.
It would be great for knowing the game state of a title, such as an "Alpha" game, a "released" game, etc.
Do you guys think it will go well with the wikipedia arts? I know maybe a lot of games won't have a game version explicitly stated, while others will.
For example the Sims will be a game with a very complicated game version to keep track of, specially because they release minor patches now and then, and the GVs are horrible.
On the other hand, games like C&C Red Alert 2 will have only one game version as the game is no longer under Development (Last version is 1.006). And Indie games such as Rimworld, will be able to state the actual Alpha version they are in.
Finally, games like Assassins Creed, have they any game version at all?

Opinions?
Frenchiveruti (talk) 15:04, 10 October 2017 (UTC)

References

We had a recent discussion on this with the consensus being that they are not appropriate. Versioning is a technical detail that doesn't mean much to the general reader. Key updates and patches can be noted in the text if they are the subject of note. --MASEM (t) 15:33, 10 October 2017 (UTC)

Major release updates are normally covered by reliable sources and the info placed into the development section. Just including the gameplay version number tells a reader unfamiliar with the game nothing; the same generally happens if you want to list alpha or beta status. ~ Dissident93 ^(talk) 22:16, 10 October 2017 (UTC)

@Frenchiveruti: I agree, the current infobox has many problems and is worse than the software infobox. For context, if you read the discussion history here, there is here a strongly interlinked author clique which objects every reasonable & needed adaption of this infobox, mainly with the argument "we enforce it for years like that: we don't like change". Shaddim (talk) 10:21, 23 November 2017 (UTC)

Why so quick to accuse people? If you'd read the discussion history right the way back, you'd realise that the Infobox used to be a massive horrendous mess, full of unreferenced garbage. As WP:INFOBOX states "the purpose of an infobox: to summarize (and not supplant) key facts that appear in the article" i.e. We should be able to delete the infobox from the article and not lose any information. Infobox VG sadly has a long history of that not being the case. The fields that are repeatedly rejected are the same ones that are never or rarely mentioned in the prose, and very rarely reference to a reliable source. They are rarely key facts. - X201 (talk) 11:10, 23 November 2017 (UTC)

Don't want to draw any conclusions but User:Frenchiveruti's first edit in three years (and second overall) was to come to this somewhat obscure talk page and query a very similar issue as User:Shaddim did in May, then is backed up in agreement by the same User..........consensus by collusion? Salavat (talk) 13:52, 23 November 2017 (UTC)

It's not because "we don't like change". If you haven't noticed, the infobox has had the media and distribution field removed in the past few years because they are also unnotable in the vast majority of cases and were almost never mentioned in prose either. Everything the OP mentioned belongs as prose instead, per my original response. ~ Dissident93 ^(talk) 19:18, 23 November 2017 (UTC)

Field order

The field order in the infobox doesn't match the field order in the article Template:Infobox video game, specifically in the Full syntax, Syntax guide and TemplateData sections. For example, the staff fields (director, producer, writer, etc.) are at the top in the infobox; on the other hand the staff fields are at the bottom in Template:Infobox video game. Could someone make the field order in the infobox match the order in Template:Infobox video game? -- Wrath X (talk) 05:13, 2 December 2017 (UTC)

The current order is pretty much fine: The specific developers appear next to the developing company, but in syntax, are at the bottom as they are usually added post-release (through in-game credits). At least that is the scheme I have followed on it with, and it works for me, and apparently most editors. Lordtobi (✉) 09:27, 2 December 2017 (UTC)

Infobox width

Could the infobox width be slightly increased so as to match the width of infobox film? Both game and film infoboxes already have matching font sizes, images sizes and label-data gap. They also have similar fields (director, producer, writer, etc.). I think it would nice to have consistency between similar infoboxes. Wikipedia:Manual of Style/Infoboxes also mentions consistency between infoboxes as a design principle. -- Wrath X (talk) 12:45, 9 December 2017 (UTC)

We are defaulting to a width of 264px. Other infoboxes either don't support width as a parameter at all, or only set it if specified. We should remove the 264px default and let the main module handle, while still supporting the parameter for the cases where it is used. -- ferret (talk) 13:08, 9 December 2017 (UTC)

Template-protected edit request on 11 December 2017

In the "bodystyle" parameter, change the width from "264px" to "22em". This is to match the width of infoboxes video game series, video game character and film. Wrath X (talk) 08:32, 11 December 2017 (UTC)

Normally, I wouldn't oppose this change, but it appears that you have previously changed "264px" to "22em" on both, VG series and VG character. This size was streamlined for video game-related infoboxes (and I guess there was a reason for that), so why do you think 22em is superior to 264px? Lordtobi (✉) 08:41, 11 December 2017 (UTC)

Because it is the same width as infobox film. Both video game and film infoboxes have matching font sizes, images sizes, label-data gap, etc. They also have similar parameters (director, producer, writer, etc.). It seems logical then for both infoboxes to have matching widths. Wikipedia:Manual of Style/Infoboxes also mentions consistency between infoboxes as a design principle. Wrath X (talk) 08:50, 11 December 2017 (UTC)

 Done Lordtobi (✉) 10:25, 11 December 2017 (UTC)

Thanks. Wrath X (talk) 10:27, 11 December 2017 (UTC)

More specifically, 22em is the default in Module:Infobox, it appears. As I said above, but was waiting for more opinions, we should remove our default entirely and allow the Module to control it, especially if our concern is consistency with other infoboxes. Changing to 22em is a fine step though. -- ferret (talk) 12:20, 11 December 2017 (UTC)

Default image width

Could someone change the default image width so it fills the infobox more? One of previous changes (in September I think) made it so that images are now less wide. Comparison with different image ratios:

• old to now
• old to now.
• old to now

I prefer the old size with less padding in all cases. --The1337gamer (talk) 00:39, 19 December 2017 (UTC)

Not done, pending discussion. Since May, it was changed from a hardcoded upright=1.15 (With no parameter to adjust) to a softcoded upright=1.0 (Overridable with image_upright). I don't think we should upscale by default. User preferences for thumbnails should take precedence. Are any other widely used infoboxes using a default upright of 1.15? -- ferret (talk) 01:18, 19 December 2017 (UTC)

No worries. Just increased thumbnail size in preferences so it doesn't look bad on my monitor now. --The1337gamer (talk) 01:28, 19 December 2017 (UTC)

I briefly check a few others. Infobox person is doing what we do, default of 1.0 with parameter to adjust. Infobox film has it hardcoded to 1 with no parameter. -- ferret (talk) 01:30, 19 December 2017 (UTC)

Removal of the display parameter

Is there any reason why the |display= parameter is still included in the infobox? Not only is it almost never mentioned within the article itself (the main criteria for infobox parameters), it's almost always unsourced, and a mass collection of technical numbers (color depth, resolution, etc) is never ideal for the casual reader. I say we just get rid of this field, as it's only relevant to older arcade games that don't go against my three points (which is a very low number). The |cpu= and |sound= paramters could also be removed, as they are only relevant for older games running their own hardware (arcade), with the notable ones already having a linked system in the |arcade system= parameter that states it anyway. Thoughts? ~ Dissident93 ^(talk) 22:09, 5 February 2018 (UTC)

Don't have a strong opinion on this, beyond the fact that everything in the infobox is suppose to be sourced and in the article. That said, if we keep these fields, I think they are prime candidates to move to a embedded infobox that would be utilized with |embedded=. -- ferret (talk) 22:18, 5 February 2018 (UTC)

Better than nothing, but my issues with it would still exist. The |cabinet= is trivial as well, and we could also replace the generic "Arcade" usage in |platform= with the actual system when known, getting rid of |arcade system= to further clean things up. ~ Dissident93 ^(talk) 05:49, 6 February 2018 (UTC)

Optional support stopped parameter wanted needed

I was editing some pages on MMO's and realized that we need optional parameters for putting in when support stops for the game. We need several:

• Offline support such as updates, patches bugfixes.
• Matchmaking servers.
• Online play servers.

This can mean patches and bugfixes for offline games. For online games we also need an to define when the servers are taken offline.

• This was discussed before, and I believe not just once, but it has never quite found any consensus. If we were to include such a parameter, it would usually just be a generic "discontinued" one, which denots the date the game (or it's multiplayer if that was the primary game component) went unplayable. I wouldn't be opposed to including such a paramter, though I cannot express support either, as it will only find limited use within our scope. Lordtobi (✉) 09:27, 31 March 2018 (UTC)
  • The problem with that is that some people would be adding that to non-MMO/offline games that haven't received updates in a longtime, such as RollerCoaster Tycoon. I don't otherwise oppose it on principle, but I suggested that we use a MMO/online-only specific infobox for this sort of thing. But as you said, it would be a small minority compared to the 1000s of other games that wouldn't need it. ~ Dissident93 ^(talk) 20:15, 31 March 2018 (UTC)

Separator

The Wikidata values returned by this template are set as separated by line breaks. From what I've seen this is unusual, doesn't look too good, and can't be changed. Now, the template default is comma-separated, which looks normal. However, an editor might want to use a different format sometimes, so I propose that we introduce another parameter into the infobox, which can be set as the separator. This can be done by changing |sep="<br />" to |sep={{{sep|}}} (I think). 101.175.16.163 (talk) 11:11, 4 April 2018 (UTC)

That seems excessive and a bit micro-managey. --Izno (talk) 12:38, 4 April 2018 (UTC)

This would also cause a lot of inconsistency among VG articles that use Wikidata. However, it should not be <br /> in general either, per WP:VLIST, we should use unbulleted list or plainlist templates instead. Lordtobi (✉) 13:26, 4 April 2018 (UTC)

The series field

Unless overridden, this automatically calls Wikidata, which can call any old rubbish in Wikipedia regardless of its relevance or irrelevance. Links to DAB pages get caught by User:DPL bot, which reports bad links to DAB pages per WP:INTDAB.

Three editors, with over 200,000 edits between them, have been discussing this problem. One of them had found a solution, after about an hour's work. See User talk:Narky Blert#Eye of the Beholder.

This is not acceptable. Templates like this which create bad links which are caught by a maintenance bot amount to WP:DISRUPTIVE editing. Narky Blert (talk) 01:21, 12 April 2018 (UTC)

We also need to consider the bad links which are not caught by a maintenance bot because they link to a credible but irrelevant article, such as Battlefield instead of Battlefield (video game series). Certes (talk) 10:17, 12 April 2018 (UTC)

It's easy enough to fix the data in Wikidata or suppress the field. Examples provided are no different than any case where a less experienced editor makes the wrong link. Seems like there's a general complaint on the talk page linked about Wikidata usage in general or entirely. Recommend that this specific template (Out of dozens) is not the venue for that. -- ferret (talk) 11:18, 12 April 2018 (UTC)

Skate (video game) and Template:Infobox video game (series= field)

@TheDeviantPro: Template:Infobox video game is one of about half-a-dozen templates which create spurious links to DAB pages. These are errors under WP:INTDABLINK. The guidelines take precedence over template documentation. If a well-behaved and long-established bot like User:DPL bot reports an error, then there is an error.

The problem is almost certainly that, somewhere deep in its innards, Template:Infobox video game is making a #ifexist call to Wikipedia. The link may show as black rather than blue in the problem article, but the error is nonetheless there and it needs to be fixed. It cannot be swept under the carpet. I came across the problem in Skate (video game) for the fourth time because it had once again reappeared in Disambiguation pages with links. I have now fixed it in another way. Errors like this are easy to see, but extremely difficult to find and to fix. I doubt that there are as many as five editors on English Wikipedia who know how to do so. (Offhand, I can only think of another two or perhaps three. I have wasted well over an hour of my life learning how to do so.)

Pinging Certes, who is the real expert on this type of template problem; and BD2412, who too has tried to fix this identical problem in Skate (video game), and who has had his fixes reversed twice. Repeatedly re-inserting an error which has been fixed is WP:DISRUPTIVE. Narky Blert (talk) 11:57, 29 May 2018 (UTC)

All templates that have a potentially ambiguous field should have a parameter to add a disambiguation term for that field. Virtually all templates do, this one just needs this functionality added. bd2412 T 12:03, 29 May 2018 (UTC)

I've only glanced at the template and the related issue with the page, but it sounds like this is (surprise surprise) a Wikidata issue, not a template issue. If the WD information is improper then it should be fixed or removed. Primefac (talk) 12:31, 29 May 2018 (UTC)

• I temporarily fixed the issue by surpressing Wikidata fetching using a comment inserted as parameter. The Wikidata entry appears to legitimately include an item for the serries which we here on enwiki simply do not have an article for. This is why I previously was against the inclusion of Wikidata fetching; we can more easily (and sourcedly) insert information into the template parameters and cross-copy to Wikidata instead of having to rely on the does-it-work?-approach when copying directly from Wikidata. This is not to say that Wikipedia is more affective to vandalism. Lordtobi (✉) 12:39, 29 May 2018 (UTC)

I can't find a relevant #ifexist call. There is lots of complex code behind the template but I think the transclusion is being recorded by the call to mw.title.new at line 370 in function _getvalue of Module:WikidataIB. Its purpose is to determine whether the title recorded as the enwiki link refers to a redirect. Infobox video game contains {{{series|…{{#invoke:WikidataIB…, i.e. it uses the value of the series parameter if set but invokes WikidataIB to get a default value if not. So, as you've already worked out, setting series=anything (even a comment) will stop the module from being called and prevent the spurious wikilink. Certes (talk) 14:41, 29 May 2018 (UTC)

Can we not creted Skate (series) as a redirect to the first Skate game (potentially to a sequel's section), and leave it be? I realize that's self-reflexive on the article in question, but it would resolve the error I think. --Masem (t) 14:44, 29 May 2018 (UTC)

Skate (video game series) exists, possibly so-named to avoid confusion with Sk8 (TV series). Certes (talk) 15:05, 29 May 2018 (UTC)

I got reverted at least twice for linking to Skate (video game series). Hence my moan here.

As so often (surprise surprise), this does indeed look like a Wikierror Wikidata issue. I trust Wikidata even less than I do Wikipedia as WP:RS. It is a major problem that Wikidata will accept neither redlinks nor {{ill}} links. Narky Blert (talk) 23:43, 29 May 2018 (UTC)

Wikidata maintains the intersite links last I checked? Sounds more like a complaint with how Module:WikidataIB functions. Perhaps some adjustments there would be prudent. If #ifexists checks are what causes DPL to flag it, then perhaps the module can be adjusted to rely on Wikidata's own sitelink data to determine existence. That will require arbitrary calls for each linked item though. Is there another way to locally check for page existence? Reading the module myself right now, I see it's already relying on Wikidata for sitelinks and only causes this due to trying to detect a redirect, as Certes noted. It's clear the module is ATTEMPTING to avoid dab links, so if anyone can suggest a method better than mw.title.new? -- ferret (talk) 23:53, 29 May 2018 (UTC)

Going to the source: Module talk:WikidataIB#New parameter for getValue sought to avoid attempt to resolve redirects. -- ferret (talk) 00:32, 30 May 2018 (UTC)

Add new field for current status

I think a new field labeled "state" under "release" would be useful for quickly informing users if the game is currently defunct or still active. — Preceding unsigned comment added by Orelbon (talk • contribs) 00:21, 15 June 2018 (UTC)

It's been repeatedly discussed here and at WT:VG, with the general consensus against. -- ferret (talk) 00:35, 15 June 2018 (UTC)

Only useful for online games that requires servers and matchmaking to function. It's far more likely to be abused, such as people adding "abandoned" or "inactive" for single-player games that haven't received a patch in a year. ~ Dissident93 ^(talk) 01:40, 15 June 2018 (UTC)

Edit request: adding "border" parameter

Include the {{!}}border function often used in the infobox's image parameter into it's own border parameter, to allow editors to have an easy route to including small borders for infobox images that have white space on their borders. It can be toggled on by any input such as "yes" or "y" if the parameter can be included using a parser function such as #switch a la {{Infobox album}}. – PhilipTerryGraham (talk · articles · reviews) 21:34, 29 June 2018 (UTC)

 Done |border= added — JJMC89 (T·C) 05:01, 30 June 2018 (UTC)

macOS in the infobox

Why should game articles use the name of the OS when it was released? The previous names of macOS are already covered in its own article, and I think that keeping the older names will only bring confusion in the future. Software articles already use the most recent name, so why not video game articles? - 83.143.85.130 (talk) 09:11, 20 June 2018 (UTC)

We want to use the terminology that matches what sources say or likely going to say. In software, which gets updated with features on a generally regular basis, there will be new content about that software which will refer to the OS as "macOS" nowadays, so it makes sense to use it there. Games, outside of things like MMOs and other newer "living games" don't get those types of updates - they may be patched or get DLC, but they're released once. Sources will only use the original name , OS X , at that point. This is similar to when studios change name, we don't update their past games to reflect the studio name (eg we aren't going to change games developed by Sony Online Entertainment to Daybreak Game Company); that would make our articles inconsistent with sources. --Masem (t) 14:17, 20 June 2018 (UTC)

"Sources will only use the original name , OS X , at that point." This couldn't be further from the truth. I have check multiple game articles, and non of the sources ever mentioned Mac OS X, OS X, or macOS, so the statement that it "would make our articles inconsistent with sources" does not apply to a game's platforms, as the only thing these sources do mention what is that the game is being developed for the Mac, not any individual version of macOS. If you are telling me that you want to "use the terminology that matches what sources say", then every single article in Wikipedia that states Mac OS X/OS X as the platform is wrong. Lets not forget to mention that Microsoft Windows and iOS do not get this same treatment. Yes, countless sources state that a game is coming out for Windows, but countless others only mention available for PC. Meanwhile, there are countless games that had been released for iOS back when it was called iPhone OS, and somehow those articles had the platform renamed.

Another reason that I have been given before is that "we retain the previous name because if Microsoft Windows was one day suddenly renamed BillGates-OS no one would want to rename every single entry on Wikipedia that way", yet here I am, having tried to do just that for macOS. Why was this done for iOS, but not for macOS? Why is Microsoft Windows 7 not listed, but OS X must be listed? - 83.143.85.130 (talk) 17:08, 20 June 2018 (UTC)

They are not the same thing. Listing Windows 7 would make it seem like an exclusive; a comparison would be listed Mac OS X Tiger for games released during its era. This is something we just don't do for platforms, as we list the base name only. ~ Dissident93 ^(talk) 21:57, 20 June 2018 (UTC)

Fair enough, but that still doesn't justify using OS X or Mac OS X as the "base name". macOS is the name of the family of operating systems for Macs, just like Windows is a family of operating systems produced by Microsoft. By this same logic, listing OS X would make it seem like and exclusive to versions of macOS such as OS X Mountain Lion, OS X Mavericks, but not macOS Sierra. - 83.143.85.130 (talk) 22:14, 20 June 2018 (UTC)

Is this just going to be ignored now? I started this discussion because I think the way macOS is treated right now is wrong. I want this to change, macOS should be the only thing that appears in any infobox, and if anyone has the time to make these change, they should be allowed to. - 83.143.85.130 (talk) 19:48, 25 June 2018 (UTC)

What response are you looking for? Two users replied about why the current consensus exists, which has already been discussed several times. Sometimes a discussion doesn't lead to the consensus changing and it remains as is, which is to keep the OSX/macOS label from the game's launch time. -- ferret (talk) 19:52, 25 June 2018 (UTC)

They may have replied as to why the current consensus exists, but they have done nothing to rebut my responses to their replies. That is the type of response that I'm looking for. - 83.143.85.130 (talk) 20:49, 25 June 2018 (UTC)

Still waiting for an actual discussion to occur here. I have stated why the current reasonings to keep the current rule are invalid, and I still aim to have it changed 83.143.85.130 (talk) 08:45, 30 July 2018 (UTC)

If you believe the response is insufficient, you should consider WP:RFC. --Izno (talk) 11:43, 30 July 2018 (UTC)

I think you're taking this the wrong way. You'd have to convince editors who follow the consensus to change their opinions (which is most of WP:VG), rather than try and convince yourself this is the correct way. Personally, I think games that just released when it was called Mac OS X should just keep that, and games released after the renaming should be macOS. The only real argument against this are ones that use the games as a service model (think popular, longlasting multiplayer games), where they are treated like constantly updated software that spans years. Your point about iPhone OS seems to be fair, but it could be argued that the brand name was still just iPhone even back then (so perhaps that's why they got renamed?) ~ Dissident93 ^(talk) 13:07, 30 July 2018 (UTC)

Iterative games

Some series push out many games, or every season in the case of sports games. Such as FIFA 98 has a sequel in FIFA 99. If you look at any sports infobox, they have "next" and "prev" parameters, for easy navigation between articles (Such as 2014 FIFA World Cup.)

Could we encorporate something similar for video games that do this? Such as NBA 2K16, or Football Manager 2008)? Lee Vilenski ^{(talk • contribs)} 10:43, 9 August 2018 (UTC)

Archive on this subject, this was previously removed (or never existed at all, but perpetually requested): Template_talk:Infobox_video_game/GameSeries. -- ferret (talk) 11:32, 9 August 2018 (UTC)

It does seem to be requested a lot, but there doesn't seem to be any opposition. It's not exactly a difficult addition... Lee Vilenski ^{(talk • contribs)} 14:45, 9 August 2018 (UTC)

My only thought on this is that the last discussion took place in 2010, and consensus can change. I think there would need to be a fairly strong consensus to overcome the "perennial proposal" issue, but asking after an 8-year hiatus seems perfectly reasonable. Primefac (talk) 14:48, 9 August 2018 (UTC)

That was an old archive specific to this topic. There have been many more since numbered archived occurred. It's been brought up in the last year. -- ferret (talk) 14:49, 9 August 2018 (UTC)

Oh, well... just ignore me... Primefac (talk) 15:00, 9 August 2018 (UTC)

I oppose this, it's likely to cause more problems than it helps (constant edit warring for some game/series), and we already have navboxes for this exact purpose. ~ Dissident93 ^(talk) 16:57, 9 August 2018 (UTC)

I support this, just to get to ball rolling that we EXPAND the infobox again, instead of the excessive minimization focus which cripples currently the VG infobox. Shaddim (talk) 08:42, 15 August 2018 (UTC)

The infobox should be kept concise as possible, that's the whole reason it exists. To add bloat to it just because it's potentially informative is not the right mindset to have. ~ Dissident93 ^(talk) 16:58, 15 August 2018 (UTC)

currently it is excessively rigid and can't fullfil its purposes for many use cases. This can be seen on the enormous amount of editors which come and came to this talk page over the years asking for fixes. Who got shut down by a group of editors which make themselves too much comfortable with the idea of an minimized / perfect infobox. This is harmful, we should take input from outside (editors), and also minimalization/"optimality in minimality" is not our primary objective, at best a tertiary goal. Some redundancy / bloat is way better than a failed "one size MUST at all cost fit ALL" Shaddim (talk) 08:27, 16 August 2018 (UTC)

Please remember that the "Comfortable editors" have seen the infobox in it's wild west days, they've seen the removed fields in action, they've seen redundancy and bloat in action. They know how bad it was for average users. - X201 (talk) 10:13, 16 August 2018 (UTC)

This is the only particular field I ever really see get requested repeatedly, except for a status/active field, being the second. -- ferret (talk) 12:09, 16 August 2018 (UTC)

website. why is website still removed? we have the internet archive, we have now practically websites for free (unlike the 90s/2000s when websites got shut down if the game was not marketed anymore, being "costly"), so game websites are now available for almost all games. Shaddim (talk) 23:08, 16 August 2018 (UTC)

Because they get shutdown even quicker than they used to. As soon as the next game in the series comes into view, companies remove the content and redirect to the new title or to a series page. Case in point, EA/FIFA is a key perpetrator. - X201 (talk) 07:37, 17 August 2018 (UTC)

Also, the official website template makes it redundant. ~ Dissident93 ^(talk) 15:18, 17 August 2018 (UTC)

As I said, we have the internet archive (which is for me the killer argument, the now dead websites of games from the 90s are of great historical interest) & websites get not "shut down quicker than they used", this was in the 90s/2000s. With digital distribution (beyond shorttime 1x retail publishing) games live longer & have longer existing, permanent websites.Shaddim (talk) 18:36, 17 August 2018 (UTC)

I have to concur with X201, "have longer existing, permanent websites" is not actually the case. Sites from big publishers often disappear as soon as the game's immediate release cycle is over and the marketing company/department moves on. —  HELLKNOWZ   ▎TALK 19:04, 17 August 2018 (UTC)

the time of "immediate release cycle[s]" is over. We have now digital distribution. And more important, we have the Internet archive (and WP should overall resist "recent'isms", a website once relevant, IS forever relevant.) Shaddim (talk) 19:33, 17 August 2018 (UTC)

I'd argue that marketing websites don't have any lasting relevancy. And even so, the external link section serves fine. -- ferret (talk) 19:40, 17 August 2018 (UTC)

Weirdly, the infobox software which suffers from the same problems for the website field, has in 95% of cases this field filled. (checked for the first 20 of https://wiki.riteme.site/wiki/Special:WhatLinksHere/Template:Infobox_software) Shaddim (talk) 21:17, 18 August 2018 (UTC)

• Oppose Unnecessary. Navboxes exist. --The1337gamer (talk) 18:38, 15 August 2018 (UTC)

Oppose, not needed. Just imagine people fighting over whether chronologically-released or story-wise sequels should, whether non-direct sequels, spin-offs and spiritual successors count, etc. This is just more work with little gain. The series parameter is already present and gives better overview on inter-game contexts, including story and release chronology. The World Cup can easily use this format since there is no in-universe logic, they are simply held every four years; video games are not that simple. Lordtobi (✉) 18:42, 15 August 2018 (UTC)

To add on this, I wouldn't oppose it for games that have set release schedules (as much as video games can have), such as the Madden and Fifa series. However, the parameters in the infobox should ideally apply to every game and not just a certain genre/type, which is the same general argument we've had against the inclusion of a |active= parameter. ~ Dissident93 ^(talk) 18:57, 15 August 2018 (UTC)

• Opposed Per others. Fandom often wars over which game comes next in a series. Navboxes cover this already, but even then almost every game that has multiple sequels has a Series page, which better conveys this. Maintain next/prev fields requires constant maintenance of a chain spanning articles as well, whereas the navbox or series article tidily presents all that with single points to maintain. -- ferret (talk) 12:09, 16 August 2018 (UTC)
• Oppose - As per ferret, Lordtobi et al. - X201 (talk) 07:39, 17 August 2018 (UTC)

On staff in infobox

I am suggesting an addition, can I see some support, opposition, or comments?

The addition is in bold:

Note: In the following, plurals such as "developers", "publishers", "artists", etc do not exclude the singular (i.e. "artists", for example, implies "artist or artists"). These fields are reserved for key individuals deemed notable by their mention in prose. Individuals should not be listed in the infobox solely because their name is listed in the game credits. Similarly, with the credit fields, individual development tasks for one field (e.g. which artists designed characters and which designed concept art; or which writers created story lines and which wrote scripts) should not be mentioned in the infobox but in the article text instead. Individual tasks should be generally kept to prose and the field should only list key people.[1][2] For example, the distinction between story and script writers of The Legend of Zelda: Twilight Princess is mentioned in the article's development section.

TarkusAB^talk 22:52, 11 September 2018 (UTC)

• Oppose. If they are lead staff, then I don't see the issue with listing them. What does one or two names hurt? ~ Dissident93 ^(talk) 01:04, 12 September 2018 (UTC)
• Oppose Not every person in the credits might be notable, but what would be the point of not listing them? Within its bounderies, it is a neat little addition to the page. Similarly you would have to impose the renoval of cover art because it is usually not subject of critical commentary. Lordtobi (✉) 05:17, 12 September 2018 (UTC)

Wikidata series should be italicized

I've been seeing some Wikidata values for |series= pop up as non-italicized (a number in the context of The Oregon Trail presently).

From what I can tell, the use of {{If first display both}} inhibits this somewhat. I'm not sure if we need a custom solution here or if there is another 'helper' template (I am skeptical this is a helper template really...) which we should prefer. --Izno (talk) 20:09, 10 September 2018 (UTC)

The invoke of getWikidata was previously wrapped in italics markup, but that was lost when it was adjusted to the better WikidataIB formatting. Should be simple enough to readd. -- ferret (talk) 20:13, 10 September 2018 (UTC)

Famous last words. :) --Izno (talk) 20:16, 10 September 2018 (UTC)

@Izno: Module:WikidataIB needed a small update, but see this diff and see the tests at Template:Infobox video game/testcases#Wikidata test italic series. -- ferret (talk) 22:15, 13 September 2018 (UTC)

I would probably prefer to use HTML there rather than wikitext, but it shouldn't matter unless there is something odd on the rest of the page. Output is fine either way in the test case page. --Izno (talk) 00:19, 14 September 2018 (UTC)

Repeated platforms

Godville has repeated platforms (specifically, 'web browser'). (I know why.) I'm wondering if that can be cleaned up; either reduce it to 1 instance of 'web browser' or include some amount of the qualification in the source Wikidata. I'm broadly in favor of the former. --Izno (talk) 20:26, 9 October 2018 (UTC)

It should be cleaned up in Wikidata, IMO. Platform shouldn't be used to denote publication dates. I.e. there should only be 1 "web browser" listed on WD Platform, and denoting Russian versus English release should by under Publication Date. -- ferret (talk) 21:12, 9 October 2018 (UTC)

Composer link

The composer label currently links to video game music, but wouldn't it be more appropriate to link it to video game composer? The label is after all called "composer". This would also make it consistent with other fields which link to designer, programmer, artist, writer, etc, as opposed to design, programming, art, writing, etc. -- Wrath X (talk) 03:32, 24 November 2018 (UTC)

Wrath X,  Done. Lordtobi (✉) 11:39, 24 November 2018 (UTC)

Hey Lordtobi, I've noticed that you also linked the director field to creative director. However, the creative director article isn't specific to video games; though it does have a section for video games. I've created a redirect link "video game creative director" which links to the video games section. May I suggest changing the director link to video game creative director? This would also make it consistent with the other staff links which start with "video game". -- Wrath X (talk) 08:57, 25 November 2018 (UTC)

Wrath X, sure. Lordtobi (✉) 11:48, 25 November 2018 (UTC)

Add "follows" and "follwed by" in videogame infobox template.

Add "follows" and "followed by" in videogame infobox template. This would make it much easier to navigate previous and next in a video game series instead of requiring the reader to return to the series page. Prodikl (talk) 20:22, 11 January 2019 (UTC)

This content is going to be covered in the article, likely in the lead, and doesn't seem supremely germane to the article topic at hand. Der Wohltemperierte Fuchs^(talk) 20:31, 11 January 2019 (UTC)

This has been discussed multiple times before and has yet to garner consensus for it, so I doubt it does now. ~ Dissident93 ^(talk) 21:13, 11 January 2019 (UTC)

To add to both, we would run into problems in many longer series of what "follows", is it by the release or by game chronology or other metrics? To use an example, there's at least three ways to organize the various Assassin's Creed titles. --Masem (t) 21:41, 11 January 2019 (UTC)

Thank you for the replies. I understand that there could possibly be some ambiguity regarding which series, but I think having the option is more helpful than not having the option. I think it is a worthwhile discussion point for each series to define their own series on a case by case basis. Users might add multiple entries for which series path they would follow

E.g. (For "Assassin's Creed Rogue"):

• Followed by: Assassin's Creed Unity (Main Series)
• Followed by: Assassin's Creed Identity (Full Series)

Again, I understand and agree with the opinions listed here, I would only argue that it'd be a net gain having this option and wouldn't detract from the experience of reading and exploring a series, and on the contrary, would add to the experience. Thank you again for taking the time to consider and reply.Prodikl (talk) 22:03, 11 January 2019 (UTC)

For bigger series, this sort of thing is handled by the navbox instead, so it's not like this information isn't represented anywhere at all. ~ Dissident93 ^(talk) 22:13, 11 January 2019 (UTC)

 Not done: please establish a consensus for this alteration before using the {{edit template-protected}} template. Izno (talk) 23:58, 11 January 2019 (UTC)

Co-op

Can this be added to the modes field since it's technically different from a traditional multiplayer mode? I can name dozens of games in which the multiplayer is co-op only (e.g. Mario Galaxy and Odyssey, Knuckles' Chaotix, etc), and the article on the subject describes it as a distinctive mode. JOEBRO64 21:27, 31 December 2018 (UTC)

I'd be on board with this, as it has a dedicated article at Cooperative gameplay. -- ferret (talk) 00:07, 1 January 2019 (UTC)

I do recall a discussion on this point, and the issue is that if you start differentiating between competitive and co-op, then people will want to add in other facets, like couch-vs-online co-op, asymetric multiplayer, etc. As long as we are very explicit that it is only 3 possible values, and that any specific aspects should be discussed in the body. --Masem (t) 00:38, 1 January 2019 (UTC)

Well, if you make it a switch statement, then you can set it to only have three values. Primefac (talk) 01:17, 1 January 2019 (UTC)

Support distinguishing between competitive and cooperative multiplayer. Phediuk (talk) 02:43, 14 January 2019 (UTC)

• I think the mode parameter should just be removed, as I feel like it's something that we have simply kept from the past where we used to include media, version numbers, and other non-essential forms of information. I'm aware this is probably not a popular opinion so its unlikely to get removed. But that being said, co-op is just a form of multiplayer, and we don't distinguish other forms that Masem brought up, so why this? But let's say this does pass, would this only be used for games that Joebro brought up? For example, would games that include co-op and PvP multiplayer include both (like Halo), or just the general multiplayer tag? I just feel like this is trying to solve a problem that prose handles better. ~ Dissident93 ^(talk) 19:22, 1 January 2019 (UTC)
  • Any more responses to this? ~ Dissident93 ^(talk) 22:14, 11 January 2019 (UTC)
    • Agreed, removal is probably the best option. Once we have co-op in, people will start calling for PvE, PvP, couch play, and whatnot. Lordtobi (✉) 13:06, 13 January 2019 (UTC)
    • No opinion either way on whether we should remove the parameter, but I agree that co-op is unnecessary and opens the doors for a lot of different types of multiplayer modes that we would have to start covering - I am very against that.--Alexandra IDV^talk 13:48, 13 January 2019 (UTC)
    • Oppose removing the parameter. Whether a game is single or multiplayer is one of the most basic possible pieces of information about it, and is generally one of the first things stated in any coverage of any game. The modes field is essential. Phediuk (talk) 00:31, 14 January 2019 (UTC)
    • Kill it. Prose handles the nuances better and categories handle the large segments. Last big discussion was here (2015), with a brief reprise in 2017. Haste the day when Wikidata starts handling these distinctions instead of us. (not watching, please {{ping}}) czar 00:54, 14 January 2019 (UTC)
    • Oppose removing the parameter. Keep it to single/multiplayer as possible choices. ~ Arkhandar ^{(message me)} 01:39, 14 January 2019 (UTC)
    • Co-op is still multiplayer, which is one of the two options for the field. I don't see a reason to complicate it further. There are many other multiplayer modes and variants. Since we can limit the field's values, I believe it can stay. Removal seems a bit extreme as same argument about details belonging in prose can be made for almost every field. Eventually, we might pull data from Wikidata, but not yet. —  HELLKNOWZ   ▎TALK 11:57, 14 January 2019 (UTC)

Guidelines for including Producer(s)

The current guidelines state:

Do not list the "Executive producer" or other "sub"-producer credits, as they are not generally as intimately involved in a game's development;

However, the page Video game producer has more nuanced view:

Most video and computer games are developed by third-party developers. In these cases, there may be external and internal producers. External producers may act as "executive producers" and are employed by the game's publisher.

For an internal producer, [a]n executive producer will be managing all of the products in the company and making sure that the games are on track to meet their goals and stay within the company's goals and direction.

This corresponds well with my own experience from the game industry.

I would therefore suggest to amend the guideline not to include Executive producer from publisher, but include them when they come internally from the developer, as in this case they are actually working very closely with the project.

--Elwetana (talk) 14:46, 12 January 2019 (UTC)

• I'm not sure if I agree with this. For one, executive producers do usually take a more hands-off approach on the game's development, and this rule about "internal producers only" would most likely be ignored anyway, with people just adding any executive producer role they see. I'd like to see what others think first, as I may change my mind on it. ~ Dissident93 ^(talk) 19:18, 12 January 2019 (UTC)

• I also don't agree with adding executive producers either, but the justification seems to be a load of OR. I'd advocate to something like "regular" producers having precedence over general and executive producers when adding them to the infobox. If a game has "regular" producers, those would suffice. Otherwise add general or executive producers. Something along those lines. ~ Arkhandar ^{(message me)} 01:44, 14 January 2019 (UTC)
  • How would it be possible to distinguish external vs. internal executive producers without doing a bunch of original research? This is rarely reported on. The guideline as written was intended to discourage over-bloating the producer credit with a million names. An overly restrictive-sounding wording is helpful as a first line of defense against that but it can be discussed on a case-by-case basis. Did you have a particular case in mind? As it stands, I don't see a compelling reason to change it. Axem Titanium (talk) 19:50, 16 January 2019 (UTC)
    • I understand you point. All right, I will discuss this on the talk page of the specific game I am concerned about.--Elwetana (talk) 09:35, 24 January 2019 (UTC)

Platform and Release Date fields

After considering for a long time, I'd like to discuss the above fields in the Infobox. Using Doom (1993 video game) as the ultimate example, I have to following two questions:

• 1. Platform - Do we really need a platform field? Ignoring the ridiculous list present in the infobox, does any of that information at a cursory glance as a casual reader help me understand anything. I'm old enough to know what MS-DOS is, but what does it help to have this as part of an ever growing list of platforms. Doom could have been on that old Nintendo Game N Watch (it probably is somewhere), it doesn't help me understand what it is or how it operates. I'd like to propose removing platform entirely OR restricting it to initial launch only, as the rest will be explained in prose.
  2. Release Date - the second is largely the same as the first, what does creating a laundry list of dates do to enlighten or educate the reader? The Sega 32X port was apparently released at 3 different points in 1994. So what? It was released in 2005, 2006, 2009, 2012, this is not helping me understand what or why the game is, and these release dates either are, or should be in the prose. Even though the list is hidden it is still redundant and in some cases impossible to complete because the sources don't exist anymore to back them up. I'd like to propose again that we restrict this to original wide release date. This proposal would probably need some refinement for major Japanese games that were released there originally and not in English (the subject of this Wikipedia) until a later date, but beyond that, I think knowing Doom is a 1993 video game is all I need to know.

I think these also both align with our existing guidelines around developers in only aiming to listing the original and not people who port a game to a different format without changes. Darkwarriorblake / SEXY ACTION TALK PAGE! 13:17, 24 January 2019 (UTC)

• To be fair, the same argument can be extended to every single field in the infobox. What does a developer name mean to a reader? It tells them nothing about where they are situated or how big they are or what games they make. How does knowing the developer's name help the reader understand anything about the game? Should we remove the developer field? Genres are vague and diluted. Modes are unspecific. Roles vary greatly. Engine is specialist knowledge. Let's not even mention arcade fields. To sum up, I kind of see what you describe for all fields. Personally, I think the line for inclusion is fine where it is. —  HELLKNOWZ   ▎TALK 14:21, 24 January 2019 (UTC)

• Echoing Hellzknowz, I do think that we opt to use the collapsable list more often in infoboxes in the case where a platform or release date list becomes longer than 2-4 lines, with the title of the collapsed list being the original platform of release and date. Or if it becomes even more unweildly (where the fully expanded list could take half the page), indicate a deference to the body. --Masem (t) 16:14, 24 January 2019 (UTC)
  • Hellknowz, I don't think that's fair, developer is akin to director or producer on films or music, platform is akin to DVD and VHS. Developers win awards, formats don't usually. You might have best PS4 game but not best Blu-ray disc.
  • Masem, I do think deference to the body should be the default as otherwise where do we judge the cut off? Is it 5 dates? 6? Doom is an EXTREME example but I can't see a reason for that information to be in the infobox. Formats I think are pointless, it's one of the reasons I shift them in to the last part of the lead on articles I work on rather than the opening. For the uneducated user, PS4 doesn't give me any information about what the game is, it could be as much a AAA blockbuster as a small 8-bit indie game. Darkwarriorblake / SEXY ACTION TALK PAGE! 19:03, 24 January 2019 (UTC)
    • If, with everything filled out and expanded, the infobox goes far outside my browser window (typically at 1000px high), then there's too much in there. Massively-ported games like Doom and Lemmings do need to be handled differently, but for the bulk of games that are not wildly ported, those platforms are important, particularly distinguishing from PC to console to handheld to mobile. They should not be buried. When you get to something like Doom, you can reduce the lede to something like "first released on PC and has been widely ported to many systems". --Masem (t) 19:48, 24 January 2019 (UTC)
    • I have generally used three as the cutoff point. ~ Dissident93 ^(talk) 22:53, 24 January 2019 (UTC)
• We should not remove the platform field entirely. Platforms are a defining characteristic of many old games and drove how the game played and was presented. I could see an argument with reducing the fields to just original release, but ultimately I could not support because I'm uncomfortable with how the policy would treat cases like Snatcher and Sonic Chaos. Snatcher was first released on Japanese computers in 1988, but the more notable release in the English speaking world is the Sega CD version from 1994. And Sonic Chaos first came out on the Master System but is primarily known as a Game Gear game. TarkusAB^talk 19:37, 24 January 2019 (UTC)

Well you could define a "notable" release then. As I said with dates above, if it was released on some type of Japanese only system first then we could include than and then the widest western release as we are a Wikipedia catering to that territory. I'd be happy to have that for Snatcher. As for Sonic Chaos I would have only thought it was a home console game tbh, I'd have gone with that release, but again if you can prove notability the game gear could go there aswell. In contemporary terms you would probably then list PC, Xbox One and PS4, for a new game, but we already exclude things like formats where a game is being emulated or available through a digital store. Darkwarriorblake / SEXY ACTION TALK PAGE! 20:35, 24 January 2019 (UTC)

• Platforms are important and should not be removed—they put games into great technical context, and video games are a very technical medium. The problem of the infobox is not the number of platforms, but the number of regional release dates. I'd personally support getting rid of them and only have one release date (the first one) per platform. They are typically unsourced and added by drive-by editors anyway. Also, I'd support combining the platforms field into the release date because it's essentially a duplication. --Niwi3 (talk) 21:31, 24 January 2019 (UTC)
• The only change I'd support is maybe just going with the initial release date in the infobox and detail everything else in the dedicated release section. That, or add native collapsible support in the parameter, which would serve the same general purpose. ~ Dissident93 ^(talk) 22:52, 24 January 2019 (UTC)
• Oppose any change at this template for the problem attempting to be remedied. Individual articles with so much content for a given field that it beings unwieldy and detrimental to the infobox should be handled on case by case basis with local remedies. For example, creating a table of platforms and release dates somewhere in the article itself, and linking the infobox field to that table instead. This doesn't need hard-wired into the template documentation itself. We already have advice to using collapsible lists, and there's many other possible options. -- ferret (talk) 22:55, 24 January 2019 (UTC)
  • I'm looking more at a guideline rule than a technical change if that helps. Darkwarriorblake / SEXY ACTION TALK PAGE! 23:03, 24 January 2019 (UTC)
    • Same answer. self-quote: "This doesn't need hard-wired into the template documentation itself." -- ferret (talk) 23:31, 24 January 2019 (UTC)
• I agree with ferret. Despite individual cases where a unique fix is required, having a dedicated place to look for "expected" information like platform and release date across articles is good and important. The entire premise of an "infobox" on Wikipedia was built with this goal in mind and it's not just on video game articles. Readers land on an article on *any type of media* and expect to find the publication date in the infobox. Removing the release date and platform fields to fix Doom (1993) is a baby with the bathwater solution. Axem Titanium (talk) 19:48, 25 January 2019 (UTC)
• FWIW in some articles I've seen if there's a ridiculous amount of platforms the game was released on, then it just says "Various" followed by a link to the development/release section. For Doom I'd do that and link to the article for versions of the game. JOEBRO64 19:53, 25 January 2019 (UTC)
  • Yes, exactly what I described as a local remedy for Doom. We have ways to do this, we don't need to make them hard and fast rules though. -- ferret (talk) 19:58, 25 January 2019 (UTC)
• I agree with Ferret and Axem Titanium. I also want to say that regional release dates are important in video games due to how the medium doesn't regularly get simultaneous or near-simultaneous worldwide releases and translations in the same way films do (Japanese games often take several months or years to come out in English) and because of regional lockouts. Castlevania is a 1986 game, but wasn't playable in Europe until 1988. If I look up a game on Wikipedia, I expect to quickly at least find when it was originally published, and when it was available in the West.--Alexandra IDV^talk 20:11, 25 January 2019 (UTC)

Derivative copyrighted cover arts

Hey, we have a user uploading derivative cover art. See File:Super Smash Bros Melee box art.png and its sources as an example. Does this violate WP:NFCCP #4? « Ryūkotsusei » 22:07, 27 January 2019 (UTC)

Yes, striping out (not cropping out) the platform branding is an improper derivative work. We do recommend cropped out the platform id when the game is on multiple platforms, if possible, but this is definitely not such as case, and even it is was, fully wiping it out is improper. --Masem (t) 22:26, 27 January 2019 (UTC)

That said, I see some of them , going through the wikia, are reportedly from E3 press kits. If they are, we should have the source to be to those kits, not through wikia. --Masem (t) 22:39, 27 January 2019 (UTC)

Can we word the guideline better? My understanding is it's more for multiplatform games like Resident Evil 2 (2019), for example, that are not historically tied to any one platform. Melee on the other hand is a GameCube game through and through, as are some other game covers the user replaced, and thus they should retain the game banner as it's part of the game's original release and tied to its history. courtesy ping @Arkhandar:. TarkusAB^talk 22:51, 27 January 2019 (UTC)

I do agree that when the game was initially released 100% exclusive to one platform, the box art should remain that platform's box art, if that's the best we can do. Multi-platform releases should strive for no platform banner if possible. However, let's assume these images are truly owned by Nintendo - the ones that show the cover art without the platform branding. Then I think it is actually find to use those, as long as it is an official sources. We should not crop away to get that state. --Masem (t) 00:43, 28 January 2019 (UTC)

@TarkusAB and Masem: Thanks for both of your replies. I also agree that the guideline should be re-written to be more specific. I also think we should retain the original box art (with platform, publisher and rating banners) when the game has only been released for one platform. If the game has been released on more than one platform (including remakes and emulation re-releases) I think it's more appropriate to have the official packaging artwork instead (without banners). As a note, I've only uploaded official artwork, not any crops. ~ Arkhandar ^{(message me)} 20:26, 30 January 2019 (UTC)

Hmm, I'm trying to come up with new wording but I'm seeing a lot of exceptions here. We might want to think about this more. Taking the images Arkhandar uploaded which strip out the platform branding but also ratings and "extranous" text (like for SSBM) above to me still is doing what the job of cover art does but without drawing one's eye away from it. The only thing annoying is that the open strip above looks off. As long as that's official imagery straight from N, I think it works better than the cover with the GC and ratings. But then I saw we cut the PS3 logo from Uncharted: Drake's Fortune, or the PS2 from Okami, but at that point, the fact both contain the ratings and company logos at the bottom make the lack of a platform branding stand out. So here's how I think we want to put it:

• If you can find official coverage imagery from the developer or publisher or a good RS that would be expected to have access to media kits, that is the same as the normal cover art but removes the branding and all the ratings (as well as ideally logos) from the front cover (as with SSBU above, or with Gears of War (video game), then this version is preferred.
• If you can't find such a version, and all you have to work with are cover arts that include platform branding and logos and ratings:

• If the game is a tied to a platform (exclusive to it or well-tied to it, as with SSBU, Uncharted, or Okami) then use the version with the branding and all. If you can't get rid of the ratings and logo boxes, it makes little sense to also get rid of branding if that game is tied to that platform.
• If the game is not tied to any singular platform, then removing the branding via image cropping is acceptable. Preferring cropping from PS2/3/4/Xbox/PC versions (where the boxes have typical aspect ratios and the branding is a bar along the top) is far less noticeable than vertical branding remove (ala Switch games).

Does that seem reasonable? --Masem (t) 21:27, 30 January 2019 (UTC)

@Masem: I know the upper "strip" on File:Super Smash Bros Melee box art.png looks off but I had nothing to do with it. It's the official artwork, cropped to the GameCube case's aspect ratio. ~ Arkhandar ^{(message me)} 22:17, 30 January 2019 (UTC)

@Masem: I wouldn't prioritize artwork on games released for a single platform. I'd go for something like this (ordered by priority):

• If the game has only been released on one platform: use the retail packaging artwork;
• If the game has been released on multiple platforms:

• Use the packaging artwork with no branding (excluding game branding, ex: logo); cropped to the aspect ratio of the retail packaging artwork where the artwork has the most visibility;
• Or use packaging artwork with branding; ideally cropping the platform branding, ensuring that the artwork is cropped minimally.

What about this? ~ Arkhandar ^{(message me)} 22:30, 30 January 2019 (UTC)

Maybe change the first bullet to "If the game was originally released on one platform: use its original retail packaging artwork for said platform;". So a game like Sonic 2 continues to sport the Mega Drive cover even though it's been ported to other platforms since. TarkusAB^talk 22:39, 30 January 2019 (UTC)

@TarkusAB: I understand the rationale behind that, but wouldn't that misrepresent the game's later releases? After all, we're not really cataloguing boxes on Wikipedia, we're using the box artwork to aid the reader identify the article's subject. As such, I think that in cases where a game has been released on multiple platforms (regardless if it was originally or not) we should just use the non-branded packaging artwork when available. ~ Arkhandar ^{(message me)} 22:48, 30 January 2019 (UTC)

I agree the image is to aid identification, and I also think the image should aid in historical relevance and accuracy. Since most game articles are about the game when it was released, and re-release artwork is typically digitally modified or re-done completely, I think we'd be doing a disservice to our readers not presenting them with the original cover (console branding and all) to provide historical context. Film articles use the original theatrical release poster from its native country, book articles use the first edition covers, and albums use the original release cover, so I think we're more in-line with the norm here. TarkusAB^talk 23:00, 30 January 2019 (UTC)

@TarkusAB: I see, it makes sense. Multi-platform rule shouldn't apply to emulated re-releases. However, if the game was ported or remade and those newer versions don't have an article of their own, multi-platform rules should apply. What do you think? ~ Arkhandar ^{(message me)} 23:09, 30 January 2019 (UTC)

I definitely disagree. We need more input. TarkusAB^talk 23:19, 30 January 2019 (UTC)

I also disagree. If you think about it in terms of the article's scope (95% of the article is about the original Genesis version), then it makes more sense to include the Genesis cover art rather than an edited, platform-free version. ~ Dissident93 ^(talk) 20:43, 9 March 2019 (UTC)

On ending the practice of laundry listing dates...

In contrast to Darkwarriorblake's discussion above, I want to specifically talk about changing the role of the |released= parameter of {{Infobox video game}}. If we need to use {{Video game release}} and {{Collapsible list}} to laundry list release dates in the infobox, then it is not faithful to the purpose of an infobox, which is "to summarize (and not supplant) key facts that appear in the article." I'm proposing that we should change the documentation to remove references to the two aforementioned templates and instead change it to a passage encouraging a) the original release date of a game be written in this parameter and b) the addition of more release dates in this parameter be agreed upon by consensus on an article's talk page. This way, the indiscriminate stuffing of release dates into {{Infobox video game}} can stop and that proper discussion on which release dates are important enough for inclusion in the infobox can potentially take place on various articles without the documentation being used to hold them back. – PhilipTerryGraham (talk · articles · reviews) 10:10, 9 March 2019 (UTC)

Why should users have to put that much time into deciding dates on a case by case basis? Something I have learned with time is that editors have lives outside of Wikipedia, and we should be streamlining our efforts not extrapolating them dozens of thousands of times, because you're always going to have one editor who wants to add further dates, and this is advocating a discussion be had around this when it happens. It is far easier if you want to eliminate those templates, to insist only upon the original release date and original country release date if talking about a non-western release like in Japan where it may be vastly different. This works fine for film articles and in the vast majority of cases would eliminate the requirement of any templates and any discussions. Darkwarriorblake / SEXY ACTION TALK PAGE! 12:38, 9 March 2019 (UTC)

@Darkwarriorblake: Would it be better if I changed my proposal for a) from "the original release date of a game be written in this parameter" to "the original release date of a game be written in this parameter, along with its release date in its country of origin if it's a non-English game"? I share your sentiment that we should be going about this the same way for film articles; the reason I brought this discussion up in the first place was because I wanted the practice to be the same for video games as it was for films, music, and literature infoboxes on Wikipedia. However, individual discussions on which release dates should be put in articles for specific films, albums, and novels have arisen on various articles on Wikipedia over the years. This is why I brought up b). I'm absolutely not implying that a mandatory discussion be made on every single article, just that discussions will arise on ones that are controversial, and those discussions shouldn't be put down but actively participated in to form a consensus. You can make a bold edit to remove excessive release dates and as long as it isn't controversial, there won't be a need for discussion. But of course, we shouldn't have to summarise the policies governing discussion on Wikipedia in an infobox documentation, I'm simply saying discussions can and should take place if release dates in the infobox are controversial, and that should be at least noted in the documentation. – PhilipTerryGraham (talk · articles · reviews) 21:15, 10 March 2019 (UTC)

Yeah, how is this subjective line of thinking going to be enforced on 1,000s of articles? We should either keep status quo, force the use of collapsible templates when games have more than a single date, or simply list the first date regardless of region and omit all others. ~ Dissident93 ^(talk) 20:38, 9 March 2019 (UTC)

@Dissident93: If there is so much information that we need to hide it from the reader in a {{Collapsible list}}, then it shouldn't be in the infobox. It should be expanded in full in the article prose instead. Both the status quo and collapsible lists defeat the the purpose of an infobox, and the third option was what I literally proposed in my original premise above. I am open to Darkwarriorblake's idea of a release date in a game's country of origin if it's not a western game, though. – PhilipTerryGraham (talk · articles · reviews) 21:15, 10 March 2019 (UTC)

Isn't that going to result in it basically being a list of US release dates? And also create the anomaly of Eastern games created outside of US getting an additional release date for their country of origin, but Western games created outside of US not? - X201 (talk) 12:49, 11 March 2019 (UTC)

No? Japanese games usually release in Japan first, so it would show that over any localized date in those cases. ~ Dissident93 ^(talk) 17:22, 11 March 2019 (UTC)

X201 no I don't think so. It should be the original earliest publicly available release date which for an English-language game on the English wikipedia, should be the earliest release in the US/Canada/Europe I guess. Maybe could go into more detailed specifics than that but there is typically a single worldwide release date for games, it's rare you get it in one country and it's released 6 months later elsewhere. For something like Earthbound, it's a Japanese game first so it should include it's original release date there and then the next widest release that can be sourced. Darkwarriorblake / SEXY ACTION TALK PAGE! 17:51, 11 March 2019 (UTC)

"should be the earliest release in the US/Canada/Europe" That's the bit I have a problem with. Games have disproportionally been released in the US days before Europe, even when they're developed in Europe. By default we'll end up being a list of US release dates, narrowing the the worldwide view. - X201 (talk) 18:52, 11 March 2019 (UTC)

Officially release or just released before date? I was under the impression that most stuff is available worldwide on the same day now, especially with digital downloads. Darkwarriorblake / SEXY ACTION TALK PAGE! 19:08, 11 March 2019 (UTC)

A lot of Japanese games still aren't, but that has changed over the last couple of years. ~ Dissident93 ^(talk) 03:57, 12 March 2019 (UTC)

Let's please not forget that older games had different schedules than today. Games took months or even years to see a release external to their country (sp. Japan). "English release date only" is a non-starter. --Izno (talk) 19:35, 11 March 2019 (UTC)

Izno Sorry I didn't say English-only, I said country of origin + earliest major western release relevant to the Wikipedia. Plus other notable dates where applicable which would be a lesser used case. I struggle to think of an example off the top of my head but a situation where a game was maybe released in some areas early due to unusual circumstances like a leak maybe. Dishonored for example lists the French and American dates as the studios in both regions were responsible for it. So you would list the Japanese date of a game if it's a Japanese game. You wouldn't exclude it by default. Darkwarriorblake / SEXY ACTION TALK PAGE! 17:29, 12 March 2019 (UTC)

@Darkwarriorblake: Unless it came out the same day, of course. Dishonored should ideally only have 9 October 2012 as its release date. The European and Australian release date difference by two and three days is not significant enough to warrant any kind of importance, and both those releases and later PlayStation 4 and Xbox One ports can easily be detailed in the "Release" section instead of crammed into the infobox. This is one example of what many other articles should do similarly to achieve the purpose of an infobox as a faithful, short summary that, in addition, doesn't have to hide information via means of {{Collapsible list}}. – PhilipTerryGraham (talk · articles · reviews) 22:46, 12 March 2019 (UTC)

I see what you mean, but summary doesn't have to mean a single entry. It's only bloted when we have like 2 or 3 different versions of a game that all have different regional release dates. ~ Dissident93 ^(talk) 03:54, 13 March 2019 (UTC)

@Dissident: Infoboxes generally don't have to be a single entry, of course, I agree with that. I'm simply saying Dishonored specifically shouldn't have anything more than 9 October 2012. – PhilipTerryGraham (talk · articles · reviews) 07:27, 13 March 2019 (UTC)

@PhilipTerryGraham: Yes I agree then, all of them are timezone related things. It's different when a game gets a big, publized release in another region months/years later, such as Persona 5 or something.

Add license field?

Could we add a license field to this infobox? There are notable video games such as Xonotic, 0 A.D. or Ryzom, that are free and open-source, which is an aspect that plays a big part in their notability, which is why I think this should be clearly visible. Similar infoboxes, e.g. the operating system infobox, have this field already. Now I am not an experienced Wiki user so I don't feel confident trying to edit the template myself -- could someone confirm this is a good idea and make this happen? Perhaps a separate field for code and asset license would be best, as these often differ (see how libregamewiki does it). ---Drummyfish (talk) 18:14, 18 April 2019 (UTC)

This field previously existed and was removed by consensus. For most video games, its not applicable, and rarely discussed by reliable sources. -- ferret (talk) 18:17, 18 April 2019 (UTC)

And if it is notable/sourced, then it can go in prose no problem. ~ Dissident93 ^(talk) 05:06, 19 April 2019 (UTC)

We need a template for the top of talk pages that links directly to the most recent discussion of frequently asked questions. Darkwarriorblake / SEXY ACTION TALK PAGE! 09:08, 19 April 2019 (UTC)

Add sequel and succeeded

Can you you probably know from the title add sequel for example Wwe 2k14 Sequel Wwe 13 succeeded Wwe 2k15 The Awesome Guy in the world (talk) 21:32, 31 May 2019 (UTC)

This has been discussed several times before, and while there are series where it is obvious, there are other series where this can be abused. The navbox at the bottom of the article is best suited for this. --Masem (t) 21:41, 31 May 2019 (UTC)

"Discontinued" date or similar for multiplayer/online games

Many online or multiplayer games depend on the developer continuing to host, patch or otherwise maintain it, so they'll come with a 'discontinued' date or something similar. A sentient pickle (talk) 11:05, 3 June 2019 (UTC)

• This has also been discussed before, with consensus being against it due to the high probability that people will misuse it. Just think of some game that is still fully playable, but hasn't had a gameplay update in a few years, so people will consider it "finished" and add something like that to the infobox. ~ Dissident93 ^(talk) 16:12, 3 June 2019 (UTC)

How about a "Based on" parameter?

What about an optional "Based on" parameter for video games that are based on other media such as Spider-Man 2: Enter Electro or E.T. the Extra Terrestrial? Americanfreedom (talk) 18:04, 3 July 2019 (UTC)

Parameters to the video game infobox

Hello there! Is it possible to add new parameters to the infobox such as: Input device and media type. Input device describes which device you use for example: Keyboard, mouse or hand control or joystick. And media type describes which media you use: For example CD, Cartridge, Floppy disc. --88.90.220.108 (talk) 11:26, 30 July 2019 (UTC)

No, these have previously been removed following discussions among WP:VG members. -- ferret (talk) 12:21, 30 July 2019 (UTC)

Addition of new optional parameters

Hello! Can you add new fields to the infobox concerning system requirements, input device and media type?. System requirements which tell which was required for the game when it is was first released. Input devices which tell what type of input devices was used for game and finally media type which concerns what type of media the game was available for. --88.90.220.108 (talk) 11:51, 30 July 2019 (UTC)

No, these have previously been removed following discussions among WP:VG members. -- ferret (talk) 12:21, 30 July 2019 (UTC)

Addition of parameters

Hello! Can you add new optional parameters concerning graphics, animation and programming. --88.90.220.108 (talk) 11:46, 30 July 2019 (UTC)

You'll need to be more specific in what you mean here by graphics, animation, and programming. We have fields for the artists and programmers already. -- ferret (talk) 12:22, 30 July 2019 (UTC)

And any notable animators would belong in the artist field anyway. ~ Dissident93 ^(talk) 21:11, 30 July 2019 (UTC)

website

Why it doesn't have this field? A lot of games have own pages, on it's serie/developer/publisher-'s websites . — Preceding unsigned comment added by Ilias48rus (talk • contribs) 19:37, 16 September 2019 (UTC)

They do not always remain long after a game has been released, whereas all the other facts in the infobox are generally stable even with the game long out of print. We do put the website as an external link. --Masem (t) 19:44, 16 September 2019 (UTC)

I have issue with general prominence of external links in infoboxes, as a separate rationale (and in general keeping with WP:EL). --Izno (talk) 21:04, 16 September 2019 (UTC)

Too many ticks for series, not sure why

@RexxS, Mike Peel, and Izno: Check out Star Wars: X-Wing. Series is being populated from Wikidata. We want the series to be italicized, so we have prefix and postfix of double tick in the template. However, it looks like extra ticks are being applied from somewhere causing the text to bold instead with single ticks around it. I might be too rusty right now cause I'm not seeing why. -- ferret (talk) 12:53, 29 October 2019 (UTC)

Note the ominous lack of "Star Wars:", WikidataIB might be interpreting the colon in the interwiki link (removing it from the caption appears to have no effect) incorrectly. Lordtobi (✉) 13:41, 29 October 2019 (UTC)

There was a recent change to Module:WikidataIB, [2], it looks like you now define which items you want to appear in italics at Module:WikidataIB/titleformats, and video game series (Q7058673) is there. So I think the solution is to remove the italics here, which I'll do with my next edit. Thanks. Mike Peel (talk) 13:45, 29 October 2019 (UTC)

Excellent, that explains it, and is probably a better way to do it for consistency besides. -- ferret (talk) 13:50, 29 October 2019 (UTC)

Indeed, this fixes the incorrect formatting, but am I mistaken that the lack of the prefix is still erroneous? Lordtobi (✉) 14:29, 29 October 2019 (UTC)

@RexxS and Mike Peel: If WikidataIB is not deliberately shortening "Star Wars: X-Wing" here, then I think that WikidataIB may be returning the Norwegian label (which is just "X-Wing") rather than the English one for some reason. -- ferret (talk) 14:58, 29 October 2019 (UTC)

Yes, when WikidataIB creates the text to be displayed in the infobox, it takes the sitelink to English Wikipedia and removes any namespace prefix as well as any parenthetical or comma-separated disambiguators. So Star Wars: X-Wing becomes just "X-Wing". The problem is that both the creators of the Star Wars series and the MediaWiki software use a colon in titles, but for different reasons. The code that does this is in lines 595–597 and I could refine it if anybody can come up with a reasonably simple algorithm that consistently distinguishes between the use of a colon as a namespace indicator and its use otherwise in titles. Cheers --RexxS (talk) 15:16, 29 October 2019 (UTC)

Maybe this is too simple to work, but with only a half-dozen namespaces that this template would be used in (if that), why not just do a match and only remove the colons when the value matches? Primefac (talk) 15:22, 29 October 2019 (UTC)

I considered something like that, but I can't be sure the list of namespaces that might be used on a Wikidata entry is closed. However, I remembered that the mw.site library holds a metatable of valid namespace names, so it's relatively simple to extract the suspected prefix and check if its entry in the table exists, and only then remove the prefix and its colon. I've made the change in Module:WikidataIB/sandbox, so for Star Wars: X-Wing (Q54853):

• {{#invoke:WikidataIB |getSiteLink |qid=Q55311} → Star Wars: X-Wing (video game series)
• {{#invoke:WikidataIB |getValue |qid=Q54853 |P179 |ps=1}} → Star Wars: X-Wing
• {{#invoke:WikidataIB/sandbox |getValue |qid=Q54853 |P179 |ps=1}} → Star Wars: X-Wing

Just checking that it still removes genuine namespace prefixes - for Category:Contents (Q1281):

• {{#invoke:WikidataIB |getSiteLink |qid=Q4167836} → Wikipedia:Categorization
• {{#invoke:WikidataIB |getValue |qid=Q1281 |P31 |ps=1}} → Wikimedia administration category, Categorization
• {{#invoke:WikidataIB/sandbox |getValue |qid=Q1281 |P31 |ps=1}} → Wikimedia administration category, Categorization

That seems to work. If nobody spots any further problems, I'll update the main module from the sandbox later this evening. --RexxS (talk) 18:20, 29 October 2019 (UTC)

 Done. I flushed the cache on Star Wars: X-Wing and it now displays Star Wars: X-Wing as planned. --RexxS (talk) 01:34, 30 October 2019 (UTC)

add website parameter

Hello.

Browsing through List of roguelikes, I encounter several games that have a website in their infobox, but when viewing the article code, I see that they are using Template:Infobox software, so, I'm asking that this template includes the website parameter, as detailed in software infobox source code.

| label23 = Website | data23 = {{#if:{{{website|}}} |{{#ifeq:{{{website|}}}|hide||{{{website|}}} }} |{{#if:{{#property:P856}} |{{URL|{{#property:P856}}}}| }} }}

Thanks, in advance. Mrmagoo2006 (talk) 11:38, 18 December 2019 (UTC)

The website parameter was removed from this template by consensus. There was an editor who disagreed with this infobox and changed games he edited, particularly open source ones, from video game to software. That behavior along with several others resulting in him being community blocked. A quick check for a few of these, I see he's the one responsible for them using software. They should be converted back to video game. -- ferret (talk) 12:30, 18 December 2019 (UTC)

Image property

Why not use P154 instead of P18? It also has its own category. --𐰇𐱅𐰚𐰤 (talk) 03:46, 2 February 2020 (UTC)

The short answer is that video game articles usually use cover art or promotional posters, not logos. It's somewhat pointless for this infobox either way as they are almost uniformly NFCC. -- ferret (talk) 04:49, 2 February 2020 (UTC)

Size parameter

I'm suggesting a parameter called "size," for which the size of the video game's installer package in MB or GB can be shown. I got this idea from Template:Infobox software. Melofors 17:47, 8 December 2019 (UTC)

• Oppose, particularly in this day of digital downloads and frequent updates. A game's size can vary significantly over time. It may be different on PC than on console. It basically falls within "technical specifications" which we have avoided for video games since there's no end to how much detail gets into that. --Masem (t) 17:53, 8 December 2019 (UTC)

  It's also rarely reported on, and where noted in "minimum requirements" would fall under the old "requirements" field, long since removed. -- ferret (talk) 17:58, 8 December 2019 (UTC)

  sometimes size is reported, I know there have been a few games that when the install size is revealed, we get a few articles like "clear out 100 gb of space for this!", but that should all fall under standard technical specifications that we generally don't include unless there's more critical commentary about it, and at that point, that makes it a prose thing, not an infobox thing. Otherwise agree :) --Masem (t) 15:56, 18 December 2019 (UTC)

• And for the MOS guideline against this, see WP:VGSCOPE #13. ~ Dissident93 ^(talk) 03:06, 9 December 2019 (UTC)
• Oppose: in addition to the reasons listed by Masem, the size might not be known for games that are not downloaded (e.g. cartridge, disc, web based, pre-installed). Also, you would run into the ambiguity of installer (or download) size versus installed size. – voidxor 23:30, 16 February 2020 (UTC)

Three parameter suggestions

I'm suggesting three parameters, two of which are very similar.

The first two suggestions are related to each other. Optional 'predecessor' and 'successor' parameters could be used for the previous entry in a series and the next entry in a series, respectively. So for example, for the article Ratchet & Clank: Going Commando, one could set the 'predecessor' parameter to ''[[Ratchet & Clank (2002 video game)|Ratchet & Clank]]'' and the 'successor' parameter to ''[[Ratchet & Clank: Up Your Arsenal]]''. Likewise, if one were editing the infobox for the game SSX Tricky, they could set 'predecessor' to ''[[SSX]]'', and they could set 'successor' to ''[[SSX3]]''. I know not all games in every game series are this cut-and-dry, but I believe it would be useful for games that are.

The third suggestion is for an optional 'website' parameter (see, for example, Infobox software), which could be used for the official website of a game (not fan sites, and not digital storefronts like Steam or Amazon). For example, if one were editing the infobox of Metal Gear Solid V: The Phantom Pain, they could set the 'website' parameter to {{URL|https://www.konami.com/mg/mgs5/}}. Likewise, if one were using this parameter in the infobox for Cyberpunk 2077, they could set it to {{URL|https://www.cyberpunk.net/us/en/}}. TheTechnician27 (Talk page) 04:08, 18 March 2020 (UTC)

All three of these have been discussed multiple times in the archives. Please feel free to search. --Izno (talk) 05:37, 18 March 2020 (UTC)

I do not see anything wrong with adding these parameters so I would generally support its addition. One thing we should avoid if the predecessor parameter is added is to avoid is being unnecessarily inserted when used for a game which is the first in the series (e.g. Uncharted: Drake's Fortune - Predecessor = series established. Regards  Spy-cicle💥  ^Talk? 20:14, 19 March 2020 (UTC) I have changed my mind on this issue since navboxes could be used plus the other reasons below. Regards  Spy-cicle💥  ^Talk? 01:41, 5 April 2020 (UTC)

Template talk:Infobox video game/GameSeries would be a good place to start research on what might be wrong with adding the parameters. Or just put precede in the archive search box. --RexxS (talk) 20:46, 19 March 2020 (UTC)

The 'predecessor' and 'successor' parameters would be prone to edit warring since they are subjective (would people put in chronological, main/sub series, and/or plot connections?), while the website thing doesn't really serve a purpose with it being listed as an EL too. I don't believe the film (and other entertainment media) infobox does this, so why should video games? Navboxes also generally serve the purpose of 'predecessor' and 'successor' too. ~ Dissident93 ^(talk) 21:08, 19 March 2020 (UTC)

{{Infobox television}} does have all three, but I've recently brought up a discussion in the hopes to reexamine the URL parameter. - Favre1fan93 (talk) 21:18, 19 March 2020 (UTC)

The "ease" which video games can be made , and thus gain prequels, sequels, side stories, alternate takes, and whatnot, compared to television and film is why we at VG don't use those parameters. --Masem (t) 22:57, 19 March 2020 (UTC)

(edit conflict) I'm against the addition of predecessor/successor parameters, because it's the kind of thing that is so open to interpretation that you will always get people changing it back and forth. What is the successor to Super Mario Bros. – is it Super Mario Bros. 2 or Super Mario Bros.: The Lost Levels? Are Pokémon Ruby and Sapphire followed by Emerald (next version of the Gen 3 games), by FireRed and LeafGreen (next releases), or by Diamond and Pearl (next generation of Pokémon games)?--Alexandra^IDV 21:19, 19 March 2020 (UTC)

As someone who was here when this was all fields and in black and white; I saw the state of the infobox when it had preceded by and suceeded by fields. It was a god awful mess. And that was on the stable articles, the edit wars on the unstable ones were ridiculous. Navboxes do this job far better than the infobox ever could. As for website. Official websites expire very quickly and within a year end up only pointing to the main holding page, or even worse the latest game in the series. Again, this is a job that the External Links section does better than the infobox. With both suggestions, others are always left to clear up the mess. If you hadn't guessed, I OPPOSE all of them. - X201 (talk) 21:53, 19 March 2020 (UTC)

I guess if we're discussing these again, then oppose for all the same reasons that were iterated previous times. The infobox was previously a bloated mess and it took a lot of work to trim it down to a clean standardized version. This meant many fields that "make sense" on their own to be trimmed for overall benefit. Most of the were never clearly covered by reliable sources and most had few games with clear values, so they are of very marginal use in the grand scheme of things. (I realize software infobox has many more fields, but I believe it's a similarly bloated version that video game one was before. It's full of technical details of interest only to very specialized audience. Many are never repeated in prose and hardly any of those are reliably sourced.) —  HELLKNOWZ   ▎TALK 22:49, 19 March 2020 (UTC)

Maybe it's time to make an FAQ page about these common ones that keep on coming up. --Izno (talk) 23:32, 19 March 2020 (UTC)

I was thinking that. They are perennial snowballs. - X201 (talk) 08:31, 20 March 2020 (UTC)

General statement of agreement with X201. -- ferret (talk) 11:53, 20 March 2020 (UTC)

Sound director parameter

I know this has already been discussed in the past. But, please, let's consider adding a parameter to indicate the key person of the sound department. If several people worked on sound, we could only mention the head of the department (usually quoted as "Audio director", "Sound director", "Sound", "Sound manager" in the game credits), omitting the sound designers, editors, studio engineers, etc. In smaller teams where the sound director may be the sound designer itself, we could mention him/her as the key person. I know that there is usually little talk about the sound department. Still, please consider that, like all the other figures mentioned in the infobox—direction, design, programming, the script (story), art, and music—, sound is a strictly necessary component of a game. —Lion-hearted85 (talk) 12:41, 5 May 2020 (UTC)

If you know it has been discussed before, perhaps you could point us to those discussions to see if what you are saying has also been discussed/rejected before. --Izno (talk) 14:33, 5 May 2020 (UTC)

I could find two sections relating to this: One from 2013 with no actual arguments and @Masem disagreeing, and another from 2015 with just as few arguments and involving @X201 and Dissident93 and yourself to an unclear position. Neither request seems to have brought any arguments pro-inclusion to the table, while the primary argument against was the relevancy of the department to the game's overall development. I also saw no clear consensus in either discussion, so I will stay neutral in this one for now. IceWelder [✉] 14:56, 5 May 2020 (UTC)

Given that DICE and BAFTA make distinctions for audio work from music in their awards, I could see a single field for the lead sound/audio producer. Its a fair-enough request. --Masem (t) 15:00, 5 May 2020 (UTC)

Yes, sorry about not citing the discussions. They were precisely the two mentioned by @IceWelder. As @Masem says, we could use this field to identify only one critical person related to sound production. When the sound producer coincides with the soundtrack producer, or if clear information is not available, we could ignore this parameter. —Lion-hearted85 (talk) 17:11, 5 May 2020 (UTC)

We already have a composer credit and the awards typically go to that person, not the sound director.Darkwarriorblake / SEXY ACTION TALK PAGE! 17:53, 5 May 2020 (UTC)

Yeah, a sound director isn't that notable and is almost never mentioned in prose (unlike the art director and composer). ~ Dissident93 ^(talk) 00:12, 6 May 2020 (UTC)

I see, you are right. It's true that most of the times sound production is not cited in prose. So, as you say, we can keep the current practice: when the sound work is interesting and notable enough (for example, for games whose sound design has been praised or awarded), it will be properly treated in the Production paragraph. —Lion-hearted85 (talk) 20:24, 6 May 2020 (UTC)

Template-protected edit request on 13 July 2020

Please add a based_on parameter for video games based around films or other works. Jalen Folf (talk) 00:07, 14 July 2020 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. I am fairly certain that has been discussed previously, but review the archives. Izno (talk) 00:27, 14 July 2020 (UTC)

I disagree, as this would only apply to certain games (of which there are not that many) and is always mentioned in prose anyway. A Spiderman game doesn't need something as obvious as "based on = Spiderman". ~ Dissident93 ^(talk) 22:28, 14 July 2020 (UTC)

Release date (P577)

Please use P577 for the release date when not entered locally. This probably means changing

{{{released|{{{release|}}}}}}

to

{{{released|{{{release|{{#invoke:WikidataIB|getValue|rank=best|P577|qid={{{qid|}}}|name=released|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon={{{noicon|no}}}|sep="<br />"|sorted=yes|{{{released|}}} }}}}}}}}

I think. (tested) — Alexis Jazz (talk or ping me) 21:13, 14 September 2020 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{edit template-protected}} template. The reason Wikidata hasn't been implemented for the release field is because Enwiki has complex rules around this fields, which regions should be included, which platforms, etc. Even the exact mechanism for how to list platforms and regions has no set in stone format, or the interaction with {{Vgrelease}} that is typically used. -- ferret (talk) 22:06, 14 September 2020 (UTC)

Hi ferret, Not sure if you're aware but everything else inside this template is invoked from Wikidata so I don't see why they'd need to get consensus for this when others have all been accepted without issue ?, Thanks, –Davey2010^Talk 11:04, 16 September 2020 (UTC)

@Davey2010: Because the original discussions to enable Wikidata, which I implemented, did not have consensus to implement the Release field due to the complexity of our rules surrounding it. To be a little clearer, the complexity of the rules cannot be satisfied with a direct pull of the "best/earliest release date", which means in essentially every case the wikidata pull of this field would be overridden. The only place it would work would be titles with a single global release. I'm not saying we won't do it, just that there's reasons we didn't do it and I feel it requires more discussion. -- ferret (talk) 11:52, 16 September 2020 (UTC)

Ferret, yeah, unless we only list a game's initial release in the infobox, I don't see how this is much help. ~ Dissident93 ^(talk) 19:46, 16 September 2020 (UTC)

Even listing just "the initial release" is not possible with the above use of WikidataIB. It will pull all release dates, without any qualifiers or context, so it will just be a list of dates. -- ferret (talk) 20:49, 16 September 2020 (UTC)

Updating Computer Releases

Currently the main three ways to say something is coming to computers is to mark a release as either Windows, Mac or Linux. For the past decade or so, the assumption was that a PC release meant a widespread PC release (i.e. if something was out on both GoG and Steam, the release would be simultaneous). However, with the introduction of not only the Epic Games store but many publishers (Bethesda, EA, Ubisoft) having their own platforms which then go on to release on Steam/Epic/GoG/etc. at later dates, we should really update how this is presented. I would personally recommend we always specify the operating system and the storefront, whether it be in a superscript reference or in parentheses (see The Outer Worlds and Borderlands 3 as examples). Buh6173 (talk) 22:19, 21 September 2020 (UTC)

No that just creates far too much potential confusion. Windows is the platform, period. If there are storefront release concerns/issues, that can be documented in the body. Its the same aspect with things like beta periods or early access periods. Once the game's out the only date we concern ourselves with is the date of release in a region or worldwide. --Masem (t) 22:23, 21 September 2020 (UTC)

Windows is not the "platform" in this case. If you're on PS4, it doesn't matter if you buy a Ubisoft game through Ubisoft or through Sony; there aren't staggered release dates. Any official release date (Steam's is different from Epic's) should be logged in the infobox. Buh6173 (talk) 22:25, 21 September 2020 (UTC)

We've had several prior discussions that we do not consider availability on different storefronts to be meanful, as we are only tracking by platform. If one simply doesn't chose to use the Epic store over Steam, that's a consumer choice, but from an encyclopedic standpoint, the game was released when it was first available on any storefront for that platform and that's all that matters for a short infobox summary. Now, to use the example of Hades, the fact that it came out on Steam and within 3 days of that hit 1M sales with 300,000 from the three days it was out, then having described the releases on separate storefronts in the body is fine. But it still clutters the infobox. --Masem (t) 22:30, 21 September 2020 (UTC)

Agree with Masem. The point of an infobox is not (or shouldn't be) an exhaustive detailing of every facet of every field. Der Wohltemperierte Fuchs ^talk 20:50, 22 September 2020 (UTC)

Template-protected edit request on 5 November 2020

Can the website parameter be added to this infobox? I see it useful to link to the official website of the video game, like minecraft.net for Minecraft, genshin.mihoyo.com for Genshin Impact, and leagueoflegends.com for League of Legends. Aasim (talk) 22:12, 5 November 2020 (UTC)

I'm going to disable the tper for now pending a discussion on this (or time for one, at least). ProcrastinatingReader (talk) 22:21, 5 November 2020 (UTC)

I refer you to my previous response at Template talk:Infobox video game/Archive 15#Three parameter suggestions. --Izno (talk) 22:26, 5 November 2020 (UTC)

Predecessor and successor

Hello! Is it possible to add fields for preceded by and followed by which denotes which game which preceded and succeeded the first game. Mvh Sondre --88.91.100.244 (talk) 16:33, 12 November 2020 (UTC)

Oh, this again. --Izno (talk) 16:43, 12 November 2020 (UTC)

Added FAQ

After yet another "GIEF SUCCESSOR" thread, I've started an FAQ. Right now it's just an index of the past year or two of discussions here. See Template talk:Infobox video game/FAQ. Feel free to go forth and actually summarize the group opinion. --Izno (talk) 17:59, 12 November 2020 (UTC)

Should an edit notice be created, pointing out the FAQ? - Favre1fan93 (talk) 18:47, 12 November 2020 (UTC)

I am not a fan of edit notices as being just more banner blindness. The utility of the FAQ above is that I can link to it like #FAQ. --Izno (talk) 18:49, 12 November 2020 (UTC)

Proposal on arcade fields

I mentioned this on WT:VG and it got some support so I wanted to make a formal proposition.

Proposal: Remove the arcade game-specific fields Cabinet, CPU, Sound, and Display from the infobox.

Reasoning: These fields are each a combination of (a) too technical, (b) difficult to source, (c) not normally written in prose, and (d) not defining characteristics of the game. We already prohibit system requirements on non-arcade games per WP:VGSCOPE#13 for similar reasons. I've omitted Arcade System from this proposal, as there was some hesitation from others about removing it.

Votes

• Support as nominator TarkusAB^talk/contrib 19:07, 11 September 2020 (UTC)
• Support These fields can all be derived from the arcade system specified and don't belong in the infobox. For that matter, I support removing Arcade System and an AWB run to move it into Platform instead. -- ferret (talk) 19:11, 11 September 2020 (UTC)
  • The "Arcade System" parameter is closer to what we'd have as an "Engine" field for video games, and I'd be careful with that. I mean, the "platform" for all arcade games is "arcade", but the "arcade system" if it is notable is like the game engine it runs on. Now, that does beg the question, how many of those are notable? I know there's an AFD on one of the Namco ones for example, If only a fraction of these "arcade system" boards are notably that a smattering of arcade game infoboxes use it, then yes, lets deprecate that parameter too. But if it can be used more than say 10% of the time, we probably should keep it. --Masem (t) 19:16, 11 September 2020 (UTC)
• Support the four give as per nom. Mostly tech specs. --Masem (t) 19:16, 11 September 2020 (UTC)
• Support - they are a relic from the past when game articles had more technical details. ~ Dissident93 ^(talk) 19:55, 11 September 2020 (UTC)
• Support per nom and above. IceWelder [✉] 20:46, 11 September 2020 (UTC)
• Oppose - Arcade system should not be removed from the template. Roberth Martinez (talk) 02:32, 13 September 2020 (UTC)
  • @KGRAMR: Re-read the proposal. It's not advocating to remove Arcade System, only Cabinet, CPU, Sound, and Display. TarkusAB^talk/contrib 03:09, 13 September 2020 (UTC)
  • Sorry! I did not make myself clear... Roberth Martinez (talk) 03:30, 13 September 2020 (UTC)
• Partial support for Sound, CPU and Display. However, looking at arcade cabinet, it seems Cabinet would definitely get a mention being one of the primary characteristics of an arcade? Please correct me if I am misunderstanding this field and arcades in general. —  HELLKNOWZ   ▎TALK 09:46, 13 September 2020 (UTC)
  • @Hellknowz: Yes Cabinet is a little different. While you may think of most arcade games being bought and sold as dedicated cabinets in the West, it was different in Japan and the East in general. They had "candy cabinets" which were sit-down cabinets (as opposed to the western upright standard), and they were generic as opposed to being decorated for a dedicated game. Games were not sold with the cabinets but rather in "kits" which included the game PCB board, instruction pamphlets, and promotional flyers. If you were an arcade owner, you owned several generic cabs and then just buy/sell the kits and swap out the boards. The JAMMA standard makes this very easy. Arcade game trading among hobbyists in the West is basically like this now. TarkusAB^talk/contrib 11:45, 13 September 2020 (UTC)

I'd say there's a rough consensus to remove fields here, with the possible exception of cabinet. -- ferret (talk) 21:11, 18 October 2020 (UTC)

• Support per above. OceanHok (talk) 00:51, 12 November 2020 (UTC)
• Support While I did think its info that would appeal to a certain audience, it goes against What Wikipedia is Not. Le Panini ^Talk 01:18, 12 November 2020 (UTC)
• Support - I agree with the concerns by TarkusAB and Le Panini, since Wikipedia is not a game guide. Lord Sjones23 (talk - contributions) 02:27, 12 November 2020 (UTC)
• Support - I would actually vote to toss out the arcade system parameter too, since in my experience it's really hard to source and only a select few are actually significant. Anyways, I'm definitely voting to get rid of the others. They're useless to anybody that isn't an arcade cabinet/board collector — general readers are not gonna care what processor is used in Pac-Man, for instance. It's WP:GAMEGUIDE material that does nothing but bloat the infobox. Namcokid47 ^(Contribs) 17:59, 12 November 2020 (UTC)

So there is near universal support for this. Only one person voiced opposition, and one voiced concern for the Cabinet field to which I replied explaining and I don't see anyone else having concerns with it. Where do I need to go to make this happen? TarkusAB^talk/contrib 03:30, 27 November 2020 (UTC)

TarkusAB, I removed them. ~ Dissident93 ^(talk) 04:54, 27 November 2020 (UTC)

@TarkusAB and Dissident93: When removing parameters, make sure to arrange for cleanup, as it floods the maintenance category. @Primefac: Could you run PrimeBot against Category:Pages_using_infobox_video_game_with_unknown_parameters to clean up the recently removed parameters? -- ferret (talk) 16:21, 27 November 2020 (UTC)

Sure, I can try to run this later today. Primefac (talk) 17:22, 27 November 2020 (UTC)

 Done, and I have to say I'm genuinely surprised that it took care of every page in the cat; usually it's "get rid of 90% of the garbage so the rest can be manually cleaned". A+, would bot for again. Primefac (talk) 23:39, 27 November 2020 (UTC)

@Primefac: Thanks. The category is usually at 0, I keep it clean. -- ferret (talk) 23:53, 27 November 2020 (UTC)

Seems like I didn't miss or break anything when removing the code then. ~ Dissident93 ^(talk) 10:41, 28 November 2020 (UTC)

Even better! But yeah, I saw when you made the edit and it all looked shiny. Primefac (talk) 10:58, 28 November 2020 (UTC)

Add field for end of life?

Online games and MMOs have an "end of life" date associated with them since they are no longer playable when the servers are shutdown. It would be useful to add that field to the infobox after the release date.S-1-5-7 (talk) 07:59, 6 October 2020 (UTC)

S-1-5-7, this has been discussed in the past (as a status parameter) and the consensus was that people would misuse this more than its intended purpose. Think of a game that stopped receiving updates, somebody could consider that game to be "end of life" even though you see cases like Left 4 Dead 2 that just received its first major update in over five years. I proposed that online-only games, including MMOs, could either have their own infobox or some sort of a yes/no flag that enables the use of status and other potential online/MMO specific parameters. The latter of course could still be misused, but the additional step(s) could be tracked and watched like we do for invalid parameters. ~ Dissident93 ^(talk) 19:50, 6 October 2020 (UTC)

Dissident93 That is an interesting observation. Maybe the field could be something like "Online service status" and could be used for both pure online games that have ended (e.g., The Sims Online) as well as traditional games that are still playable but no longer allow multiplayer (e.g., Homefront). Games that don't have an online service component (e.g., Doom) wouldn't put anything in there even though they haven't been supported in decades.S-1-5-7 (talk) 13:46, 7 October 2020 (UTC)

S-1-5-7, I personally don't disagree with this, but I still see this creating more problems than it really solves. ~ Dissident93 ^(talk) 20:27, 7 October 2020 (UTC)

It looks like this Template_talk:Infobox_video_game/Archive_11#Closure_date was the previous discussion of this. S-1-5-7 (talk) 13:50, 7 October 2020 (UTC)

S-1-5-7, there were more recent discussions too that had the same consensus. ~ Dissident93 ^(talk) 01:43, 19 October 2020 (UTC)

I think this decision is a little short-sighted. The fact that a online-game is no longer available is a key fact about the game and belongs in the infobox. Pokémon Brick Bronze is an example where the fact that the game was discontinued was "crammed" into the released field. We put the "end-date" in all sorts of infoboxes (people - death_date=; companies - defunct=; websites - current_status=, etc.) The fact that it could be "misused" should not drive the content. The question is "is this a key fact that belongs in a summary of the topic?" MB 15:21, 28 November 2020 (UTC)

I would agree with this. Rather than discarding the idea for fear it'd be misused, I think we should workshop a name for the parameter that can't be as easily misunderstood.--Alexandra^IDV 15:28, 28 November 2020 (UTC)

Alexandra IDV, see my suggestion above. ~ Dissident93 ^(talk) 23:33, 28 November 2020 (UTC)

Oh, sure, if it can be solved in a technical way like that on/off switch that'd work too.--Alexandra^IDV 01:28, 29 November 2020 (UTC)

Budget field

In order to be more like Infobox film, we should add a field for a game's budget. With the PS5, we're going to see all sorts of records being broken. — Preceding unsigned comment added by 81.178.205.194 (talk) 00:09, 19 December 2020 (UTC)

Absolutely opposed. Game budgets are rarely announced, and are so difficult to source that the List of most expensive video games to develop is woefully out of date and incomplete. It also wildly lacks context as the costs for developing a game has changed vastly over time, above and beyond simple inflation. -- ferret (talk) 00:17, 19 December 2020 (UTC)

Also opposed for the same reasoning as ferret. ~ Dissident93 ^(talk) 05:24, 19 December 2020 (UTC)

Further opposed. Film budgets are regularly reported, game budgets are not. --Masem (t) 06:04, 19 December 2020 (UTC)

What a crappy reason. If there's no data then you leave it blank. No need to be defeatist and give up before you've started. — Preceding unsigned comment added by 81.178.205.194 (talk) 17:37, 19 December 2020 (UTC)

From experience, if we have a field, inexperienced editors will want to fill it out with any data they can find, including data from unreliable sources, which is not a good thing. But again, the percent of games we accurately know budgets for is probably less than 5%, making a field that would not get much use compared to all the other fields we have in place in this template. --Masem (t) 17:48, 19 December 2020 (UTC)

Translate title

Had a thought. The same way that {{infobox person}} has |pronunciation= and |native_name= parameters, have we considered adding something similar, to avoid footnoting in the lede? Similar to the current MoS, it would only be useful if the title was originally released in a non-English language and is also known by that native language title, but it's a much more elegant solution than footnoting in the first sentence. czar 19:43, 2 January 2021 (UTC)

Sounds like a good idea to me. So, we'd be looking at title in original language, what the language is, romanization (if applicable), and an English translation? Anything else?--Alexandra^IDV 20:16, 2 January 2021 (UTC)

Watching for more opinions, but pointing out this would be difficult to implement for Wikidata. Would need to talk to RexxS and MikePeel. Maybe pull country of origin property, then pull the label of that language if available. A thing to consider, though. -- ferret (talk) 20:20, 2 January 2021 (UTC)

I'd make a table like we have today that traces the language item identifier to country/region identifier, maybe. (I think you might still have problems with countries like Canada that support both English and French.) --Izno (talk) 20:58, 2 January 2021 (UTC)

Keep footnotes Darkwarriorblake / SEXY ACTION TALK PAGE! 20:33, 2 January 2021 (UTC)

Infoboxes are supplementary. Footnoting in the lead was a compromise for a valid alternative title (in many cases). I would not support removal of such footnotes. (I see no issue with the infobox having an alternative name in a different language, but that rationale is crap.) --Izno (talk) 20:33, 2 January 2021 (UTC)

Izno, agreed. Do other forms of media like films have this sort of thing? ~ Dissident93 ^(talk) 20:44, 2 January 2021 (UTC)

Absolutely, you can find 'native name' in most other infoboxes in general, in fact. --Izno (talk) 20:54, 2 January 2021 (UTC)

Izno, oh, I meant in addition to pronunciation parameter. I also see no issue with native name but I am unsure if it should fully replace the footnote. ~ Dissident93 ^(talk) 22:14, 2 January 2021 (UTC)

What quantity of articles are lacking that it is necessary to amend the infobox for this purpose on the English Wikipedia? For the same reason we use the footnotes, the non-English name is not important information on this part of the Wikipedia. It also tends to be long, like Metaru Gia Soriddo Surī Sabushisutansu which on top of unnecessary, would also aesthetically affect the infobox. Unlike biographical articles where the person's foreign name is their actual name, media known by a popular name does not need to be translated in the infobox. It's Metal Gear Solid, not Metaru Gia Soriddo. I vote to keep the use of footnotes, and I vote against amending the infobox for this purpose. Darkwarriorblake / SEXY ACTION TALK PAGE! 23:09, 2 January 2021 (UTC)

Darkwarriorblake, you are thinking about transliterations/romanizations. In Metal Gear's case, its displayed native name would be メタルギア. "Metaru Gia Soriddo" would be omitted from the infobox or relegated to the footnote. ~ Dissident93 ^(talk) 00:08, 3 January 2021 (UTC)

That's worse! But thanks for clarifying. Darkwarriorblake / SEXY ACTION TALK PAGE! 00:14, 3 January 2021 (UTC)

Emulated Ports and Arcade Archives? + Non-English Release Dates?

A lot of articles I see feature emulated rereleases of games in the infobox under Platform(s) and Release(s). Thing is, the syntax guide says not to include things like Virtual Console or PSOne Classics. Not only do a lot of articles do this, but many are listed as "Virtual Console" (here) and "PlayStation Network" (here). As seen in the first example, games released under the Arcade Archives series are also listed, despite these releases being emulated ports (most articles don't even acknowledge these rereleases outside of the infobox). Other articles (presumably more popular ones) aren't formatted like this (here). My question is which formatting is the correct one?

Another small question, is there a way for me to find release dates for non-English speaking regions (since they're omitted often) or do I just have to search on other sites? Thank you! -NJ (talk)

• None of them are correct and thus they should all be removed. As for your second question, Wikidata is supposed to document that sort of thing, but seeing as though that project gets a lot less traffic than the encyclopedias so you'd probably have to look elsewhere yeah. ~ Dissident93 ^(talk) 21:20, 4 January 2021 (UTC)

Template-protected edit request on 17 January 2021

Please add a "website" or "url" parameter so I can add the URL for one of the video game articles I am editing right now. Aasim (talk) 11:18, 17 January 2021 (UTC)

 Not done: Please see the FAQ. This is a perennial request that will not be done. -- ferret (talk) 14:30, 17 January 2021 (UTC)

Early access date

Is it worth adding a field for games that are released for early access to the public? It's common for this to be verifiable and different from the actual release date. It could also make it less confusing when people aren't clear if a game is released or just "early access" released. Jontesta (talk) — Preceding undated comment added 19:53, 20 January 2021 (UTC)

No, we don't consider the early access date as a release date. It can (and should be) noted in prose, but as some games that enter early access never get to a final release, we want to be careful to imply the early access is a release date. You can add it to the release date field but 1) if this is before a final release date is known, it should clearly be marked as early access, and 2) once a final release date is known (to the day, not a vague year or quarter/period) that needs to be removed in favor of the final planned release date. --Masem (t) 19:57, 20 January 2021 (UTC)

Oh I agree with all that. I was suggesting expanding the template with two different fields, so that it's clear when a game is released as early access, and also clear when a game is released (or never released). It might avoid the misunderstandings that you just mentioned. Jontesta (talk) 20:09, 20 January 2021 (UTC)

I think we want to avoid that. We already have the problem with the release date field getting flooded inappropriate with re-released in emulated versions (eg virtual console releases) and the like, and the goal of the infobox should be to briefly summarize the key details. Early access dates are just extra noise in that sense once a game is in a released state. --Masem (t) 20:16, 20 January 2021 (UTC)

Implementing {{detect singular}} for plural parameters

Following recent discussions on {{Infobox television}} and {{Infobox film}} the decision was made to implement {{detect singular}} in a number of fields within those templates. Like there, I believe there is grounds for similar implementation here. Moreso, given that nearly every single field name currently ends with an unsightly "(s"). In the specific case of {{Infobox video game}} I think we could feasibly implement the change to every single field. EDIT: I've sandboxed it here. -- JascaDucato (talk | contributions) 12:15, 23 February 2021 (UTC)

@Jasca Ducato: Detect singular does not work for data pulls from Wikidata. I added some testcases to check that if you want to look. Personally, I'd say it's quicker, cleaner and less work to just remove the plurals period, all the time, and not worry about it. -- ferret (talk) 13:18, 23 February 2021 (UTC)

Some non-Wikidata observations:

There are several scenarios where the developer's names already contain a comma, e.g. those with an ", Inc." in their common name, that will be evaluated incorrectly:

• {{#if: {{Detect singular|Atari, Inc.}} | Singular | Plural }} → Plural (cf. Battlezone (1980 video game))
• {{#if: {{Detect singular|2015, Inc.}} | Singular | Plural }} → Singular (cf. SiN: Wages of Sin)

The template also "detects" every use of 'list':

• {{#if: {{Detect singular|Felistella}} | Singular | Plural }} → Singular (cf. Felistella)
• {{#if: {{Detect singular|Kalisto Entertainment}} | Singular | Plural }} → Singular (cf. Kalisto Entertainment)

Some will argue that "Xbox Series X/S" should be plural:

• {{#if:{{Detect singular|Xbox Series X/S}} | Singular | Plural }} → Singular

While "(s)" is certainly a workaround, using {{detect singular}} might introduce unwanted side-effects that the template user cannot really control (or know the cause of). As Ferret stated, the lazy method of removing "(s)" might be the best low-maintenance solution. IceWelder [✉] 13:28, 23 February 2021 (UTC)

All valid observations that I hadn't considered. If we were to go down the "lazy" route, I believe removing only the paranthesis (leaving us with, for example "Directors") would be sufficient. After all, you can have a list of directors with only one entry, but cannot have a list of director. -- JascaDucato (talk | contributions) 13:40, 23 February 2021 (UTC)

I mean, that's works for me. "Genres" is a field. It might have zero, one or more entries. -- ferret (talk) 16:14, 23 February 2021 (UTC)

Minor aesthetic changes

Opening a TPER per the discussion below. — Goszei (talk) 02:38, 17 May 2021 (UTC)
I have made some minor aesthetic changes in the sandbox to the text styling (here is the diff from live: [3]). There are no functionality changes, and the test cases look good. If there aren't objections, I will open a TPER in a week or so. — Goszei (talk) 08:50, 8 May 2021 (UTC)

Multiple lines of a single field appear to be more apart than before. I'm assuming this is caused by the removed datastyle field? IceWelder [✉] 10:47, 8 May 2021 (UTC)

Yes, that is correct. With the datastyle the element height for a line is 16 pixels, and without a datastyle it is 18px (on desktop at 14px default). The style can be re-added, if desired. — Goszei (talk) 18:39, 8 May 2021 (UTC)

Although it seems counter-intuitive as you removed a "font-size: 90%", I am finding that the text size in the sandbox version has shrank visibly. Is this really desired? Are we still meeting ACCESSIBILITY? -- ferret (talk) 19:22, 8 May 2021 (UTC)

My changes set the smallest text to 12.32 px (88% of other text on page, which is the default style for infoboxes), so we should be good for accessibility, which requires higher than 85% (MOS:SMALL).

The "font-size: 90%" refers to the percentage of the size of other text on the page (14px default on desktop). So removing it is equivalent to changing that to "font-size: 88%". — Goszei (talk) 19:40, 8 May 2021 (UTC)

 Done Primefac (talk) 16:54, 18 May 2021 (UTC)

Template-protected edit request on 31 May 2021

I suggest adding a parameter for when the game shuts down, e.g. for games like Call of Duty Online (which will be shut down on August 31, 2021. The parameter name should be called "{{{shutdown}}}". Jobenhein (talk) 16:30, 31 May 2021 (UTC)

 Not done: Repeatedly discussed. See talk page archives and the FAQ at the top of the page. -- ferret (talk) 18:33, 31 May 2021 (UTC)

Use proper lists

The documentation for Module:WikidataIB rightly says: "For reasons of accessibility (see MOS:PLIST), do not use |sep=<br> for vertical unbulleted lists; use |list=ubl instead." Please follow this by replacing all instances of |sep=<br> with |list=ubl. Hairy Dude (talk) 14:15, 12 June 2021 (UTC)

 Done User:GKFX^talk 08:10, 13 June 2021 (UTC)

Parameter suggestion: "size"

Hello there. I hope this is the right place for this post. I suggest adding a "size" parameter, as some PC games, especially earlier ones (i.e. not modern games like Fortnite that are constantly updated), have a fixed on-disk size. I was about to add it to a page, thinking it exists, but I got this error:

Warning: Page using Template:Infobox video game with unknown parameter "size" (this message is shown only in preview).

— Preceding unsigned comment added by Zephyr Gaming (talk • contribs) 10:06, 14 June 2021 (UTC)

See Template_talk:Infobox_video_game/Archive_15#Size_parameter. —  HELLKNOWZ   ▎TALK 10:10, 14 June 2021 (UTC)

Oh, that was a quick response. I will take a look. Much appreciated! -Zephyr Gaming — Preceding unsigned comment added by Zephyr Gaming (talk • contribs) 10:13, 14 June 2021 (UTC)

Propose adding Age Guide

I would propose again the idea of adding available age guide into the game infobox, e.g., ESRB E10. This info helps parent to decide. If available for more than one jurisdiction, should list all. --Rynh (talk) 13:59, 11 June 2021 (UTC)

Has been asked for before many times, but no. Across the relevant Wikiprojects where ratings could apply, there's strong agreement to not include ratings due to the large number of ratings systems out there. If we included ESRB, we've have to include PEGI, CERO, etc. to avoid a US bias. If the game's rating is of discussion (such as when Australia's board refuses to rate a game) that is discussed in text but that's it. --Masem (t) 14:06, 11 June 2021 (UTC)

Thank you for confirm. --Rynh (talk) 16:43, 11 June 2021 (UTC)

Just adding that if people really wish to document age ratings for games, then they can via its respective Wikidata page. ~ Dissident93 ^(talk) 06:01, 12 June 2021 (UTC)

• if it's in wikidata then it can be in wikipedia just as well.bi (talk) 04:38, 24 June 2021 (UTC)

| label18 = [[ESRB]]
| data18  = {{{ESRB|{{If first display both|{{#invoke:WikidataIB|getValue|rank=best|P852|qid={{{qid|}}}|ESRB=|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon={{{noicon|no}}}|list=ubl|sorted=yes|{{{ESRB|}}} }}|{{#ifeq:{{{refs|no}}}|yes|{{wikidata|references|normal+|{{{qid|}}}|P852}}}}}}}}}
| label19 = [[PEGI]]
| data19  = {{{PEGI|{{If first display both|{{#invoke:WikidataIB|getValue|rank=best|P908|qid={{{qid|}}}|PEGI=|suppressfields={{{suppressfields|}}}|fetchwikidata={{{fetchwikidata|ALL}}}|onlysourced={{{onlysourced|no}}}|noicon={{{noicon|no}}}|list=ubl|sorted=yes|{{{PEGI|}}} }}|{{#ifeq:{{{refs|no}}}|yes|{{wikidata|references|normal+|{{{qid|}}}|P908}}}}}}}}}

• bi (talk) 05:22, 24 June 2021 (UTC)

  Baratiiman, the two projects have different guidelines. The English Wikipedia has good reason to omit this sort of thing in the infobox, as they are not independently notable 99% of the time and are thus unmentioned in the article body as well. ~ Dissident93 ^(talk) 06:10, 24 June 2021 (UTC)

  it's last edit was 8 october 2012, wikidata was developed 29 october 2012. bi (talk) 06:39, 24 June 2021 (UTC)

  https://www.kaspersky.com/blog/game-ratings/32492/ bi (talk) 06:47, 24 June 2021 (UTC)

• Per established Enwiki consensus, I agree with continuing to exclude ratings from the infobox. "It's in Wikidata" is not an argument for inclusion on Enwiki. The two projects have very different goals, in some ways opposing. Not everything in WD belongs here. -- ferret (talk) 11:54, 24 June 2021 (UTC)

  10 years before there was consensus try again. there is only PEGI and ESRB and they reasons are covered definitely always, legitimate wikis like baike show this data as appropiate age in infobox https://baike.baidu.com/item/%E5%88%80%E5%A1%942?fromtitle=Dota+2&fromid=2946584 https://www.facebook.com/photo/?fbid=1382250985480080&set=a.257183677986822 bi (talk) 02:56, 25 June 2021 (UTC)

  There are not just PEGI and ESRB, there are dozens of countries with their own rating systems, some with multiple systems. The original consensus might have been established some years ago but still holds today. IceWelder [✉] 05:55, 25 June 2021 (UTC)

  I don't care how many years ago we last made a decision was. The consensus has been reaffirmed multiple times since then each time someone brings it up. It is still the established consensus, regardless of how long we've held it. We absolutely would not have individual fields for each rating system as you've put in the sandbox. Nor are those the only two rating systems, as already noted. -- ferret (talk) 11:53, 25 June 2021 (UTC)

• not in en countries https://wiki.riteme.site/wiki/Template:Infobox_film#Ratings bi (talk) 08:23, 25 June 2021 (UTC)

The section you link says:

[T]here are simply too many ratings systems in English-speaking countries, let alone the world over.

and emphasises that ratings should not be included. The same is the case for video games with at least six different ratings boards in English-speaking countries (EU, US/CA, UK, AU, NZ, ZA) and we are not limited to that. IceWelder [✉] 10:12, 25 June 2021 (UTC)

• To further add, WP is not a sales catalog, of which the ratings information is only to serve. If you are a parent, you can research the ratings information elsewhere. We mention ratings only when they impact a game's release or create controversy around a game (eg often the case for games that fail to be rated by the Australian ratings board as that by law there prevents their sale, which creates sourcing we use to discuss that - we're not including the rating as a parential guide but because of the impact on the game). --Masem (t) 17:04, 25 June 2021 (UTC)

"other_name" paramter

For many games that were released internationally, they have different names, e.g. Aero Fighters 2, which is known as "Sonic Wings 2" in Japan. A subtitle under the main title of the infobox that can be invoked with |other_name= or a similar parameter would be greatly useful. — Berrely • ^Talk∕_Contribs 08:02, 29 June 2021 (UTC)

Berrely, I'm not entirely opposed to it, but usually games with alternative (English) titles are already listed in the lead. If you include the scope to include localized titles in other languages and scripts then I fully oppose that for cruft reasons. ~ Dissident93 ^(talk) 09:16, 29 June 2021 (UTC)

I don't want something like a native name, but some regions have different English names for games. It's fine being in the lead, just thought it would make sense in the infobox as well. — Berrely • ^Talk∕_Contribs 09:19, 29 June 2021 (UTC)

Add a space to input succeeding and preceding games if it is in a series

VictorBaxter (talk) 01:48, 19 August 2021 (UTC)

No. See the FAQ at the top of the page. -- ferret (talk) 01:53, 19 August 2021 (UTC)

Automatic short description

I would like to propose the following automatic short description, in the format "[year] video game":

{{main other|{{short description|2=noreplace|{{#if:{{{released|{{{release|}}}}}}|{{#invoke:String|match|{{{released|{{{release|}}}}}}|%d%d%d%d?|match=1|nomatch=}} video game|Video game}}}}}} updated based on feedback below 16:19, 29 August 2021 (UTC)

If the infobox is used in mainspace, and there isn't a manual short description already added, this will take the "released" parameter (or its alias "release"), and use the first four-digit string as the year (ex. "2004 video game" will be the auto SD). It will ignore any other four-digit strings (i.e. releases on other platforms listed after). If there's no release parameter, the fallback is "Video game" (capitalized by SD convention).

I put a version of this in the sandbox (with the mainspace detection commented out for testing). Since it is hard to show test cases for this, I have been pasting infoboxes from the wild into my user sandbox and changing them to use to the infobox sandbox, and it seems to work. I got the format from Template:Infobox film/short description, pinging author User:Primefac to check this logic. Any thoughts? — Goszei (talk) 08:14, 29 August 2021 (UTC)

Looks fine to me. Primefac (talk) 10:56, 29 August 2021 (UTC)

Does this work with WP:SHORTDESCHELPER? —  HELLKNOWZ   ▎TALK 11:17, 29 August 2021 (UTC)

I mean, it will show up as a shortdesc. I'm not sure I understand the question. Primefac (talk) 11:21, 29 August 2021 (UTC)

You check for both released and release but only match against released for trying to find a year. I'll be frank, I still don't really understand the purpose of shortdescs or why we need to automatically fill them when Wikidata should already be doing so, but meh. -- ferret (talk) 14:06, 29 August 2021 (UTC)

Wikidata usage for short description was discontinued last year, Ferret, for fear of obscure vandalism finding its way through. Short description helper allows you to import from wikidata, but if this does this for you (which is kind of what is being suggested) then I'm all for it. So long as we can overwrite it with the regular template, everything looks good. Just to confirm, if an article has a short description, this change isn't going to supersede that? Best Wishes, Lee Vilenski ^{(talk • contribs)} 14:29, 29 August 2021 (UTC)

Correct, the |2=noreplace means that it will not overwrite anything that is already on the article. Primefac (talk) 16:18, 29 August 2021 (UTC)

 Fixed. Primefac (talk) 16:19, 29 August 2021 (UTC)

Could this somehow be adjusted to also track short descriptions that don't fit the YEAR video game pattern too? It wouldn't have to automatically fix them, unless that can also be done too. ~ Dissident93 ^(talk) 08:43, 30 August 2021 (UTC)

Do you mean articles with manually-added SD's in the format "[year] [genre] video game", for example? I don't think tracking is possible here; overwriting the manual SD's with "[year] video game" is possible, but not advisable (I presume that editors disagree on what should be in the "perfect" or canonical video game SD, and there are always exceptions, etc). — Goszei (talk) 22:11, 30 August 2021 (UTC)

How would the bot tell if the template was added manually or by itself? ~ Dissident93 ^(talk) 19:18, 31 August 2021 (UTC)

Well, there's no bot at play here. The "noreplace" parameter allows the manual SD to take precedence. — Goszei (talk) 02:45, 1 September 2021 (UTC)

 Done I have implemented the code above in Special:Diff/1041716785, with one tweak. Note to Primefac: as far as I can tell, the "?" in the Lua pattern allowed three-digit strings to be fed into the SD, such as "123", so I removed it. — Goszei (talk) 02:45, 1 September 2021 (UTC)

Add field for latest release version and date (as in Infobox software)

We should add 2 fields "latest release version" and "latest release date" as in Template:Infobox software. Most current games are frequently updated with new online releases, unlike games sold on shelves only. --OpenNotes1 (talk) 20:27, 15 September 2021 (UTC)

I'm pretty sure we've discussed this before and we're generally against it. Whereas productivity software updates are frequently discussed and by version number, game updates do not regularly get this (games like No Man's Sky are exceptions rather than rules), and differences in platforms can create differences in versions. --Masem (t) 20:36, 15 September 2021 (UTC)

See the FAQ at the top of the page. Perennial drive by request. :) -- ferret (talk) 20:43, 15 September 2021 (UTC)

FAQ

Given the hard work that's gone into it and the fact people seem to waltz past it in it's collapsed state, are there any objections to adding |collapsed=no to the FAQ and making it expanded by default? - X201 (talk) 09:57, 16 September 2021 (UTC)

I'd actually like to see a case where this is actually useful. I'm guess for sectional infoboxes? ~ Dissident93 ^(talk) 08:14, 18 October 2021 (UTC)

On the engine field

Right now we have the engine= field documented to limit to only standalone (notable) engines. I would suggest that we allow engines which have reasonable sections (named by the engine) within the body of article of the developer that created them as an allowed entry or part of the series page that the engine was specifically made for, as long as the engine has been used in at least or 3 games or where the engine has clearly been made note of by multiple sources. That is - the engine itself could be notable but for comprehension having it has a part of the developer or series. For example, Ubisoft's Dunia Engine is well sourced as a core engine in the Far Cry series, but there's just not quite enough info compared to something like Unreal or id Tech to make a standalone article for it to make much sense. So it as a subsection in Ubisoft is reasonable, but for the purposes of the infobox, then having it as an allowed entry in the engine= field makes sense. What we do want to include is that random indie game dev that made their own engine for their one or two games that they may have dropped its name in a blog but not covered anywhere else, for example. --Masem (t) 18:21, 17 October 2021 (UTC)

• Personally, if there's a redirect to a valid section with sourced details, I don't bother to remove it. I only tend to remove non-linked/red-linked. -- ferret (talk) 19:12, 17 October 2021 (UTC)
  • I actually thought we had discussed this as being allowable per guidelines. It's really just the stuff not notable enough to even to have a redirect, as well as frameworks like XMA and Java being added there that should be removed. ~ Dissident93 ^(talk) 08:12, 18 October 2021 (UTC)
    • I have made an adjustment to the engine= parameter documentation here to reflect this, that redirects to developed sections on a game engine (like Dunia) are fine as well. --Masem (t) 15:12, 20 October 2021 (UTC)
• A redirect to a non-engine-dedicated article that is (independently and reliably) discussing the engine should be fine, as this sort of link/mention would allow for discovery of additional material. Oh wait, this is already implemented. Fait accompli, FAIT ACCOMPLI!1~`1 —  HELLKNOWZ   ▎TALK 16:15, 20 October 2021 (UTC)
• I feel like there should be a half-sentence that not every apparently blue-linkable engine is eligible. There are frequently redirects for game-specific engines to that game or to the game's developer, without any actual information on the engine. People frequently use the sole availability of a blue link as an excuse to link the engine to no value to the reader. IceWelder [✉] 19:06, 20 October 2021 (UTC)
  • Yeah, it should at least link to a solid section within another article. ~ Dissident93 ^(talk) 18:41, 21 October 2021 (UTC)

No way to add a website.

There is no way to add the website of an online game. The Spanish version of Call of Duty Online uses Wikidata and that is a lot more complete and flexible. In English, this template is used and it is extremely restrictive.

George Rodney Maruri Game (talk) 08:10, 12 November 2021 (UTC)

The English one has been stripped of unnecessary fields. See the FAQ near the top of the talk page for past discussions on a website parameter. IceWelder [✉] 08:23, 12 November 2021 (UTC)

The external links section is used for websites here. ~ Dissident93 ^(talk) 10:09, 13 November 2021 (UTC)

Optional Source Code Repo field

Currently there are quite a number of games that are either open source (0 A.D. comes to mind) or had their source code released later under an open source license (discounting fauxpen source filth like the recent release of Amnesia's source code without any of the art assets, or that 'source available' BS), and most of these games don't actually use Video Game Infobox template and instead opt for the Software Infobox template, but only because it has a section for a source code repository, which the current Video Game Infobox template does not have. I suggest adding an optional field for a source code repository. I also think that it would be a good idea to add sections along the lines of "release version", "experimental version", and other similar sections for games that follow an early access model, like Satisfactory. LiftedStarfish (talk) 14:43, 2 November 2021 (UTC)

Many of those cases were changed unilaterally from Infobox video game to Infobox software by a user who was later community banned (Partially in relation to such changes). We also do not include website in this infobox, see the FAQ above for some of the reasoning. There's really no need for website or repo in the infobox. Put it in external links. -- ferret (talk) 14:53, 2 November 2021 (UTC)

Agreed, links to open sources repositions is fair game for the external links section. --Masem (t) 15:47, 2 November 2021 (UTC)

This seems like something for external links since it is in the spirit of open knowledge/content. There isn't really any common information to be learned from that link in the infobox. We want things in the infobox that provide a good overview of the game compared to other games and a link by itself doesn't say anything other than there is source code. But a general reader, even a general player will not care about this. —  HELLKNOWZ   ▎TALK 18:24, 2 November 2021 (UTC)

To add, the infobox should only cover information that all games would have, such as the developer and a release date. Anything that only applies to a small number of them would be better off kept as prose or as an external link. ~ Dissident93 ^(talk) 10:13, 13 November 2021 (UTC)

"Italic title" parameter not implemented

The template documentation lists italic-title=no as an option, but this is not in fact implemented into the template. I recently implemented this for Template:Infobox video game series (diff) – could a user with the necessarily privileges implement the same change into this template, please? Obskyr (talk) 03:27, 6 January 2022 (UTC)

@Obskyr: I'm not sure you understand the purpose of italic title. This is not about changing the italics of the above class. The title of a video game should *always be italic*. Italic title controls whether the infobox will make the title of the article at the very top, outside of the infobox, italic. It is used when the article name contains disambiguation, which should not be italicized, so that a proper DISPLAYTITLE can be specified instead. I've reverted your edit to Infobox video game series as well, as that should not be done. -- ferret (talk) 15:04, 6 January 2022 (UTC)

@Ferret: Oh, so that parameter is for the article title. I see. The use case for de-italicizing the title in the infobox is when it, following a newline, contains the original-language name in a script that doesn't use italics. This is somewhat common in articles about Japanese video games – Japanese script should not be italicized, so there needs to be a way to deactivate (or work around) the auto-italicization. How do you reckon that should be handled? Obskyr (talk) 16:54, 6 January 2022 (UTC)

The Japanese title shouldn't be in the infobox. This is English Wiki. The Japanese titles aren't supposed to be directly in prose either per MOS:VG, but instead in a foot note if they are important. -- ferret (talk) 16:56, 6 January 2022 (UTC)

We don't always have an English title, but either way, the Romanji title is usually available, which should be italicized. Izno (talk) 21:24, 7 January 2022 (UTC)