Template talk:Infobox video game/Archive 16

Archive 10

←

Archive 14

Archive 15

Archive 16

"Official Website" Field

I first encountered this issue with Wordle's infobox, but this is applicable not just with online video games, as almost video game has a website, from Baba is You to Roblox. The official website provides a variety of information to the end user, and it's standard practice with other infoboxes, so I really see no reason not having it here as well. If the issue is that some websites are temporary, we could very well leave the field as optional, and if needed, make it so it does not automatically take data from Wikidata. I definitely think the benefits outweigh the potential problems. YuvalNehemia (talk) 08:06, 25 January 2022 (UTC)

This has been discussed many, many times in the past. Beyond the issues brought up in many of those discussions, I suggest other factors as to why it's not a good idea: infobox bloat (because most games these days have websites, so invariably this is going to mean people running around adding websites to infoboxes and doing nothing else), another pointless area for disagreement (which is the official official site? The dev's site? The publisher's?), the fact that link rot means these links aren't going to be useful long-term, and the basic selfish Wikipedia point of we want people to stay on our site, not immediately link away from it. We aren't a PR mouthpiece for video games. Sticking the external link at the end where it functions as "further reading" properly prioritizes its importance insofar as an encyclopedic work. Der Wohltemperierte Fuchs ^talk 15:09, 25 January 2022 (UTC)

External link is sufficient. We shouldn't link away from the very top, per Fuchs. -- ferret (talk) 15:46, 25 January 2022 (UTC)

This should be added. "Template bloat" is a nonsensical objection, and we have many other infoboxes - including many of the most-used - which include |website=. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:08, 3 February 2022 (UTC)

If it's a web-based game, it makes no sense to not have it in the template. It's utterly basic information. Like the address of a building. All the other arguments suggested here are utterly unconvincing. If the URL changes, that's fixable with one edit. If there's more than one candidate for the proper URL, that can be resolved through discussion. "Insofar as encyclopedic work" is meaningless puffery. "We aren't a PR mouthpiece": more scare words. On our pages for companies, projects, software, etc., we provide a link in the infobox because that's basic information. And because it is Wikipedia's convention to provide a URL in the infobox for virtually every kind of entity that "has a website", I expect to find it in the infobox. In this case, because the subject doesn't just have a website, but exists in the form of a website — yes, of course you put a link to the subject of the article in the infobox.--Father Goose (talk) 23:19, 7 February 2022 (UTC)

The website is exactly what should be in external links for anything like this. This works for nearly all of our contemporary media infoboxes (films, tv shows, music, etc.) The website is an identity and branding for companies so it makes sense that it appears in the infobox, but it's not branding for these other works or for software. --Masem (t) 01:32, 8 February 2022 (UTC)

As most new games have an important online component or are purely hosted on a website, addition of a website field would be useful. We live in a digital world where traceability of original sources has become ever more relevant and copies of any popular idea pop up very easily. If this template is not the appropriate for supporting a website parameter as some suggest, the question becomes whether this template should be used. Maybe an 'online games template' would be a great addition? Personally I consider such an addition as creating unnecessary work, but the current situation of standstill is not preferable either. Frisie (talk) 21:06, 19 March 2022 (UTC)

The info is already in the article, in the external links section. We really don't need it in the infobox. Best Wishes, Lee Vilenski ^{(talk • contribs)} 21:28, 19 March 2022 (UTC)

Staff precedence

Modern video games (due to larger development teams) have "design/technical (program)/art directors" in addition to "lead designers/programmers/artists". Many of these games generally credit the former roles ahead of the latter roles. To me this suggests that "design/technical (program)/art directors" should take precedence over "lead designers/programmers/artists" and I think the template documentation should reflect that.

Currently the documentation says to list "lead designers/programmers" with "design/technical directors" being mentioned as synonyms, suggesting that both roles are equal or alternatively that "lead designers/programmers" (mentioned first) as taking precedence over "design/technical directors" (mentioned second). Interestingly "art director" is mentioned before "lead artist". -- Wrath X (talk) 03:35, 3 March 2022 (UTC)

I think the presence of these fields need re-evaluation in general. At the very least a restriction to notable individuals, if not a removal entirely. Or, condense to a single "Notable credits" field. -- ferret (talk) 16:55, 9 March 2022 (UTC)

I'd agree, given how much time I spent reverting the additions of credits that are either a) unreferenced, b) to personnel not even mentioned in the article body, or c) both unreferenced and unmentioned. This stuff is, for our purposes, trivial, especially since game development ≠ the highly structured and credited film industry, so even trying to attempt to follow a similar strategy makes no sense. I agree that a "Notable personnel" field as a replacement might help solve some of the problems, or at least contain it. Der Wohltemperierte Fuchs ^talk 17:08, 9 March 2022 (UTC)

I agree as well. It's tedious dealing with these Sonic or Mario fans that continually bloat the infobox into some sort of complete credits documentation. It might get worse before it gets better with implementing this, but I think it's a worthwhile change overall. Sergecross73 msg me 17:52, 9 March 2022 (UTC)

Given that there are some games with good distinction on staff roles with notable individuals (many JRPGs), any change should be graceful. Adding a general "staff=" field as the preferred means to handle credits would be good, which if present would suppress the display of the othe staff ones. --Masem (t) 18:03, 9 March 2022 (UTC)

• I've implemented 'staff' in the sandbox, example test case at Template:Infobox video game/testcases#Test 4 staff. The presence of staff suppresses the display of the older credit fields, per Masem's suggestion. -- ferret (talk) 18:49, 9 March 2022 (UTC)

  Looks great to me. Sergecross73 msg me 19:13, 9 March 2022 (UTC)

  • I think this is really well done, thanks so much for pushing this. Nomader (talk) 19:16, 9 March 2022 (UTC)

    • I think if you change 'Notable' to 'Major' or 'Principle' or 'Main', it looks quite good. It'll certainly be a help for me with articles. Any further staff, especially those that don't have articles, can be discussed in article itself. I can foresee a similar possible problem to series article infoboxes, of users just adding in names ad nauseum. I think this needs some kind of established limit, say only five or six names. --ProtoDrake (talk) 19:51, 9 March 2022 (UTC)

  I would avoid the word "notable" (MOS:NOTE) but otherwise I don't dislike this.--Alexandra^IDV 19:20, 9 March 2022 (UTC)

  I like this change in principle but I hesitate to support it until we get a concrete proposal for inclusion criteria that would be added to the template documentation. Replacing the current implementation without substituting in an equally explicitly defined one is likely to increase conflict in this domain, not decrease it. I appreciate the graceful implementation as suggested by Masem and executed by ferret, though. I also agree with ProtoDrake and Alexandra that we should pick a different word than "Notable". Axem Titanium (talk) 21:29, 9 March 2022 (UTC)

• The label can be adjusted before "go live". "Lead Staff"? It's always been in the documentation to only includes leads, but it was left out of labels for space. As for documentation, my thought is anyone in the list must have an article. This is a simple requirement often used for LISTCRITS, i.e. notable entries only. If that is deemed too weak, we could also explicitly list the titles, gleaned from the existing fields. I.e. programmers, artists, composers/musicians, directors, producers (with executives excluded as per now). I don't know if a numerical limit is necessary. We have like 6-7 fields now that allow up to four, so that's 24-30 people in an infobox already. Very very very few games would have even 10 notable people working on them. -- ferret (talk) 22:00, 9 March 2022 (UTC)

"lead staff" would look awkward on small indie titles. "Key staff" may work. Also, I would not just limit it to blue-linjed people but those that are named in the article, typically by way of development lead interviews. This dies mean that if it was mentioned that Johnny the beta tester found a key bug they would be included, it should still be the top level staff, ideally limited to established lead roles. --Masem (t) 22:44, 9 March 2022 (UTC)

The problem I see with "lead" or "key" staff is it's beating around the bush of our problem—namely, people adding tangential or non-notable people to infoboxes. I get why people would want to stay away from "notable", but at a basic level excluding anyone who doesn't have an article seems like the simplest ruleset for pruning these exhaustive credits, and I'm not sure what else would work as clearly. Der Wohltemperierte Fuchs ^talk 23:27, 9 March 2022 (UTC)

I'm not a fan of this test case; both the parameter label and the brackets look inconsistent and messy to me. Personally I'd be satisfied with Wrath X's initial suggestion, but if we're adamant about notable staff, then I think we should keep the template exactly the same but change the inclusion criteria to blue-linked people only. I think there's an argument for maintaining the top level creative/game directors too, blue-linked or not. – Rhain ☔ 23:58, 9 March 2022 (UTC)

I'm not a fan of the test case either. But if we're to list blue-linked staff only, then I think we should also list the no-linked staff who share the same role. For example, Dan Houser should be listed with James Worrall for Grand Theft Auto: Vice City since both are credited equally as writers. Listing only Houser suggests that he was the sole writer or lead writer. -- Wrath X (talk) 02:54, 10 March 2022 (UTC)

I think more clarity and specifics for what we're actually changing the usage instructions to is warranted. Wrath's example here highlights an unconsidered edge case that has the potential to exacerbate existing biases in Wikipedia's coverage, for instance. Axem Titanium (talk) 03:26, 10 March 2022 (UTC)

I agree with Axem Titanium that this proposal creates a lot of biases. I do not support the idea of listing only "notable" staff. There are many notable game developers that don't have their own articles. There are also many poorly-written articles that don't even have a development section (thus the names of the key staff would not be mentioned anywhere). The staff parameter is also overly vague (anyone from studio head to lead animator to lead QA can be listed as long as their names are mentioned in an interview). The need to list the exact duty of each individual in the staff parameter also makes the infobox overstuffed. OceanHok (talk) 05:01, 10 March 2022 (UTC)

This pretty much sums up all my thoughts much clearer and more concise than I could put it. – Rhain ☔ 06:15, 10 March 2022 (UTC)

• My issue is that "staff" label implies employment. A bunch of work on video games can be done via contracts, outsourcing, remote studios, etc. For example, a lot of musicians work on multiple projects and would only work for a brief time on any given video game. "Staff" would not be a correct label here. —  HELLKNOWZ ∣ TALK 10:36, 10 March 2022 (UTC)

Just tossing the hand grenade in. Do we actually need to list people in the infobox? - X201 (talk) 10:51, 10 March 2022 (UTC)

• deep breath* Short answer: yes. Long answer: we need to remember what the purpose infoboxes serve on Wikipedia. They deliver to the reader "key information at a glance". What counts as "key information" is obviously up for debate (like this one) and people draw the line in different places. "At a glance" is a general purpose exhortation not to clutter the infobox with a tremendous amount of info that it can't be absorbed at a glance. I've been on both sides of the line in terms of suggesting additions or removals from the VG infobox. There is a goldilocks zone for this. I think "key people" is a worthwhile addition to the infobox because it gives the reader a quick high-level understanding of who made a game. For the readers who know who Miyamoto or Kojima or Romero or Hennig is, seeing their name in the infobox delivers a hefty nugget of information very quickly by the mere listing of a name. I think that's worth it. Axem Titanium (talk) 11:05, 10 March 2022 (UTC)

Bouncing off your examples: How about limiting it to 'big hitters' who have been recognised for their abilities by induction into BAFTA or similar bodies? - X201 (talk) 11:24, 10 March 2022 (UTC)

Proposal break - Key people

I'd like to rephrase my proposal a bit. A lot of focus has been on the label I picked quickly, "staff". The label is a bit of a red herring. "Key people" is fine, or any number of alternatives. What's important is the concept.

Here's the direct proposal now: Add a new "key people" field, which when populated suppressed the old credit fields. This field will be limited to notable individuals or individuals mentioned in the prose of the article.

And as a secondary proposal: When old credit fields are used, they will also be limited notable individuals or to individuals mentioned in the prose of the article.

Now to address how I've rephrased this and the concerns above. Instead of using notability as a guideline, I've rephrased to allow non-notables mentioned in the article. This of course is a weakness for stubs, but in general, if someone is worth presenting to the reader first thing in the article, they should be mentioned in the article somewhere. This helps address the bias concern that notability alone as a criteria would present.

Second, as pointed out by Axem, "at a glance" should be considered. Remember that on mobile, infobox displays first, ahead of the lead. That means the longer our infobox is, the longer it takes the user to get to the actual article. Let's look at the case that spawned this discussion, Max Payne 3. The lead programmers, Slett, Gordon, Valer, and Kozuh, were never mentioned anywhere in the article. They were replaced by the technical directors, Hoare, St. Pierre and Gordon. Also none of them mentioned in the article. That's 3-4 names the reader must scroll past with no context that is never mentioned again. That's not even counting that the credits contain 10 more names have no mention in the article anywhere else, and are currently non-notable (or at least, article-less).

Part of the issue with these fields are that they aren't being treated as "key information for the reader" currently. They're being treated as obligatory. "Go read the credits, find the names, add them, regardless of secondary coverage or context.". That's our current state, and what I'd like to really try to address.

This is similar to how we treat {{Video game reviews}}. Although often ignored, it requires any reviews listed in the review table to be in the prose. Although often not the case, it represents the preferred state to strive for. -- ferret (talk) 13:46, 10 March 2022 (UTC)

For AA-AAA+ games, this proposal broadly makes a lot of sense to me. How do you envision it applied to indie games? E.g. Night in the Woods or Gone Home. Axem Titanium (talk) 14:02, 10 March 2022 (UTC)

I think "key people" or something solves the issue. Avoids question of staffing/contractors, doesn't imply that someone bluelinked in that list is the only creative for something (like sole writer, etc.) At some point there's no way to append a modifier that won't have some imprecise elements to it (the explanation can go into the template documentation.) To go with a less-extreme example than the Max Payne one above, I see similar issues with Halo: Combat Evolved—some of these people are mentioned in the article body, but knowing the art team is definitely not a crucial element for a high-level overview of the game versus release date, publisher, etc, and by the very nature of the fields it creates a flattening of reality that I'd rather avoid as well (for example as specified in the game and as common with many smaller projects, various members of the team were working in roles outside their specific credited ones, so to just say 'these two guys were the artists' is incorrect.) As a final issue, a lot of this stuff is never verified, or, to take a recent change I reverted, cited to MobyGames and other stuff we have long held unreliable. Der Wohltemperierte Fuchs ^talk 18:18, 10 March 2022 (UTC)

I am not sure why we need a separate parameter when we already have parameters that are more specific. I think "key people" is even more vague than "notable staff". Are voice actors "key people" that can also be listed? For instance, Michael Mando is essential for Far Cry 3's success and one can argue that his role in the game's development is also important. Key people is such a broad term and it makes no sense to put studio heads, director, writer, composers, and the voice actors together in one single infobox field. A more straightforward solution is to completely depreciate certain infobox fields that are commonly unsourced, or lead roles that are deemed less important (e.g. producers/progammers/artists). OceanHok (talk) 20:35, 10 March 2022 (UTC)

I also agree that "key people" is too vague and would be prone to edit warring. Like some others have said, I'd rather we just limit entries to bluelinks than merge everything in one field (imagine how much of a bloated mess Chrono Trigger's infobox would be). ~ Dissident93 ^(talk) 22:12, 10 March 2022 (UTC)

If we must make a change, then I agree that blue links is the way to go, but I also think that directors, (lead) writers, and composers without articles should be permitted—only listing, say, one of three writers is misleading and makes them appear to be the only one (whereas listing only one lead artist or programmer doesn't have the same effect). There's also potentially an argument to be made about indie games made by less than a handful of people: Undertale was clearly the heart and soul of Toby Fox, but its art was designed by one person, who does not have an article; That Dragon, Cancer was designed, programmed, written, and composed by four people who do not have articles, but at least three of those are mentioned pretty extensively in its development section, so their exclusion from the infobox feels unfair and misleading. I'm not sure if or how this could be clarified in the documentation—I suspect it would be prone to edit warring otherwise—but it's something to consider. – Rhain ☔ 00:31, 11 March 2022 (UTC)

One option is remove people from the infobox entirely and list them in the article under their own section instead; see Interstellar's article. -- Wrath X (talk) 02:42, 11 March 2022 (UTC)

What about limiting the amount of non-blue-linkable people to a lowish number instead of banning them outright? To, let's say, 5 names. (With repeats due to multiple roles possibly to not be counted.) Still, I'd prefer mentions in body text as the threshold for inclusion. --LaukkuTheGreit (Talk•Contribs) 14:24, 11 March 2022 (UTC)

It's currently limited to four. The point is that it puts a lot of generally uninformative information at the top of the article which is never discussed in the article body. It also leads to a lot of robotic watchlist spam as people endlessly tweak it and fill them in automatically from credits regardless of any secondary coverage taking note of the role. If no one else feels it's an issue that needs address though, I'm not going to push hard. -- ferret (talk) 18:41, 11 March 2022 (UTC)

I support this too. My preference is to limit it to blue links only. Anything's better than the constant bloating that happens now. I'd much have a straightforward and easily understood bright line stance like blue links only though. The issue we have is less about anyone here, and more about the hundreds of casual and passerby editors that tweak this sort stuff all the time. It's best to have it something simple and at least somewhat intuitive. Sergecross73 msg me 18:57, 11 March 2022 (UTC)

My issue with a blanket ban on redlinked names is the same as Wrath's/OceanHok's, above. It entrenches existing biases in Wikipedia's coverage. Redlinked people are disproportionally women, people of color, nonbinary people, non-English speakers, etc. In an ideal world, all of these people would be getting the interviews and coverage in RS to warrant making those articles and meet our requirement for listing in the infobox. We don't live in that world and to systematically exclude them would be to imply, true or not---by the infobox's 'at a glance' nature---that games are made mostly by white men (and a few Japanese men). Axem Titanium (talk) 12:34, 12 March 2022 (UTC)

Sounds like a great reason to not have these names in the infobox at all, because there's no getting around existing biases in Wikipedia's sources. Der Wohltemperierte Fuchs ^talk 15:49, 12 March 2022 (UTC)

The problem with banning red-linked invidiuals is that sometimes the most important person is not listed in the infobox, while those who are less important are listed instead. For instance, Jake Solomon was essential for the development of the recent XCOM games, but if we only list blue-linked people, only Michael McCann/Tim Wynn (composer) would be shown. Another example is Dean Evans from Far Cry 3: Blood Dragon. If he is ignored, the infobox would only show Lucien Soulban (writer) and Power Glove (composer). Both game directors played a more significant role when compared to the composers/writers (the section is basically them reflecting on how they made the game). This is like writing Jojo Rabbit but then decided to leave out Roman Griffin Davis (lead role) because he is a kid who does not have an article about him yet. It simply does not make sense to not list them in these situations. A complete ban on red-linked invidividual is a very unreliable and inaccurate way to define notability. OceanHok (talk) 19:21, 12 March 2022 (UTC)

The caprices of who gets made available for an interview should not dictate how Wikipedia documents credit. We have already agreed that dedicated full credits sections are inappropriate for a number of reasons. That's fine and I agree with that guideline, but it leaves crediting up to the infobox (at a glance) and the Dev section (more in-depth). A given article may be in any state from stub to FA and some articles in the early stages may not even have a Dev section yet. Or maybe it's an obscure game whose devs never covered in RS for all time. Does that mean you're not allowed to add any credits at all to the infobox, since you can't mention them in prose? I think misattributing credit or "misattributing-by-omission", as described by OceanHok above, is a worse sin than the alternative. There are some holes in the guideline as proposed that presume too much about the advanced quality of the article AND the state of other biography articles. I hope the final proposal addresses these common situations. Axem Titanium (talk) 22:56, 12 March 2022 (UTC)

Does that mean you're not allowed to add any credits at all to the infobox, since you can't mention them in prose? Yes? The point of INFOBOXREF is that it heavily discourages stuff from only appearing in infoboxes, and the reality of these fields in the wild right now is people add every goddamn person to every goddamn field and at best cite it to MobyGames. All this academic talk about systemic bias is kind of pointless to me because in the actual 'media, I have to spend the inordinate amount of time cleaning up after people, month in and month out, and I'm tired of it. So a dumb and arbitrary requirement like only blue links is still a massive improvement over the status quo. Why do we have to waste editor time on this? Der Wohltemperierte Fuchs ^talk 00:10, 13 March 2022 (UTC)

• After reading the above thoughts, this has been my thinking process:
  1. We definitely want some type of field for staff (or "personnel", or whatever) available to use in the infobox, as opposed to removing staff fields all together. Per Axem, the purpose of the infobox is to summarize key facts that appear in the article, and the staff behind a game are (often) one of those key facts. The field should at least be available to use, but not required.
  2. I think most readers want to see, at a high level, the primary creative minds behind a game in the infobox, if any exist. Not every game has them. People will disagree all day on who the key people are. We can't go by roles, as how influential a role was fluctuates on a game-by-game basis. Ultimately, the best thing we got is what sources say. "Key people" would be those who are discussed by sources as evidently having a key role in shaping the game. Naturally, they should be mentioned in prose and beyond a passing mention.
  3. While most readers want to see the primary creators of a game in the infobox, there is an issue when the personnel are likely unknown to the reader. Placing information in the infobox which the reader will not understand is generally ineffective. The best measuring tool we have to determine who is "notable" is whether or not they have their own Wikipedia article. I understand Wrath's concern with only one contributor in a partnership circumstance being notable. In that case, I would suggest presenting person A as a "co-whatever" and/or footnoting person B next to person A's name.

In conclusion, I suggest to only list people who are both (1) discussed as a primary creative force per sources AND (2) have their own article (notice how I'm not saying blue link, to avoid people creating cheap redirects to circumvent this). To further clarify or clear up possible misunderstandings, footnotes should be used. TarkusAB^talk/contrib 08:55, 15 March 2022 (UTC)

Can we tackle this with a technical solution as well, and make a field that has a maximum number of characters, to avoid bloat and the constant clean up required after every employee, including the tea lady, has been added? - X201 (talk) 09:54, 15 March 2022 (UTC)

ferret, as a note, "Remember that on mobile, infobox displays first, ahead of the lead." is incorrect. You'd think that based on the HTML/CSS of the template and typical page layout, but MobileFrontend specifically has server-side code to move infoboxes to display after the first paragraph. Izno (talk) 22:23, 23 March 2022 (UTC)

Well, first paragraph is just half way. Either way, I'm not pushing this proposal further. It's just another one of those tasks that fill my watchlist that I'll ignore going forward. For me at least, trying to keep these fields sorted and to guidance holds no value. -- ferret (talk) 22:58, 23 March 2022 (UTC)

Wikidata issue?

@Mike Peel: Could you look at Special:Diff/1079564688? This article has been displaying Wikidata for nearly 4 years. @OceanHok rightly populated the fields because they weren't showing, yet Wikidata seems to still be populated. So why no data pull? -- ferret (talk) 13:14, 27 March 2022 (UTC)

@Ferret: Sorry for the very slow reply. The information on Wikidata isn't referenced, so it doesn't show up here per this edit by @Jonesey95:. Thanks. Mike Peel (talk) 18:40, 6 May 2022 (UTC)

Ahhhhhhhhhhh. That's quite the hole to fall into. -- ferret (talk) 19:15, 6 May 2022 (UTC)

Programming language

There have been a few requests to add a field for the programming language used to develop a game. The consensus mostly was that this is not necessary as it would depend on what engine a game uses, that it is difficult to source, and that most games use C++ anyways. I do agree with the fact that it does not make that much sense with modern mainstream games, but I do think that there are some cases where this field could be useful, mostly with vintage games. The articles do often mention it already and proper sources are usually available for older games. Also, the concept of a separate video game engine was not common back then and only a single programming language was often used for everything. --91.115.29.152 (talk) 05:07, 3 August 2022 (UTC)

Addition of short desc parameter

Hello! Would it be possible to add a short description parameter to the infobox? It appears to cause issues relating to the Wikidata short desc categories as seen on American Truck Simulator and Euro Truck Simulator 2, where the infobox's short description is overridden by the short description template, but Wikidata doesn't see that it's overridden so it says that the short desc both matches (short desc template) and doesn't match (infobox short desc) the short desc stored on there. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:22, 21 September 2022 (UTC)

The template does add a shortdesc. If shortdesc helper isn't recognising the mismatch, that's an issue to raise at the script's talk page. Primefac (talk) 13:26, 21 September 2022 (UTC)

I just checked both and they rendered just fine. Regardsless, this would not be the fault of this template but rather that of the script (maybe a cache issue?). I also removed the incorrect shortdescs from both articles. IceWelder [✉] 13:32, 21 September 2022 (UTC)

The shortdescs were incorrect? Cause they matched Wikidata (hence the maintenance category saying it matched). I discussed this on the Discord server last night. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:35, 21 September 2022 (UTC)

Cause what I"m sayin gis, the template adds a shor description, but there's also the short description template on the article. Wikidata sees both short descriptions and one matches and the other doesn't. The issue isn't with the script but with Wikidata and this template. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:36, 21 September 2022 (UTC)

We don't really care what WD sees. As mentioned, if the shortdesc helper is saying "one of these shordescs doesn't match WikiData!" that is an issue with the shortdesc helper, not this template; the template cannot determine what the WD shortdesc is or should be. Primefac (talk) 13:40, 21 September 2022 (UTC)

I'm confused. The issue isn't with the shortdesc helper. It's an actual maintenance category Category:Short description is different from Wikidata. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:44, 21 September 2022 (UTC)

Technically speaking, that is a tracking category, not a maintenance category (I've changed the header to match). As stated on the category page, there is nothing that needs doing to any of the pages in that category. Primefac (talk) 13:51, 21 September 2022 (UTC)

Ah alright. Well at least the article is no longer in 2 categories that contradict each other. Thanks! Also, there was a discussion regarding this issue on the shortdesc talk page. If you'd like I'll link it here once I'm able to. ― Blaze Wolf^Talk_{Blaze Wolf#6545} 13:57, 21 September 2022 (UTC)

Oof. Bad this was marked as maintenance, as it is FULLY EXPECTED that short desc will often not match Wikidata. -- ferret (talk) 21:49, 22 September 2022 (UTC)

"0000 video game"

Hi -- I noticed that ZZT ends up with a short description of "0000 video game". I can see this template has some logic to extract a four-digit number from the release date, but I can't decipher it well enough to tell how it's coming up with zeroes. Is the logic known to work? (I thought it did for other game pages, but now that I check, they all seem to use Template:Short description directly instead...) Andaphantie (talk) 04:08, 14 December 2022 (UTC)

I did a bit of experimenting. Short description is generated from the |released= field, specifically a match for 4 digits - presumably, a year. In this case, {{Video game release|NA|January 15, 1991<ref name="ZZT-Museum912"/>}} produces this output '"`UNIQ--templatestyles-00000004-QINU`"'<div class="plainlist"><ul><li><span style="font-size:95%;">[[North America|NA]]:</span> January 15, 1991'"`UNIQ--ref-00000003-QINU`"'</li></ul></div>, which the template matches to the first found "0000" - this is why it ends up being "0000 video game".

I changed the year match pattern from any four digits "DDDD" to specifically "1DDD" or "2DDD" only. (This should work unless there are more than 1000 ids before the infobox, which seems highly unlikely.) —  HELLKNOWZ ∣ TALK 11:43, 14 December 2022 (UTC)

e.g. PEGI age ratings are missing from this info box

Please bring in pegi ratings. 2001:999:600:3AE8:7474:488B:AD85:CD2 (talk) 10:49, 18 February 2023 (UTC)

This is not to be added unless independent notable per WP:GAMECRUFT #16, which is not the case in 99.9% of games. ~ Dissident93 ^(talk) 11:05, 18 February 2023 (UTC)

Add Reception?

Shouldn't we add Reception to this template? Would be really useful to have this at the top of the page, rather than scrolling to the bottom.

Could use symbols such as or something, to indicate "generally positive" on Metacritic. 92.14.54.22 (talk) 09:37, 21 January 2023 (UTC)

That wouldn't work well with different scores for different platforms, conflicts between Metacritic and GameRankings, etc. We have a specialized template just for reviews, which I think fulfills that purpose just fine. As for not "scrolling to the bottom", a short summary of a game's reception is usually included in the lead in game articles. IceWelder [✉] 11:58, 21 January 2023 (UTC)

Also opposing since the lead is supposed to summarize reception instead, which is vastly superior than a green arrow that gives zero explanation or context. ~ Dissident93 ^(talk) 11:07, 18 February 2023 (UTC)

Add a link to the website of the game

I was thinking it would be a good idea to add a field where you can link to either the game's official website or for online games the site where the game is hosted. This can be useful for online games like Cookie Clicker, where the game's URL could be found in the infobox, or perhaps for more traditional page where the url in the field could point to the game's official release page or other relevant pages. What do you think about this? Nar 2608 (talk) 12:08, 3 April 2023 (UTC)

See the FAQ just above. It links to a few of the previous discussions on the topic. - X201 (talk) 12:12, 3 April 2023 (UTC)

worldwide date

In the release field it reads: "Use the Video game release template" but then "Only use WW to provide clarity where a game has various differing release dates including multiple regional release dates on some platforms and worldwide on other platforms." But I can't use the template if I want to list the dates without "WW" or am I missing something?

So if I want to list a Steam game where there's no indication of regional releases, should I list it plainly with "br" tags or with a template:.
October 12, 2013 (PC)
November 12, 2013 (Mac)
or

• WW: October 12, 2013 (PC)
• WW: November 12, 2013 (Mac)

Mika1h (talk) 15:12, 24 April 2023 (UTC)

Yes, you would leave out the Vgr template and use a plain list instead. Per WP:VLIST, you should use {{Unbulleted list}} for that. IceWelder [✉] 15:16, 24 April 2023 (UTC)

Correct. VGRelease is an Unbulleted List under the covers. -- ferret (talk) 16:33, 24 April 2023 (UTC)

DRM

With so many games featuring DRM (and companies publicly arguing for its inclusion), the DRM used in the game should be added (if known). Please add a DRM field. Thanks! 136.57.164.226 (talk) 13:41, 28 April 2023 (UTC)

Opposed. The vast majority of PC games, at the very least anything sold on Steam, have some degree of DRM. Only a handful get actual coverage in regards to it. And for non-PC games, it doesn't really apply at all. -- ferret (talk) 13:54, 28 April 2023 (UTC)

"Based on" parameter

I know that there are two discussions about this linked above, but one was an edit request with no consensus and the other only listed a few examples and got zero responses. I think it would be useful to have a "based_on" parameter added, and I think it should be discussed to allow a consensus to be reached. My argument in favor of it is that we currently have many, many pages about video games based on works; we have 201 pages in Category:Video games based on anime and manga, 162 pages in Category:Video games based on television series, 145 pages in Category:Video games based on novels, and 72 pages in Category:Video games based on comics. This isn't even including the subcategories that exist in those categories I listed, and there are other categories as well. If films can have a parameter to indicate that they're an adaptation of an existing work, video games should as well, in my opinion. I would really appreciate some discussion so we can reach a consensus this time. Thanks, Di (they-them) (talk) 23:03, 27 May 2023 (UTC)

• I support this idea. Licensed games are increasingly common these days. OceanHok (talk) 12:34, 28 May 2023 (UTC)
• I previously opposed this but no longer do since it would match the film infobox and would only be used in conjugation with the categories anyway. ~ Dissident93 ^(talk) 13:40, 28 May 2023 (UTC)
• Support This would be quite useful. QuicoleJR (talk) 15:21, 31 May 2023 (UTC)
• Weak Support only because I am worried about potential misuse of this on a large scale (for example several Star Wars games could be argued to be based on specific SW works, rather than the frabchise as a whole)As long as its used correctly, it makes sense to include. --Masem (t) 23:17, 31 May 2023 (UTC)
• Neutral, leaning oppose I feel like this has a great deal of overlap with the existing series parameter. -- ferret (talk) 00:15, 1 June 2023 (UTC)

  Maybe we could omit the series parameter for obvious licensed works and use this instead? Most of the time it just links to a small video game section on the franchise article anyway. ~ Dissident93 ^(talk) 08:25, 1 June 2023 (UTC)

  The Lego games would pose an immediate problem. Masem (t) 12:37, 1 June 2023 (UTC)

  I don't see how the LEGO games would be an issue. Using Lego Star Wars as an example, in the based_on parameter, we would simply put Star Wars, while the series parameter would have Lego Star Wars. Di (they-them) (talk) 16:44, 1 June 2023 (UTC)

  Yeah, this is how I would handle it too. ~ Dissident93 ^(talk) 15:13, 4 June 2023 (UTC)

  I would also support if we just simply allow the series parameter to also include licensed works. OceanHok (talk) 12:26, 1 June 2023 (UTC)

  Isn't this how it's currently handled? ~ Dissident93 ^(talk) 17:16, 4 June 2023 (UTC)

  I don't think so. The infobox guideline explicitly says "video game series". For instance, neither Star Wars and Middle-earth is a video game series, so articles like Star Wars Jedi: Fallen Order or Middle-earth: Shadow of War do not list them in the series parameter. OceanHok (talk) 12:50, 5 June 2023 (UTC)

•  Comment: To expand on the categories count − over at Wikidata we have 1600 video games that use based on (P144) (see query below). It’s a bit of a mixed bag because it’s used to express a fairly wide range of relationships (often clarified with qualifiers), including to other games − for example that’s how we may model remakes/remasters or clones ; potentially also parodies, spin-offs, side-stories… (You can alter the query (or ask me to :þ) to only have based on other games, or any works excluding games, etc.) Anyhow, putting that here as it might also feed in your policy on what exactly you want to allow and not allow in that infobox parameter. :-) Jean-Fred (talk) 19:08, 4 June 2023 (UTC)

SELECT ?video_game ?video_gameLabel (GROUP_CONCAT(?based_onLabel; SEPARATOR = "; ") AS ?based) WHERE {
  ?video_game wdt:P31 wd:Q7889;
    wdt:P144 ?based_on;
    rdfs:label ?video_gameLabel.
  FILTER((LANG(?video_gameLabel)) = "en")
  ?based_on rdfs:label ?based_onLabel.
  FILTER((LANG(?based_onLabel)) = "en")
}
GROUP BY ?video_game ?video_gameLabel

Click here to launch the Wikidata query

• (To be clear: I’m not saying you should tie that future field to Wikidata’s P144, I think it might be a bit too much of a kitchen sink at the moment for that purpose ; I mean to say “based on” can have several meanings. Based on the opening statement, sounds like you want to use it for “based on an existing work of another type” ; but you should expect folks might want to use it with other video games, or franchises. Jean-Fred (talk) 07:23, 5 June 2023 (UTC))

  (One last thing − over at Wikidata we have media franchise (P8345) so we would not put a franchise like Star Wars as based on (P144). Jean-Fred (talk) 18:23, 5 June 2023 (UTC))

"Downloadable content" parameter

I'm not sure if this has been discussed previously; I tried checking but I couldn't find anything regarding this, but correct me if I'm wrong. I was wondering if, for certain games that have notable downloadable (DLC) content, there could be a "downloadable_content" or parameter for the infobox of a videogame? There's a certain amount of videogames that have specific articles made about some of their DLC content, and I feel like it would be a good idea to include links to those articles in the videogame's infobox, on top of just the summarized description of what downloadable content they include located in the article. For example, Fallout 4 has an article for its downloadable content but also has specific articles regarding Far Harbor and Nuka-World, which I feel might be a good idea to include in the main game's infobox to indicate these notable DLC's. B3251 (talk) 13:37, 6 July 2023 (UTC)

My initial gut reaction is...probably not. Yes there are games with notable DLC like Fallout 4 as you demonstrated with standalone articles, but they are the exception. The overwhelming majority of DLC is trivial map packs, skin packs, extra missions, and so on. No matter what stipulations are placed for the field, there exists a breed of editors who will feel compelled beyond all reason to fill out every infobox with all DLC information. Ultimately there will be a marginal improvement to articles like Fallout 4 but a determental addition / edit warring to most other articles. TarkusAB^talk/contrib 22:10, 6 July 2023 (UTC)

This, but to add, for games with standalone article-notable dlc, those probably should be clearly mentioned in the lede, just as sequels or spinoff would be mentioned. This alleviates the need for anything in the infobox. Masem (t) 23:16, 6 July 2023 (UTC)

Super Mega Baseball#Super Mega Baseball 3

The infobox retrives an (incorrect) image from Wikidata eventhough the "image" field is left blank. Mika1h (talk) 15:20, 16 August 2023 (UTC)

@Mika1h Not a bug/issue. To suppress the wikidata pull, the field cannot simply be blank. Populate it with a hidden comment, or alternatively, add parameter | suppressfields = image to the infobox. -- ferret (talk) 15:49, 16 August 2023 (UTC)

I added QIDs for both sequels. Any info it needs to pull from Wikidata should now com from those entries. IceWelder [✉] 18:18, 16 August 2023 (UTC)

Yes, that's also needed when using multiple infoboxes on one article -- ferret (talk) 18:49, 16 August 2023 (UTC)

why no section for the budget?

film infoboxes have it, and many of the bigger and more recent vidya games have their budgets publically known. why not add that as a parameter?

if anything those budgets would prbably be more legit/closer to truth than those of films thanks to the absence of teh phenomenon of Hollywood accounting Daikido (talk) 23:48, 9 September 2023 (UTC)

Actually, knowing the true budget of a video game is typically abnormal in the industry. Our list of video games that cost the most to make has massive coverage gaps. -- ferret (talk) 00:26, 10 September 2023 (UTC)

To add, whereas in the film world production budgets are nearly always reported (at least for films from major distributors) and tracked on sites like boxofficemojo, there is no equivalent in the video game industry. Budgets are kept very very tight, with no normal public reporting, and thus no tracking of them. There are some games we have gotten the idea of budgets from but these are usually critically important games. Masem (t) 00:50, 10 September 2023 (UTC)

Adding rating data on Infobox.

Hello, could you please adding Rating label and data with Infobox video game? Bonthefox3 (talk) 14:54, 15 November 2023 (UTC)

Perennial request. Please see for example, Template talk:Infobox video game/Archive 16#e.g. PEGI age ratings are missing from this info box, Template talk:Infobox video game/Archive 15#Propose adding Age Guide. IceWelder [✉] 14:59, 15 November 2023 (UTC)

Writer is connected to author (P50)?

Why is this parameter linked to author (P50) when the wiki article listed in the infobox explicitly describes the writing of the script? I think screenwriter (P58) would be a more reasonable choice, while "author" would be more appropriate for the "Idea/Story by" line, which by the way is separated from writer in the Template:Infobox film. Speaking of usage - P58 is used with 428 video games and P50 with 218 video games. What do you think about swapping properties? Solidest (talk) 19:48, 6 December 2023 (UTC)

Because P50 made sense at the time. No one ever refers to video games as having a "screenwriter". I'd suggest all such cases switch to P50, but honestly no one from WP:VG really maintains Wikidata and I've debated suggesting we pull it back out. -- ferret (talk) 20:12, 6 December 2023 (UTC)

If we switch everything to P50, wouldn't it make sense to rename the parameter to "author" as well? Because an author is more than just a writer. An author can be the original creator of the idea, while writer is hardly referred to as such in this pair. For example, I would say that the author of Gears of War (video game) is Cliff Bleszinski or Sven Winke is the author of Baldur's Gate 3, but both of them are not writers of these games. An author is something between director/writer/gamedesigner which may variate in different cases. While a writer may be someone who adapted the original work or idea of the author. For the very same reason Pac-Man doesn't have a writer, but it does have an author/creator. Solidest (talk) 22:14, 6 December 2023 (UTC)

IMO "author" shouldn't be used for video games at all unless it is a one-person indie game, since it refers to the creator of the entire work (as with books), not just the initial game idea. Removing all Wikidata garbage, though, would be the best solution. IceWelder [✉] 22:24, 6 December 2023 (UTC)

It’s better to not be too hung-up on the (English) label of a property. P58’s French label is “scénariste”, which is most definitely used for video games. Among the English aliases is “screenplay by”, and video games have most certainly been referred as having a screenplay (just one random example, 1992’s Alone in the Dark has « Screen Play: Hubert Chardot, Franck Manzetti » in its opening credits). I would agree with the suggested move to P58 (disconnecting the field from Wikidata is also a possible solution of course, which I’m sure can be done without having to refer to anything as 'garbage'). Jean-Fred (talk) 07:50, 17 January 2024 (UTC)

Alone in the Dark is definitely an outlier. "Screenwriter" is an exceedingly rare title in video games from an English view. -- ferret (talk) 14:51, 17 January 2024 (UTC)

If anything, both properties have "writer" and "written by" AKAs. And I sincerely don't understand how someone who holds the position of "Lead Writer" (the most common credit in modern narrative games used by this parameter) can be called the author of a game.

I didn't mention it the first time, but the situation here is exactly about how the properties are designed on wikidata. The author (P50) is primarily a property for literary works and for indicating the out-of-category authorship of a work. Can we say that the hired writer of a script for a game becomes the author of a video game? Of course not. Whereas the property screenwriter (P58) is rather used for any audiovisual works, starting from the cinema. Writing for a game is much closer to writing for films than writing poems or novels, if anything. And it doesn't matter how you call those positions. In both film and games, it's a script because in a game, as in a film, there is a narrative that is played out/performed visually (essentially written in dramatic mode). Writing in the form of regular literary prose is quite rarely used in games - exceptionally in unconventional indie projects where text is an important part of the gameplay.

Another nuance is that author (P50) used 217 times with video games (or its subtypes), while screenwriter (P58) is used 436 times.

And the last is that author (P50) is connected to author (Q482980)=Author and writer (Q36180)=Writer, while screenwriter (P58) is screenwriter (Q28389)=Screenwriter. Check these items on wikidata - the former is all about literature and books, the latter as I said is about audiovisual works, including video games. Then check the content of the articles on wikipedia and find where they mention "video games" - the conclusion is also unambiguous.

To be honest, there is not even any room for manoeuvre here and it is obvious that at the moment the property is given incorrectly. Solidest (talk) 21:59, 17 January 2024 (UTC)

I mean, you kinda showed it. P50 is attached to Writer, which is why years ago, we chose that property. Like, literally 8 years ago now. And at the time all efforts to determine appropriate properties pointed to P50. Now, 8 years later, Wikidata has been off doing it's own thing and populating P58 instead, and no one brought it up till now. Wikidata drifted from what Enwiki was doing in the years, which is part of the issue with Wikidata integration in the first place. Video games do not have a credit called Screenwriter and no one in WP:VG would have ever thought to use that. -- ferret (talk) 22:08, 17 January 2024 (UTC)

Okay, since we seem to have come the agreement on this, I open an edit request. Solidest (talk) 22:46, 17 January 2024 (UTC)

Per the reasons above, Wikidata property for "author" should be replaced to P58. Solidest (talk) 22:46, 17 January 2024 (UTC)

Have we come to agreement? I'm steadfast in "screenwriter" is not a video game credit. -- ferret (talk) 23:09, 17 January 2024 (UTC)

So you ignored all my arguments, and yet your argument is "that's how things were on wikidata 8 years ago and they seem to have changed and you demonstrated it" turns out to be your disagreement with the state of things? i.e. you basically don't care about it? Also, based on the fact that you focus on label, and ignore descriptions, aliases, and other statements of wikidata items and properties, it looks like you don't really understand how wd really works and should be used in importing. Or either you are just showing stubbornness/ ignorance, which hardly plays any role here or elsewhere on wikipedia. If you really have counterarguments that you are ready to give to the points above in the described context, I will be glad to hear them. So far I haven't seen that from you, except for repeating the phrase to which you have been answered by 3 people (and I personally gave you three reasoned answers to that). Video game writer is not "author" on wikidata of 2024, p58 is correct property for that. Solidest (talk) 02:05, 18 January 2024 (UTC)

Hmm, yes, let's try to avoid riding the line of personal attacks. I literally implemented all Wikidata integrations for WP:VG, and was a proponent for years. I did give my reason, but you misunderstood it as agreement, somehow, even though I explicitly said once more that "screenwriter" is not the English project usage, and the descriptions/aliases made no mention of video games on the property. Then you rushed to an edit request. You highlighted that author is an connected to writer, which is what I referred to with "you kinda showed it", as why we used it. When Wikidata moves out of alignment with English Wikipedia expectations, such as using a different term than we do, we don't necessarily change to match Wikidata, we sometimes just stop using it, as Jean-Fred alluded to above. This is also Icewelder's position, though he'd remove all the credits from using Wikidata. The project tends to sit on edge of deciding to remove these fields entirely, regardless of Wikidata, as well, due to numerous issues in how they are sourced and populated. The actual smoking gun from the Wikidata side, not brought up so far, is that video game writer is a suggested constraint on Occupation for P58. This is a very clear argument, and does make the Wikidata intent clear. But, I'm also more in line with Icewelder and would currently lean towards removing the properties entirely. -- ferret (talk) 02:47, 18 January 2024 (UTC)

I don't mind removing the properties, as it would stop gadgets suggest exporting values into two different properties. This infobox also has a problem with "artist" param, when for 95% modern games people most of the time list "art director" there which has its own property art director (P3174), but the infobox is connected to game artist game artist (P3080) - and this also creates incorrect or doubling exports. Unlinking will also help to resolve this issue as well. Basically, Wikidata favours precise data, while Wikipedia prefers to fit 10 different positions into 5 parameters and therefore degrades the quality of data in this regard. And the situation is unlikely to change until English wikipedia revises its approach towards infobox data accuracy rather than compactness. Solidest (talk) 03:39, 18 January 2024 (UTC)

Yes, artist is another sticky one, where there are two properties representing related roles. It looks, at a glance, that P3174 was added just after we had implemented as P3080 (which I think I actually requested because there was nothing suitable at the time). Infoboxes on English Wikipedia aren't meant to be detailed accuracy, but compact "at a glance" information. Our rules for Release date are so arcane that we never even tried to implement Wikidata for that. Are any of the credit positions actually correct, once we review all related properties? Programmer is using P943, but of course we also want only "leads" or "directors". And of course, we use the generic P57 for directors, and P123 for producer. P86 is probably fine for composer? -- ferret (talk) 03:45, 18 January 2024 (UTC)

Director is also a tricky one. When credits have "creative director" and "game director" at the same time, then it would mean that game director is rather a production head position (unit production manager equivalent), than creative position as what "game director" is usually is. Using two roles at the same time is not as common, but it still happens: 1, 2, 3, 4. The infobox documentation currently assumes that this is the same position. A couple of weeks ago I created a proposal for "creative director", mostly as it's often used on television and is quite different from director in this context. And it's not really clear how to use this with video games - people will probably still fill this in when a role is specified. Solidest (talk) 15:36, 18 January 2024 (UTC)

 Not done for now: please establish a consensus for this alteration before using the {{Edit template-protected}} template. Relax, Solidest and Ferret. As an alternative solution, Wikidata may need a new property for video game writing credits. Neither "author" nor "screenwriter" (in English) adequately describe the work of video game writers in my opinion. SWinxy (talk) 03:08, 18 January 2024 (UTC)

(Wow, this conversation sure got busy overnight :) ).

@Ferret: re: Alone in the Dark being an outlier and screenwriter being rare lingo for video games: sure, I’ll take your word for it. (we may want to tweak the articles for screenwriter (which currently says A screenwriter [writing for] video games) and screenplay (which states "A screenplay, or script, is a written work by screenwriters for a […] video game"))

I’m not sure I get what the problem is here. Ferret, it seems to me you are getting defensive about the use of P50? There is no reason to: I don’t doubt that using P50 felt like the right thing to do 8 years back − even our own WD:VG documentation has been pointing to P50 for 11 years. But Wikidata is a wiki, it’s in perpetual evolution. Sometimes the change happens in a controlled way (we have a discussion, decide on changes, and implement them) ; sometimes it happens on its own, someone eventually notices (in this case Solidest) and we have the discussion a bit after the fact. As changes on WD side do potentially impact other projects (like this infobox), then the former is obviously a more ideal process. I don’t think the latter has happened that often with video games (perhaps I’m wrong), but I understand this can be annoying for you. Personally, I think we have more to gain by working somewhat together rather than actively against each other, and since I understand that not many (if any) en.wp VG editors want to get involved with WD (which, fair enough − only so many hours in the day), I don’t mind picking up a bit more of the extra work to make things work smoothly between our projects.

Anyhow, coming back to the topic at hand: I opened a more formal proposal on our side to clarify the P50 vs P58. I do acknowledge that the English label might not be a great fit ; but really, I can’t stress enough that "it does not really matter": properties encode an agreed-upon relationship between item and value. if we all agree that in the context of video game items, P58 means "video game writer" then it does. And we do have Descriptions, Aliases and Constraints to clarify. (There is certainly no requirement for this infobox field header to be changed to screenwriter). Of course, preferably, the labels are a good fit (which is the case in French and any other language I can read, for that matter), so we can start a discussion to relabel P58 − would “scenarist” make everyone happy? Jean-Fred (talk) 11:10, 18 January 2024 (UTC)

@Jean-Frédéric We use video game writer here, which has an entire article on the process. It does make some comparisons in a few places to screenwriters, but generally avoids the use of the term "screen" and refers to "script writing" more generically. There's no defensiveness here, I'm simply direct in my text, and very calm. As noted, the missing piece to me in the arguments was the constraint on occupation that directly mentioned video game writer. Otherwise, P58 makes no mention of video game writing. Adoption of WD is hampered by changes in the structure like this: Sure, this one case has been identified, but what other templates on Enwiki have either improperly chosen a property, or that property's use has changed since it was adopted? Either way, Enwiki's infobox video game has an arcane rule set for credit fields in that we only want to display lead roles, which means almost any Wikidata pull is a violation of the template documentation outside of very small game projects. We've discussed removing these fields entirely, though I don't think that's happening. It may be best, as Icewelder first stated, to remove WD for these staff fields. -- ferret (talk) 14:09, 18 January 2024 (UTC)

Just to point out that you talk about the word "screen", but omit the fact that "author" is also not used anywhere in Video game writer and avoided in exactly the same way. In the context of video games it can not only have a different meaning in other languages. Jean-Fred already said about French, and I can say that in Russian this word has the basic meaning "creator", which is why this parameter is already called "scenarist" in the video game infobox on ruwiki. But in English it's also a case - just look what author describes. It has a very different scope compared to the role of screenwriting in film, which is the equivalent for writing scripts in video games. The situation with the exact title of the profession does not play an essential role when we talk about the concept of the position itself. The exact same job can have different titles in different fields, and on wikidata there is no possibility to add 5 titles in the same language at once. That's why items have aliases. But anyway, I think renaming the properties to "scenarist" suggested by Jean-Fred should really handle this situation, as well as adding explicit AKA "video game writer" and additional intentional linking video game writer (Q3476620) in P58. And by the way, you're addressing disconnecting wikidata from the infobox again, but that's not what we're originally talking about. Here we are discussing replacing one property with another. If you want to start the discussion on removing wikidata from the code, you should probably start a new discussion below, pausing this one. Since switching from one topic to another is a bit confusing. Solidest (talk) 15:49, 18 January 2024 (UTC)

For P58 specifically, I think "scriptwriter" is the primary English label you want to cover the most media of this type. I think this in general should pause until WD:VG concludes their discussion (as they said to use P50 as well, as noted). Once that concludes and the exact guidance from WD is in order, we can update the property usage for this field. If we change the infobox right now, we potentially fix the pull for some ~450 items... but break it for ~250. Then we should resume discussing the fact that multiple properties can apply to these fields (i.e. as noted above for artist, etc) and the suitability of continuing using them given our rules to filter to "Leads" only. -- ferret (talk) 16:03, 18 January 2024 (UTC)

@Ferret Thanks, this sounds like a plan. I’ll come back here once the discussion on WD:VG concludes. I will also float “scriptwriter” (as you suggest) as potential new English label for P58.

I look forward continuing the discussion regarding multiple properties and the "leads" only rule.

Jean-Fred (talk) 19:04, 18 January 2024 (UTC)

Modes field

This might be me being old-fashioned, but... does it make sense to set the Modes field for single-player games? I'm a fan of keeping infoboxes lean and svelte, and single-player seems like the "default" for a game to me, and thus skippable. Which isn't actually true as far as playership (Fortnite, CoD, Minecraft, etc.), but is surely true as far as raw number of games treated equally (most games are single-player only). I'd suggest updating the doc to say that "Modes" parameter should only be filled in for multiplayer or mixed single & multiplayer games. Every little bit of trimming helps get the infobox over sooner and get back to the text, especially notable on mobile displays where the user needs to swipe through the full infobox on their way to the second paragraph of the lede. Thoughts? SnowFire (talk) 18:08, 16 January 2024 (UTC)

If you are going to show it for all other modes, includes games with both single and multiplayer modes, you really need to keep it for singke player only games, otherwise a reader could conclude something dufferent. Masem (t) 20:55, 16 January 2024 (UTC)

I think single-player being the default is a faulty assumption, and the casual reader might come to a completely different conclusion under a lack of information. Also, removing the field for one value but keeping it for all others feels completely arbitrary. That is somewhat like defaulting to a Windows release assumption unless the infobox states otherwise. IceWelder [✉] 21:42, 16 January 2024 (UTC)

My argument is merely that the best Infobox is the shortest one. Infoboxes are not for every single true fact. I don't think a game being (mostly / all) single-player really needs to be highlighted; it is generally obvious from context. SnowFire (talk) 22:24, 16 January 2024 (UTC)

There isn't really that much context to go around if one only reads the infobox. If you would like to make an argument for deprecating the field entirely, I would get that, but only disallowing one value that you think everyone would be able to infer seems unreasonable -- and difficult to enforce. IceWelder [✉] 22:38, 16 January 2024 (UTC)

My two cents... I'd cut credits before cutting modes down. Also, since we only support single player and multiplayer, I mull what if we had "singleplayer=yes", and "multiplayer=yes" and built the displayed field from that. This would also eliminate every case where someone puts a non-accepted item in the field. -- ferret (talk) 22:52, 16 January 2024 (UTC)

This, or making the existing field a three-entry enum, sounds like a great idea. IceWelder [✉] 23:04, 16 January 2024 (UTC)

I'd still rather just not display pure single-player at all, but seems others disagree on that.

I agree that simple y/n flags might be handy for external Wikidata-style analysis, though. Only worry is that I can see people throwing in footnotes to explain certain edge cases? And I'm not sure what would be a good way to represent that, short of creating a new `mode notes` and `mode group` field or the like. (And yes, I say this after just going ahead and saying that short infoboxes are better, but if people are arguing about whether a game qualifies or not, having the ability to throw in {{efn|The 1991 Sid Meier's Civilization release is single-player only; the 1995 CivNet remake has multiplayer capability.}} or whatever seems handy to avoid eternal edit wars. SnowFire (talk) 15:46, 17 January 2024 (UTC)

If we had yes / no fields, there wouldn't be a way to insert a footnote, at least not in the field itself. As someone who patrols this field regularly, I've never seen anyone do that, tbh. -- ferret (talk) 15:54, 17 January 2024 (UTC)

Interesting that you've found it rare. I'm guessing it does mostly occurs in-text rather than my example of a footnote - I see that at Star Ocean 3 for example. I just imagine completionists who just can't help but point out that one totally optional multiplayer minigame buried in a 70 hour game or whatever, or want to point out that the tutorial of a MOBA is technically single-player. (But I definitely haven't done an extensive analysis, so I'll defer to you on this.) SnowFire (talk) 22:01, 17 January 2024 (UTC)

I've honestly never seen that. Usually what I see is older games who's infoboxes haven't been updated in age that list things like "co-op" and "splitscreen". -- ferret (talk) 22:04, 17 January 2024 (UTC)

It is always possible that if we converted the modes field to simple three-mode (sp/mp/smp with aliases, defaulting to sp) that we can add an extra field to be treated as a type of explanatory note. I don't know what that would be named.

Also we need to consider how to grandfather existing infoboxes if we change this field. Masem (t) 22:06, 17 January 2024 (UTC)

Oh I'm confident Primefac could bot update it. That's not really an issue. We would only have two new fields, sp=yes/no and mp=yes/no. If both are yes it'll programmatically show both. -- ferret (talk) 22:10, 17 January 2024 (UTC)

I've put a demonstration of sp/mp yes/no flags in the sand box and test cases at Template:Infobox_video_game/testcases#Mode_switch_test. Is this a direction we want to go? These are the only two values we allow anyways. -- ferret (talk) 03:07, 18 January 2024 (UTC)

I'm fine with it, but per above, despite the potential for annoying pedantry, I'd rather keep either the ability to either override the values, or to always use the sp / mp values but to also have some sort of explanatory addition or footnote. In particular, the example of multiple relevant releases of the same basic game, but where the value changes, seems like something important enough to go in the Infobox (the Civ1 vs. CivNet example, say) if we're going to have the field at all. SnowFire (talk) 21:29, 19 January 2024 (UTC)

It's a good thought. I also believe in keeping an article lean, but I don't think single player is a fair assumption to make. Just at quick glance, it looks like around 30% of games on Steam are multiplayer. It's probably worth clarifying which is which, so readers don't assume. I like the idea of two simple "Y/N" flags for single player and multi player, because it prevents editors from piling on more information than necessary. Shooterwalker (talk) 16:39, 2 February 2024 (UTC)

released field

Currently it reads "Add release dates ... for English-language regions and the developer's region." I think it should also say "first country of release" or something similar. The original release isn't necessarily in the developer's region. Saw this at Gray Matter (video game) where original release date was deleted because it wasn't in a "major region". Mika1h (talk) 00:17, 20 February 2024 (UTC)

I have altered the wording to state that it should be the region of first release (if different from Western release) and that typically is the developer's region. — Masem (t) 01:35, 20 February 2024 (UTC)