Template talk:Infobox video game/Archive 10

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

I think it should changed to say "This field is for the name of the company or development team (...)", because some of the larger companies have names for their development teams and the current, unchalleged usage is to use these more precise names instead of the name of the general company. See for instance Final Fantasy VII or Devil May Cry 2. Thoughts? Jonathan Hardin&#39; (talk) 12:25, 18 August 2010 (UTC)
 * Agree. That is the way it is used in many articles anyway. However, development studios/teams need references if they are not mentioned in the (English version of the) game. For example, Nintendo R&D1 is not mentioned to be the developer in the staff credits of Super Mario Land 2: 6 Golden Coins, therefore it can be considered original research and has to be changed to simply "Nintendo" unless a reliable source is provided. Another example: Final Fantasy VII mentions Square Product Development Dept. #1 as the development studio, but it does so only in the Japanese credits: therefore, it is not common knowledge in an English speaking country and needs a reference not to be considered original research and to be changed back to simply "Square".


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


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

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


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


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


 * [forgive the late reply] Yes but the titles I'm referring to, and specifically mentioned in my post above, do NOT have ANY significant changes in them EXCEPT for the title screen and box art, other than that they're the EXACT SAME GAME just with a different title. That's why it can be confusing to readers who, for example, were used to playing Out of this World their whole lives, go to look up their favorite game on Wikipedia and see it listed under a completely different title! That's why I think an explanation is warranted, in the simple form of an infobox field such as "North American title" or some such. -- &oelig; &trade; 06:18, 31 August 2010 (UTC)

Alternate covers?
In the same way that the infobox for a song or album can show alternate covers, would it be possible for us to add an alternate cover parameter to this infobox? – PeeJay 22:58, 12 August 2010 (UTC)
 * There's already issues with alternative covers for albums and non-free content. I strongly recommend against; if an alternative cover is significantly covered (see Okami's Wii version) it can be included in the prose. --M ASEM (t) 23:04, 12 August 2010 (UTC)

See my related post above at. -- &oelig; &trade; 06:20, 31 August 2010 (UTC)

Role fields in infoboxes
The last discussion resolved a lot of issues, but we still have no clear consensus on what to do with role fields (programmer, designer, artist, composer, etc.) Do we limit these? Do we limit to notable? Do we limit to only 1/2 notable key people? I shall draft the sub-section again so that we can have easy consensus building. I suspect it may be hard to decide on the best method, but at least it will be possible to say what not to do. Note that these are directed at general cases and newer games, I realize there are obscure examples for each case where the best option is to WP:IAR. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)


 * WikiProject_Video_games/Templates "The fields for director, producer, designer, programmer, artist, writer, and composer should be used to list people who played key roles in the development of a game. However, their inclusion should be carefully measured not to make the infobox overly long."


 * Template:Infobox_VG "As with the developer field, individual development tasks for a single field (e.g. who of the artists did the character design and who the concept art, or who of the writers created the story and who the script) should not be mentioned in the infobox but in the article text instead."


 * Template:Infobox_VG For each field &mdash; "[field] The popular name(s) of the [role]."

No limit
No limit to people mentioned, include everyone.


 * Strong oppose. This can span pages for latest games. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)
 * Oppose. Someone may also be designated a "designer" when there role is covered elsewhere, e.g. "director" Vyeh (talk) 20:14, 9 September 2010 (UTC)
 * Oppose. For obvious reasons. Infoboxes are not a pastebin for game credits. Prime Blue (talk) 01:56, 11 September 2010 (UTC)
 * Strong oppose - this could lead to trivial members mentioned. 陣 内 Jinnai 18:03, 19 September 2010 (UTC)

Arbitrary limit
Limit to a certain number of people, selected at the editor's discretion.


 * Oppose. I do not see how one would determine who is more and who is less notable to be included. That would be OR, and there are few to none sources with such info. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)
 * Weak support. There may be interviews with the lead designer, where he identifies two or three individuals as the co-designers. This does not have to do with notability, but with who actually was part of the design team. (I am editing Sid Meier's Alpha Centauri, where there are RS interviews with the lead designer.) Vyeh (talk) 20:14, 9 September 2010 (UTC)
 * Oppose. Impossible to determine who did what for the overwhelming majority of games. Prime Blue (talk) 01:55, 11 September 2010 (UTC)

Limit to notable
Only include notable people (with articles) or if they are particularly mentioned in regards to the game. (This seems to be the current consensus, though it is barely being enforced in most articles)


 * Weak support oppose. Notable people may not have been in a key role for the game. This may have been a minor role for someone who only later became notable. Similarly, someone can become known only for 1 game, but not have article per BLP WP:1EVENT. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)
 * Weak oppose. There is a real problem when notable people are listed in the credits, e.g. Sid Meier, and a non-notable person, e.g. Timothy Train in the sequel to Sid Meier's Alpha Centauri, Sid Meier's Alien Crossfire, is the actual lead designer. Vyeh (talk) 20:14, 9 September 2010 (UTC)
 * Oppose. Notability cannot limit the inclusion of people in the infobox. Prime Blue (talk) 01:41, 11 September 2010 (UTC)
 * I agree to that, not sure why I put that as support. Notability should not relate to inclusion criteria for credits. — HELL KNOWZ  ▎TALK 09:50, 11 September 2010 (UTC)

Limit to lead people
Limit to (1/2) key (lead role) people that can be clearly identified as being the key role - "lead programmer", "lead artist", etc.
 * I renamed "key people" to "lead people" for clarity after Prime Blue's comment. — HELL KNOWZ  ▎TALK 09:45, 11 September 2010 (UTC)


 * Support. And if the key role cannot be identified, then don't list. Any "hard to define" roles can be discussed in prose, if they are significant. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)
 * Support. Changing the role descriptions to add "lead" (lead programmer, lead designer, lead artist, lead composer, etc.) would make it clear to both readers and editors what belongs in this field. Vyeh (talk) 20:14, 9 September 2010 (UTC)
 * Oppose. Directly ties in with two other points: Impossible to determine who did what for the overwhelming majority of games, and two to three people are more the rule than the exception. We are limiting the field to the key people anyway, but regulating people to a set number that can only be used in a small fraction of articles is useless as a guideline. Prime Blue (talk) 02:05, 11 September 2010 (UTC)
 * Game credits usually list lead roles. There are few cases with more than 2 lead roles as credited. If such cannot be identified, then there is no necessity to fill in the field. It is the "lead roles" that can be reliably verified most of the time. I understand that there will be exceptions, but there always are. — HELL KNOWZ  ▎TALK 09:45, 11 September 2010 (UTC)
 * We have RSes that list lead roles therefore we can detemrine for a majority of games who is the lead for many of those roles. 陣 内 Jinnai 18:15, 19 September 2010 (UTC)
 * support - it is generally easy to find the lead roles for most games because like almost everything else, game companies want someone to be in charge so there is a basic direction. Ocasionally there are 2 or even more rarely more leads for one section, but those are the exceptions. For some we cannot determine who was the lead and in those cases we don't have any way to determine a lead person, we don't add them. 陣 内 Jinnai 18:15, 19 September 2010 (UTC)

Limit to 1 person
Limit to one person in the key role. If there are several key (lead role) people, the don't list them.


 * Weak oppose. This would enforce smaller and cleaner infoboxes, but there are games where two or three people significantly collaborated. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)
 * Weak oppose. Although we could note an exception for cases where there are two co-equal leads. Vyeh (talk) 20:14, 9 September 2010 (UTC)
 * Oppose. Two to three people are more the rule than the exception. Prime Blue (talk) 01:44, 11 September 2010 (UTC)
 * Strong oppose - this goes against creative team aspect which would have problems with series like Dragon Quest. 陣 内 Jinnai 18:06, 19 September 2010 (UTC)

Do not list roles
Do not list any roles associated with the game.


 * Oppose. These are fields that can provide essential info; for some games these are particularly important where a person was a huge influence. — HELL KNOWZ  ▎TALK 22:29, 5 September 2010 (UTC)
 * Weak support. The infobox should not attempt to replace the article or even list every essential information. Where a person is particularly important, that person can be mentioned in the lead. Vyeh (talk) 20:14, 9 September 2010 (UTC)
 * I am not sure what this is supposed to mean. If it says "no people in the infobox", then of course an oppose. Unlike the lead section (disregarding alternate names), infoboxes are not solely a summary of the article and can contain information not included in the prose (extended release dates, for example). If something is known about the development process of the game, the people are mentioned in the development sections additionally. Prime Blue (talk) 01:53, 11 September 2010 (UTC)
 * Yes, it meant "no people in infobox". This is merely to cover the whole spectrum of possible opinions, as I did not wish to bias this discussion too much. — HELL KNOWZ  ▎TALK 10:00, 11 September 2010 (UTC)
 * Strong oppose - key staff members are considered essential info to understanding the work. 陣 内 Jinnai 18:07, 19 September 2010 (UTC)

Discussion
That above being said, I think the current limitation already prevents people from going insane: "The fields for director, producer, designer, programmer, artist, writer, and composer should be used to list people who played key roles in the development of a game. However, their inclusion should be carefully measured not to make the infobox overly long."

Super Smash Bros. Brawl has almost 40 composers, no question, they are not listed. Fragile Dreams has some 20 writers, no question, they are not listed. Ocarina of Time could be considered the maximum people-wise, and it's still somewhat unintrusive. The credit fields are hardly ever the reason that make the infoboxes explode: It's mostly publishers, release dates, and ratings that do. But now that we use collapsible lists for the fields that would get too long, and now that we forbade development tasks in the credit fields, the infoboxes are actually very clean, easy to read and helpful. I very much like the current formats.

And that said, I think the system requirements are the most pressing unresolved issue now. Prime Blue (talk) 02:28, 11 September 2010 (UTC)
 * You are welcome to make a section for System reqs (release dates, etc.); it was merely my opinion that role fields are more pressing at the moment.


 * I believe following this discussion we can at least further extend that guideline and update the infobox template to represent that. Even if it will say "Do not judge inclusion by person's notability." or similar.


 * Also "list people who played key roles in the development of a game" is probably the best guide there currently is, and I agree with it. I think this is what "Limit to lead people" was meant to say. I know some games will have 4 lead programmers, because they felt like saying so. These will be the inevitable exceptions, that will have to be dealt on case-by-case basis. — HELL KNOWZ  ▎TALK 10:00, 11 September 2010 (UTC)
 * We have a system requirements section already, there just is no more discussion going on (which probably implies someone should go bold on it and add the proposal)...
 * I just think the current explanations for the credit fields are sufficient to prevent over-inclusion – and if no notability restriction is mentioned, then people won't assume there is one. Ergo, no need to say "no notability restriction" as it is already governed by the other guidelines mentioned in my post from July (the situation basically mirrors that one here). The problem with that "lead..." or "...director" limit is that it still does not tell us anything about what an individual so identified was responsible for. A "lead programmer" would imply the most significant programmer, but it still does not tell us how much of the game he did program – take Metroid: Other M: Taiyo Aramaki was the "engineering lead", but with 17 other engineers, that does not confirm whether he did the most or just led the team. I find it is better not to use the field in such a case. I don't expect any edit wars about the credit fields either, so keeping the current liberties and letting people discuss in case of disagreements seems to be the best way.
 * Asking the other way around: Is there an example of an infobox you find particularly messy that could not be cleaned up with the current guidelines? Prime Blue (talk) 13:11, 11 September 2010 (UTC)
 * "lead..." or "...director" are the industry definitions. There is usually a reliable source, secondary or primary that identifies these people. We can use that, we can reference that. How many games have developer interviews that mention individual people contributions or their direct responsibilities? Very few. If we place names based on what their contribution/responsibilities are, it will become increasingly OR without proper sourcing. At the end of the day, infobox doesn't care if he lead the team or did 95% of programming, he was credited as "lead" and so he is. Blunt, perhaps, but this is what prose is for.
 * Also people assume the most strange things unless explicitly told not to. I've seen 10 people listed in two small font columns in the roles fields, and the editor most likely thought they all deserve an equal place in the field. Guidelines are to remove such assumptions and show the most acceptable solution per previous discussion. — HELL KNOWZ  ▎TALK 13:53, 11 September 2010 (UTC)
 * Again, is there an infobox that can not be cleaned up with the current guidelines and would thus call for an elaboration? Prime Blue (talk) 14:59, 11 September 2010 (UTC)

Initial discussion
As per past discussion, the licensing field was removed due to misuse. With that said, however, I could not disagree more with the outcome of the aforementioned discussion. With major developers like ID Software releasing entire sets of games (e.g., Castle Wolfenstein, Wolfenstein: Enemy Territory, and Return to Castle Wolfenstein) under the GPL, it is apparent that we do need this parameter to exist in our template--and we need it more than ever. And if misuse is such of a grave problem, then we can consider alternatives such as a numerical input format. —  C M B J  09:15, 24 September 2010 (UTC)


 * I support this field only with preset values, i.e., enumerated options. — HELL KNOWZ  ▎TALK 10:59, 24 September 2010 (UTC)


 * I would support it with broad, preset values such as we used with the  field. Broad ones would be something like: Freeware, Shareware, Commerical, Adware, Crippleware, Open source. These are terms most readers can recognize and are not loaded terms like Abandonware. 陣  内 Jinnai 15:23, 24 September 2010 (UTC)


 * At a minimum, we need to have options for the types that we have freestanding articles on:


 * 01 = Adware
 * 02 = Beerware
 * 03 = Freeware
 * 04 = Open source
 * 05 = Proprietary
 * 06 = Public domain
 * 07 = Shareware
 * 08 = Postcardware
 * Abandonware
 * Bundled
 * Commercial
 * Freely redistributable software
 * Pre-installed
 * Registerware
 * Donationware
 * Free software
 * Nagware
 * Scareware
 * Plus, I'd seriously like to see at least seven of the most popular open source licenses available as an option:
 * 09 = GNU General Public License
 * 10 = GNU Lesser General Public License
 * 11 = BSD License
 * 12 = Mozilla Public License
 * 13 = MIT License
 * 14 = Apache License
 * 15 = Creative Commons license
 * Abandonware is probably the only one of contention, which can be discussed separately from my general proposal. —  C M B J   18:26, 24 September 2010 (UTC)
 * Again we don't need all of those. FE: Abandonmware is still commeial. Just because a company has (theoretically) abandoned it doesn't mean its not a commerical product. Using such words has WP:NPOV violation issues as its a non-neutral term. That's why, in part, the field was removed.
 * Others like Reigsterware can be lumped in with Propriatary or commerical since that's what it essentially its.
 * Others like beerware, postcardware, etc. are essentially a freeware program with the fee being something that isn't monetary.
 * The mechanism to enforce the rights doesn't matter. This is meant to be a broad-usage category that the reader can understand.
 * This also is not a software in general, but video games. Scareware thus is not needed.
 * Finally pre-installed and bundled is not a license of any type, even unofficial term for such. Pre-installe is a catch-all term for any software that is well, pre-installed be it an commerical, proprietary, a shareware version of a software, a crippleware version, etc. Bundled just means the software is distributed together in some manner.
 * EDIT: Also people were essentially giving very specific licenses that only varied a little from another type which if someone doesn't know the intricacies of licensing law just makes the infobox which is suppose to be a snapshot of essential info made easy and understandble for the reader not so easy and understandable. Specific types of variations on licenses like those you describe in the 2nd section (and some in the first) are better left for prose. 陣 内 Jinnai 22:40, 24 September 2010 (UTC)
 * I'm willing to concede on terms that violate WP:NPOV or WP:MOS. But there are creative ways to script around that without limiting functionality. —  C M B J   09:10, 25 September 2010 (UTC)


 * I'm not an expert on licensing, but I can't see why infobox would need more than "Freeware", "Free", "Open-source", "Shareware", and "Commercial". Everything else is just a variation of this. The exact specifics are for prose if this is truly important. If the license in not important to be discussed in prose with sourcing, then I cannot see a real need to have it in infobox. A general reader should not ponder over 10 variations of the same thing. — HELL KNOWZ  ▎TALK 01:42, 25 September 2010 (UTC)
 * Not everyone agrees on a single definition of "open source". Some companies have started to (ab)use the term as a buzzword that bears little if any resemblance to the definitions set forth by the FSF, OSI, or copyleft community as a whole. Regardless, the fact that we're even discussing an exclusive approach makes me very skeptical of even supporting a numerical input method of any kind, because PC games are, after all, software. The comparable Template:Infobox software, which is much more widely used than this template, appears to accommodate all licensing parameters without controversy -- and there has been no demonstrated rationale for a double standard here. —  C M B J   05:20, 25 September 2010 (UTC)
 * On the other hand there's been no compelling rational to reinstate it either. I still contend that its best left in the prose if it's going to end up being a free-for-all with a bunch of licensing jargon being used here which goes against WP:MOS. 陣 内 Jinnai 05:57, 25 September 2010 (UTC)
 * I consider the status quo to be a compelling rationale in this case. Template:Infobox software has contained a licensing parameter for at least five years now. And though it can be argued that the parameter has potential for misuse, it has clearly not stopped either of the two featured class software articles (OpenBSD, Opera) from achieving such status.


 * Subjectively, as a reader, I favor inclusion of the licensing parameter because I rely heavily on it when evaluating software titles. I would argue that, to me, its informational value has historically been rivaled only by the 'platform', 'image', 'released', 'engine', and 'latest_release_date' parameters. Moreover, as an editor, my instinctual reaction was to consider replacing with  as a workaround in Wolfenstein: Enemy Territory. Honestly, in my opinion, an editor should never face such a dilemma when dealing with a mainstream template.  —  C M B J   09:29, 25 September 2010 (UTC)


 * There are always companies misusing and mislabelling something. It is nevertheless quite easy to determine what type of software they are actually producing (is it free, with shared codebase, paid, limited before paid?). If their official ads/infos disagree, this can footnoted and described in prose. If editors feel strongly about having more field values, then we can discuss individual ones. I just do not see how "licenses" like Beerware merit their own categorization. — HELL KNOWZ  ▎TALK 11:51, 25 September 2010 (UTC)

It basically boils down to this:
 * 1) Is it free?
 * 2) Can I modify it and distribute those modifications without needing to compensate someone else?
 * 3) If its free, is it supported by adds and there is no upgrade to remove them? or is the intention of the game to market a product?
 * 4) If its free, was it created by an organization that cannot hold any kind of license or copyright, such as the US government?
 * 5) If it isn't free, is there a distributable form I can use it with some restrictions (disabled features, nagging screens, adds, limited timeframe)?
 * 6) If it isn't free, then its commercial. This does not include demos or scripting that do not change the game's code.

This leads to basically one of only a few relevant choices:
 * Freeware
 * Open Source
 * Adware
 * Shareware
 * Commercial
 * Public Domain

Shareware is a catch-all term that describes pretty much any type of software that is freely distributable with some kind of catch to it. In fact several of those articles it mention that the type of distribution method is basically a version of shareware.

Adware is meant to be only for products whereby the financial support is through the ads, but having a way to remove them by paying would make it shareware as the author(s) of the game get money from people registering, not the adds, as their primary means.

Donationware and other optional payment ones are essentially one of the freely distributable ones as it is implied that freely distributable software relies on donations whether its open source or freeware. Only public domain differs here. 陣 内 Jinnai 21:35, 25 September 2010 (UTC)


 * After closely examining H3llkn0wz's data, it seems that we've all been debating over straw men here. Out of 15754 video game articles, we've only got one single article about a game licensed as 'donationware', and we do not even have an article about a video game licensed as 'beerware' or 'postcardware'. Moreover, even when considering all potential policy violations, only about 5% of the 332 surveyed articles could be considered erroneous or problematic. Though I had already typed up a fairly complex table to propose for a whitelist here, I'm left begging the question of why we need a new layer of bureaucracy to deal with such an empirically insignificant problem. —  C M B J   22:35, 25 September 2010 (UTC)


 * It has the hallmarks that the  field had. People putting down different words to represent the same thing with no real form of consistency and at times without any knowledge of what the license really is. In addition a few have issues with being too technical which is better explained in the prose. The reason for restricting via syntax to certain displays is the same, if we were to re-implement it, for modes. 陣  内 Jinnai 22:31, 25 September 2010 (UTC)


 * I am unsure what correlation is there between a white-list and the 5% problematic articles? To address straw men fallacy &mdash; I'm personally opposed to a license field with freely selectable values. I support the inclusion of the field if it is set to allow one of the most used and informative values (hence the table below). The problematic articles can omit the field and discuss the problems in prose. — HELL KNOWZ  ▎TALK 22:37, 25 September 2010 (UTC)


 * See below. —  C M B J   23:29, 25 September 2010 (UTC)

Statistics
Out of 15754 articles with infoboxes, 332 (2.1%) have non-empty license field:

— HELL KNOWZ  ▎TALK 14:57, 25 September 2010 (UTC)

Out of 7544 software infobox articles, 4545 (60%) have a non-empty license field:

— HELL KNOWZ  ▎TALK 22:49, 25 September 2010 (UTC)

Discussion after statistics

 * Try running that same search again on all articles with .  —  C M B J   18:40, 25 September 2010 (UTC)


 * Doesn't matter WP:OTHERSTUFFEXISTS isn't a reason we need it. Neither WP:IBX nor any policy requires or even suggests its necessary. It is just what the community considers essential information. Consensus here was that it wasn't because it was rarely being used and the cases it was were generally being used improperly in that they did not conform to the other guidelines/policies. 陣 内 Jinnai 20:44, 25 September 2010 (UTC)
 * This is not a WP:OTHERSTUFFEXISTS argument. Video games are software, and it can be observed that many of them actually use . At a glance through Category:Free, open source video games, I was able to find sixteen: WorldForge, UFO: Alien Invasion, Tux, of Math Command, Solipsis, Slingshot (video game), Simutrans, RoboWar, robotfindskitten, Chess (application), ChessV, Eboard (chess), GlChess, GNU Chess, Thief (chess), XBoard, and BZFlag.  —  C M B J   21:10, 25 September 2010 (UTC)
 * 2% of the video game articles is hardly a lot. 陣 内 Jinnai 21:13, 25 September 2010 (UTC)
 * 2.1% does not include any of the sixteen examples I just listed, nor does it include PokerTH, Liquid War, GNU Go, Gnomine, gbrainy, or FlightGear. Regardless, even if it were 2.1%, that would still be a very substantial number, because the real world ratio of proprietary software is almost equally disproportionate. —  C M B J   21:34, 25 September 2010 (UTC)
 * Just a note that Infobox software has far fewer fields than Infobox video game has/used to have. Many users don't bother with the licensing info. I'll run a bot on the software infobox for comparison, though I have to agree it borders on OTHERSTUFF. Besides, I (and Jinnai) actually support the fields addition should it be limited to preset values. The license field statistic I ran was to show which values are the most reasonable for inclusion. — HELL KNOWZ  ▎TALK 22:25, 25 September 2010 (UTC)

DRM?
Shouldn't games have some information on the digital restrictions management in use? I saw a game for sale on steam but was trying to figure out what SecuRom 4 machine activation limit actually means. I know the Xbox360 version doesn't have that garbage, but the pc version has issues worth noting in this article. Shouldn't this be in the video game template? Several game websites list this kind of information - it seems like wikipedia is lacking in this repect. Teque5 (talk) 06:12, 22 October 2010 (UTC)

Edit request
Can the be moved down to the bottom of the template text? If, and a  is on the page, as well, it puts a carriage return at the top of the article, leaving a blank space.— Ryūlóng  ( 竜龙 ) 21:38, 17 November 2010 (UTC)
 * Think this has already been done. &mdash; Martin (MSGJ · talk) 13:32, 18 November 2010 (UTC)

Broken?
There seems to be a typo or something broken in the template, as there is always some extra space at the bottom of the last row used. See the example -->

Megata Sanshiro (talk) 12:05, 19 November 2010 (UTC)
 * Related to above. Hopefully fixed now? &mdash; Martin (MSGJ · talk) 13:07, 19 November 2010 (UTC)
 * It appears fixed. Thanks MSGJ, I didn't see the talkpage note about the issue until today. Der Wohltemperierte Fuchs ( talk ) 15:17, 19 November 2010 (UTC)

RfC: Should contributors be permitted to manually specify licenses in an infobox under some circumstances?

 * Proponent contends that a user-defined license parameter is an indispensable tool which, according to statistics, has presented a negligible maintenance liability to the project and would be even more manageable under current proposals. —  C M B J
 * Opponent contends that a user-defined license parameter is nonessential and an unjustifiable burden because of a problematic history including the use of technical terms, superfluous exhibition, and other general misuse. 陣  内 Jinnai

Relevant information:
 * 1) Consensus to remove license parameter
 * 2) Initial proposal to reinstate license parameter
 * 3) Bot-generated statistics on use/misuse of the license parameter in both Template:Infobox video game and Template:Infobox software
 * 4) Continued discussion
 * 5) Second proposal to reinstate license parameter
 * 6) Third proposal to reinstate license parameter

Should contributors be permitted to manually specify licenses in an infobox under some circumstances? —  C M B J  22:36, 22 November 2010 (UTC)

License parameter
Can we added it? It is useful for free games as Hedgewars. Regards. emijrp (talk) 19:40, 25 November 2010 (UTC)
 * See the above discussion and accompanying RfC. — HELL KNOWZ  ▎TALK 20:02, 25 November 2010 (UTC)

Italics
Since Template:Infobox has now been changed so that it allows italics, could someone change the code to reflect this please rather than using Italic title infobox (similar to how its been implemented at Infobox book, Infobox album, Infobox newspaper, Infobox play etc etc.)? Mhiji (talk) 23:34, 29 November 2010 (UTC)
 * Sorry. Just realised this template doesn't use Template:Infobox. Could someone convert it to an infobox first and then do this please?! Mhiji (talk) 06:27, 30 November 2010 (UTC)

Not done: You'll have to code this in the /sandbox first (I notice someone has started it) and then get consensus for the change. And it might be worth checking the talk archives in case this has been discussed before. &mdash; Martin (MSGJ · talk) 09:51, 30 November 2010 (UTC)

When did the infobox get this wide? How to change that
Everywhere this template is used, it takes up far too much of the article. It wasn't always this wide. It takes up 50% of the top of the articles its in. Can we reduce it back to its original size? Even if you reduce the size of the image in it, its still that big. Compared to what it was previously.  D r e a m Focus  06:33, 5 December 2010 (UTC)
 * Both look the same width here. Could be a browser issue. --M ASEM  (t) 06:37, 5 December 2010 (UTC)
 * Firefox 3.6.3 is what I'm using. People complain about it loading up badly for them as well, and are trying to eliminate the infobox altogether because of it.  Wikipedia itself must've changed something that is causing this problem, since the same article imported to the wikia still works fine.   D r e a m Focus  06:43, 5 December 2010 (UTC)
 * I also see no difference, im also using Firefox but version 3.6.12. Salavat (talk) 07:20, 5 December 2010 (UTC)
 * I updated to the newest version, which is 3.6.12, and still have the problem. Using Windows Vista, although no idea why that would matter.  Some see the problem, others don't.  That is weird.   D r e a m Focus  08:41, 5 December 2010 (UTC)
 * I can only speculate it may have to do with the fundraising banner, but that's not an assurance. --M ASEM  (t) 15:01, 5 December 2010 (UTC)
 * I checked the box in "my preferences" under "browser gadgets" to "Suppress display of the fundraiser banner". Reload the page, still the same problem. I continued the discussion at the help desk since someone there might know, and it does affect all infoboxes not just this one.   D r e a m Focus  15:10, 5 December 2010 (UTC)
 * It may be because you accidently zoomed in text. 陣 内 Jinnai 18:28, 5 December 2010 (UTC)
 * Thanks! That solved the problem.  In Firefox I click the View tab, then Zoom, then Reset, and its all better now.  I'll tell the others.   D r e a m Focus  21:35, 5 December 2010 (UTC)

is it acceptable to have the infobox not load up at all?

 * Need more opinions at a game article page that involves this template. Some want to make it so that just the image shows up and not any of the infobox text for the first infobox, and then nothing at all for the second infobox for the expansion pack farther down into the article.  Just a collapsed state and you have to click "show" to see it.  Please click both edits to see.  Since the experts about this box are on this talk page, I assume, does any article out there that uses it do this?  Doesn't it defeat the purpose of having an infobox entirely?  Is this a good place to ask for a third opinion about this, since it is concerning this template?    D r e a m Focus  15:19, 5 December 2010 (UTC)
 * The main infobox at the top of the article should never be collapsed completely per WP:ACCESS, though individual fields within it can be (see the documentation for the exact fields). The second box further down is debatable, though if there is enough space in the article, I see no reason to collapse it. It's all about weighing up WP:ACCESS against formatting. Prime Blue (talk) 17:00, 5 December 2010 (UTC)
 * We have never wanted to completely collapse the main infobox - just the text in it. This box would be okay to have fully expanded. But in the case of the second i-box, it pushes other material (a box on the games reception) almost completely out of the reception section. That one needs to be collapsed.  Nolelover  It's football season!  18:24, 6 December 2010 (UTC)
 * You're not really allowed to collapse much. You can collapse long lists of production staff or releases, but the other info would have ACCESS violations. You may have to move your image to the left rather than right. Looking at the article, you can collapse all but the first release date. 陣 内 Jinnai 18:33, 6 December 2010 (UTC)
 * I assume you are talking about the first infobox, in the lead?  Nolelover  It's football season!  18:40, 6 December 2010 (UTC)
 * I don't see where WP:ACCESS says the infobox can not be collapsed (or if it is considered collapsed if the image is shown). Could someone point me to the section of WP:ACCESS where infoboxes are discussed? WP:ACCESS specifically says infoboxes are optional. Vyeh (talk) 19:02, 6 December 2010 (UTC)
 * See the section "Users with limited CSS/JavaScript support". --M ASEM  (t) 19:05, 6 December 2010 (UTC)
 * Thank you. It looks like infobox content that is mentioned elsewhere in the article can be collapsed as the intent is not to deny article content to people with limited CSS/JavaScript support, but it is recognized that their experience will be inferior. Vyeh (talk) 02:56, 7 December 2010 (UTC)


 * I think I fixed the problem with alignment using Wikipedia code to make things work out properly, so please look at the article now and discuss it on the talk page there.  D r e a m Focus  19:14, 6 December 2010 (UTC)
 * Looks fine, but that second infobox needs to be merged with the first one per WP:LAYOUT. 陣 内 Jinnai 19:27, 6 December 2010 (UTC)

Two infoboxes are certainly not forbidden, but in this concrete case, I'm almost leaning towards merging them as well: The only different fields are designer, version and release date. At the expense of the version field (and under the condition that the designer situation is explained in the article), a single infobox with the current formats employed would look like that. Prime Blue (talk) 19:57, 6 December 2010 (UTC)
 * Vyeh, I say we just go ahead and merge the infoboxes...now! Anything, and I do mean anything, looks better then this!  Nolelover  It's football season!  21:02, 6 December 2010 (UTC)
 * I'm in favor of implementing Prime Blue's suggestion. Vyeh (talk) 02:56, 7 December 2010 (UTC)

Another push for license field
Having reread this a couple times, I fear the current table will not get consensus as too many different highly specific licenses are involved even with all the best faith by CMBJ. However, we can mostly agree that restricted usage is acceptable. So I re-propose to firstly instate the "basic design" for the field and then discuss further expansion (i.e. freelicense) if we wish. I deliberately did not list categories yet (and that is a great idea that encourages this proposal) in order to finish the main proposal &mdash; to have pre-defined field values. So one step at a time.

Amendments welcome.


 * Support this field design idea as before. This will completely remove all the license cruft and force users to select real, correct licenses. This can then further be applied to categorize the games. In future, the available field values can be expanded/modified when such consensus is reached. I believe the above selection addresses nominator's and supporters' desire to include the license field as well as preserve simple and non-specialist approach applicable to almost all games. For exceptions, there is also the custom input field. As mentioned above, a bot can in future check what values are most used/desired and we can adjust the field accordingly. — HELL KNOWZ  ▎TALK 22:55, 19 November 2010 (UTC)
 * Support - I have taken you up on your offer to amend the proposal by (1) clarifying the descriptions of the "open-source" and "free software" parameters in a more user-friendly way, and (2) reincorporating the automatic categorization model which should be very helpful to readers and editors alike. You can re-remove the categories if they're a deal breaker for you, but if categorical redundancy is the primary concern, we may just as well implement a genre1=, genre2=, genre3= series and integrate the two while we're at it. —  C M B J   10:38, 20 November 2010 (UTC)
 * I support adding auto-categorization, but just one step at a time to get a move on this. I would also support genre sorting by several fields and automatic categorisation as well, in a separate discussion. — HELL KNOWZ  ▎TALK 11:14, 20 November 2010 (UTC)
 * We can separate auto-categorization from this proposal if you really want, but I do not foresee there being much objection to such an uncontroversial win-win. On a side note, I have re-amended the proposal to preclude use of non-neutral terms, as well as to include public domain as per Jinnai. —  C M B J   23:15, 21 November 2010 (UTC)
 * Oppose-I think adding one for public domain should be done as that is a possibility of a well...non-license license. However, that part isn't really a major concern of mine as there aren't too many at this time.
 * I do not want to add the custom support it because of the custom field. It will be abused in the same way the current field is being abused and solve absolutely nothing for why we removed the field. People will simply use that to slap a specific license on their that's very technical and doesn't help the understanding of the item to the average Wikipedian reader. I want to make it clear I'm not against a notation of having another unusual license, just not one in the lead because people will essentially put stuff like beerware instead of shareware which is what it should be as beerware is simply a minor subset of shareware. 陣 内 Jinnai 17:15, 20 November 2010 (UTC)
 * What if there was no custom entry field? I suppose any "special" licenses can be discussed in prose? — HELL KNOWZ  ▎TALK 17:29, 20 November 2010 (UTC)
 * My support is dependent on having a custom field, and Jinnai's opposition, though well intended, is a perfect example of why. He has not satisfactorily demonstrated why a bot cannot mitigate misuse that stands to affect only 1-5% of the relevant article base. His specific example of Beerware is not and never was anywhere close to being a statistically significant problem. There is absolutely no known empirical evidence whatsoever that misuse of the parameter in this form could result in any more than ten to twenty minutes cleanup work annually. Yet, despite all of this, an outside editor must still fight an uphill battle for months on end in order to gain support for something that is widely accepted elsewhere on the project—that's precisely the kind of intrinsically bureaucratic process that compelled me to take my position in the first place. And honestly, if we cannot even agree on the validity of existing statistical analysis, then I think that there's little remaining opportunity for us to reconcile our respective viewpoints. I will go ahead and try to initiate an RfC tomorrow, assuming that Jinnai and I reach an agreement on the terms. —  C M B J   08:31, 21 November 2010 (UTC)


 * Oppose: Still suggested to be used for commercial games. Prime Blue (talk) 17:37, 20 November 2010 (UTC)
 * That could be done by simply having in instructions that leaving this blank means that the license for all works is proprietary commercial or the same as those already listed similar to how we don't list modes for games where the mode for all games is the same. 陣 内 Jinnai 23:14, 21 November 2010 (UTC)

Can we figure out some way to move forward with a licensing parameter? The accompanying RfC does not appear that it will ever materialize at this point. —  C M B J  23:24, 14 December 2010 (UTC)

Moving forward with the 'game engine' parameter: revised proposal
Moving forward with H3llkn0wz's willingness to reach a compromise, I propose that the above be added to the template. Automatic categorization is also a real possibility, but seeing as the extensive number of game engines may require a fair bit of code, I'll leave this for a future discussion. —  C M B J  10:46, 20 November 2010 (UTC)


 * Support as nominator. —  C M B J   23:07, 20 November 2010 (UTC)
 * Moving from neutral to Support in this format. Only engines with an article, that can further the game's understanding by clicking on the wikilink. I can see how this is useful, as opposed to listing unknown, non-notable engines that do nothing informative for the reader. As a side note, there would be far too few members in each engine category to warrant auto-categorisation. We can, again, use a bot to scan for non-compliant field values. — HELL KNOWZ  ▎TALK 11:25, 20 November 2010 (UTC)
 * Support. I'm surprised there's no "Game Engine" parameter yet (I would have it output "Engine" instead). It would link all the Unreal Engine, id Tech and RAGE game pages nicely. However, here's a borderline case for that "full independant page" requirement. Carmageddon and a few other games use the Blazing Renderer engine, yet it is a pitiful paragraph on the developers page. It doesn't look likely for expansion. Should that be ignored, or linked to anyway? JaffaCakeLover (talk) 12:28, 24 November 2010 (UTC)
 * I would ignore that, since it's not a stand-alone article. There's not much info one can learn from that. — HELL KNOWZ  ▎TALK 12:39, 24 November 2010 (UTC)
 * You can learn what engine it used. If a new game is notable enough to have an article, sometimes it company isn't yet, but we still list its publishers.  Same way with the designers being listed.  Any engine that a notable game is made with should be notable enough to have its own article anyway.  Only linking to some and not others is rather bias.   D r e a m Focus  06:38, 5 December 2010 (UTC)


 * Support - I wasn't active when the removal of this parameter was discussed in archive 9, but the engine is an important defining factor of a game. - hahnch e n 11:09, 2 December 2010 (UTC)
 * Support adding this parameter back into the infobox, but not limiting who is listed, for reasons I stated above.  D r e a m Focus  06:38, 5 December 2010 (UTC)

As per this discussion - please re-add the engine parameter. A partial revert of this edit. - hahnch e n 20:33, 13 December 2010 (UTC)
 * ✅ Ron h jones (Talk) 20:43, 13 December 2010 (UTC)
 * Looks like the instructions still need to be updated. —  C M B J   22:52, 21 December 2010 (UTC)

Deperecate the Version Field
The most recent version number of any software is a piece of highly dynamic unpredictably time sensitive information, I don't think it's something that should be generally included. Can the version field be deprecated or removed completely? --Pyroguy (talk) 08:44, 7 December 2010 (UTC)
 * The last time it was discussed, we had a weak remove and a weak keep. I can't say I'd care much if it was removed. Prime Blue (talk) 13:34, 7 December 2010 (UTC)
 * I've personally found the version information to be a useful aid when patching games. In some cases, the information is vital: developers may go out of business or otherwise wholly cease supporting a multiplayer game that still needs the final version for productive matchmaking on GameRanger or GameSpy. Strangely enough, I don't recall ever encountering inaccurate information, either, though I'd imagine it is a reasonable cause for concern. —  C M B J   05:36, 9 December 2010 (UTC)
 * Remember that we're serving the non-gamer reader here. A version number, while certainly useful to a gamer that is trying to patch things, has very little value to anyone else.  In the case you described, it's better to go to fileplanet or other game download site and look to see what patches are there, than to rely on WP for that. --M ASEM  (t) 23:42, 13 December 2010 (UTC)
 * The latest version field does seem like info creeping. While it may be "useful" information, it isn't defining of the subject. This is information that one should get from a game wiki. It also gets frequently abused by modders (or fans of mods) attempting to change the canonical version number to a mod version. Ham Pastrami (talk) 07:46, 14 December 2010 (UTC)
 * In its favour, it's a good way for the reader to quickly see whether a title is still a going concern with its developers, or how long it was "supported" for.  Mi re ma re   18:56, 14 December 2010 (UTC)
 * I would say the version number marginally accounts for essential info you'd expect to find at a glance for PC games. 陣 内 Jinnai 03:51, 15 December 2010 (UTC)
 * I recognize its utility, but I still don't think it's any more essential than a dozen other things one could mention. When all of those things are put into the infobox, it becomes info creep, a bunch of little things that a few might, but most do not care about when seeking an encyclopedic overview. IMO the standard for this type of detail simply has to be set higher, especially when e.g. information like DRM is excluded (and that even has a context of importance outside the actual playing of the game). Ham Pastrami (talk) 02:01, 18 December 2010 (UTC)
 * The version field does define the subject, that's exactly what it does. I agree that the field is much more useful for describing ongoing software projects such as VLC media player, but even for games, it can be important - for example, Counter-Strike 1.6 is massively removed from Counter-Strike b6.0. - hahnch e n 22:41, 19 December 2010 (UTC)
 * But we don't have separate articles for CS 1.6 and CS b6.0 - they're one and the same. It's fine to discuss the differences within the article, but the reader (non-gamer) isn't going to care in the infobox. --M ASEM  (t) 22:48, 19 December 2010 (UTC)
 * If we had separate articles, then we wouldn't need the field. The Counter-Strike article isn't very good, but if it were to have a gameplay section, it would discuss 1.6 gameplay. The version field defines the subject, a non-techy may not care about it, in the same way a non-techy does not care about the browser version they are using - this doesn't make it unimportant. - hahnch e n 23:18, 19 December 2010 (UTC)
 * The field is also useful for mentioning game release cycle info, such as, alpha or beta, which may be significant, especially in Indie scene (e.g. Minecraft) or for games being constantly expanded/developed (e.g. WoW, OpenTTD). It is pointless to list minor revisions and such, but larger milestones is what the field should be used for. — HELL KNOWZ  ▎TALK 00:09, 5 January 2011 (UTC)

italic title
Shouldn't setting the "italic title" parameter to "no" also de-italicize the name of the game in the infobox (not just the page title)? Powers T 00:57, 14 January 2011 (UTC)
 * "Italic title" refers to the page title specifically. See Italic title. Do you need this de-italicizing for something specific? Reach Out to the Truth 21:48, 14 January 2011 (UTC)
 * Well I found a workaround, but it seems like the same semantics should apply. EverQuest Next is the article; since it's a code name, not an actual title, it shouldn't be italicized.  Powers T 03:45, 15 January 2011 (UTC)

Distribution field
The addition of the distribution field was made following a discussion on archive 9 arising from confusion over the media field. But in practice, as can be seen at Template:Infobox video game/doc, instead of superceding the media field, it's just used to indicate whether a game is distributed digitally or retail. This is utterly, utterly redundant. The platforms usually indicate if it is digitally distributed, and when it doesn't, the distribution is trivial. Do we indicate that albums are now available on digital? That films can be streamed? No, because it makes no difference - let's get rid of it. - hahnch e n 11:28, 2 December 2010 (UTC)
 * You mean the field labelled "Distribution" added here right? Not the "Distributor" one that sits below publisher. Gotta make it clear which of the two similarly named items is being talked about, one very important and the other not. If you're talking about the "distribution" field, then yeah, get rid of it. Is it even used anyway? -- Sabre (talk) 12:23, 2 December 2010 (UTC)
 * The original proposal was to limit the field to games where the distribution method is ambiguous (as we do with the media field if the media is ambiguous). Jinnai opposed, so the documentation currently dictates to use the distribution field in every video game article. And I have to say with more games using digital distribution, this is a good move – as it also makes sense for older platforms. While the media field becomes virtually redundant with the platform field as the media is a consequence of the console used, the distribution method is not as clear-cut and evident to people who are not familiar with the subject. Prime Blue (talk) 17:10, 2 December 2010 (UTC)
 * Why is the distribution method relevant at all? We can grab mp3s, stream movies, and download ebooks, yet I'm sure Wikiproject Literature would balk at a distribution field.  When everything goes digital, the media field will become redundant, but this doesn't make the distribution field relevant. - hahnch e n 21:06, 2 December 2010 (UTC)
 * The distribution field is relevant because there are platforms where the distribution method is not clear to the reader (e.g. Microsoft Windows) and because "download" cannot be used in the media field since it is not a type of digital media. I don't quite understand what you mean by the last sentence, though: The physical releases won't go away just because there are more and more digitally distributed games. Prime Blue (talk) 15:17, 3 December 2010 (UTC)
 * That a game is digital or retail is not relevant, it doesn't need a separate line on the infobox to define. If it is, just put "None (digital)" in the media field. - hahnch e n 16:25, 3 December 2010 (UTC)
 * What would you do for games with ambiguous media platforms that have received a digital release as well? "Cartridge, optical disc, none (digital)". Ew, no thanks. I'm still for limiting the distribution field to games released on platforms with an ambiguous distribution method (though this is something that should rather be discussed with Jinnai than with me), but I am strictly against the removal of the field. Prime Blue (talk) 17:17, 3 December 2010 (UTC)
 * Or you could get rid of it altogether, which is what I'm proposing. Or you could just put digital distribution into the media field, which we had been doing previously anyway, knowing that the reader will understand what it entails.  Knowing that I can buy a game in a shop is not useful. - hahnch e n 17:41, 3 December 2010 (UTC)
 * I am aware that you do not find the field to be "useful" or "relevant", but it does not solve the problem as I do not share your opinion. You did not answer my question either. Prime Blue (talk) 18:14, 3 December 2010 (UTC)
 * I did answer the question. Just do what we did before.  You need to justify this field. - hahnch e n 23:15, 3 December 2010 (UTC)

Well we could just get rid of it, but it does have some benifit. I would rather not have this for systems where distribution method is always the same, FE: PS2. However, some newer and some older systems, as well as computers, use different methods of distribution that aren't quite the same. A cart isn't the same as a disc and a floppy disc isn't the same as a cd/dvd and none of those are the same as download distribution. FE: new consoles have disc and download distribution methods. Older systems, like the NES have often had computer peristalsis and thus different methods of distribution. Finally, there is now the concept of cloud computing which is not the same any of the above methods. 陣 内 Jinnai 21:30, 3 December 2010 (UTC)
 * That's not what the distribution field is for though. It's not about a CD or floppy, that's clearly stated in the media field.  All "distribution" does is specify whether it can be downloaded - this is not a defining factor of a video game, given that anything can be downloaded.


 * Cloud computing is fairly crystal ball, unless you're talking about browser games, in which case the platform usually dictates it. I don't think whether a game is on OnLive deserves to be mentioned in the infobox at all, unless its an exclusive. - hahnch e n 23:15, 3 December 2010 (UTC)
 * I forgot we kept media field. I thought we were merging it into this.
 * With that said, there need only be 3 types listed here then:
 * Physical - default assumed when its the only type. If multiple types exist, then it should be listed.
 * Download - downloading the entire game.
 * Cloud - having none or little of the game on your computer and accessing the resources through a central hub, usually via the internet.
 * By definition, all MMOs are cloud games because much of resources they do not host on their own PC. They just host the textures and stuff like that. It's not nessasarily cloud computing like many think of it where nothing is kept on the computer, but cloud computing by definition doesn't require this therefore its not crystal balling. 陣 内 Jinnai 23:32, 3 December 2010 (UTC)

Different idea to prevent this from becoming a circular discussion: The distribution field contents do not fit the media field, but it works vice versa: Simply remove the media field and include its contents in the distribution field (replacing the "physical" option): New possible values would then be "floppy disk", "cartridge", "memory card", "optical disc", "download", and "cloud computing". Only use the field if the platforms leave this ambiguous (e.g. Microsoft Windows). Problem solved. Prime Blue (talk) 14:22, 4 December 2010 (UTC)
 * As I thought that happened already, something along those lines is fine. 陣 内 Jinnai 18:29, 5 December 2010 (UTC)

Edit request
No objections to the replacement of the media field by the distribution field despite a reasonable amount of views on this page. The sandbox was recently changed, so I'll just list the revision here. This line has to be removed:

Thank you, I'll handle the documentation. Prime Blue (talk) 10:52, 13 December 2010 (UTC)
 * This does not include the contents of the media field in the distribution field, as I think was discussed above. Please clarify, thanks. &mdash; Martin (MSGJ · talk) 14:42, 13 December 2010 (UTC)
 * See this edit. Hahnchen's case was to remove the distribution field as it does not supersede the media field. As the contents of the distribution field do not work in the media field but it fits vice-versa, the media field is now replaced entirely with the distribution field. Additionally, the field is restricted to articles where the platforms leaves the distribution method/media ambiguous. That course of action is also in line with the original discussion. Prime Blue (talk) 17:53, 13 December 2010 (UTC)
 * I've asked for more input at WT:VG. I'd be OK using the distribution field for everything, but instead of removing the media field, you should just make it point to the same thing. - hahnch e n 20:29, 13 December 2010 (UTC)
 * Removed edit request as there seems to be some room for discussion still. What do you mean by "point to the same thing"? Prime Blue (talk) 20:34, 13 December 2010 (UTC)

Can you explain why we shouldn't just revert back to the singular media field. I originally thought it referred specifically to storage media, but it seems to refer to the broad definition of digital media, which could encompass CDs as well as network delivery. - hahnch e n 00:39, 17 December 2010 (UTC)
 * Because "download" is not a type of media, "none (digital)" is a very clunky way of explaining it and all of the contents fit the distribution field without any problems. Prime Blue (talk) 09:44, 17 December 2010 (UTC)
 * It is a form of media. Not storage media, but it could be classified as the transmission medium, which is covered under digital media.  If you're using that relaxed definition of media, it easily covers everything the distribution field offers.  The distribution field actually leads to content delivery which almost exclusively used for digital distribution, and could lead to people filling in CDNs or services into the field.  The media field has been used for years on Wikipedia, and can (and has previously covered) downloads. - hahnch e n 21:52, 19 December 2010 (UTC)
 * The media field points to digital media. A download is not a type of digital media, no matter how you turn or twist it – and the article does not talk about digital distribution in any way. Additionally, your definition of content delivery is wrong: The term is not a synonym for digital distribution and the article clearly explains that it is instead "the delivery of media content", and it goes on to specifically mention the two types of content delivery: "Delivery of finished content for digital distribution" and "Delivery of the end product to the consumer". And your concerns over the usage of the distribution field are not valid: Everything will be explained in the infobox documentation as it already is and there are – let's face it – a lot more people who use the media field the wrong way by including intricate details like cartridge sizes and number of discs. But this is all irrelevant to this discussion. That said, I find that your stubbornness in opposing one field over the other is reaching hardly bearable levels, especially given the fact that I have already compromised to cut it back down to one field for all the field contents and to limit the articles the field is used on. Prime Blue (talk) 14:03, 20 December 2010 (UTC)
 * Let's roll back a bit. You suggested the distribution field, you had one support, from the entire video game space, and then implemented it - that's not a consensus, I'm trying to reverse that.  Above, you failed to even justify why you think the field is relevant.  Download could just be classed as a form of transmission medium as streaming media is.  And content delivery is synonymous with digital distribution.  In the real world, it's called supply chain management.  Try searching for "content delivery" on Google Books and see what you get. - hahnch e n 21:24, 20 December 2010 (UTC)
 * Agreed: even if you talk traditional media (newspaper, magazines, etc.) it's recognized that "online distribution" is a new media type. I would consider "online distribution" as the media term for downloadable titles as to diff from the possibly-confusing "digital distribution". --M ASEM  (t) 21:29, 20 December 2010 (UTC)

As I have said before, I am perfectly fine with removing one of the fields, grouping the contents into the remaining one and limiting it to articles where it is actually ambiguous – but all the contents have to fit the field. Neither "download" nor "cloud computing" (it was Jinnai who insisted on the latter, before someone comes complaining to me...) are types of media, especially not in the sense explained in the "Digital media" article (which refers exclusively to physical media). I'd be more open to the idea if you had reliable sources backing up that those two contents are in fact a type of media. Same goes for content delivery: Neither of the reliable books defines content delivery as a synonym of digital distribution – and you'll notice that the books turning up on Google Books are also based entirely on the online distribution aspect and not the traditional delivery of digital media. Though, if you still insist it is a synonym, I have nothing against removing the link to "Content delivery" either. The article is lackluster and, given that users will know what the field tries to convey by its contents, not much of a help anyway. Prime Blue (talk) 17:06, 21 December 2010 (UTC)
 * Well you could use the same argument and remove the link to digital media, yet carry on using the media field. Unlike your distribution field, it wouldn't mean having to revisit thousands of articles.  And if you don't accept that download as a form of media, then you don't accept streaming as a form of media. - hahnch e n 20:44, 23 December 2010 (UTC)
 * Again no, I have mentioned several times before that a few contents for the field are not a type of media, and no one has proven the opposite so far. Also, no matter which field is used, they have to be corrected without a bot as the current media fields in many articles mention details that are forbidden per the documentation (cartridge sizes, number of discs etc.). Prime Blue (talk) 16:28, 24 December 2010 (UTC)
 * The download itself is not the media, it defines the media, such as streaming media does. This is not difficult to understand.  The problem with "cartridge sizes" is tangential and not really an issue, going through articles systematically removing information is not going to improve the encyclopedia.  There has been absolutely no consensus for the inclusion of a separate distribution field, there has been more opposition to it. - hahnch e n 13:57, 29 December 2010 (UTC)
 * If "download" and "cloud computing" are not types of media, then including it in a field that lists types of media does not make any sense. You fail to justify cutting back to the media field if one field is to be removed. If you want all the current contents in a single field that is not called "Distribution", then make a suggestion for another fitting name. Prime Blue (talk) 15:15, 29 December 2010 (UTC)
 * It doesn't have to be a type of storage media to define what media is. Cloud computing is not used anywhere, and is not a "distribution". There is next to no support for your position.  There was no consensus for the addition of the distribution field.  The addition should not have been made. - hahnch e n 18:09, 2 January 2011 (UTC)
 * But this is exactly what the media field is used for: the type of storage media. If not cloud computing, digital distribution via a download is used in many articles, and a download is not a type of media – you have shown nothing so far that would imply the opposite, although I brought this problem up several times before and asked you to show evidence. The distribution field, as the template documentation clearly explains, is for the method of distribution – games are distributed via downloads, via cloud computing, on floppy disks, cartridges, memory cards, and optical discs. But download and cloud computing are not the types of media a game is distributed on, and that is what the media field is for. I have compromised a lot already, have explained my stance to you, given you a chance to explain yours, and asked you to bring up possible alternatives. All to no avail. The only reason you have brought up to cut back to the media field is the implementation of the fields, but as I explained before, they have to be corrected manually either way, no matter which field is used. Prime Blue (talk) 21:14, 2 January 2011 (UTC)
 * I think people are on different wavelengths. I know it seems I am with PB. I always thought media field meant media distribution in which case cloud and download are relevant. 陣 内 Jinnai 00:03, 5 January 2011 (UTC)

Edit request 2
Reversion of this edit. No consensus for original addition of field made in this request. Discussion near zero, opposition is voiced above. Edit should not have been made. - hahnch e n 18:26, 2 January 2011 (UTC)
 * I agree that cutting back to one field makes sense, but I do not think that it should be the media field, as I explained multiple times above. Thus, I don't understand how you feel an edit request is appropriate here when we are still determining what field should be used – especially since there is a vocal dissent here, which obviously was not the case the time the field was added or I requested the media field to be removed (just because you keep bringing the addition up as if it was done in bad faith). For now, I have requested a third opinion as it seems to be clear that we're not going to agree anytime soon. Prime Blue (talk) 21:14, 2 January 2011 (UTC)


 * Requesting a third opinion means there's no consensus, so ❌. I've taken the request out of the queue for the time being. When you've come to an agreement, let us know what you'd like done. :-)  K rakatoa    K atie   05:47, 3 January 2011 (UTC)
 * Understood. I originally put in the request to solicit a third opinion from an admin, but I guess that's not the right process. - hahnch e n 22:46, 4 January 2011 (UTC)

First of all, thank you for taking the time to provide an outside opinion! I think both "Media distribution" and "Distribution media" would again result in a problem of definition, but I'd be fine with "Media / distribution". That way, both terms could even stay linked to their current articles. What do you think, Hahnchen? Prime Blue (talk) 05:14, 8 January 2011 (UTC)
 * I'd be OK with that. It might take up two lines on the infobox though. - hahnch e n 22:19, 12 January 2011 (UTC)
 * Okay, this is what it would look like. Anybody got any objections? Prime Blue (talk) 15:12, 14 January 2011 (UTC)
 * Can we get something that goes into 1 line? It kind of defeats part of the purpose, reducing size, if it takes up 2 lines just to say something like "Floppy". 陣 内 Jinnai 21:23, 14 January 2011 (UTC)
 * EDIT: It may be that we simply need an article for Digital Media distribution or Video game distribution methods. We have Digital distribution so its not impossible as a parent article. 陣 内 Jinnai 21:32, 14 January 2011 (UTC)
 * I fixed it so it is only one line now. An article on video game distribution methods would be appreciated, but I don't think it would solve the problem with the infobox since "media" will be kept in the field description. Prime Blue (talk) 00:21, 15 January 2011 (UTC)
 * The output is fine, but keep "media" as the field name in the template as to not having to fix anything. - hahnch e n 15:07, 16 January 2011 (UTC)
 * Alright that seems fine. 陣 内 Jinnai 20:00, 16 January 2011 (UTC)

Edit request 3
As discussed above, removal of the distribution field and a change of the media field description. Code is in the sandbox. Prime Blue (talk) 14:40, 21 January 2011 (UTC)
 * ✅ HJ Mitchell  &#124;  Penny for your thoughts?   20:25, 21 January 2011 (UTC)

Edit request 4
Can we get the field updated to it supports only the types listed and automatically wikilinks them? And probably add auto category to pages that have invalid formats. These should be:
 * floppy disk
 * cartridge
 * memory card
 * optical disc
 * download
 * cloud computing 陣 内 Jinnai 01:47, 28 January 2011 (UTC)
 * Please make the required changes to Template:Infobox video game/sandbox, then get consensus on them, then reactivate the request ;) &mdash; Martin (MSGJ · talk) 07:35, 28 January 2011 (UTC)

Edit request 5
The interwiki to Dutch Wikipedia is wrong. It redirects to "Infobox Game", which should be "Infobox computerspel". Please change. Sander (talk) 16:44, 17 March 2011 (UTC)
 * Done (the subpage is not protected). Thanks for the heads-up! Prime Blue (talk) 16:51, 17 March 2011 (UTC)
 * Thanks, didn't know I could do it on the subpage! Sander (talk) 13:50, 20 March 2011 (UTC)

Thematic genre
Hey guys,

I added "Sci-fi" to the genre field of a couple of games, and another editor said that the "genre" field is specific to the gameplay genre and not the thematic genre. Is this correct?

Where can I add "Sci-fi" (or Western, Horror, or any other thematic genres)? If the "genre" field is not suitable, then can another field be added to specify "Theme" or whatever? It's nice to be able to ascertain the theme/genre of a game from the infobox, as I am a sci-fi/steampunk fan.

InternetMeme (talk)
 * Which editor said this? Not saying they're right/wrong, but genre is used differently for video games in general than literature and and cinema. 陣 内 Jinnai 23:29, 20 January 2011 (UTC)


 * I got that information from a chap by the name of User:S@bre, who presumably knows what he's talking about.


 * I agree with what you say: Video games are differenct from cinema and literature in that video games have two types of genre:


 * 1) The gameplay genre
 * 2) The thematic genre.


 * Both are very important when describing a video game.


 * InternetMeme (talk) 23:45, 20 January 2011 (UTC)
 * Opposing this as much as it gets: Will only provoke edit wars on dozens of article infoboxes and is not one of the defining features of a video game itself. If the fiction genre is commonly known and backed up by reliable sources, it can be added to the plot section as an introductory sentence. Prime Blue (talk) 05:45, 21 January 2011 (UTC)
 * Pretty much agree with not adding this. At least with gameplay genre, it's not too difficult, but I have seen edit ways on thematic genre when the game straddles a few ones...--M ASEM (t) 06:11, 21 January 2011 (UTC)

I Support this as much as it gets (in order to balance out Prime Blue's vote). If we are to concern ourselves with the potential for information to provoke edit wars, then we'll pretty much have to delete the entire Wikipedia (no kidding, everything provokes edit wars). Also, I think that 20 years ago the thematic genre of a video game wasn't a defining feature, but in 2011, many video games have themes more detailed and involved than typical movies.

In regards to Masem's point, I rather think that the gameplay genre has the potential to cause edit wars: Is Mirror's edge a first person shooter, an action adventure game, or a puzzle game? It turns out that it's all three, and all three genres are listed. So in the context of genre labelling, even having the potential to cause an edit war simply results in two or three individual genres being listed together. No problem.

InternetMeme (talk) 08:05, 21 January 2011 (UTC)
 * The problem is that the gameplay genre is normally specified by the developer/publisher or by reliable sources, whereas the fiction genre is not. In many articles, this will be original research, and, as Masem said, the genres oftentimes will be too ambiguous to determine the "right" ones. Take Resident Evil, for example: is it science fiction, detective, mystery or horror fiction? Or Final Fantasy VIII: science fiction, fantasy or romance? I can't imagine these being the most problematic examples, even – and for other games, it would just feel tacked-on (e.g. the Mario series). If we list every genre possible, it would clutter up the infobox again. As I said, if it is not ambiguous, a mention in the plot section might be reasonable to prepare the reader for what is to come, but I'll remain negative towards its inclusion in the infobox. Prime Blue (talk) 07:00, 22 January 2011 (UTC)


 * I'm surprised this isn't in the documentation. When I performed the reverts on the few articles that crossed my watchlist, I thought it was, but the syntax guide is lacking any explanation of how to use the genre field. It was discussed somewhere, but I can't remember where (WT:VG probably). I apologise for jumping the gun a bit in that respect. I've got to agree with Prime Blue's above statement though. I always thought the reason why we left this particular type of genre out of the infobox was because it was often too ambiguous to define the literary genre properly, whereas the game genre is usually easily citable to multiple secondary and primary sources. Although if the literary genre isn't ambiguous I often make a note of it in the lead sentence of the intro. -- Sabre (talk) 13:39, 22 January 2011 (UTC)


 * I've added docs for the genre field to indicate we're looking at gameplay and not thematic. --M ASEM (t) 14:28, 22 January 2011 (UTC)

Edit request 6
edit protected The video game director article was turned into a disambiguation page recently, and thus needs to be delinked.

The change is

to

Thank you. Prime Blue (talk) 09:27, 27 March 2011 (UTC)
 * Done. Der Wohltemperierte Fuchs ( talk ) 15:49, 27 March 2011 (UTC)

Bug: "showimage" field bolds image caption
There is a bug where the caption for the image will be bolded if "showimage" is set to "yes". See these two revisions of Half-Life 2 for an example (before, after). --Nicholas Davidowicz (talk) 07:42, 16 April 2011 (UTC)
 * ✅. To get the collapsible to work right, the image and caption are actually a part of the title field when, which is why it was bold. I set it to be normal weight either way. MrKIA11 (talk) 12:45, 16 April 2011 (UTC)

Can we add cast to this?
With Video games now being a major form of entertainment and also now being put on Actor's Resume's do you think it's fair that we add a cast part to Video Games, because there are some games that have budgets akin to hollywood movies.--Jack Cox (talk) 23:56, 16 May 2011 (UTC)
 * Discussion takes place at Wikipedia talk:WikiProject Video games. Prime Blue (talk) 11:54, 18 May 2011 (UTC)

A few questions.
May I ask a few questions here?
 * Is it really correct to call cloud computing a type of media/distribution? Wouldn't it be right to call it streaming instead?
 * Is it right to call OnLive a platform? I mean, I kept adding it to the platforms field in the past, right before someone told me this was not the option. But now, after a couple of months, I keep stumbling upon it all over the place.
 * Here's the last one: the thing is that there are thousands of infoboxes with the media/distribution field filled in entirely wrong. After I've learnt that it kinda must not include such values as wii optical disc, blu-ray disc, DVD-DL, etc., I feel a bit confused. Should I wipe these values out entirely or what?

Thanks in advance. Postwar (talk) 23:45, 22 June 2011 (UTC)
 * Streaming would better than cloud, at least for right now - there's not that much difference.
 * Online is not a platform, as games are not specifically developed for it (though Online does modified the games to work properly over the streaming channel). There was an effort by fans of Onlive a few months back to assert what games were on Onlive, but these should be wiped when found. --M ASEM  (t) 00:02, 23 June 2011 (UTC)
 * "Cloud computing" was added after Jinnai insisted on it, but I don't think I've ever seen any infobox use it – would not object to removing this altogether, either. Digital distributors and platforms is a problem that will have to be discussed more thoroughly soon. With all the digital releases lately, these are getting kind of excessive and confusing. For the media field: if the platforms use only one type of media, the field is not used (e.g. PlayStation 2, Virtual Console). If at least one of the platforms uses several types of media (basically Microsoft Windows and a few odd retro platforms), it should be filled with one of the six predetermined values (for all platforms, a PC floppy release and a Virtual Console release would be: "Floppy disk, download"). Many infoboxes still use the outdated formats because the project never formed a taskforce or used robots to clean up. Prime Blue (talk) 00:25, 23 June 2011 (UTC)

Styling tweaks
I've done some minor cleanup work to the template to bring it a little closer in line with the infobox defaults and to improve its semantics (by making the labels proper table headers again rather than just bold cells). Examples are on the test cases page. There should be no change in functionality, just a little more consistency with other infoboxes. Chris Cunningham (user:thumperward) - talk 14:09, 24 June 2011 (UTC)
 * Superscript is barely visible, which is rather annoying, especially when it comes to release dates. Can you fix it, please? Postwar (talk) 14:51, 24 June 2011 (UTC)
 * There is so little difference, I might just go ahead and change it. Postwar, how do suggest it be 'fixed'? Things such as superscript are hardcoded into the software, so there is not much that can be done about it AFAIK. For ease of editing, what was the purpose for breaking up the fields into separate lines? Also, the edit breaks the image. MrKIA11 (talk) 15:14, 24 June 2011 (UTC)
 * Superscript text inside the vgrelease template looks too small to be legible, however, superscript text outside the template is in its normal state. Which is wrong and needs to be fixed. Postwar (talk) 15:25, 24 June 2011 (UTC)
 * While slightly hackish, that could possibly be fixed by bumping the font size only for that particular row. Would that help? Chris Cunningham (user:thumperward) - talk 20:12, 24 June 2011 (UTC)
 * Maybe. Could you show me some examples of how it would be hacked? Postwar (talk) 12:04, 25 June 2011 (UTC)
 * Check the test cases page now. There may be a better way to do it, but the five-second hack works well enough to demonstrate. Chris Cunningham (user:thumperward) - talk 12:22, 25 June 2011 (UTC)
 * Disagree with the small text – looks uglier and is a lot harder to read for an infobox with so many different fields. For video games and films, I prefer the normal text size. Prime Blue (talk) 15:02, 24 June 2011 (UTC)
 * Agree with Prime. Der Wohltemperierte Fuchs ( talk ) 16:25, 24 June 2011 (UTC)


 * There is no plausible difference in actual content here between video games and films and, like, every other topic on the encyclopedia. The stripes are excused because, hey, stripes are actually quite a cool feature, and it's just a pity that the implementation is too hackish to move into infobox itself. But the font sizing (and let's not forget that the template downsizes the title text as well: it's simply arbitrary) is not a significant win, and indeed means that infoboxes which are already very text-heavy end up being massive. A minor font adjustment saves about two inches of vertical space on my monitor for the Grand Theft Auto test case and that's even with the reduced width. Chris Cunningham (user:thumperward) - talk 20:12, 24 June 2011 (UTC)
 * But what's the advantage to be won by consistency? Legibility trumps any concern that an infobox goes down for a bit. If you're concerned about length, the best thing to do is not fill the infobox with unnecessary fields. Der Wohltemperierte Fuchs ( talk ) 16:53, 25 June 2011 (UTC)
 * Consistency allows for the simplification of the markup (the template can simply inherit the skin's infobox styling defaults rather than overriding them), and as an added bonus means that should those defaults change (or the user picks a different skin) the infobox automatically adopts them without need for half-tweaking. The legibility argument is no more convincing here than on any other infobox: if the infobox defaults weren't legible they'd have been changed, and the VG infobox's font size is simply arbitrarily larger rather than out of a specific desire for greater legibility (which again can be noted from the template title being smaller than the default). Chris Cunningham (user:thumperward) - talk 10:15, 26 June 2011 (UTC)
 * Might add to David's comment that the old infobox in your test cases looks horrible because it does not employ our established standards. I see no problem with the current style whatsoever if it's done right (see above): looks tidy, does not take up too much space, and is easy to read. The suggested style, on the other hand, uh... I'll stick to my "oppose". Prime Blue (talk) 17:56, 25 June 2011 (UTC)

Mode
I am having trouble with the "mode" field. At the page DarkOrbit, I am trying to add multiplayer, but it does not show up. --EdwardZhao (talk) 23:02, 25 June 2011 (UTC)
 * It's "modes=" (plural), that's why it didn't work. Prime Blue (talk) 23:17, 25 June 2011 (UTC)

Usages
Having hand-checked all 2+ usages, the stats are approximately: 3939 single-player; 455 multiplayer; 1622 both; 885 weird. The rest are probably at the same proportions. Most of "weird" can be classified as SP/MP/Both easily, but most of them are examples of what I assume is arcades, where it says "two players" and such; This is a significant portion.

Discussion

 * Previous discussion resulted in rough consensus to limit the modes field to "single-player", "multiplayer", or both values.

I propose to deprecate the poorly understood modes field with yes and yes fields. This will automatically produce the field value, correct wikilinks, and categorize the game. It is also more intuitive for anyone working with the infobox and clear to new editors, where the majority of strange field values occur. For the few "special" games we can have a modes-other field so the editors wanting a custom value can still have one. It could also be possible to introduce other options such as two-player-arcade or something, but somebody more familiar with arcades and their "modes" should comment. — HELL KNOWZ  ▎TALK 10:16, 26 June 2011 (UTC)
 * If you intend to get rid of the strange values, an additional custom mode field would only relocate the problem. Still believe that our three standard values ("Single-player", "Multiplayer", "Single-player, multiplayer") avoid cluttering up the infoboxes, the rest should be explained in prose anyway if it's important to the gameplay. That said, if you want to replace "modes" with "single-player" and "multiplayer" fields, only a "yes" value is needed (leaving it blank is "no" by default). Prime Blue (talk) 13:47, 26 June 2011 (UTC)
 * I too believe anything non-standard should be left to prose. I am myself unsure about the custom field, so I said "can have". This relates to the arcades and what "multiplayer" means there. I leave that to consensus without explicitly proposing either way. Also, I should have clarified that any value except "yes" defaults to "no". — HELL KNOWZ  ▎TALK 13:59, 26 June 2011 (UTC)
 * Sounds fine save it should also be true for "y" in addition to "yes". 陣 内 Jinnai 01:31, 29 June 2011 (UTC)
 * Is there evidence that modes have been an issue ever? Der Wohltemperierte Fuchs ( talk ) 17:46, 29 June 2011 (UTC)
 * (I'll assume that was a general question, not specifically to Jinnai) All the uses are in the table above. Not really an editorial issue (except some cases of misuse), but it does bring consistency (viewing and editing) and automatic categorization. — HELL KNOWZ  ▎TALK 18:01, 29 June 2011 (UTC)
 * Well, on that note, do we really need such massive categories as "Single-player games" or "Single-player games"? I'm just not particularly seeing much reason for changing at this point unless it was actively an issue. Der Wohltemperierte Fuchs ( talk ) 18:03, 29 June 2011 (UTC)
 * We do have large categories such as Category:Living people. I see no harm in having these, especially if they are automated by the use of appropriate fields in the infobox. Editors won't need to add the categories manually. I can see how WP:DONTFIXIT argument comes into play, but I still think single-player and multiplayer fields are more intuitive and help clean up all inconsistent past usages and prevent future misuse. After all, there are cases where the fields are used wrongly, or could use correct grammar and improved wikilinking. Having the categorization is just a bonus that would serve its purpose if it is useful at least to somebody. This proposal does not change a whole lot, but I think it is an improvement nonetheless. — HELL KNOWZ  ▎TALK 19:38, 12 July 2011 (UTC)