Template talk:Infobox video game/Archive 13

Mode field
Hi guys, two things.

1: The syntax guide says: "Playing modes the game offers. The only values possible are single-player and multiplayer (or both)", based upon a consensus reached three years ago. May I suggest a new discussion here? From the top of my head, there are offline single-player games (Skyrim), games that require to be online even playing solo (Diablo III), multiplayer (any will do here), games that have a single-player story and a separate multiplayer mode (The Last of Us, BioShock 2), asynchronous multiplayer (Demon's Souls, Hitman: Absolution), co-operative multiplayer (Payday: The Heist, for instance), MMOs, you name it. Considering a game will need the input of at least one player, what about changing the field to an optional multiplayer, and describing that multiplayer element?


 * Re modes. This is the reason we stripped it to only allow SP/MP values -- too much field misuse, everyone wants to describe how their multiplayer or single-player is different or special. This was not supposed to include always-on or anything like that. I don't mind expanding the list of allowed values (like co-op), but no custom ones.


 * Thanks for your reply, Hell. I am in favor of expanding the options from SP and MP to at least a couple more. T / C 07:46, 26 August 2013 (UTC)


 * Given that the infobox should be information at a glance, I think limiting the mode to SP, MP (implied competitive), and co-op MP as the only choices. Getting any finer on the details of gameplay for more complicated modes should be in the Gameplay section. These three hit the major bases for most fundamental gameplay elements. --M ASEM (t) 13:55, 26 August 2013 (UTC)
 * Anything that isn't a single player campaign only an d allows for multiple players on a separate console via a network is multiplayer. Darkwarriorblake (talk) 15:21, 26 August 2013 (UTC)
 * There's also local multiplayer (multiple controls on same console). The point though is that there is very large difference in competitive and cooperative MP mode to warrant that type of distinction as an infobox field. On the other hand, on- verses off-line MP does not since the mechanics typically remain the same. --M ASEM (t) 15:25, 26 August 2013 (UTC)


 * While I thought co-op is a good straight-forward candidate, I have some questions. So many multiplayer games are also "co-op" in some way -- team-based games, players versus AI games, MMOs versus NPCs, etc. They all technically fall under this. If we allow co-op, wouldn't that mean every game with a "multiple player versus computer" option would become a co-op? Like in TF2 you can play against a bot team, making it a co-op mode. And then, for example, Borderlands can't be played non-co-op, so multiplayer becomes redundant. — HELL KNOWZ  ▎TALK 15:36, 26 August 2013 (UTC)


 * If there is any component of PvP (even if it is team vs team), that would be standard MP. I would argue that co-op is strictly where the players are completely working together (or at least, designed to) against strictly component opponents. Borderlands 1/2 is the example here - even though there's an optional PvP thing you can do, the game is fully designed around players working together and thus is a co-op MP game. TF2, prior to Mann vs Machine mode, was strictly an MP game, but MvM itself is a strict co-op mode.  Arguably, I'm sure there are MOBAs and the like where your team can practice against an AI team, but the core concept is still PvP at the end of the day, and thus I would argue these aren't co-op. --M ASEM  (t) 15:47, 26 August 2013 (UTC)

Okay, so removing the field altogether might be a bit much, but what else can we do? Three entries, like in other VG infobox fields: SP, MP and additionally co-op? But as we've concluded, there all these different kinds of ways to play games -- should we let it go, and go by a game-by-game judgement? Upcoming Titanfall now has "Multiplayer (with single-player elements)" in the field, while Diablo III's is Online single-player, multiplayer, which doesn't look so bad to me. --Soetermans. T / C 19:41, 26 August 2013 (UTC)
 * I think keeping it broad helps because ultimately people will abuse it. Linking Diablo III as online single-player for instance is abuse, I haven't played it, but if it is single player that requires you to be online, the only notable part is teh single player. If it involves online play between several players, it is multiplayer, I don't think it is necessary to say if it is cooperative or otherwise since non-cooperative multiplayer can still result in cooperation. Again with Titanfall, is it multiplayer or is not? GTA V's online can be called multiplayer with single player elements if noone else is playing, if it revolves around multiplayer, it is multiplayer, if it doesn't have a dedicated single player it isn't single player. Darkwarriorblake (talk) 20:14, 26 August 2013 (UTC)
 * Well, the cooperative is important if the game is designed that all players currently connected are meant to be working together - ala Borderlands - and not just playing simultaneous w/o PvP (eg most MMOs are not cooperative multiplayer games, they're just multiplayer). I would personally think 5 modes are acceptable here: single player (irregardless if there's any online component like Diablo III or SimCity); multiplayer (implied to be online), local multiplayer (if specifically not online MP), cooperative (game is designed or has specific modes specifically designed for this), and local cooperative (if specially not online). If a game supports both local and online competitive modes, one does not list both (as if online MP is supported, local is usually implied.).  --M ASEM  (t) 20:29, 26 August 2013 (UTC)
 * I'm sorry Darkwarrior, I don't quite understand you. What do you mean by "I think keeping it broad helps because ultimately people will abuse it"? I think you might be on to something Masem, but can we assume that 'multiplayer' implies 'online' these days? --Soetermans. T / C 20:39, 26 August 2013 (UTC)
 * Well, there's another way to go about that. If I said "here's a multiplayer game for the Atari 2600", you know by default that that isn't online. On the other hand, if I told you that "here's a multiplayer game for the PS3", you would likely be surprised if the game lacks online. Basically, based on the platforms the game is released to, we should be able to assume online-ness from that, though I will argue with the PS2 or Dreamcast which had limited online functionality, it may need to be called out explicitly.  But the other way is that to assume people reading today will expect all games, if they have multiplayer, that it is online, and we only need to clarify when that wasn't the case. --M ASEM  (t) 20:58, 26 August 2013 (UTC)
 * If we create a handful of acceptable terms that might help a little, at least then if someone insists on adding Multiplayer with single player elements you have somewhere to point to and say no, it comes under this. Darkwarriorblake (talk) 21:45, 26 August 2013 (UTC)
 * We could create a template that would only allow specific modes (eg ); it wouldn't disrupt existing text for game mode lines in infoboxes but if we make that the preferred method, it would help prevent extraneous details. --M ASEM  (t) 14:25, 28 August 2013 (UTC)

Engine
And number two.

2. I saw there were past discussions about the engine field, but I couldn't see what the outcome was. System requirements have been removed from the infobox, and the other day we've reached consensus on removing them from the article body also. If video game articles shouldn't be too technical, might it be a good idea to retire the field (once more, I think)? As a huge gamer I don't really care what engine is used, so what about the average reader? Besides, often the engine isn't mentioned in the article body at all (The Last of Us), isn't that a sign that isn't noteworthy? Minecraft for instance doesn't mention any engine whatsoever. Syntax guide says: "Only use this field for game engines with an established, independent article and wikilink its name". The in-house engine then would fail that requirement. And just to list Havok... What I would like to see, if the use of the engine is in fact notable, that it is mentioned in the article body (Uncharted 3 has a graphics and technology subsection, BioShock has a game engine subsection). --Soetermans. T / C 09:30, 25 August 2013 (UTC)


 * Re engine -- I think it's a reasonable field, since we require there to be an article linked -- the reader can actually learn more from this. You can't learn that way from system reqs. And only notable engines are included, otherwise every game will have an "engine". Stuff like "in-house engine" is not supposed to be there, that's like saying "our game has code". And yes, prose should be mentioning them if notable, though having a notable engine does not in itself mean its use is notable. — HELL KNOWZ  ▎TALK 10:01, 25 August 2013 (UTC)


 * Good to know that in-house engines don't have to be mentioned in the first place, but I'm still not convinced. All the other things listed in the infobox are general information (publisher, developer, director, mode, distribution), to me, engine doesn't seem to belong there. I'd love to see more input here, is this talk page visited frequently, or can I leave a message at WT:VG? --Soetermans. T / C 07:46, 26 August 2013 (UTC)


 * Splitting the discussion here. Your input here would be much appreciated, and . --Soetermans. T / C 19:41, 26 August 2013 (UTC)
 * I'm not invested in the Engine field, its somewhat generic since like 90% of games are on Unreal, it is something again probably better used in prose if and where notable, but at the same time I guess it's a little akin to "filming location" on the film infobox. It's hard for me to judge as I personally have no interest in the game engine itself. Darkwarriorblake (talk) 21:47, 26 August 2013 (UTC)
 * It's not 90% as tables below show, although it's a major portion. — HELL KNOWZ  ▎TALK 14:36, 28 August 2013 (UTC)
 * It is somewhat more important in the area of FPS/TPS where there is definitely a distinct line of game engines families, but I would emphases that this field should only be filled in if reliable sources specifically mention it, and since this is not true of all games, I would lean towards removing it. Important information on the engine can be discussed in the body of the article if this is removed. --M ASEM (t) 14:29, 28 August 2013 (UTC)

RFC: Add license field
Let's add a license field to infobox video game. Many video games come with a license other than "all rights reserved" and this should be mentioned. The infobox is the natural place for this bit of useful information. Looks like there was such a field but it was removed. Also, many articles already have data in the license field but it's not displayed by the current template. Palosirkka (talk) 08:08, 18 August 2013 (UTC)


 * Previous discussions: #.22License.22_field and #Licensing_parameter, #Another_push_for_license_field


 * Unless something has changed from the last discussion, my opinion is still the same - to have the field, but only allow preset values and exclude when simply proprietary. The original concern was the broad misuse of the field and values that hardly mean anything to the reader. — HELL KNOWZ  ▎TALK 09:37, 18 August 2013 (UTC)
 * Sounds good to me, I'm all for this. Palosirkka (talk) 10:36, 18 August 2013 (UTC)


 * Oppose, the license status of a game is irrelevant to the infobox and if notable (which would be rare at best) belongs in prose rather than a field applicable to every single video game article. Darkwarriorblake (talk) 11:00, 18 August 2013 (UTC)
 * Oppose, Not notable for the majority of titles that use the infobox, and when it is notable, it can be mentioned in prose. - X201 (talk) 18:03, 18 August 2013 (UTC)
 * Oppose. Hi. I am afraid such a field on 90% of times would read "Commercial proprietary"; on 9%, it's "shareware". Then, we are going to have the same problem that we have in ordinary software articles: Some guy adds "Electronic Arts EULA" to them (in spite of wide consensus against this nonsense) and when you tell them it is against consensus and gives zero information, ... well, the last guy told me "go fuck yourself". The only video game I know to have come with a different license is Warzone 2100.
 * Best regards,
 * Codename Lisa (talk) 03:45, 20 August 2013 (UTC)
 * Actually, per Template talk:Infobox video game/Archive 10 it was primarily proprietary and almost as much GNU, before various others . Just for information. — HELL KNOWZ  ▎TALK 08:11, 20 August 2013 (UTC)
 * Actually, I had Microsoft Excel group the data, combine similar values and create a pivot table out of them. Result:


 * Free software || 60
 * Freemium || 2
 * Freeware || 80
 * Mixed || 9
 * Commercial || 162
 * Shareware || 11
 * Unlicensed || 8
 * Grand Total || 332
 * }
 * As you can see, free software (GNU and other free licenses) constitute only 60 / 332 or 18%, not counting the Mixed. Proprietary constitutes (2 + 80 + 162 + 11) / 322 * 100 = 76%, not counting the Mixed. Best regards, Codename Lisa (talk) 15:54, 20 August 2013 (UTC)
 * Hmm, my bad, I was looking at the software article table, thanks for summing it up (I was way too lazy at the time) and now just got it mixed myself. Anyway, I'm not arguing to have the field, if anything I'm more inclined to not have it with every argument. — HELL KNOWZ  ▎TALK 16:16, 20 August 2013 (UTC)
 * If we were going to have it, my suggestion would be to keep it out of the default parameters. We tend to have a breed of editor that will see every blank field as something to be filled out, even when it's redundant or unnecessary. Der Wohltemperierte Fuchs ( talk ) 16:59, 20 August 2013 (UTC)
 * Unlicensed || 8
 * Grand Total || 332
 * }
 * As you can see, free software (GNU and other free licenses) constitute only 60 / 332 or 18%, not counting the Mixed. Proprietary constitutes (2 + 80 + 162 + 11) / 322 * 100 = 76%, not counting the Mixed. Best regards, Codename Lisa (talk) 15:54, 20 August 2013 (UTC)
 * Hmm, my bad, I was looking at the software article table, thanks for summing it up (I was way too lazy at the time) and now just got it mixed myself. Anyway, I'm not arguing to have the field, if anything I'm more inclined to not have it with every argument. — HELL KNOWZ  ▎TALK 16:16, 20 August 2013 (UTC)
 * If we were going to have it, my suggestion would be to keep it out of the default parameters. We tend to have a breed of editor that will see every blank field as something to be filled out, even when it's redundant or unnecessary. Der Wohltemperierte Fuchs ( talk ) 16:59, 20 August 2013 (UTC)
 * Hmm, my bad, I was looking at the software article table, thanks for summing it up (I was way too lazy at the time) and now just got it mixed myself. Anyway, I'm not arguing to have the field, if anything I'm more inclined to not have it with every argument. — HELL KNOWZ  ▎TALK 16:16, 20 August 2013 (UTC)
 * If we were going to have it, my suggestion would be to keep it out of the default parameters. We tend to have a breed of editor that will see every blank field as something to be filled out, even when it's redundant or unnecessary. Der Wohltemperierte Fuchs ( talk ) 16:59, 20 August 2013 (UTC)


 * Oppose. Seems like this has been addressed several times and I gather from reading the references to previous discussions, a consensus to not have a license field has been previously been addressed and voted down. Since it's been previously addressed, why has there been yet another RfC for an issue previously addressed and resolved? It doesn't make sense to me. Wickedlizzie (talk) 12:09, 8 September 2013 (UTC)


 * I would like to add the field "license". The available free and open-source games are clearly a minority, but for them it would be nice to have. The others, can safely ignore the field. Any objections? ScotXW (talk) 10:01, 14 September 2013 (UTC)
 * Yes, the above. Darkwarriorblake (talk) 10:22, 14 September 2013 (UTC)

"Collapsible" as default with expanded state
Hi there! I've got a suggestion to make this Infobox more consistent with other templates (and the table of contents as well): why not make the default state of the Infobox "collapsible=yes" as well as "state=expanded"? The result is the same Infobox as we have it now, except with a [show/hide] button. Here's an example to show you what I'm talking about. Ultimately this change just results in more options being available to the reader by default, but still leaving all the options for us editors on the backend. Undoubtedly this may break several pages, so I'm not quite sure how feasible a change like this may be.

Comments? — SolarStarSpire (talk) 19:54, 22 September 2013 (UTC)
 * Can you list a few examples of what you'd like to change to what, and why you suggest it? It is my understanding that the discussions on this page have erred on the side of reducing infobox bloat, so this suggestion's devil is in the details. czar  ♔  21:14, 22 September 2013 (UTC)

re. Images for games on a single platform
Hello! The documentation regarding use of cover art in this infobox reads, in part, "Where a game is released on multiple platforms, the PC cover is preferred over console covers to avoid bias towards a certain console. However, if possible, artwork should not use any platform indicator at all." The latter part is a bit confusing though: does the "platform indicator" guideline apply to cover art for all games, or just those which were released on multiple platforms? Could this be clarified as well? Thanks for any help! DK  qwerty     20:07, 21 September 2013 (UTC)
 * If the game was released on a single platform, it doesn't matter whether the art is platform-neutral (just don't edit war about it). Do you have a specific article/instance in mind? czar  ♔  21:27, 22 September 2013 (UTC)

List markup
I made a minor change to the template to allow for * list markup in the data fields (see the example to the right). it should generate no noticeable difference in the output, and very minimal additional overhead. the way the tweak works is to embed the data in parserfunction, in this case. this forces the backend properly expand 'genre' as if it were started on a new line. the '#if:1' check is the minimal additional overhead. eventually this template should be switched to use Template:infobox, but before that can happen, Template:infobox will need to have support for alternating row colouring, if we want to keep the colouring. Until that happens, this minor tweak will allow list markup to work, like it does with Template:infobox. please do let me know if there are any problems. thank you. Frietjes (talk) 16:15, 12 November 2013 (UTC)

RFC: Add budget field
This has previously been suggested here for Grand Theft Auto IV (to no reply), and Grand Theft Auto V has resurrected the suggestion in my mind, but there are now a number of other games that show that a budget (and potentially revenue) field would be a valuable addition (as List of most expensive video games to develop shows; although the list is tagged for a couple of issues, five of the top six have in-line citations for their budgets as being $100 million or more). The GTA games may be outliers in their time, but blockbusting games are fast catching up to Hollywood movies in terms of budget; adding GTA V to the List of most expensive films would place it at number 2 in the list, with Star Wars: The Old Republic at joint 19th place with Iron Man 3, Toy Story 3, and Transformers: Revenge of the Fallen, among others. While not necessary for all games (especially most pre-millenium games and independent games), it would be a useful optional field when talking about big-budget video games. — Sasuke Sarutobi (talk) 14:06, 23 September 2013 (UTC)
 * Previous suggestion: #Budget / Revenue.
 * Oppose Reported budgets for video games are a rarity, particularly as video games are more judges on reviews than revenue. Films, on the other hand, are nearly always measured in success by box office take vs budget, and budget numbers are usually easy to find for most films, hence why they have it there. An added issue with VGs is the split between actual development dollars and marketing dollars that might inflate the budget. If a budget is known, it definitely should be covered in the Development section, but its so infrequently reported that it doesn't make sense for the infobox across all games. --M ASEM (t) 14:26, 23 September 2013 (UTC)
 * Oppose. The fields are for common data available for a large number of articles. Reported budgets are indeed rare, and most are just educated guesses and speculations. A few indies post their numbers, but most aren't notable to be included. Beyond that, it's very rare. In addition, just knowing a number isn't really indicative of anything. How much is for publisher, how much actual developer, how much outsourcing, etc. Besides, this doesn't account for inflation or cost different between regions/countries. If such data is available, it should appear in prose and give context. — HELL KNOWZ  ▎TALK 15:38, 23 September 2013 (UTC)


 * Oppose as data points we wouldn't be able to consistently populate across articles. As when similarly situated with vague data (e.g., sales figures), it's best expressed, when notable at all, in the prose. czar  ♔  14:27, 24 September 2013 (UTC)
 * I wanted to support this, and in theory, I think its a great idea, especially since this is related to an issue the industry is currently going through; increasing development budgets running conversely to acceptable buying price for consumers going down. However, at the same time, I also agree with the main concern raised here; sadly budgets are rarely disclosed except for in special cases. It can be difficult to even get sales figures, since NPD can be vague with their figures, and VGChartz aren't considered a reliable source here, let alone budget figures to compare them against. I'd fully support this proposal if this ever starts to change though... Sergecross73   msg me   16:44, 24 September 2013 (UTC)
 * Oppose Budgets for games are not akin to film budgets and are rarely, if ever, a focus of discussion. They are also rarely available and in the case of GTA V, an estimate. Darkwarriorblake (talk) 17:25, 24 September 2013 (UTC)

I guess the above establishes the consensus, and for very good reasons that I hadn't considered, so thank you all for your time and comments. If I may, I would like withdraw my proposal with consensus established as Opposed. — Sasuke Sarutobi (talk) 23:16, 24 September 2013 (UTC)


 * Support If the information isn't available, then that bit won't load up in the infobox. If it is known though, that is something that is important.  And the games are made because they make money, just like films do, that how investors judge them.  The reviews don't matter, its the profits.  If you saw the infobox of a film or a game that said it made hundreds of millions of dollars profit, you'd be more likely to check it out than not.   D r e a m Focus  18:01, 21 October 2013 (UTC)
 * In the video game industry, at least today, it is not the number of units you push, it is the Metacritic scores. A game may push millions of units, but if it doesn't get a certain MC score, the publisher may force cuts on the dev team. --M ASEM (t) 18:24, 21 October 2013 (UTC)
 * That's nonsense. Where did you hear some a ridiculous thing, and why do you believe it?  All businesses exist to make money.  That's all that matters to them, not what some reviews say.   D r e a m Focus  18:28, 21 October 2013 (UTC)
 * , etc. --M ASEM  (t) 18:41, 21 October 2013 (UTC)
 * Oh yeah, reviews definitely matter way more than they should and publishers make rash decisions that affect developers and dev studios more than anything. They use it for cheap incentive and cutback excuses alike. This isn't new or unheard of and has been going on for a while now and is a really stupid way to judge a team. The difference in review scores actually matters way more in games industry than a similar difference in profits. — HELL KNOWZ  ▎TALK 19:10, 21 October 2013 (UTC)
 * Those links say that they use it as an excuse to not give bonuses to people. The sales and profits are still quite high regardless of the rating.  Some higher rated games don't have higher sales and profits than some of those with lower ratings.  So metacritic ratings and sales are not related.  Not all companies do this I'm sure.  Especially when it comes to sequels.  Not going to say, hey, I know you made a few hundred million dollars profit last time, but your metacritic rating was a bit low, so we're not going to let you make a sequel.  And the ratings still aren't a reason not to include budget in the infobox.   D r e a m Focus  19:53, 21 October 2013 (UTC)
 * Because Obsidian did not get the bonus for getting a higher MC score, they had to let go of 20-30 people. Even though the title sold millions and remains popular. Yes, there is no connect between reviews and sales, that's the problem, because of the fact that the VG market has unique challenges like digital downloads, piracy, used games, etc. While some bookkeepper is tracking sales and budget somewhere for the publisher, the industry realizes these are no longer useful metrics to judge a video game.  But this still goes to the point that the field would be used for a tiny minority of titles (probably 2% or less judging my own experience), and I've found when you add a field, editors will naively try to fill in every field even if the information is not well verified. --M ASEM  (t) 20:04, 21 October 2013 (UTC)
 * I was only commenting on MC score usage. As for actual field, I've already said above -- it applies to very few games where we have actual reliable sources covering this. Video games industry does not reveal budgets for most games. — HELL KNOWZ  ▎TALK 20:35, 21 October 2013 (UTC)
 * Surely even for games that are highly pirated or frequently traded as pre-owned, new sales would establish even a lower bound for companies to see whether it made a return on investment in development costs? So even if 500,000 people bought the game new, and 50,000 people pirated it, the publisher would still see if the game made back the development costs. — Sasuke Sarutobi (talk) 14:00, 13 November 2013 (UTC)

Ordering of platform field
I would like to consider the idea of introducing a template to help fill in the platform field as to present any platforms in a proper "order". The idea of the template would be that, say, for a game on PC, OS X, 360, PS3 and Vita, you'd simply do: and it would produce these in a proper order.

To that end, I'd like to discuss what that proper order should be. I know currently that we have the idea of using alphabetical, but this puts what I would consider (not in a disparagingly way) secondary platforms like Android and iOS above key platforms like PC or the like. I would like to suggest that for nearly all games (to date), there are typically three blocks of platforms: personal computer, console (including handhelds), and mobile/other devices.

Within each the ordering should be alphabetical, except that the three of Microsoft Windows, OS X, and Linux should be first and foremost and in that order for personal computers (given that today, these are the three primary PC platforms, and have that much influence in that order). I am not 100% sure how this would come into play with older games that might have had Windows support (3.1 or earlier) alongside Amiga or similar ports. (you go much before this, and now you're talking MS-DOS instead of Windows).

Within consoles, they would be grouped to keep brands together with respective consoles before their respective handhelds: eg one possible list would be "Nintendo Wii, Nintendo 3DS, Ouya, PlayStation 3, PlayStation Vita, Xbox 360". For mobiles, this would be simply in order (though I can see having iOS and Android as the first two irregardless).

Each section would have a catchall for any additional platform or text that may be necessary, such as at Lemmings (video game) there's simply too many ported systems to list, and it just ends with the major ones and "various".

I will point out that the chronological ordering (include native platform) should be obvious from the release date field, as well as in the lead.

Any opinions if this is a good idea, or just better to let the platform field continue to be manually filled in? --M ASEM (t) 15:22, 21 October 2013 (UTC)


 * Template:would be a good idea to keep the order consistent, but keep it alphabetical. It minimises the ability for people to argue over the order. - X201 (talk) 15:47, 21 October 2013 (UTC)
 * Why isn't it ordered by platform release date (and alphabetical for identical release dates)? That would seem to solve your contention. Either way, I think a template to enforce the consensus (to order) is smart. czar  ♔  16:12, 21 October 2013 (UTC)
 * You could always make it so the platform section displays only major launch platforms within a reasonable time frame (so a Ubisoft textbook PC version delay by a month wouldn't exclude it for instance) while other platforms are hidden under a collapsible block. This would help retain neatness for a start when older games have been ported to everything ever, but also stop situations like Deus Ex where it appears that it was released on Cloud at the same time as PC (Side note, is Onlive not simply streaming an existing platform like PC? They are not PORTING the game to OnLive are they? Then its not a platform, its a distribution channel. Darkwarriorblake (talk) 17:15, 21 October 2013 (UTC)
 * The issue of Cloud gaming was discussed maybe about a year or so ago, and the conclusion that I remember that "cloud" is a platform, but specific instances like OnLive are equal to storefronts like Steam, and only should be included if there exclusivity towards that. --M ASEM (t) 17:36, 21 October 2013 (UTC)
 * So where are we at with this? I was thinking of something like this:


 * Though I think that Cloud thing needs revisiting. Darkwarriorblake (talk) 07:09, 26 October 2013 (UTC)


 * Well, the cloud thing was specifically to placate a number of OnLine editors that thought we were dissing their platform completely. As for what you are hiding there in the list, that doesn't really make sense. I would argue I'd only add reissued ports, like Sega Classics from the Genesis being available as PC or Xbox Live titles, for example; in the case of AC there, Wii U and OS X major platforms with reasonably-expected delays in their own vesion. --M ASEM  (t)
 * I consider it the same as releasing a film on DVD after it was released 20 years earlier on VHS. The only important thing that should be conveyed in the infobox is the original release (window). Original developer, original release date (window), original platforms. Deus Ex is the quintessential PC game, it being released on PS2 later as an after thought isn't relative to it's original success/reception/notability. Darkwarriorblake (talk) 15:08, 26 October 2013 (UTC)
 * Yeah, that's not consistent with the project, nor my thoughts. PS2 should be a listed platform for DX, as of course for PC and Mac too. But, as I read it down, there's also Cloud and PS3 listed; as the PS3 version is just the PS2 version in emulated mode, that's not a platform, nor in this case Cloud, as that's just a more recent version comparable to getting the PC version off GOG or Steam. --M ASEM (t) 15:27, 26 October 2013 (UTC)
 * Going back to the previous argument, how are the Wii U and OS X platform releases for Arkham City reasonable delays? They came out over a year later, and are both ports of a completed game, one even has a different name. I don't see what is harsh about putting them under a list, it's a reasonable expectation that not every platform can go in the infobox, so it doesn't seem unreasonable that that list be limited to its initial major release platforms, and that if others MUST go there, they be placed in a collapsible list, the same way we would for excessive release dates, which themselves become a running joke. And it should be made clear in the infobox guidelines what is a platform and what is not, streaming or a digital version of an existing title, i.e. PS2 games on PSN, is not a platform, it's a distribution strategy. Darkwarriorblake (talk) 18:26, 31 October 2013 (UTC)
 * I like the separation of original platform releases and later releases. However, there is some ambiguity with games which are released on different platforms on different days but with each day being within the same time period, whether that be a week or a month. E.g. Game released on Xbox 360 December 1 and PS3 on December 2, should PS3 be included as an original platform? What about if it's December 1 for Xbox and December 31 for PS3? Where is the line drawn? Generally, if we can choose a general rule for time periods pertaining to the original release I fully support this addition, especially for games which have been ported to more than a dozen platforms. Nicereddy (talk) 00:50, 1 December 2013 (UTC)
 * I think I mentioned it in this discussion but we could work out a reasonable time frame. Something that is released a month later is not something that has been ported after the fact, it's something that has been designed for the launch window but delayed either for technical or financial reasons, the way Ubisoft tends to delay the PC versions of things like 2 weeks before release. If it was announced for that launch window as well I think it should be included UNLESS the delay is significant, like say half a year or more. Things announced after the release/released over 6 months to a year later would definitely be classed as outside the launch window. We can refine this timeline of course but I think generally it tends to be obvious what is a launch window system. 3 months would probably be a more appropriate timeline with leeway given if its 3 months and 2 weeks or whatever. Again, we can discuss and refine this. Darkwarriorblake (talk) 09:35, 1 December 2013 (UTC)

Bumping to call attention to this topic, it needs to move forward. DWB (talk) / Comment on 'Dredds FA nom!'' 00:15, 26 December 2013 (UTC)

Rating
Make a extra line for ratings such as E, M, 17+, or whatever other game ratings are. If you can, then make each one display the standard image for that rating. Techdude3331 (talk) 15:11, 2 January 2014 (UTC)
 * We've discussed this repeatedly before, and we don't include it because it typically is only of use to a potential buyer, plus we'd have to include ratings from all other countries too and make it too hefty. If the content rating is the subject of discussion by sources (eg many many games with Australia), that's appropriate to discuss in the article body but nowhere else. --M ASEM  (t) 15:13, 2 January 2014 (UTC)

"Based on" field
Why there isn't a field "Based on"? There are a lot of games based on another media, like The Walking Dead (Comic), The Simpsons: Hit & Run (TV series), The Witcher (Novel), Blade Runner (Film), etc. --186.182.145.234 (talk) 03:20, 7 January 2014 (UTC)

P.S.: The article also lacks of a "Starring" field. Beyond: Two Souls has a top billing, for example.


 * For both your points, the number of games that are based on other media, or those with notable people in "starring" roles, is very few, and thus not appropriate to include. These details of course should be in the lead and elsewhere in the article because of their importance, but they don't need a spot in the infobox. --M ASEM (t) 03:25, 7 January 2014 (UTC)
 * Ditto. Video games have way more specialized fields than films, so we tend to not include ones that don't apply to many games. — HELL KNOWZ  ▎TALK 13:11, 7 January 2014 (UTC)

Input bug
input was making the Sound Shapes infobox freak out. (example) Thought someone may want to take a look to make sure all's being sanitized properly. czar ♔  15:55, 7 January 2014 (UTC)


 * Its a defunct field, wonder if the code addition above may be linked? - X201 (talk) 16:24, 7 January 2014 (UTC)


 * I've reapplied the request for the administration categorization (in a different place this time). Please  if any issues arise from this and I'll be on it like a fly on poo.  Thanks! Technical 13 (talk) 18:15, 8 January 2014 (UTC)

Infobox broke
The infobox seems to be bugged; the developers field is not under but to the right of the image, and |- style="" is appearing as part of the caption. E.g. Batman: Arkham Asylum, Nintendogs, Mario Power Tennis. I'm pretty sure it's the infobox that's got the error. – Bellum (talk) (contribs) 22:08, 7 January 2014 (UTC)
 * This was the same issue I had above. Looks fine since the recent change was reverted. More discussion at User_talk:Technical_13. czar  ♔  07:16, 8 January 2014 (UTC)
 * By the way, all three of those articles were using deprecated parameters (now removed), so that's part of the bug, for whoever's patching the code czar  ♔  07:23, 8 January 2014 (UTC)


 * I've reapplied the request for the administration categorization (in a different place this time). Please  if any issues arise from this and I'll be on it like a fly on poo.  Thanks! Technical 13 (talk) 18:16, 8 January 2014 (UTC)

Tracking category
Can we add a tracking category to record all pages still using the deprecated parameters at Template:Infobox video game? I'd like to remove them some time in the future to reintegrate them with the rest of their respective articles, and I have the code already set up at Template:Infobox video game/sandbox. TeleComNasSprVen (talk &bull; contribs) 02:48, 27 December 2013 (UTC)


 * I support this. - X201 (talk) 15:33, 2 January 2014 (UTC)


 * I haven't checked the code, but I support the idea. czar  ♔  17:13, 2 January 2014 (UTC)

Calling an admin to sync this then, hopefully won't break anything. TeleComNasSprVen (talk • contribs) 05:05, 7 January 2014 (UTC)
 * Technical 13 (talk) 12:41, 7 January 2014 (UTC)
 * Yes check.svg Done Technical 13 (talk) 12:50, 7 January 2014 (UTC)

Can an admin sync it exactly as the code currently is on the sandbox page this time, without making any further changes to it? TeleComNasSprVen (talk • contribs) 17:21, 8 January 2014 (UTC)
 * Yes check.svg Done again... I had to undo the first try based on User talk:Technical 13 but have tried again in a different manner. I've taken another stab at it (it's still not in the alternating rows template because that is a bad idea) and see no issues on the test cases page... I'm going to purge and check a few of the pages in the category to see if there are issues there and I'll get this working right before getting off or I'll revert and let someone else do it. Technical 13 (talk) 18:06, 8 January 2014 (UTC)

I have starting working through this list, removing defunct fields, and have just noticed two other fields that are still hanging around in the article code. Can we have the template fields preceded by and followed by show up in the category as well please? - X201 (talk) 09:12, 9 January 2014 (UTC)
 * Could we also have it look for website which still crops in infoboxes from time to time, along with two old fields that were superseded; latest release version and latest preview version. We may as well do a thorough job with this clean up. - X201 (talk) 11:06, 9 January 2014 (UTC)
 * Sorry for pinging you, but if I can tidy up the additional 6 categories above as I go, it will save a double pass. Thanks. - X201 (talk) 08:55, 10 January 2014 (UTC)
 * Yes check.svg Done has been added.  It will still take a bit to run through the job queue and populate those new ones into the category though, so some may end up being double passes.  Also, what exactly are you doing?  Is it something that can be done quicker with a bot (or AWB)? Technical 13 (talk) 11:24, 10 January 2014 (UTC)
 * Thanks for the addition. I'm using AWB, I think its a better choice than a bot. The human element allows me to rescue references and stuff, and handle all of the "wonderful" unique methods our editors have come up with for laying out template code ;-) - X201 (talk) 12:39, 10 January 2014 (UTC)
 * There are currently page(s) using deprecated parameters, if you give me your find/replace from AWB, I'd be happy to go through some of them and help you burn down the backlog.  Ping me and let me know if you are interested. Technical 13 (talk) 15:16, 10 January 2014 (UTC)
 * I'm still fine tuning AWB at the moment, but yes, thanks, when its ready (next week sometime). In the meantime... I've just discovered that the "Latest... fields you added earlier also have companion date fields to them latest release date and latest preview date. Is there any chance you could do the necessary again please? - X201 (talk) 16:54, 10 January 2014 (UTC)
 * added to list. Technical 13 (talk) 17:01, 10 January 2014 (UTC)
 * Have you done manual checks to save any sources that may still be linked in the given fields, even if defunct? I've come across a couple but I haven't had time to fully integrate the sources into the rest of the article while also removing the field. And thanks for offering to take on this monumental task. TeleComNasSprVen (talk &bull; contribs) 09:23, 9 January 2014 (UTC)
 * There have only been three or four fields with sources so far, out of the 80 articles that I've done. The only things sourced are the ratings and the system requirements(e.g.), which are easily re-obtainable anyway. I'm doing this semi-manually with AWB so will keep my eye out for any ref that is worth saving. - X201 (talk) 09:53, 9 January 2014 (UTC)

So it begins
and anyone else who wants to help. The count currently stands at 12,254 articles that need editing. The AWB code that I've been using is below, I've tested it on about 500 articles and its mostly OK, there are still a couple of user generated formatting arrangements that it can't handle, but on the whole it works. I'm only just starting with RegEx so if anyone can improve this, please do. Just copy and paste the code below into a text file, then rename the file as a .xml and then load that into AWB. Please keep an eye open for named refs and check the article to see if they're used elsewhere in the article and do the edit manually. Thanks in advance for any assistance. p.s. the code in the hidden box is a big splurge of text, but it will work, if you want the properly formatted XML you can nick it out of the template code on this page.

- X201 (talk) 16:05, 13 January 2014 (UTC)

I've just spotted a problem with the website field replacement. Its also matching the website field of the Cite:Web template. Suggest disabling that rule. I'll try and get the RegEx fixed asap. - X201 (talk) 09:29, 14 January 2014 (UTC)


 * I've fixed the Website problem mentioned above, Its in the new version below which also implements Izno's suggestion of fixing template redirects at the same time as removing the defunct fields. Please switch over to the new code if you're using AWB. Thanks.

-X201 (talk) 15:07, 14 January 2014 (UTC)
 * You can probably remove the template redirects in this code if we add the pages to AutoWikiBrowser/Template redirects. A trial for that would be good. --Izno (talk) 16:37, 14 January 2014 (UTC)

Change to "Genre" description
To limit abuse of the field and retain a focus, I propose the following minor change to the field guideline. ";
 * The primary gameplay genre(s) (such as first-person shooter, adventure, etc.) the game is categorized in by its developers and publishers, or by reliable sources. This should not include thematic genres (like science fiction, horror, etc.) as video games are more difficult to categorize in such a way. Verifiable thematic genres can be mentioned in the article's body. This field should be limited to no more than 3 genres. For games that fit into several genres, describe in prose in the article body."


 * I do agree on setting a reasonable limit on the number of genres, and 3 seems like a good upper bound. I can't think of any examples that really need more than that where the genres are all central and not minor elements. May be where sources disagree on it, but that's prose material.


 * While we are at it, "categorized in by its developers" is bad, because this is WP:PRIMARY and pretty much fails WP:V if they decide to call it something that nobody else calls it. Activision can call Call of Duty a real-time strategy all they want, but that doesn't make it one. Like everything else, it should be supported by secondary sources. This shouldn't have been there in the first place. — HELL KNOWZ  ▎TALK 14:06, 19 January 2014 (UTC)

";
 * The primary gameplay genre(s) (such as first-person shooter, adventure, etc.) the game is categorized in by third-party reliable sources. This should not include thematic genres (like science fiction, horror, etc.) as video games are more difficult to categorize in such a way. Verifiable thematic genres can be mentioned in the article's body. This field should be limited to no more than 3 genres. For games that fit into several genres, describe in prose in the article body."


 * Updated. I'll note that it was The Last of Us that made me open this discussion as someone added Third-Person shooter to the genres, and while it is in third person perspective and lets you fire guns, it is not primarily a third person shooter, as it features equal emphasis on melee combat, unarmed combat, and stealth, it does not feature a focus primarily on shooting, and at higher difficulties shooting is a last resort, so its hard to justify that as a primary genre. Darkwarriorblake (talk) 14:13, 19 January 2014 (UTC)

Field review
The infobox needs more refined guidelines. This is Doom at the minute, that infobox is a joke and it makes the project look bad. A long list of publishers of questionable importance, right down to two different ones for XBLA releases. These companies have literally done nothing but release an already completed and released game and I'm not sure how they even do that when it comes to XBLA where there isn't even physical media. Release dates for every single release, even the two XBLA releases under different publishers. Even collapsed it is embarrassing and despite basic logic it isn't actually against any guidelines (except for the presence of JP release dates which do not belong. Coming originally from the Film project, I don't understand why the Infobox is used to indulge such an overdetailed history of games. A publisher for a later release, especially a DVD release, is no different to a different distributor release a film on DVD to the one that released it in the theater. The original developer/publisher combo did the work, they brought the work into the world to create an item of varying notability and this should be the info readily and immediately available as an overview, which is the purpose of the infobox. The infobox, like any other table/structure on Wikipedia is not designed to replace prose and yet on the game project it is being used as an excuse to do so, like the VG Ratings template (see Broken Age).

In the same vein, laundry lists of release dates are not of value. It does not provide an informative gain to know that Doom was released on XBLA on January 18, 2012, there is nothing inherently notable about this release or date, and it would be better covered in prose under a Release section. I would like to propose reviewing these existing infobox guidelines to explicitly not implicitly state what dates should be covered, what publishers should be covered, developers, whatever. This is another opportunity to review anything and everything to do with the infobox. DWB (talk) / Comment on Dishonored's FA nom! 16:21, 25 January 2014 (UTC)

I think what we need to do for starters is to make a clear distinction between the game and its ports. Infobox is for immediate key information. Infobox should be for the original game and its primary information (original developer, publisher, platform(s), date(s), etc.). Any port made at a much later date or by a different developer/publisher should not be included in this base data. I also understand the argument that ports are often important and deleting data is frowned upon, so I propose a collapsible field ports for official ports that can contain all the extras -- platform, publisher, date. This way we remove all the clutter for main fields and move it away into an auxiliary list that can be shaped and trimmed on an infobox style guide level and by article-level consensus. I will agree on the surface this sounds like "moving the problem elsewhere", so I will re-stipulate having a small, collapsible list (perhaps spanning both columns) and much cleaner original fields as my argument. I think this is the next step in battling overlong infoboxes for contemporary games and porting sprees. If there is interest, we can expand this into a proper proposal/RfC with examples/use cases and such. (P.S. My most glaring example is Minecraft. Its mobile and console versions are completely different games simply with visuals and gameplay reproduced as closely as possible.) — HELL KNOWZ  ▎TALK 19:03, 25 January 2014 (UTC)
 * I'd say with Minecraft that you don't need a release date for XBL and a 360 disc version, it should simply be the earliest release date for that platform, whether that is digital or otherwise. The guideline already says something like this "Use the first public non-festival release in the game's country of origin, as well as any English-language release dates available", so public release is public release regardless of the method of distribution. Also I believe this, quoted from the Template:Video game release documentation, should be added to the infobox guideline for clarity, because people will not often go elsewhere if they have read the infobox guideline...

""Release dates should be provided from primarily English-speaking regions, including North America, Europe, and Australia/New Zealand. If the video game is first released in a non-English country, commonly in Japan, then that should also be stated ... Releases in non-English countries should not be included in the infobox (unless it is first released in a non-English country), but if determined to be necessary to include, can be discussed further in the article's body.""


 * Release dates should only be given for Japan when the game is first released in Japan. Otherwise Japanese release dates are completely worthless on the English wikipedia. I disagree with creating a separate port table, I think notable ports are obviously notable, and in those cases you would discuss why they are notable but if they didn't create or expand on the content and ported an existing game maybe a decade down the line, what is informative about sticking an otherwise random name in the infobox? The example that comes to mind is Resident Evil 4, where I think the designer said he'd behead himself if the Gamecube version was ported? But that you'd discuss in prose because it's an event in the game's history. Similarly, I think it would benefit to set out that if tasks are handled by the same person, you shouldn't be relisting them either. Again using RE4, you have Capcom listed 3 times as a Developer, regional Nintendo offices and for some reason 3 publishers for Australia? If it's not an Australian game what is informative about this? I think the Video Game Infobox is an outlier here, the Film and Television infoboxes do not give such focus to external distributors outside the country of origin, and 9/10 times this information is going to also be unsourced. Though I think I can agree that if the game is completely built from scratch (i can't say I know enough about Minecraft to say if that is hte case I will take your word for it), then you can argue they should be listed, but probably under a collapsible list so emphasis remains on the original people involved in bringing it into existence.


 * Some of the info just seems outdated and built for older consoles. Such as "Individual development tasks handled by different companies (e.g. scenario, programming) and ports" from the Developer field, and could maybe do with clarifying. That to me reads like if there was a main developer such as is the case with Grand Theft Auto V in Rockstar North, then studios providing non-core tasks (Rockstar NYC, Rockstar San Diego, Rockstar Leeds, Rockstar Toronto, Rockstar New England, Rockstar London, Rockstar Lincoln) should not be listed under "Additional work by" lists. Which I guess seems fair, since referring to my earlier point, they all fall under the same umbrella of Rockstar, and there is more benefit to discussing in prose what their actual contributions were. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 20:45, 25 January 2014 (UTC)


 * Just a quick note about Minecraft: those aren't different release dates for the same game, those are release dates for different ports. Same goes for extra values in platforms, developers, publishers. Currently infobox treats all ports as the same game, which is why I proposed to split them up first, then deal with individual fields. But that's my point - we keep discussing these on article level while infobox only gives vague guidance. I think splitting/trimming off anything beside first official releases for all games would significantly clean up the essence of the topic. — HELL KNOWZ  ▎TALK 22:01, 25 January 2014 (UTC)


 * This is currently the recommended way of doing release dates in the infobox, as a collapsible list, e.g. Minecraft, Half-Life, Half-Life 2, etc. I would prefer if we either made numerous parameters in the infobox for each release (e.g. xboxrelease, xboxonerelease, xbox360release, windowsrelease, etc.) or made a separate template which could be put inside the infobox's release date parameter with these abilities. Preferably with a well-documented help page since the large number of platforms could be complicated. As for why this'd be useful, it would allow the release dates section to be unified across all articles. Currently many articles refer to Windows as "PC", "Microsoft Windows", "Windows", or few variations thereof. There's also the issue that it's often inconsistent in the way it shows release dates on each game. Some are collapsed lists, others are non-collapsed but still use a similar list format, and then others don't use bolding or linebreaks to contrast between which release dates are representative of each platform.


 * I realize Template:vgrelease exists already, but it's not helpful in the slightest for representing multiple platforms, and orders the release dates by region rather than release date (Is there any reason for this? I don't understand it at all). — Nicereddy (talk) 23:29, 25 January 2014 (UTC)
 * If you want to order the dates how you want you should be using Template:Video game release. An improvement to the template may be including some kind of standardized naming and emphasising use of the Template:Small template over bolding format names which is obtuse. But creating individual fields for every format would be a nightmare and is not a practical solution. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 00:23, 26 January 2014 (UTC)

I also see benefit in creating a standardized list of what constitutes an acceptable "format". Batman: Arkham Asylum lists OnLive as a format, yet OnLive is a streaming service streaming PC version of the game, others may list Steam, but Steam is not a platform, it's a distribution device. I also question the use of XBLA or PSN, especially since I am of the understanding that XBLA games will not play on XboxOne? Is that correct. Either way the platform is the console, XBLA is the distribution channel. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 00:27, 26 January 2014 (UTC)
 * Format
 * Very timely and relevant this image from this article on Game Informer shows the insane abuse when not properly reigned in. I'd also propose that GOTY versions (which are just re-releases) and compilation pack appearances should not be appearing in there and should also be mentioned in prose where notable. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 01:22, 26 January 2014 (UTC)
 * We were sort of pushed by OnLive people to include Onlive (or at least "Streaming") as a format, but I'm fine with ditching it. --M ASEM (t) 04:21, 26 January 2014 (UTC)


 * I think a major thing here is that if any field in the infobox gets beyond, say 4-5 items, what's in the infobox should be summarized and a link to a section in the article going into those details should be provided. So, say for Doom, the summary should be to the initial release, and a section in the article about its remakes and ports, including relevant parties, should be listed (prose, table, doesn't matter). If a game, like what DWB points out about Sonic in GI, gets zillions of ports, list the primary/first releases and link to a section describing ports later. Same goes with people involved (if there is that many), and perhaps even release dates. --M ASEM (t) 04:21, 26 January 2014 (UTC)
 * The problem with current guideline is that each article needs to be reviewed separately in the end. Say, if a game only has 1 port, it's easily included in the article. Then it has 2, and that's not too bad. Then it's 3, but established consensus in article is already to include it. Then it gets 4 and somebody objects. Then a discussion is held, but there is no clear guideline that says why and why not to include extra items. It has to be worded clearly -- "don't include ports" or "if more than 2 ports, don't include" or "if more than 3 items, don't include ports" or something that sticks with only rare IAR instead of every second article. — HELL KNOWZ  ▎TALK 10:47, 26 January 2014 (UTC)
 * A single port listing in the infobox is fine. But if that gets to 2 or more, that's when you start considering to break those out and say "See #Ports" giving no favoritism to any port over the others (but respecting the key main game). And often, the thing with ports are most of them are non-notable and just need to be identified for completeness. It's just that the line when to break out something like this has to depend on what's already in there and if the infobox is too large already. It might be possible to retain a nice tight condensed infobox with a game and its 3-4 ports. Just that once the decision is made to extract the ports, all ports have to be extracted, regardless of the importance of one over another, to be fair. --M ASEM (t) 16:47, 26 January 2014 (UTC)
 * "consider", "depends", "possible" is the kind of diplomatic rationale that makes perfect sense for individual approach to each article. Don't get me wrong, I don't disagree with anything. But that doesn't solve the problem with having tens of thousands of pages. We don't have enough editors to hold a discussion on each page when guidelines are so vague and subjective. Boldness to remove/trim is often promptly reverted asking for discussion first. And lesser known games don't get enough impartial comments to form local consensus, in fact the opposite--opinions sway to include it all. Besides, since this information needs to be in prose, that's the expectation for the editor who removes it. What I am saying is that the burden should be with the original content, not with those who try to fix it. The guideline should be strict enough to handle these situations efficiently. — HELL KNOWZ  ▎TALK 17:58, 26 January 2014 (UTC)
 * The biggest metric on when there's reason to move things out of the infobox or use collapsed sections or the like is if the infobox itself, with the image, gets too large. What is "too large" is going to be a huge issue, but the way I would take it is if, under a regular desktop screen using standard settings, that the length of the overall box starts to push past 1000-1200px (eg the current infobox for BioShock Infinite is just tickling that length). The infobox is meant to be "at a glance" and thus ideally all the core details on one "screen" without scrolling, but how to define "screen" with all the various types of devices is near impossible. Thus, instead, it is better to say to trim for sake of a clean infobox, and that is something reasonably objective that can be used to justify the trimming of an infobox BOLDly or to set the star for rationale discussion. I would argue that the number of games that actually have this problem is a minority of our articles. Basically, if you're looking for something strongly objective for reasoning to clean up the infobox, there really isn't one; we can write guidelines about it and have something you can link to when you clean it up to hopefully prevent rapid reverting but we can't force anything else. --M ASEM  (t) 19:41, 26 January 2014 (UTC)
 * We did change a few fields a few months ago where we basically limited a lot of staff fields to 3 or less, I think 3 is a fair number for pretty much anything. As for ports, I think it would be possible to develop a guideline to state what should be in the infobox and what should be covered elsewhere. I certainly wouldn't recommend its infobox which looks terrible, but Ghostbusters: The Video Game had its PS3 and 360 versions, and then for whatever reason the Wii version was developed separately, the same story/characters/settings/missions, but built for motion controls and given a completely different cartoony art style and they were released at the same time, so while it is easy to argue that the Wii/PS2 version was an afterthought since it was not marketed at all compared to the realistic version on PS3 and 360, they are effectively the same game, built by separate entities (although under the existing guidelines, I don't think multiplayer should be under developer and cutscenes definitely wouldn't be). DWB (talk) / Comment on 'Dishonoreds FA nom!'' 20:01, 26 January 2014 (UTC)
 * What's a "port" - at least for determining the difference between the main release and the general concept of ports - has been difficult. I would not call the Wii version of Ghostbusters a port as it was, as you state, released within the same timeframe. On the other hand, where we have problems is like when there's a game for the PC, and the devs have promised a Mac version in the future (often through Aspyr) but that version doesnt come out for 3-6 months. Is the Mac version really a port or not?  In contrast, I want to say that for some of the Telltale Games that they after-the-fact announce support for iOS and which is out within the month, and I wouldn't call that a port but it wasn't part of their initial plan.  If we had to had a hard definition, I would say that a port is not a version of the game that was initially announced by the studio at the time of its first release (regardless of how long it takes to come out), nor a version produced by the same development team and released within a 6 month (rough) period of the initial release. Anything else would be one, but that's again, open to interpretation. --M ASEM  (t) 21:03, 26 January 2014 (UTC)
 * If a version is released later but by the same team it's a lot less conflicting a point to make as you aren't required to add any additional developers/potentially publishers to the infobox. Work done by a third party of an existing game that is announced after the originals release I would consider a port, as it is not within the scope of the original release plan/advertising/promotion. I do think my personal experience has been to see ports referred to as such when its someone translating another developers game to another system, or a platform release developed well after the original by the original developers. So Wii Ghostbusters isn't a port, while XBLA Doom has to be. I think a guideline could be established while leaving room for debate over contested/questionable situations. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 21:48, 26 January 2014 (UTC)

Is there a way to make the field accept only certain terms? We are actually very specific on what can go in there in the guideline, but using Ghostbusters: The Video Game as an example, that clearly doesn't matter and it's difficult to police the thousands of articles edited by people who haven't read these guidelines. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 20:02, 26 January 2014 (UTC)
 * Media
 * Unless we can assuredly list out every possible case for media (or any other field for that matter), it's pragmatically a problem. If we could, yes, we can force the template to only accept certain terms for the media or any other field. --M ASEM (t) 20:46, 26 January 2014 (UTC)

Revival break
Can we talk more about this: I like the sound of this, and I'd be interested in a RfC. Also "if more than 2 ports, don't include" works for me. Others?

And then maybe someone interested can make a mock-up for one of the aforementioned cluttered infobox examples? czar ♔  13:02, 6 February 2014 (UTC)


 * I just fear that we will have confusion and edit wars between something like a Mac OS port of a game that was all planned before the release of the windows counterpart but comes out 2-6 months later by a different company (like Aspyr), compared to a PC version of 10-year old game, etc. I can see that while there would be those handling this with common sense and pragmatism, fanboys may fight to include their preferred port in the uncollapsed part.
 * We can develop rules for what are ports to be included, but we do need to preface common sense must apply. --M ASEM (t) 16:35, 6 February 2014 (UTC)
 * Sorry for taking a while to reply, I have something, I don't know what but I've been bed ridden for a good few days., there will always be edit wars, but having a guideline in place gives something to point to that shows they are in the wrong, allows us to attempt to educate them, and ultimately request they be blocked if they continue to make edits that are deliberately disruptive purely to get their own way. I think it is possible to set up some easy context information, your Aspry example, for example, I would assume in that situation that the version MUST have been in development at teh same time as you can't rewrite code, test it, and release it within 2-6 months. There are the examples raised before with things like Ghostbusters where the versions are drastically different, made by different people, but ARE ultimately the same game, developed at the same time and released at or around the same time, so while there may be a clearly defined lead platform, they're not really ports just different releases. I can't think off the top of my head of an example where a Port has been significantly notable to the original, maybe the PS2 version of Deus Ex which got derided for being massively technically inferior, but as far as I am aware, it's still just the same game that Ion Storm made.
 * Discussion can be used to allow exclusions, but in the case of OSX ports, it seems to not be as much their preferred port, just the only one they can play, and their allegiance to any one particular system cannot be used to bully information in.DWB (talk) / Comment on 'Dishonoreds FA nom!'' 17:16, 8 February 2014 (UTC)
 * A guideline is fine, just something that we need to say "common sense overrules when something should be listed", to avoid the fanboy edit warring. We don't want editors edit warring by, say, stripping all non initial releases from game Y because they can't have their favorite port of game X in the infobox. --M ASEM (t) 17:20, 8 February 2014 (UTC)
 * Well that would fall under disruptive editing and why we want to create a well-rounded guideline without ambiguity. You can add a line like "discuss additions outside these rules on the talk page where necessary". Additionally, the existing guideline discourages the listing of studios that worked on components of hte game but weren't the main developer:


 * So things like Grand Theft Auto V for example, where it is just an arbitrary list. If it can be explained what they contributed it should be discussed in prose, they can be listed in prose as well, but that is just a random list without context. I would definitely mention in the Infobox general guidelines that it is encouraged to expand on things in prose rather than just providing meaningless lists. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 18:57, 8 February 2014 (UTC)

Italics
Is there any reason why I can't see the VG-related pages in italics? (I'm using Chrome); with other non-VG pages it works. ©  Tb hotch ™ (en-2.5). 02:41, 12 January 2014 (UTC)
 * Can you be more specific please? Maybe a screenshot or two to show me what you expect to see? Technical 13 (talk) 02:43, 12 January 2014 (UTC)
 * For example Crash Team Racing title should be Crash Team Racing like in I Am... Sasha Fierce, but it is not the case (I see "Crash Team Racing" w/o italics), and it is repeated in other VG pages like The Simpsons: Hit & Run and Uru: Ages Beyond Myst. ©   Tb hotch ™ (en-2.5). 03:43, 12 January 2014 (UTC)
 * Note: I'm referring to the level 1 header not the lead paragraph. ©   Tb hotch ™ (en-2.5). 03:44, 12 January 2014 (UTC)
 * Can you show me a screenshot because when I follow those links, all of the displaytitles are in italics. Technical 13 (talk) 05:36, 12 January 2014 (UTC)
 * Likewise, I see the titles in italics czar  ♔  07:10, 12 January 2014 (UTC)
 * There was an edit to the template that accidentally caused this; it is already fixed, but it takes a while for articles to re-update. You can edit or purge cache of the page to force it to update. — HELL KNOWZ  ▎TALK 11:41, 12 January 2014 (UTC)
 * Yes, that edit soved it. Thanks. ©   Tb hotch ™ (en-2.5). 05:35, 24 February 2014 (UTC)

Technical Director
I think the Technical Director warrants a place in the Programmer(s) credits. From what I've seen from plenty of game credits, a Technical Director is as important in the Programming Team as the Lead Programmer. Moreover, the relationship between the Technical Director and the Lead Programmer seems to be very similar to the relationship between the Art Director and the Lead Artist, in that the Director acts as the director/supervisor of the Lead. Seeing as how Template:Infobox video game states that the Art Director or Lead Artist must be credited for Artist(s), I suggest that Technical Director can be credited along with Lead Programmer for Programmer(s). --- Wrath X ( talk ) 14:13, 10 February 2014 (UTC)
 * The field for programmer also says it isn't really used in modern games because of the size of teams, and I don't see why it would be except in indie games. You're talking about an unknown, generally unnotable person who is one of hundreds, or in extreme cases, thousands of programmers. Listing them in the infobox doesn't help anyone, unless it is a small or indie game where their contribution could be more significant or solely their own. DWB (talk) / Comment on Dishonored's FA nom! 20:19, 10 February 2014 (UTC)
 * Unknown, generally unnotable person? The Technical Director is technically more important than the Lead Programmer (who is already notable enough to have a credit field). Like I said, the Technical Director is the director/head of the programming team in the same way the Art Director is for the art team. If the latter is important enough to be credited, then why not the former? There are hundreds of people on the art team who work on a game as well, but only the Art Director and Lead Artist are mentioned. Why not the same for the programming team? I'm just trying to be consistent. I'm merely suggesting that "Technical Director" be mentioned as a synonym for "Lead Programmer" the same way "Art Director" is for "Lead Artist". Moreover, I think the reason the "field is often unfilled in modern high budget development due to large team sizes and collaboration" is because the large team sizes means there isn't a Lead Programmer (the work is divided between several people). However, there are still several "big" games that use a Lead Programmer such as The Last of Us, Red Dead Redemption, XCOM: Enemy Unknown. --- Wrath X ( talk ) 06:08, 11 February 2014 (UTC)
 * You're using fields as arguments against me when I don't support the use of those fields on large games either. There are hundreds of artists, putting the head artist doesn't help anything, they don't have an article, they didn't produce the art single handedly, for all we know they sat on their hands and barked orders all day. On large scale projects it's entirely unfair and misrepresentative to put just one name there and exclude all the others. It's also misused because the field says "Artist", and they weren't the Artist(s), they were the artistic director. Adding a field for a job title that apparently means the same as programming but not does not seem to be the most important thing the infobox currently requires. The credits for some games are 10-15 minutes long, like the Last of Us, who are we to pick a random bunch of roles and names to highlight over others? In modern games there is clearly a bias towards presenting the writers or directors, these are small handful roles and easy to credit. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 19:30, 11 February 2014 (UTC)
 * Regardless, Template:Infobox video game is used as a guideline for video game articles on Wikipedia, apparently reached by consensus. I'm not arguing for or against it. I just want it to be consistent. --- Wrath X ( talk ) 21:10, 11 February 2014 (UTC)
 * Still waiting for a response. --- Wrath X ( talk ) 16:57, 13 February 2014 (UTC)
 * My response remains the same, you require outside input to me. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 21:52, 13 February 2014 (UTC)
 * If that's how you say it, then how about I propose the removal of "Art Director" on the Artist(s) field? So we don't credit the Art, Programming, Design (team based) directors. Just trying to be consistent here. --- Wrath X ( talk ) 12:51, 22 February 2014 (UTC)
 * I think it needs more refinement than removal, on older titles or indie creations, such a role might be the singular contributor or actual major contributor to the role (I can't think of any off the top of my head I am just thinking of older stuff like Megaman or whatever that probably had teams of 20). The original changes made... like just over a year ago I think were fine in principle, but I question the usefulness of listing such roles on bigger blockbuster titles where the individual contribution of any one person is potentially non-existent or supervisory rather than hands-on. DWB (talk) / Comment on 'Dishonoreds FA nom!'' 21:54, 22 February 2014 (UTC)
 * So, any ideas on how to refine or improve on the infobox? Or at least a way to differentiate those who supervised from those with hands-on work? --- Wrath X ( talk ) 15:55, 24 February 2014 (UTC)
 * My thoughts mirror User:Darkwarriorblake's comments. Fields like "artist" and "programmer" or "designer" encompass multiple or dozens of people on AAA games; including a single name or just a few names is worse than omission, it actively distorts the facts. If more descriptive labels are not being used, the names shouldn't be part of the infobox (there's also the question of why we would include credits in the infobox when they might not be mentioned in the article itself, or the personnel are not notable enough for their own articles.)


 * If that conflicts with the infobox documentation, then it's best to reappraise it entirely and advertise at VT:VG than follow it like a suicide pact. Der Wohltemperierte Fuchs ( talk ) 16:21, 24 February 2014 (UTC)

The main point that I remember about the "creatives" fields is that they were there as an addition to people who should have been mentioned in the prose. The spirit of the discussion was very much, only add them to the infobox if they warrant a mention in the prose. - X201 (talk) 16:51, 26 February 2014 (UTC)

Personally, I think the infobox should distinguish between those with a hands-on job and the ones supervising. For example, Template:Infobox video game states to "List the person credited as "art director" or "lead artist"" for the Artist(s) field, when in fact it's pretty inaccurate to credit an Art Director in the Artist(s) field. Either add an Art Director(s) field or don't list the position at all. Same goes for Design or Technical Program Director. --- Wrath X ( talk ) 05:27, 28 February 2014 (UTC)

More descriptive credits
I think the video game infobox needs to be more flexible. Unlike films where there is always a director, producer, cinematographer, etc., video games don't have fixed credit labels. While some games have game directors, others have creative directors, or project leads, or project supervisors. None of these positions are technically the same and yet the infobox generalizes them by inaccurately placing them in a single Director(s) field. These game leader positions should be clearly defined. Several articles are inconsistent because of this, for example, Good article Portal 2 has the infobox list Joshua Weier as the director when he actually is credited as the project lead; Featured article BioShock on the other hand lists creative director Ken Levine as the director, while the actual project lead Alyssa Finley is not listed.

The infobox also needs to distinguish team directors from actual team members. Template:Infobox video game actually instructs to list Art directors in the artist field or design directors in the designer field. As Der Wohltemperierte Fuchs  noted "Fields like "artist" and "programmer" or "designer" encompass multiple or dozens of people on AAA games; including a single name or just a few names is worse than omission, it actively distorts the facts." If we're listing an Art Director then he should be listed as Art Director. It's these types of inconsistencies that make editing video game articles frustrating. --- Wrath X ( talk ) 12:08, 3 March 2014 (UTC)


 * If anything, my 2c are that, credit fields need to be less flexible. They shouldn't list anyone the prose doesn't discuss or anyone who doesn't fall under role definitions. Infobox is supposed to be an overview and shouldn't contain non-obvious material not described in prose. Most of these credit field additions (usually to non-notable people) are listed in infobox and never described in prose. There is no context of what exactly they did or what impact their role had. And video games are terrible with inventing and retitling roles to various non-standard "director", "technical", "senior", etc. terms. This is more reason not to include people that the article doesn't talk about. Because, if there is nothing to say about them, then there is most likely no point in listing them in the infobox -- it doesn't explain what they did besides their title. Seeing a person X in credits says nothing unless I already know who they are and--even then--it says nothing about what they actually did. — HELL KNOWZ  ▎TALK 12:55, 3 March 2014 (UTC)


 * I wasn't necessarily suggesting we list anyone the prose doesn't discuss or anyone who doesn't fall under role definitions. I was mainly trying to say that those who are listed should be listed right. Now you do make a valid point regarding my first paragraph, but what about the second one? My main gripe regarding the infobox is that it should distinguish team directors from actual team members. While the infobox works for small independent games that generally have lead designers, programmers, artists, it doesn't do the same for those AAA games that usually work in teams with design directors, program/technical directors, and art directors. I feel that, instead of the infobox instructing to list the three aforementioned directors directly in the designer, programmer, and artist fields, it should at least have additional fields for them. Either that or don't list them at all, as it's unfair to the actual workers of the game. There are several notable examples of these directors (i.e. they have their own articles) that are listed inaccurately. For example Yoji Shinkawa, art director of Metal Gear Solid games, is instead listed in several articles as the actual artist as per Template:Infobox video game. John D. Carmack, program/technical director of several games, is instead listed as the actual programmer. --- Wrath X ( talk ) 14:42, 4 March 2014 (UTC)


 * Similarly, my point re "it should distinguish team directors from actual team members" is that prose should do this. Indeed, if we list indie programmer on a one-man game same way we list lead programmer on some AAA title, infobox given no context. My opinion is that prose should be the one to describe that company X lists person Y as having done role Z responsible for features Q. Then we can also add them to the infobox for an overview and the reader can learn specifics in the text. Even if we account for "director" and "technical" and all those fluffy titles in the infobox, they still don't give any context. I do agree that the infobox makes no visual distinction between "one man programmer", "main programmer(s)", and "lead programmer(s)" and are all listed the same way. However, even if we had "lead artist" or similar, this still doesn't explain if there were 1 or 100 artists or if he was the one drawing or the one managing. The fields are already for main and lead roles. Having read all the above discussions, I'm just not sure more fields will solve this. — HELL KNOWZ  ▎TALK 15:23, 4 March 2014 (UTC)


 * The main point I'm trying to get across is that team directors are entirely different roles altogether. I understand that you're saying the fields are for main and lead roles, and I agree. I have no problem with the Infobox listing, say for example, the lead artist or any notable artist in the Artist(s) field; I do have a problem with the Infobox guidelines instructing to include the Art Director in that field. A lead artist is not an art director. While an artist actually works on the material with a hands on approach, the art director more-or-less supervises and instructs the actual artists. To add any artist in the artist field is logical, to add the art director in that field is just untruthful. All I'm suggesting is to either remove the Infobox rule stating that team directors should be included in the fields, or to simply add just three director fields for the design, program, or art teams. --- Wrath X ( talk ) 7:44, 5 March 2014 (UTC)


 * "A lead artist is not an art director". There are at least 3 already-cited sources using "art lead" to describe exactly what "art director" does in game art design. Just taking a source like this: "[art director]'s even defined differently among game companies: art lead with technical experience, lead artist who can script, art director but must be hands-on, publishing art director with program management skills, etc." Even if we split the fields, how are we going to source how each company defines their roles from indie to AAA? You can be as meticulous as you want with definition, but that doesn't change that video game companies don't necessarily use them the way you would expect. — HELL KNOWZ  ▎TALK 10:20, 5 March 2014 (UTC)


 * Okay I concede, let's leave the fields. I do like to point out though that while Template:Infobox video game instructs to list the lead artist and art director in the artist field, and list the lead designer and design director in the designer field, it only says to list lead programmer in the programmer field and fails to mention the program/technical director. So could someone just see to that if it's not too problematic. Also, in the same way lead planner is a synonym for lead designer, lead engineer is a synonym for lead programmer. --- Wrath X ( talk ) 10:35, 9 March 2014 (UTC)


 * For films, more often than not the credit lines in the infobox will be filled with notable (blue-linked) people, meaning that readers can learn more about these people elsewhere. For video games, 90% of the time the credits are non-notable people. It does not make sense to include more credit lines that will include more non-notable people. Thus we should avoid doing any expansion in credit lines on infoboxes, and real should only be filling in lines when one or more of those are likely to be blue-linked names. --M ASEM  (t) 15:28, 4 March 2014 (UTC)
 * I don't think giving more options, and potentially more lines for a longer infobox, is a way to go, but if more suitable titles can be created I wouldn't mind, as long as the purpose isn't solely to allow for the addition of otherwise unnotable people. The obvious solution for Director would be, IMO, Project Lead, but I imagine that label would be too long and break the infobox layout, but it would serve as a catch all for whoever was in charge. DWB (talk) / Comment on Dishonored's FA nom! 21:29, 5 March 2014 (UTC)

Release date titlestyle
Is the "titlestyle" portion of the documentation's release date collapsed list directions still accurate? The 12px font part seems out of place. czar ♔  12:34, 22 March 2014 (UTC)

Move to template infobox
Hi could we move this to infobox meaning we would update it to look like

Please Paladox2017 (talk) 15:35, 3 April 2014 (UTC)


 * Why? What does it do? What are the benefits? - X201 (talk) 15:53, 3 April 2014 (UTC)
 * It looks like this would make this less standardized, which is not what we want to do. --M ASEM (t) 17:02, 3 April 2014 (UTC)
 * no it would just add infobox template to the template. It would also be easer to add more labels and add more data. — Preceding unsigned comment added by 86.135.250.172 (talk) 17:16, 3 April 2014 (UTC)
 * Which we don't want. We've trimmed out things to avoid having the infobox get excessively long. If there are specific fields you'd like to see you can request them, but I doubt we will want random label additions. --M ASEM (t) 17:17, 3 April 2014 (UTC)
 * oh but why not. 86.135.250.172 (talk) 18:24, 3 April 2014 (UTC)
 * I think sufficiently explained why not. We don't want extra info cluttering up the infobox. You can request specific things to be added if you think they're necessary. &mdash; Fr&epsilon;ckl&epsilon;fσσt | Talk 18:32, 3 April 2014 (UTC)

preceded_by and followed_by
I believe that preceded_by and a followed_by fields are needed for the video game info box, as many video games have successors/sequels.Kentronhayastan (talk) 21:00, 8 June 2014 (UTC)
 * Its been asked for 11 times in the last 8 years, it even has its own private talk archive because it comes up so often. The short version of it is that the job is done perfectly well at the foot of most articles with a navbox. There stuff can be laid out as it needs to be, rather than the arguments that would ensue from what is canon and non-canon in a single infobox field. - X201 (talk) 09:02, 11 June 2014 (UTC)
 * Since it is so frequently-asked, might it be worth someone adding some notes to the documentation to explain this and how to do it (or linking to a source)? I can do so later on, but am fairly unfamiliar with standard practice for this, so it may be better addressed by someone with more experience in such construction. — Sasuke Sarutobi (talk) 09:41, 11 June 2014 (UTC)
 * I'm not quite sure what you're saying. I was pointing out that its been asked for numerous times and has been opposed and rejected on all occasions. In short there is a long standing consensus to not have preceded by and followed by fields. - X201 (talk) 12:29, 11 June 2014 (UTC)
 * And pointed out that game articles in a series may have a navbox at the bottom. For example:


 * Creating them is rather straight-forward (if you're familiar with wikimarkup). You can ping me on my talk page if you want some pointers. — Fr&epsilon;ckl&epsilon;fσσt | Talk 13:33, 11 June 2014 (UTC)

Media: Cassette tapes.
In the Syntax Guide, under "media" it says: "The only values possible are "floppy disk", "cartridge", "memory card", "optical disc", "download", and "cloud computing" (and combinations thereof)."

What about early games that were released on casette tapes? I don't know how to do it, but I think that should be made a possible value as well. — Preceding unsigned comment added by Derboo (talk • contribs) 19:27, 3 July 2014 (UTC)
 * The listed categories are a guide, just type cassette in, see template to right. - X201 (talk) 06:02, 4 July 2014 (UTC)

Rating system
So there's still a lot of games on Wikipedia with the rating system that finished in 2012, as seen here Template talk:Infobox video game/Archive 11 Is there a project involved to go round to all these games and remove the video game ratings template to clean up the infobox, or does it stay in the infobox? Just wondering, as I had already started a couple of video games that feature the template, featured in the What links here section. --Mjs1991 (talk) 09:59, 17 May 2014 (UTC)
 * There was "We're editing 42% of all WP:VG articles" (Archive 104), but I don't know the status of that effort czar ♔  14:36, 17 May 2014 (UTC)


 * Don't worry. I'm working on it. The end of days is soon approaching for those. I'll post an update tomorrow. -X201 (talk) 20:48, 18 May 2014 (UTC)

Update
So given the previous threads about the removal of defunct fields. There was a delay whilst we gave Wikidata the chance to salvage what they want from it. They have now completed that and we're almost ready to start a run to get rid of the defunct fields. I've started testing the new AWB script that we have for this, mainly to see if it can handle the different formatting of the requirements section and other formatting oddities that exist out there. So in summary, yes, almost 5 months after setting the ball rolling, we're on the brink of getting the clean up started. - X201 (talk) 08:04, 20 May 2014 (UTC)


 * So there's an easier task using AWB rather than actually checking the "what links here" page? Is their a link that shows how to do this?

--Mjs1991 (talk) 14:14, 20 May 2014 (UTC)
 * Yes, no need for the manual method, that way will send you mad. There's an AWB script that I'll post after I've finished testing it. It does a multitude of things in one hit, it removes all of the defunct fields (picture format, aspect ratio, input, license, resolution, ratings, requirements, version, preceded by, followed by, latest release version, latest release date, latest preview version, latest preview date, website) from the template, it also corrects instances of Infobox VG to Infobox Video game as well as doing all of the usual AWB general fixes. Give me another day or two to finish testing it (have found one glitch that people need to watch for when using it) and I'll post it here and you can download it and let rip with AWB on the 11,000 articles that need fixing. - X201 (talk) 14:39, 20 May 2014 (UTC)
 * I think I've managed to fix the big problem I found (Matching was going mental when it came across a vgratings template that had references inside it). I've also added a small formatting fix, to move title down to a new line when its on the same line as the template name. I'll put another load of articles through it to find more errors and then post the code up here for anyone who wants to join in. - X201 (talk) 15:58, 21 May 2014 (UTC)


 * Thanks for that!!--Mjs1991 (talk) 21:29, 21 May 2014 (UTC)
 * I added the infobox name change to the genfixes via the template replacement page, so you can probably remove that from your changeset. --Izno (talk) 01:42, 22 May 2014 (UTC)
 * Done, thanks. - X201 (talk) 08:45, 23 May 2014 (UTC)

We need your help again. I've found another defunct template field, called footnotes (see discussion), it was a short lived one, but its just cropped up on an article so stands the chance of cropping up on others. Could you create the tracking category template code to find it, and get it added to the template please? We may as well do a thorough job on this. Thanks. - X201 (talk) 08:43, 23 May 2014 (UTC)
 * Doesn't look too difficult; according to what I can read from the source code, I think if you just add a single line to the list of deprecated parameters like , instead of  ''', thus avoiding a redirect within the template.  The change to be made is on line 16 as follows —

IS NOW:

CHANGE TO:

— QuicksilverT @ 15:40, 4 August 2014 (UTC)


 * Oppose as per MOS:NOPIPE - X201 (talk) 15:50, 4 August 2014 (UTC)

Cover art border
Observe the cover art for Final Fantasy VII. That, along with many others, needs an infobox field to add a 1px border like Template:Infobox album. The last time this was proposed was in 2006, so it's high time someone brings it up again. Make it happen? Mac Dreamstate (talk) 21:16, 8 September 2014 (UTC)
 * I was a bit puzzled by your examples to start with, Nevermind on the album Template page wasn't the best choice to indicate the added border. The Beatles White album is much better at the job. As regards the function, I'm not sure if it would be a benefit or not. - X201 (talk) 08:43, 9 September 2014 (UTC)
 * Why would it not be beneficial? It is clearly a helpful feature on album pages (your example was perfect), and video game cover art often suffers from the same whitespace problem on WP. After eight years since it was last suggested, is it still that hard to implement? Mac Dreamstate (talk) 13:02, 9 September 2014 (UTC)
 * No, unless albums, our VG box incorporates the use or more than just video game covers - we have screenshots, we have title screens, we have standalone logos, etc. Forcing a 1px border is not good across the board. Additionally, most VG art is not as abstract as cover art where it would be more helpful (the White Album a good example of a rare case it might be needed). I will note that one can add "border" to an image to add a border, so this might be good for rare cases that need it. --M ASEM  (t) 13:11, 9 September 2014 (UTC)

Licensing
Perhaps an additional license field much like that of the software template may be beneficial, particularly for ease of differentiation between free and non-free games

122.148.182.166 (talk) 10:55, 17 September 2014 (UTC)
 * Please include a specific edit you want to be made when placing ; if you just want to discuss options, the edit request isn't needed. — xaosflux  Talk 11:49, 17 September 2014 (UTC)


 * We used to have a license field and decided to get rid of it. Also, please read the note at the top of the page and seek consensus before using the Edit Protected template, thanks. - X201 (talk) 14:18, 17 September 2014 (UTC)

Remove alternative field name (Mode)
In the template, mode can be used instead of modes as the field name. The mode option is not used in any article, all articles that use the infobox now use modes; there were 10 articles that used to use mode but I edited them so that they now use modes. As an aside, the code in the the template doesn't work correctly when mode is used, it puts the field in the template but doesn't display the field values. I propose that we remove the mode alternative from the template code and standardise on modes. - X201 (talk) 09:51, 16 September 2014 (UTC)
 * It's been three days and it sounds uncontroversial so go for it czar ♔   22:10, 19 September 2014 (UTC)

Please change:

To:

Thanks - X201 (talk) 13:52, 22 September 2014 (UTC)
 * done. Frietjes (talk) 19:16, 22 September 2014 (UTC)

Article Infobox code cleanup
The cleanup of infoboxes can finally start. I've manually cleared all of the awkward stuff (User pages, Talk pages, Drafts, Template code etc) from the category. I've also cleared things that don't play well with this code, such as Hidden List, Collapsible list, and templates that use the same field names (Software and VG Series), so you shouldn't come across them, if you do, either skip them or fix them manually. The really important part of this is doing it via AWB with General Fixes switched on. We are only allowed to do Gen Fixes as part of another larger job, so this is our chance to fix a lot of common errors that are in our articles, it also allows us to correct a number of templates names as well. If you have Bot level access to AWB, please don't use automatic mode as there is still some nasty user created formatting out there waiting to trip you up (some of it is real head scratching stuff). There's no rush to get this completed, I'm happy to do all 9000 articles on my own if it means getting the benefit of the General Fixes and allows a pair of human eyes to spot other errors in an article (you will, trust me).

Just copy the code in the above window, paste it into Notepad, save it as FileName.xml, Load it into AWB, press Make List, and away you go. I'll ping because they expressed an interest in taking part, I'll also drop a note at AWB tasks in case anyone wants to use it as a filler job. If you join in, please just add a "Me too" to the bottom of this, so we can list everyone who helped at the end of this. - X201 (talk) 11:31, 11 August 2014 (UTC) Please notify me of any erros or of anything extra that we can fix as well. - X201 (talk) 11:31, 11 August 2014 (UTC)
 * I'd be happy to help with this. Will do some here and there as I have time. Sam Walton (talk) 12:11, 11 August 2014 (UTC)


 * Thank you, !! I've been waiting for this day. I'm definitely in.--Mjs1991 (talk) 22:10, 11 August 2014 (UTC)
 * - Have done ~200 edits so far, but this one broke some bracket syntax for some reason, might want to investigate why. Sam Walton (talk) 10:14, 12 August 2014 (UTC)
 * It's because there are too many line returns in it. I've tried coding for it, but because the layout is user created there are far too many variations to code for, and it causes too many problems with all of the other fields. The Requirements field and the ratings field(its references that break that one) are the two fields that can cause a break, its a case of keeping an eye on the AWB window and either skipping the edit or manually removing the requirements field, then proceeding with the AWB edit. Thanks for the edits so far. Any other problems apart from this one? - X201 (talk) 10:26, 12 August 2014 (UTC)
 * I see. Will keep a closer eye on it in future. No other problems really, apart from coming across Portal:Chronicles which I've CSD'd. Sam Walton (talk) 10:42, 12 August 2014 (UTC)


 * I'm having difficulty finding out how to load the document into AWB as it doesn't seem to find the file at all --Mjs1991 (talk) 09:06, 14 August 2014 (UTC)
 * Can you tell me what you've done so far and I'll work out what the problem is. - X201 (talk) 09:10, 14 August 2014 (UTC)


 * I've copied the code to Notepad and done FileName.xml, its just finding out how to put it through to AWB that I'm having issues with. Not too sure where to go from there, in regards to loading it. --Mjs1991 (talk) 09:16, 14 August 2014 (UTC)
 * In AWB: File > Open Settings, browse to the place you saved FileName.xml, open it, click the "Make List" button" (It's on the left, just below centre). After the list has populated, click the Start tab, and then the Start button on that tab. Do the account login stuff and you should be up and running. - X201 (talk) 09:24, 14 August 2014 (UTC)

Thank you --Mjs1991 (talk) 09:28, 14 August 2014 (UTC)
 * And make sure you do the above with a clean version of AWB, as it has a horrible habit of merging a newly opened list into a currently open one. - X201 (talk) 09:30, 14 August 2014 (UTC)

Progress
That's the first 1000 articles fixed. Well done Chaps/Chapesses - X201 (talk) 10:02, 14 August 2014 (UTC)


 * In an amazing act of serendipity, the last person to edit managed to stop with 6365 articles left to do. The reason this is amazing is because its exactly half way from the 12000+ articles that this whole thing started with back in January. - X201 (talk) 08:02, 22 August 2014 (UTC)

So, one month gone and we've managed 5,500 articles. Keep that pace up and we should complete it before the two month mark. - X201 (talk) 07:54, 12 September 2014 (UTC)

have we finished all the articles, because nothing else is coming up on AWB for it --Mjs1991 (talk) 00:14, 12 October 2014 (UTC)
 * Yep, it is done. I'll keep the category active for another 6months/year just to mop up anything that crops up with an old field on it. But as for the tidy up, its done, 10,000 articles in this phase, 12,000 overall, with the side benefits of General Fixes on 10,000 articles, many hundreds of user pages tagged and cleaned up, in association with another clean-up redirects to Infobox VG have been slashed from 12,000 to 5000, numerous other problems/queries have come to light, but above all heaps of dead code has been removed from articles. Thanks for your help, and of course and  too, and  for starting the whole thing off back in January and  for doing the template shenanigans for the tracking category.


 * The next task is for me to get my edit count back to its below 1000 edits a month level, until I've got the next phase of the clean-up ready to roll next year. - X201 (talk) 10:15, 12 October 2014 (UTC)
 * No worries, sorry I slacked the past few weeks! Good job all :) Sam Walton (talk) 16:05, 12 October 2014 (UTC)

Important
I've spotted something that I'm not happy with. There's a clash with the AWB code and Cite Web, I think the number of articles affected is very small, but because this risks damaging references I'm not taking any chances, we need to stop checking for the "website" field, and sort it out at the end of the clean-up. I'm not sure how good you are with AWB, so I've written step-by-step instructions on how to disable that bit of code. Alternatively, you can follow the instructions above to create a new file by copying the new code from here.


 * 1) At the bottom of the screen, in the central control panel, click the Options tab.
 * 2) Click Advanced settings.
 * 3) In the left hand list click Remove web so that its highlighted in blue.
 * 4) Untick the Enable box on the right of the screen.
 * 5) Click the sub-rule titled  \n\|( *?)website(.*?)\n 
 * 6) Again, untick Enable
 * 7) Click on any other rule. Both of the web rules should now be bright red to show they're disabled.
 * 8) Click Close.
 * 9) Save your settings.

It looks like we have a three pronged attack going at the moment; alphabetic, reverse-alphabetic and from the middle. Thanks for the help with this. - X201 (talk) 14:33, 15 August 2014 (UTC)
 * Ooh-er, changed my file. Sam Walton (talk) 18:35, 15 August 2014 (UTC)


 * My AWB was perfectly fine, the web rules were already displayed in red.--Mjs1991 (talk) 06:48, 17 August 2014 (UTC)


 * I've just checked every article that has been, or would have been, edited during this clean-up and the good news is we haven't broken any references. There were only 37 articles that could have been affected. - X201 (talk) 15:24, 18 August 2014 (UTC)
 * Have you edited those 37 to remove the website parameter manually? Sam Walton (talk) 15:28, 18 August 2014 (UTC)
 * Yep, those 37 are no longer in the category. Most of them didn't have the website parameter, but because they had at least one old field, they were in the category, then when AWB scanned them, it mistakenly tried to remove the website in the cite web template. They are no longer a problem now, so you can turn the website search back on if you want. - X201 (talk) 15:43, 18 August 2014 (UTC)

FYI I had another bugged edit, since reverted. It seems the title field from the reference was mistaken for the template's title field, similar to the previous issue I believe. Sam Walton (talk) 09:00, 28 August 2014 (UTC)
 * Thanks, I'm on it. I'm fairly certain that I know what caused it. Will report back. - X201 (talk) 09:39, 28 August 2014 (UTC)


 * , I had a similar issue (here) with the infobox stuffing up.--Mjs1991 (talk) 10:41, 28 August 2014 (UTC)
 * Found it.
 * Follow steps 1 and 2 of the instructions above. Then look for a rule called . Click that rule to highlight it, then untick the   setting, close and save your settings. Thanks for pointing this out. - X201 (talk) 13:27, 28 August 2014 (UTC)
 * Another weird one. AWB was happy to remove the line |requirements= but didn't recognise that the list of requirements underneath was attached to it. I removed them manually in the linked diff but you can see the layout in the previous article version. Sam Walton (talk) 17:38, 28 August 2014 (UTC)
 * And in the completely opposite fashion, it wanted to remove everything below requirements from |this article, including the valid fields (again, I fixed it manually). Sam Walton (talk) 17:52, 28 August 2014 (UTC)
 * The requirements things is because of what I mentioned above. Because users create their own variations on how to layout the info in that field, and because there is no guarantee that requirements is going to be in a specific place in the infobox, it makes it hard to search for. I had to go for the compromise option of four different search patterns that catch the majority of formats in the requirements field, after four the interaction between each one got worse and worse and the results got more and more erratic, hence the compromise. If requirements was guaranteed to always have a certain field after it, it would be easy to code for, but because the following field could be anything it makes it a bit harder (although in typing this I've just had an idea) - X201 (talk) 08:00, 29 August 2014 (UTC)
 * I think I've cracked it. Just need to test it. - X201 (talk) 08:50, 29 August 2014 (UTC)
 * In light of the above reports, I've updated the AWB code. The new version is here. I created a Test Page with the infoboxes that you reported problems with and ran the page through the new code, everything was fine. No doubt there will be articles out there with some kind of formatting that I haven't taken account of, so we'll have to play those by ear. If you get any odd occurrences, let me know. Once again, thanks for the help with this. - X201 (talk) 13:58, 29 August 2014 (UTC)
 * Are we still disabling the check for "website"? Also might be worth removing the parameter for price, since I've seen that one a few times. As long as we're doing this, it might be good to have something that converts the CD-ROM (or DVD) into "Optical disc" and "Digital download" into "Download", if you're interested. (Or we could do one better and remove the field, because I'm never sure whether it's accurate and it almost always doesn't follow the guidelines...) Also System Requirements (or requirements is another frequent that could be removed. And might it be worth sanitizing the image field to remove braces and manual image size adjustments? Doesn't the template do that already? czar ♔   14:26, 29 August 2014 (UTC)

I'll try and get those done today, but it will probably be Monday if I'm realistic. - X201 (talk) 15:14, 29 August 2014 (UTC)
 * 1) Website: I've re-enabled it in the current version along with making sure singline was turned off. I've run the best part of a thousand articles through it without a problem, but there's always the chase of something making it malfunction.
 * 2) Price: Shush, that's the TOP SECRET Stage Two that I haven't told anyone about yet. Once we've got the known rubbish out of the system, we can then start on the unknown rubbish. The best way to find it is to search for anything that isn't a valid field, it will need more code adding to the Template though. And another tracking category.
 * 3) Optical Disc/Download: Good idea, will knock up a test.
 * 4) Requirements: Hopefully this is being removed, its been in the code since day one, and was the reason for the last update.
 * 5) Image: Will look at it, although the template isn't bothered if it has brackets or doesn't.
 * 6) Image Size: By manual adjustments do you mean the 250px commands? I've pondered getting WP:VG to approve converting everything to the Frameless upright method as that allows user preferences to work.
 * Re: requirements, I had several that weren't picked up. For example, I did Dragonica's manually and Drift City didn't pick up on the rating or requirements fields. Re: optical disc, might be worth including something that turns "single player" to "single-player" too. Re: image, it's more that since we're doing cleanup anyway, might as well put the image into the best machine-readable format, which would seem to be removing the image size syntax (e.g., ). Might it be worth building frameless upright into the infobox itself? czar  ♔   15:29, 29 August 2014 (UTC)
 * Did the requirements failure happen with the new code I posted about 2 hours ago? - X201 (talk) 15:36, 29 August 2014 (UTC)
 * Yes, I loaded the updated code before running this morning. Just happened on this one and on this one too (removed requirements manually). Can you replicate? czar ♔   15:39, 29 August 2014 (UTC)
 * Replicated it, and found it. In the rules, switch the rule called Main from Inside templates to Entire text. - X201 (talk) 15:54, 29 August 2014 (UTC)
 * Have updated code on the AWB code page. Have copied infobox of articles that caused problems to the Test Page, try a test edit on that. - X201 (talk) 15:59, 29 August 2014 (UTC)


 * , an edit here seemed to remove the website and accessdate from the references.--Mjs1991 (talk) 21:48, 1 September 2014 (UTC)
 * OK, thanks. Have fixed it and uploaded a new version of the code.. It was caused by a combination of things, but mostly me. The cite web title field may also trip up, but that will take me a bit longer to update, as it does more than just remove stuff. - X201 (talk) 08:17, 2 September 2014 (UTC)

Hello all. I've updated the AWB code with some improvements and new fixes. New code to make the number of false matches very very low, and code to match alternate field names and switch them to the preferred version in the Template instructions. - X201 (talk) 08:22, 17 September 2014 (UTC)

, an edit here seemed to break the infobox by not going past a Endplainlist Template in the infobox.--Mjs1991 (talk) 12:39, 25 September 2014 (UTC)
 * OK, thanks, will see if there are going to be more like it. - X201 (talk) 13:15, 25 September 2014 (UTC)
 * CONGRATULATIONS you found the only VG Infobox in the whole of Wikipedia that uses the plainlist template. Your prize is a foot rub from Jimmy Wales. ;-) - X201 (talk) 13:37, 25 September 2014 (UTC)
 * Correction: You found the only one that was formatted in that specific manner. Have found others with different formatting. My initial opinion is that it will only be a problem if the field to be removed is using plainlist. Will have to check if that is true. I already know what the probable solution will be if it is true. in the meantime, of the 1700 Infoboxes left to process, 13 of them have got Plainlist in them, so keep an eye out for them. - X201 (talk) 15:58, 25 September 2014 (UTC)

Rationale?

 * Hi guys. Where's the discussion or explanation or rationale of any of this?  How did this apparently just appear on this talk page as an execution of a longstanding idea or whatever?  Are there parameters in the infobox which became deprecated in the template code, or which were never supported?  Which ones?  Why would you destroy data rather than relocate it or support it?  Thanks. — Smuckola (Email) (Talk) 13:30, 8 September 2014 (UTC)
 * Hi Smuckola, please see the current first discussion on this page, and the discussion at WP:VG. I'm not sure if there were further discussions elsewhere, but the fields' data was I believe saved to Wikidata before this cleanup began. Sam Walton (talk) 14:05, 8 September 2014 (UTC)
 * Two good links at the top of Template_talk:Infobox_video_game czar ♔   14:36, 8 September 2014 (UTC)
 * Hello, most of the fields were removed from the Template four years ago in a major discussion. After waiting for any challenges to that consensus (e.g the Engine field was re-added to the template) users have been slowly removing the defunct fields in the process of normal editing. At the start of this year I suggested a clean-up plan, in the course of getting ready for that, WikiData were alerted and have harvested the data that they wanted from the defunct fields. This is now just the last stage; removing the defunct code to make the template markup easier and less confusing for all editors, especially new ones. Hope that explains it. - X201 (talk) 15:35, 8 September 2014 (UTC)

I'm not sure what happened at this edit to Freedom Fighters (video game). I have reverted it back to the previous version. It needs manual cleanup by someone who understands the infobox. Be careful out there. – Jonesey95 (talk) 00:19, 6 October 2014 (UTC)
 * Fixed it. It was caused by the fact its one of the few articles that actually has a reference in the writer field. - X201 (talk) 08:17, 6 October 2014 (UTC)

Designer
Since this infobox is only for video games, shouldn't the field Designer(s) link to Video game design? . Hakken (talk) 12:40, 8 December 2014 (UTC)

Virtual Reality support
Hi!

Could we add a new field - "Virtual reality support"?

A lot of games are already supporting some sort of a virtual reality device (like Oculus Rift, Razer Hydra etc), and many more'll come because of the Project Morpheus and similar projects. It would be awesome to indicate this feature.--Ewigekrieg (talk) 18:15, 13 November 2014 (UTC)
 * I think this would be a useful addition as an optional parameter for games that use it. I do not believe it should be included in all articles with something like "Virtual Reality Support: No" but it should be added to games that do support it. Maybe like "Virtual Reality Support: Oculus Rift". Keavon (talk) 04:57, 10 January 2015 (UTC)

Developer Info box
Why co-developers and ports developers can't be mentioned in the info box developer section like in Assassin's Creed Unity and Rogue. Template:Infobox video game has stated that they should be mentioned in text but I don't understand. Co-developer is STILL developer. They has contributed in the game's development. I don't see the point for not adding them into the info box. AdrianGamer (talk) 10:19, 7 November 2014 (UTC)
 * Because modern video games are sub-contracted out on a massive scale, we should only list the main developer that is in control of the game and its appearance and style.-X201 (talk) 06:19, 8 November 2014 (UTC)
 * I'm in favor of adding extra developers to a degree, but no every single subcontractor or small company that helped. That would be overdoing it. But it a notable studio helped with a port or with stated aspects of the main game, I think that should be added. I think we need something like an addendum to the rule that allowed, under certain conditions, for additional developers to be added rather that just saying a flat "No". --ProtoDrake (talk) 08:38, 9 November 2014 (UTC)
 * I believe that if the publisher itself reveals the the co-developer(s) then they should be listed in the info box. I also agree that notable port developer is necessary to be shown in the info box. AdrianGamer (talk) 15:34, 9 November 2014 (UTC)
 * I would support adding every sub-contracted out developer in a collapsed subsection under the listed main developer. This collapsed section would be restricted to plain text (no links, not even internal ones, those should be in the prose of the page) and should only include developers mentioned in prose (that are backed by reliable sources if a disagreement arises).  I would be happy to code this extra capability in if there is a consensus to add it.  Ping me with the result of the discussion. —   13:37, 23 January 2015 (UTC)


 * The main developer/publisher should be sufficient for the infobox. It's only supposed to be for quick reference data, not all-encompassing. Thanks for the coding offer, though czar ⨹   22:12, 23 January 2015 (UTC)

Media(Arcade cabinet)
Should arcade cabinet be an accepted value? --Mika1h (talk) 18:39, 31 January 2015 (UTC)
 * There's a specific field for it, called cabinet. - X201 (talk) 15:30, 12 February 2015 (UTC)

Screenshot and logo
Hundreds of game articles I've looked at required a logo + screenshot. Typically people use the infobox for the logo, and the screenshot is displayed messily below it. See Age of Empires II: The Forgotten as an example. Sometimes only the game box cover is displayed in the infobox (See this). Can we add a "screenshot" parameter to the infobox similar to Template:Infobox software? -- Wonderfl (reply) 07:22, 19 February 2015 (UTC)
 * Its been a long standing consensus to only have one image in the infobox, with preference give to the game's cover or logo over a screenshot. Having screenshots in the article body helps illustrate it. The number of screenshots allowed in each article is limited, if one of these is moved to the infobox we'll end up with even bigger passages of text without an image to break them up. - X201 (talk) 09:03, 19 February 2015 (UTC)

SteamOS
Our line on Steam in the infobox has been "Steam is not a platform but a distribution service", though this ostensibly changes with SteamOS (its own platform). I'd like to preempt a few edit wars by clarifying here first: should we advise against adding "SteamOS" in the infobox platform section simply because it's the same as saying "Linux"-compatible? czar ⨹   14:06, 6 March 2015 (UTC)
 * I'm OK with that being the position on it. - X201 (talk) 14:09, 6 March 2015 (UTC)

Platforms
"The console or operating system the game was released for." is written in past tense. If we follow this guidelines strictly, it means that every single articles in Category:Upcoming video games, Category:Upcoming video games scheduled for 2015, Category:Upcoming video games scheduled for 2016 and every other games that have a port in development lacking platform information in the info box. In my opinion, this is not sensible as platform information are often very important to articles. Therefore, I suggested to add a short statement and turn the sentence to something like "The console or operating system the game was released for or is set to be released on." AdrianGamer (talk) 16:28, 7 March 2015 (UTC)
 * Fine by me but alternatively rephrase: "The game's supported platforms (console or operating system) both as released and in development." Also not sure we need to specify "console or operating system". czar ⨹   18:04, 7 March 2015 (UTC)
 * IIRC Console and operating system are there for a reason. They're there to cover stuff like On-Live etc. - X201 (talk) 18:30, 7 March 2015 (UTC)
 * This seems clear-cut for fully-launched games and upcoming games, but fuzzy for ones which have been released on some platforms and are only scheduled to launch (but may yet be cancelled) on others. Is it worth distinguishing the two - either having two fields, or recommending a notation for as-yet-unlaunched platforms? Or is it enough to assume that the reader will also notice the "Release date(s)" field, which will probably be filled in in these cases, and appreciate that some listed platforms are in the future? --McGeddon (talk) 20:16, 7 March 2015 (UTC)
 * I think we can assume readers notice the release dates field. Besides, port cancellation is not common after all. AdrianGamer (talk) 06:31, 8 March 2015 (UTC)

"Last Updated" section
For games that are still in development (such as early access, alpha/beta, and games with ongoing updates) it would be useful to have an "Updated" or "Last Updated" section that can be used to denote the date of the last update. This should, of course, be an optional parameter since it's not needed in finalized games, but this is more important as the early access trend grows. The Software infobox template has this, for example. Keavon (talk) 04:54, 10 January 2015 (UTC)
 * I agree. This is useful not only for early access games, but games that are never really "finalized" and get continually updated.  At the moment, I'm looking at Live for Speed, which was technically released in 2005, but received it's last version update on 27 Sep 2014. This issue might be handled by adding something like "Initial Release", "Stable Release", "Preview Release" dates and versions.  --Mindfrieze (talk) 19:54, 22 January 2015 (UTC)

We only got rid of it a couple of years ago. It was an unmitegated mess of unreferenced "stuff". If its important put it in the prose. -X201 (talk) 20:16, 22 January 2015 (UTC)
 * Now that we have Early Access and games that are continually updated are becoming more popular, I think it would be more useful now than it was at that time in the past. Keavon (talk) 04:37, 15 March 2015 (UTC)

Prequel/Sequel
Can we PLEASE add a sequel & prequel section? It would help with games like Lego Marvel Superheroes and Lego Marvel's Avengers, where you could barely tell that they're related without leaving Wikipedia, or games like Planetside and Planetside 2 that don't have a series page like games such as Final Fantasy may. AKA Casey Rollins Talk with Casey 7:30 PM EST, April 9, 2015.
 * A mention in the prose and again in the lede should be enough. czar ⨹   01:39, 10 April 2015 (UTC)
 * The problem is that this suffers from what fans might want to see, and can be seen fought over. As czar says if it is a true prequel or sequel as documented by sources, it can be listed in the lead. --M ASEM (t) 01:48, 10 April 2015 (UTC)
 * , When you say "this suffers from what fans might want to see, and can be seen fought over," do you mean some people might fight each other over which video game is a sequel? Also, I feel that the infobox should contain the most basic information that is most commonly looked for (Title, release date, producers, etc), and Prequel/Sequel is one of those things., while what you say to some extent makes sense and is true, sequel/prequel info isn't always in the lede. --AKA Casey Rollins Talk with Casey 8:23 PM EST, April 13, 2015.
 * Yes, people will fight over whether a game is a sequel/prequel in story, as opposed to a game being a retail sequel to another game. Or, basically, for games with large #s of titles like Zelda or Assassin's Creed, the difference between release and story chronology can be difficult to track and the monikers "prequel"/ "sequel" lack meaning without context. --M ASEM (t) 00:44, 14 April 2015 (UTC)
 * To back up Masem's point with an example "Is the video game Jak and Daxter: The Lost Frontier canon to the main story, or is it a spin-off?" This article has suffered five years of flip-flop edits and even though there's a consensus, other editors still "correct the error". - X201 (talk) 10:22, 14 April 2015 (UTC)
 * Thanks and . I suppose we hypothetically could make two seprate chronology sections for both retail and canonical sequels but it would be a little confusing for people looking to add information to a page. Maybe we should use those little chronological boxes instead. --AKA Casey Rollins Talk with Casey 8:12 PM EST, April 14, 2015.
 * I can't find clear guidelines on when or when not to use succession boxes, but your edit to Lego Marvel's Avengers doesn't seem right. It doesn't succeed the previous title, it just follows it. The previous game continues to exist in the exact same state as before. It is stated to be a sequel in the lead and the two Lego Marvel games are grouped together in the Lego series navbox at the bottom of the article. Do you believe this to be insufficient? Reach Out to the Truth 02:23, 15 April 2015 (UTC)
 * Hmmm...you are right, thanks . And yes, the succession box is sufficient. I literally didn't think about using them until last post. User:AKA Casey Rollins 8:33 PM EST, 15 April 2015.

Engine
Just wondering, why we only use the engine field only when the engine have its own article? AdrianGamer (talk) 11:59, 30 April 2015 (UTC)
 * A concensus from years ago. The parameter was removed (archived discussion), then re-added back under those conditions (archived discussion). --The1337gamer (talk) 12:24, 30 April 2015 (UTC)
 * I understand it now. Thanks for the links provided. AdrianGamer (talk) 12:33, 30 April 2015 (UTC)

Media
Why does this entry exist? What information does it give us to say that it was distributed on particular physical (or non-physical) media? The OS seems more than sufficient. --Golbez (talk) 13:23, 30 April 2015 (UTC)
 * Again, concensus from years ago. A distribution parameter was added previously (archived discussion), and then subsequently removed with media kept (archived discussion). --The1337gamer (talk) 13:46, 30 April 2015 (UTC)
 * I wouldn't mind starting up a discussion since it's been five years, especially since a lot has changed in five years - we're deep into an era where classic games are now being officially re-released for download, and there's simply no reason to have to update everything to add that. I cannot imagine any situation where my understanding of a game is improved by knowing if it was released on a CD and/or floppy and/or download, unless it was a special retro release which would be better handled in text rather than the infobox. --Golbez (talk) 14:10, 30 April 2015 (UTC)
 * Go for it. Its rapidly slipping down my list of important fields. - X201 (talk) 14:20, 30 April 2015 (UTC)
 * Agreed, I don't really see the need for this field in conjunction with the platform list. Any unexpected releases can be documented in prose (such as Goat Simulator getting a retail box release). --M ASEM (t) 14:46, 30 April 2015 (UTC)

Just as an aside, we currently have 3264 different types of media listed via the media field. Its a mess. - X201 (talk) 15:00, 30 April 2015 (UTC)
 * ... is there a list of these somewhere? I mean, I assume that much of that is ordering ('floppy, cd' being distinct from 'cd, floppy') but good lord, over 3000 variations? --Golbez (talk) 16:13, 30 April 2015 (UTC)
 * This list was created by the best part of two years ago. Referencing Masem's comment below, I can create an up-to-date version of the data in the infobox fields if needed. - X201 (talk) 17:16, 30 April 2015 (UTC)
 * One thing we'd ought to check through at some point is how many "terms" there are for fields that would be term-based, like Platform, Game Mode, Media, etc. and if these are flooded with so many possible variations as to lose their usefulness, get rid of them or figure out a way to enforce normalization. --M ASEM (t) 17:04, 30 April 2015 (UTC)


 * Kill it. A mess to maintain, very little use value, and everything already stated. czar ⨹   16:23, 30 April 2015 (UTC)
 * Support removal. I'd support removing the parameter. As pointed out it is being used incorrectly on hundreds of articles and fixing it is maintenance that nobody wants to do.  It's redundant on many articles, one can assume the type of media or distribution simply by viewing the platform page. I also don't think it is important enough to be included in the infobox; a lot of articles don't even mention the distribution method in prose so why is this information being relegated to the infobox when it has no place in the article body.  If it was worth mentioning then it can be done sufficiently in prose. --The1337gamer (talk) 15:36, 2 May 2015 (UTC)
 * Support removal. I support what the others have said above. It's just a mess to maintain and Wikipedia could use more consistency in not having 3000+ variations for a single value. ~ Dissident93  (talk) 21:56, 2 May 2015 (UTC)

Yep, I'll sort it. I'm creating a sort of WP:VG General Fixes file for AWB, so I can combine removal of the media crud with it. - X201 (talk) 11:40, 9 May 2015 (UTC)
 * Updated AWB code that removes the Media field. It also fixes a few other little things; e.g Release is a little used alternative to Released, I'm working towards eradicating it and standardising on Released. - X201 (talk) 11:09, 11 May 2015 (UTC)

I've updated the AWB code so that it now fixes single-player/multiplayer issues as well, i.e. the 5,000 different permutations of it. - X201 (talk) 09:50, 12 May 2015 (UTC)

Well this is annoying. There was no need to remove this. I really hate when I don't see these discussions until after a decision has been made. -- JDC808  ♫  15:10, 12 May 2015 (UTC)
 * ,, . It may be an idea to stop the removal of the media field from articles for 24 hours, in case wants to challenge the removal of the media field. - X201 (talk) 15:37, 12 May 2015 (UTC)
 * It's not that it's a hard consensus—just that no one expressed any opposition in the usual week we give these things. JDC808, what's your case? czar ⨹   16:01, 12 May 2015 (UTC)

To counter JDC808 a bit- I'm in favor of this; for older consoles it didn't make sense (Playstation 1 games are always on CDs, etc.), for older PC games it no longer makes sense (even if it was released on floppy, it'll be a download now) and modern games are released in whatever format you find them in- data is data, and it no longer makes sense to pay attention to the specific container that the data is sold on, since it can always be transferred to another container. It's just an extension of the long-removed system requirements field, but for cd-rom drives. -- Pres N  19:38, 13 May 2015 (UTC)

An update to the Media-Wiki software has broken AWB for everyone. So the 24 hour window will be closer to 48 hours. - X201 (talk) 13:33, 14 May 2015 (UTC)

Template-protected edit request on 30 April 2015
Proposing a simple, optional command, for a various small number of articles, which allows the template code to automatically italicise the game title on the template, but not the article's title itself. (say italic title=yes/no)

Hope(N Forever) (talk) 21:21, 30 April 2015 (UTC)
 * If its just for a few articles, why does it need adding to a template that serves 20,000 pages? - X201 (talk) 22:11, 30 April 2015 (UTC)
 * Red information icon with gradient background.svg Not done: please establish a consensus for this alteration before using the template. -- Red rose64 (talk) 22:49, 30 April 2015 (UTC)
 * As a question, when would such a situation be needed? --M ASEM (t) 13:42, 9 May 2015 (UTC)
 * You would also need to explain why that is important to have it. Gamingforfun365 (talk) 23:18, 15 May 2015 (UTC)

Prequel/Sequel Labels
How would it be if there were information for a video game's prequel and its sequel? I mean, we already have the "series" label, but I think that, under that label, these labels would be great so that we would quickly know what came first and what came then. Gamingforfun365 (talk) 19:58, 15 May 2015 (UTC)
 * The problem is that for many series, the labeling of "prequel" / "sequel" can become a matter of original research and the link (for example, Legend of Zelda). This type of information can be best explained in the prose how the game fits into a longer series. --M ASEM (t) 23:32, 15 May 2015 (UTC)
 * As for primary sources, we can always use secondary sources instead, they can always be called "predecessors/successors" instead (probably not necessary to say), and they can always be compared to GPUs since there already is such information for GPU templates. This is just to supplement, not to replace. Gamingforfun365 (talk) 01:25, 16 May 2015 (UTC)
 * I imagined this would be purely for chronological release, rather than "in-story/numeric" release. --Golbez (talk) 04:16, 16 May 2015 (UTC)
 * Even so, most editors wouldn't know this and they will keep changing it. As mentioned in the above discussion, it would likely cause lots of arguments. And there are other things we'd have to consider: Do we include remakes? Do we include spin-offs? Do we include titles without articles? Do we include crossover titles?  What about if multiple games in a series are released simultaneously? I think adding this stuff to the infobox would cause a lot more hassle than it's worth.  This sort of information can be explained in prose without any confusion and I think it's better if it stays there.  --The1337gamer (talk) 11:25, 16 May 2015 (UTC)
 * I see. I was just thinking of arranging it in an in-game, chronological order for a game's storyline, but thank you both for your explanation about it. I am sorry for my confusion there. Gamingforfun365 (talk) 14:42, 17 May 2015 (UTC)
 * O wow! I did not even notice that there is another earlier discussion about it. I did not see that. Whoops! Gamingforfun365 (talk) 14:53, 17 May 2015 (UTC)

Additions to the composer field
Currently, it states:

"The popular names of the composers who worked on the game's music.
 * 1) List people who contributed significantly to the soundtrack. Discuss inclusion criteria on a per-game basis on the talk page."

I think the following additions would improve this field and cause less controversy on certain pages.

"The popular names of the composers who worked on the game's music.
 * 1) List people who contributed significantly to the soundtrack. If possible, order them by how much they contributed (from most to least). Generally, the game's credits will have them in this order, but not always.
 * 2) Composers who were contracted to write a single song (opening theme, ending theme, etc.) should not be listed if their role is mentioned in the article itself.
 * 3) Only list people who directly wrote (new) music for the game. Try to not list people who's music was re-used, either arranged or directly, from another game. Discuss inclusion criteria on a per-game basis on the talk page."

Any thoughts? ~ Dissident93  (talk) 01:39, 2 April 2015 (UTC)


 * the logic should still be consistent with the other personnel fields, that only notable people or ones clearly identified in third-party sources, be included. I do agree with the additional bullet points. --M ASEM  (t) 01:49, 10 April 2015 (UTC)
 * Are there really no other opinions on this? The recent media field removal shows that this page is active and watched, so what's the deal? I tried to be as consistent with the rest of the personnel fields as possible, and I believe these suggestions would prevent controversy that have happened on certain pages before. I'm now thinking that all the personnel fields could be updated, as fields like "artist" currently say not to include character designers, yet many GA pages have them listed anyway, so why not make it official? I'd be willing to make more suggestions, but only if people actually comment. ~ Dissident93  (talk) 19:31, 11 May 2015 (UTC)
 * What's wrong with it the way it is? If anything, the additional bullet points should be generalized for all fields instead of being just for the composers. Our documentation is already super long and largely unread. – czar   13:31, 22 May 2015 (UTC)
 * You might be surprised but, a lot of edit warring has happened with this field on various pages in the past. But I agree that this could work for the other personnel fields as well. The writer field currently says "The writers should be listed in the order of their contribution", which should apply to every field already. Also, if a writer just wrote a single quest plot, that's too minor to have him listed in the infobox correct? Then it should be no different from a composer not being listed because of writing just a single song out of 50+, or an artist doing a single monster design. ~ Dissident93  (talk) 21:04, 22 May 2015 (UTC)

Add co-op as an acceptable game mode
Currently the description for mode says "Playing modes offered by the game. Currently, the only accepted values are single-player, multiplayer, or both." However, co-op is a very different game mode from multiplayer. Multiplayer basically means something with multiple players where not all the players are working together to achieve the same specific goal. This could mean a team-based game where teams fight each other or perhaps an MMO where there's lots of people not doing the same thing together. Co-op is much like a singleplayer game where there is one express purpose that a small group of players work together to achieve. I would not think of Portal 2, for example, as a multiplayer game. Currently, by forcing co-op games to be considered multiplayer games, this is making the definition of "mode" way too broad, almost to the point of making it unnecessary. Co-op is as much a singleplayer experience as it is a multiplayer experience. Also, there's a lot of co-op games adding co-op as a mode even though it's not "valid" according to this template's standard. These are all examples of games that are undeniably co-op games and certainly not multiplayer games that use the co-op mode in the infobox: Portal 2, Borderlands, Borderlands 2, PayDay: The Heist, and Magicka. Since co-op is a totally different mode from multiplayer and I would even consider it closer to a singleplayer experience than a multiplayer experience, we really should add "co-op" as an allowed game mode. Keavon (talk) 02:48, 24 March 2015 (UTC)
 * As a comment, please see this last discussion. I think the fear was that with some game, the list of modes could grow huge if you include all the various co-op and coop/competitive mode. --M ASEM  (t) 03:18, 24 March 2015 (UTC)
 * Thanks for linking to that. I agree that growing the number of modes to something like the ones mentioned in the beginning of that topic would be very bad. Modes should be for the most broad level. But I see most broad level as being singleplayer, multiplayer, and co-op. With those three modes, I could categorize any game in existence so it should not grow any further. Things like "competitive", "free-for-all", "team-based", etc. are all very specific and don't belong in the mode field. However, a game like Portal 2 co-op is simply not appropriate being classified as "multiplayer". If we extend the allowed values to three and no more, that will allow all games to be encompassed. Since this limitation is already a problem, the articles I linked to above have gone ahead and broken the standard because the standard simply doesn't fit those game. However, games on that list some say "co-operative", some say "cooperative", and some say "co-op". If the standard were extended to allow "co-op", the name for this could actually be standardized rather than going off various unofficial names. With a more accommodating list of three options, this would also deter articles from creating their own of overly-specific modes by going along with the idea of ignoring the "allowed" values. If a standard is bad, people just won't use it, and then you have a mess of nonstandard names. I think that it's obvious that, if the majority of the biggest co-op games out there have broken the standard, the standard simply doesn't fit. I would like to continue this discussion and ultimately (hopefully) come to a consensus that "co-op" should be added as an allowed mode along with adding a strong notice that no other mode names should be used. Keavon (talk) 03:38, 24 March 2015 (UTC)


 * Masem, I think it would be a good idea to go with your suggestion in that last discussion, creating a template to only allow certain video game modes. I've been searching through a lot of articles in the past week and have noticed hundreds that don't conform to documentation.  I think it will save a lot time and make future maintenance and cleanup easier if a template restricting game modes was added. – The1337gamer (talk) 10:07, 24 March 2015 (UTC)

I've known about this problem for sometime - I was trying to clear the decks in order to fix it, but, seeing as someone has opened the can of worms, here goes. This problem is much, much worse than you imagine, Masem's fear of it growing too large is already a reality. The Modes field is already out of control.

This sterling piece of work by in 2013 shows that its already a mess. Please follow the link and look at the mode field, its truly shocking.

Hellknowz's report shows that there are 16799 different entries for the mode field. Ignoring spelling differences, that's 2462 permutations for a field that supposedly has only three possible permutations. There are numerous spellings and redirects of Single Player and Multiplayer, there are other values like Two Player or Alternating Play added and there are explanatory notes like being available on one platform but not another, there are single player and multiplayer separated by slashes and/or line breaks, There's Co-op, ad-hoc, wifi, TCP, modem, 2 player battle, LAN, sharing, campaign, split-screen, etc

I'm willing to start the clean up (it will allow for other important WPVG stuff to be carried out with AWB), we just need to decide what goes and what stays. - X201 (talk) 11:01, 24 March 2015 (UTC)
 * Wow, that's a *lot*, and I wouldn't be surprised if it's even gotten worse since then. I still stand that all games can be accurately described as any combination of singleplayer, multiplayer, and co-op, but any more than that is too overdoing it and anything less (i.e. the current two) is too limited. I would be willing to help the cleanup effort and standardize a bunch of articles if we can decide on that. As a separate issue, I think that "single-player" should be spelled without the hyphen, but I'll ignore that for now. I think that the exact standard should be "Single-player", "Multiplayer", and "Co-op". Each should start with a capital letter and they should be listed in the order of most importance for each game, i.e. a primarily singleplayer game like BioShock 2 can be listed starting with Single-player and have its less central mode (multiplayer) be listed second as Multiplayer. Keavon (talk) 01:28, 25 March 2015 (UTC)

How can we proceed, either through a further debate/gather of consensus or through proposing such changes and initiating a site-wide cleanup effort? Keavon (talk) 01:52, 2 April 2015 (UTC)

Restricting this field
Seeing as the field is restricted to 2 values, is it possible to code this straight into the infobox? Instead of accepting any string it will only accept the correct values and automatically link to the the right pages and present the two values in the correct format. Similar to how works with pre-defined entries. For example, we add two extra parameters:


 * single-player = yes/no/empty


 * multiplayer = yes/no/empty

Whenever both of these parameters are used, the infobox disregards the modes parameter and shows the correct stuff in place of mode. Helps phase out the modes parameter without disrupting articles in their current state. Or can a separate template be created and start being used to restrict this as previously suggested --The1337gamer (talk) 15:17, 10 May 2015 (UTC)
 * I'm not even sure we need a mode field, but assuming that we do, I think this proposal is a better way of handling it. The "no" option shouldn't be necessary, as all non-"yes" should default to "no". This also allows for easy standardization of other values, like yes/local/network/online to format as "multiplayer (local, network, online)" (multi-input) or "local multiplayer" (single-input). I think it's worth the effort to get it right, if we're going to do it at all. I'd also be in favor of a co-op param with similar options. My only concern would be the edge cases, e.g., single-player games that get a multiplayer option with a later version (though that would be the same deal as it is now), or any case where there isn't mode parity between platform releases. I think the benefits outweigh the costs for the local/network/online co-op/multiplayer distinctions, though. czar ⨹   16:03, 10 May 2015 (UTC)


 * Any opposition to this, or is this something we should start implementing? – czar   13:00, 22 May 2015 (UTC)
 * I'm in favour of it as long as we are only stating the game modes and not making a distinction. e.g. we say it has multiplayer and aren't bothered whether its online, offline, LAN only. ad-hoc, alternating turns or third person view only, "within shop", DS version only or "in more recent versions" (and if you think I made those up...) as long as its just a binary has/doesn't have then I'm OK with it, and the addition of co-op. - X201 (talk) 13:33, 22 May 2015 (UTC)
 * Curious why you'd be opposed to the simple options of "local", "network", and "online" (not the smorgasbord of other stuff). Even as it is, "multiplayer" or "co-op" is almost unhelpful in its lack of context. – czar   14:41, 22 May 2015 (UTC)
 * I'm not opposed to them if they are baked into the code and are options turned on by a  or   field. I'm opposed to them if its a case of multiplayer being the option, then users get free reign to add text describing the type of multiplayer, because that will just lead back to the current mess that we have. - X201 (talk) 14:53, 22 May 2015 (UTC)
 * Agreed—that's what I had in mind. Want to have a go at coding it in the sandbox? (Is there no way to parse csv like "local, online"? Is that why separate params are necessary? If so, might be better as multiplayer_online than online_multiplayer.) – czar   15:13, 22 May 2015 (UTC)
 * I oppose having co-op or network/local/online multiplayer listed in the infobox, considering that all of them fall within the scope of "multiplayer". They are information that should be mentioned in prose, not in the infobox. AdrianGamer (talk) 08:31, 23 May 2015 (UTC)
 * "Multiplayer" by itself is vague to the point of being unhelpful. At least knowing if a game is online-only or local multiplayer gives readers what they're looking for at a glance. The descriptors are prescribed in this case, so it wouldn't be an issue of extraneous detail, which is still left for the prose. – czar   16:27, 24 May 2015 (UTC)


 * Can we not do this and just leave the field as is. I'm fine if people want to put co-op in.  It's irrelevant how many permutations can be found in the mode field as long as it still describes the mode in each article. - hahnch e n 13:18, 25 May 2015 (UTC)
 * The field is already supposed to be restricted. Read to doc: Playing modes offered by the game. Currently, the only accepted values are single-player, multiplayer, or both.   The inclusion of co-op and other values would be a proposed change, not leaving it as is.  --The1337gamer (talk) 13:27, 25 May 2015 (UTC)
 * It's supposed to be restricted, but isn't. I don't think it needs homogenization. - hahnch e n 21:22, 25 May 2015 (UTC)

Shut down
I believe we should add a "Shut down" property, to be added right under "Released". This would only be applicable for games that can ONLY be played while connected to an official server, and thus become unplayable when all such servers are discontinued. Perhaps "Shut down" is not the best wording, please suggest if you have better teminology. Example: Age of Empires Online shut down on 1 July 2014. Sygmoral (talk) 22:19, 11 February 2015 (UTC)
 * I agree, this would be useful for games like Age of Empires. Keavon (talk) 04:35, 15 March 2015 (UTC)
 * Discontinued would be a better nme for it, but yeah. Great idea for games like Planetside. AKA Casey Rollins Talk with Casey 7:25 PM EST, April 9, 2015
 * I'm a bit in doubt about the naming: Discontinued might also be interpreted as if no more updates will be released or something like that, while I believe it's a different thing when the online service required for play is shut down. Sygmoral (talk) 21:26, 8 May 2015 (UTC)
 * Another alternative could be "Terminated" (as in, the online service has been terminated). Sygmoral (talk) 13:13, 24 May 2015 (UTC)


 * Other service infoboxes use "closed". I think that makes sense here too. – czar   16:23, 24 May 2015 (UTC)
 * Those examples are both for physical places though. I notice that the software infobox uses "discontinued", as AKA Casey Rollins suggested. Video games are software of course, so perhaps it would be most consistent if we used that then (despite my initial reservations about that word). Sygmoral (talk) 16:55, 24 May 2015 (UTC)


 * Oppose: We've removed fields before because they would affect a very small number of articles, this is not something that belongs in the infobox when it can be mentioned in the article body. Darkwarriorblake / SEXY ACTION TALK PAGE! 20:38, 24 May 2015 (UTC)
 * Why don't you just do something along the lines of "Date 1 - Date 2"? - Favre1fan93 (talk) 01:09, 25 May 2015 (UTC)
 * Oppose same reason as Darkwarriorblake. The number of articles that would make use of this is small. --The1337gamer (talk) 10:37, 25 May 2015 (UTC)
 * The reason it does not apply to a high percentage of the articles is because most of them are about old video games. It was a non-issue in the past when games never needed a server, but they are now played online or require an network connection more and more often. So we can expect 'discontinuations' to happen more often too, for more recent entries. Are we blocking this then, just because of the vast array of old games that will never use it? Sygmoral (talk) 22:49, 25 May 2015 (UTC)
 * Are you including single player games with a multiplayer component there? Because the Infobox wouldn't be used for a segment of a game no longer being played online. Might as well add a date for when they stop patching it too. Darkwarriorblake / SEXY ACTION TALK PAGE! 22:56, 25 May 2015 (UTC)
 * I would say it is mainly meant for when the 'discontinuation' has the effect of disabling any form of play (except through illegal means such as private servers). For example, if World of Warcraft shuts down all of its servers one day, I really think the infobox ought to say it's not a playable game anymore (just like Age of Empires Online today). It is an important piece of information about any game: can I play it? (so I personally feel the field should not be used when only the multiplayer component of a game is unavailable, but the single player can still be played) Sygmoral (talk) 00:34, 26 May 2015 (UTC)
 * We do want to make sure this is limit to the cases where dedicated servers are absolutely required to play the game, and not that, say, the services that supported the console are no longer active to allow the game to be played. So, for example, with the way XBox One games seem to be set up to require online connections at all times, when in the far future that this service is disabled by MS rendering all such games playable, this would not be a "shutdown" for the game. If we do mention a shutdown it should be because the actual playable servers were purposely taken down for that game, as would be the case of most MMOs.  As another option, "years active' might be a better way to represent this field. --M ASEM  (t) 00:39, 26 May 2015 (UTC)


 * Support - I suggested this in 2013 but never followed up on it. For the increasing number of games run as services, the date of their death is as important as any other piece of information in the infobox, and more important than several of the credits-style fields. - hahnch e n 23:43, 25 May 2015 (UTC)
 * Interesting mention of the dead MMOs category there (as well as inactive online games), as well as several other good points. Sygmoral (talk) 00:38, 26 May 2015 (UTC)

"Box offices" for movie templates; "Copies sold" for this template...
So I have recently noticed that there are labels for movie templates called "Box office" and "Budget", which is great because it is important and non-trivial, but we don't have anything like that for this template for video games.

So my idea is that we have a label, "Copies sold", which shows how many times it sold itself. Of course, it too would need a reference. My point is that, unlike movies on Wikipedia, we don't usually see (cited) information for how much money one video game grossed nor how many times that video game sold itself. In addition to that, in the "Reception" area, I seldom see information for how many video game copies were sold.

However, considering that there was never such label for the number of sold copies, my right side of my mind presumes that it be unnecessary for that information because it may be harder to find that information and because we can always use a prose instead, even though my idea is just to supplement, not to replace. What are your opinions about it? Would that help Wikipedia, or would that harm it? I appreciate your honest opinions. Gamingforfun365 (talk) 01:51, 18 May 2015 (UTC)
 * Another thing about which I worry is that it might be trivial rather than important. Gamingforfun365 (talk) 01:59, 18 May 2015 (UTC)
 * The largest issue is that unlike films, where these numbers are regularly reported, the true numbers for video games are kept under wraps; even recently the NPD group (tracking sales in NA) cut down how much public data they made available. This leaves primarily VGChartz as the only source for this data, and this is very unreliable source. When the sales numbers or budget numbers are given, we absolutely should give them in the appropriate sections (it is not trivial to us), but it's so limited and with the issue of poor sources that an infobox field could be more trouble than its worth, since people seem to want to fill in every section they can. --M ASEM  (t) 01:59, 18 May 2015 (UTC)


 * As Masem said, it would be trivial and difficult to find up-to-date sources for the true numbers for every game. If it's really that important to mention, it should just go into the Release section. ~ Dissident93  (talk) 22:17, 1 June 2015 (UTC)

Image field documentation
The documentation for the image field currently says this at the end of it  If I'm correct, the template now uses Frameless and upright as a default, so there's no need to explicitly state them in on the actual article. This line needs to be removed if my understanding is correct. Also I have an AWB file the does general WPVG fixes (fix template names, correct links, remove defunct fields etc), now the template handles size issues would it be a good idea for me to add a new rule to the AWB file that removes sizing info like, and   from the template markup in articles? I won't touch any image that has alt text, as we haven't got an alt field to transfer it to and removing it will be to the detriment of users with screen readers. - X201 (talk) 09:38, 22 May 2015 (UTC)
 * More precisely, you'd have to strip images of their File syntax; the instructions predate Module:InfoboxImage. We do have an alt field. Alakzi (talk) 11:52, 22 May 2015 (UTC)


 * Rather than removed, it should be updated to say that the image is automatically sized with "frameless" and "upright" so no extra syntax is needed. That'd be a start. – czar   13:25, 22 May 2015 (UTC)
 * Updated. I'll start working on the regex to remove px and frameless as it seems like a no-brainer that they now need to go. Will test the alt field too. - X201 (talk) 13:44, 22 May 2015 (UTC)
 * X201, since the template supports the alt field, can you please add the alt field to the documentation? Prhartcom (talk) 21:37, 1 June 2015 (UTC)
 * ✅ - X201 (talk) 08:10, 2 June 2015 (UTC)


 * If you're going to remove the sizing requirements from the input, can you bake in  to preserve image width at 250px on default settings. - hahnch e n 14:15, 24 May 2015 (UTC)
 * OK. - X201 (talk) 09:13, 2 June 2015 (UTC)

Localization
Can I add a field for "Languages" (ie which languages the game is localized into?)

Wonderfl (reply) 10:21, 25 May 2015 (UTC)
 * Oppose this addition. This field is going to get messy if it is added. For example, Minecraft is a available in over 60 languages, having a list that long in the infobox would be ridiculous.  I don't think languages is important enough to be included in the infobox.  Any particularly notable localisations can be mentioned in prose. --The1337gamer (talk) 10:30, 25 May 2015 (UTC)


 * Oppose: Really trivial information that, if needed, should just go into the main article space. The infobox is not meant to be all-encompassing. ~ Dissident93  (talk) 22:15, 1 June 2015 (UTC)


 * Oppose: Better suited for prose; a rough idea of localization can be determined based on the release date system (knowing if it is Japanese, English, or EFIGS (English/French/Italian/German/Spanish). --M ASEM  (t) 22:18, 1 June 2015 (UTC)


 * Oppose Games with lots of languages would not benefit from this; it'll clutter the page even more. -- Anar  chyte   09:24, 2 June 2015 (UTC)

Website section
Re-add website section, it'll clean up the External Links section. Having it inside the Infobox is easier than having it in its own section which normally never gets updated with other links. -- ☣  Anar chyte  ☣ 07:05, 30 May 2015 (UTC)
 * Oppose – For the same it was removed/not added previously. External links works fine. This will just bloat the infobox further. --The1337gamer (talk) 09:49, 30 May 2015 (UTC)
 * Support – Website is kind of critical for open source games. &mdash;SamB (talk) 02:42, 14 June 2015 (UTC)
 * Please establish a consensus before reactivating edit template-protected. Alakzi (talk) 11:38, 14 June 2015 (UTC)
 * Oppose: For the same reasons it was removed and rejected numerous times since. - X201 (talk) 11:46, 14 June 2015 (UTC)
 * Oppose – Well, with all of your respect, we do have the "External Links" section, and I am pretty sure that adding so to that template would be somewhat trivial, so it is a template well enough. Gamingforfun365 (talk) 09:36, 19 June 2015 (UTC)

Co-developer
Few months ago I have proposed to allow co-developers to be added to the infobox. Before my proposal, these co-developers have already been added to the infobox in a variety of way, unbulleted list, notelist, or collapsible list. Even some of our featured articles have them as well. And with the recent poorly-optimized ports, (High Voltage with MKX and Iron Galaxy with Arkham Knight) they may also be notable as well, to a point that they can also be listed in the infobox alongside with the lead developer. Not to mention cases like Battlefield Hardline and Tom Clancy's The Division, in which every developer seems to have play an important role during the development of the game. So, I am proposing it again. Restriction should be set, in which only co-developers that are supported by reliable sources should be added, and that the developer itself should be considered notable. Something like LittleBigPlanet 3 or Star Wars Battlefront should be considered inappropriate. Any thoughts? AdrianGamer (talk) 11:23, 24 June 2015 (UTC)
 * The "Additional Work" collapsed list seems to have become rather common place, despite the language in the template's documentation. It's certainly not being... hmm... policed?... as well as some other fields, such as Engine and Modes. Would it maybe be prudent to simply make a field for "Additional Developers"? I would think regardless that a reliable source is required for a developer to be noted as having worked on the title. I'd also agree that, like the Engine field, developers must be notable in their own right in order to be listed. -- ferret (talk) 01:53, 26 June 2015 (UTC)
 * I'm fine with the "Additional Work" collapsed list, but I don't think that ports should belong at all. I don't think we should have a field for "Additional Developers" either, since people will put every company that simply sponsored the game, or contributed one piece of art. The infobox documentation needs a re-write, honestly. ~ Dissident93  (talk) 05:48, 26 June 2015 (UTC)
 * I agree with Dissident. In my opinion, co-developers =/= a port developer. An example of actual co-developers would be the Assassin's Creed series, where each game has a main developer, but the other Ubisoft studios all contribute material to the final game. Port developers, in my eyes, take the work of the main developer and attempt to translate it over to another platform. In cases where the ports themselves become notable, this info, and the developer, can be mentioned in the release section and/or a technical issues/reception section. - Favre1fan93 (talk) 16:49, 26 June 2015 (UTC)

alternate names
I'm touching up the article on Realm of Impossibility. This was originally released as Zombies. I don't see a way to indicate this in the infobox? Maury Markowitz (talk) 11:45, 23 July 2015 (UTC)
 * I don't see a need for alternate names in the infobox. Consider adding it in the history/development section or if you think people are likely to recognize the game based on the title, the lead. --Izno (talk) 14:29, 23 July 2015 (UTC)
 * This is a common feature of many infoboxes, as it allows automated tools to directly identify aliases. Simply placing it in the lede doesn't do that. Maury Markowitz (talk) 15:25, 24 July 2015 (UTC)
 * Which infoboxes? How do they implement it? - X201 (talk) 15:39, 24 July 2015 (UTC)

Middleware in Engine field
Should links to middleware be included in the engine field? I see articles such as Dragon Age: Inquisition, Just Cause 2, and The Witcher 2: Assassins of Kings linking to Havok (software), PathEngine, and SpeedTree. I'm sure there are probably others. It's not covered in the template doc and I don't think it is necessary to list individual software components. --The1337gamer (talk) 13:03, 27 July 2015 (UTC)
 * No.Darkwarriorblake / SEXY ACTION TALK PAGE! 13:07, 27 July 2015 (UTC)
 * No. The consensus and status quo is for the field to be used for game engines only. I've updated the instructions to clarify it. - X201 (talk) 13:23, 27 July 2015 (UTC)

Japanese dates for English-first releases
As it stands, a Japanese dev can release a game in North America before Japan and we wouldn't include the Japanese date in the infobox. Is this correct? Do we need/want to change this? (example, discussion) – czar   07:18, 27 July 2015 (UTC)
 * The policy should be changed to always allow for the release in the home market of the developer to be listed, it just seems odd to omit something like that. ~ Dissident93  (talk) 07:50, 27 July 2015 (UTC)

I think you're misreading it. I can't see how you've got to the point where that bans Japanese dates. It says "Use the date from the country of origin; and any English dates." It was worded like that to allow for any (non-English)country of origin but to exclude all other non-English dates. - X201 (talk) 08:16, 27 July 2015 (UTC)

How about moving the festival bit to its own sentence? - X201 (talk) 08:22, 27 July 2015 (UTC)
 * That's good. And how about rephrasing the first sentence: –  czar   08:59, 27 July 2015 (UTC)
 * Much better, but would this get rid of South Korean and Brazilian dates? Also, early access dates being listed is fine before an official release date is announced, right? ~ Dissident93  (talk) 10:53, 27 July 2015 (UTC)
 * There's consensus that non-English region dates shouldn't be listed if they're not the location of the developer. Only the main English language regions should be listed. The infobox on more and more articles were becoming an absolute mess, articles with ten or more release dates were not extreme examples, they were the norm. Articles would have separate dates for Japan, US, UK, France Germany, Spain, Portugal, South Korea, Malaysia, Brazil, Australia, New Zealand and Canada. It was a hideous wall of numbers that caused a rethink where it was limited to North America, EU and Australasia along with Japan (or others) if it was the location of the developer.


 * Early access dates shouldn't be put in the infobox, the consensus is that it should be the public release date. Early access can be listed in the prose if its relevant. - X201 (talk) 11:23, 27 July 2015 (UTC)
 * The only case I'd make an exception for is for games that are presently in Early Access or equivalent but not yet reached final, if there is no word on when the actual release date is. This helps to identify games that are in the endless cycle of early access at a glance. Once the game is released as a final version, I agree completely that the early access date should go away from the infobox. --M ASEM  (t) 14:28, 27 July 2015 (UTC)
 * So how would we handle something like DayZ (video game), which has the exact date for it's early access release, but only a vague one for the official release date (2016). ~ Dissident93  (talk) 22:28, 27 July 2015 (UTC)
 * I'd only replace it in the case of a firm planned release date (day and month). --M ASEM (t) 05:59, 28 July 2015 (UTC)


 * ✓ done – czar   20:36, 3 August 2015 (UTC)
 * What about when a game was not developed in Japan but was published there? E.g., Donkey Kong Country 3: Dixie Kong's Double Trouble! was developed by Rare (UK) and published by Nintendo (JP) and was published in an English-speaking region before Japan—would we still need the Japan dates in the infobox? No, right? – czar   20:43, 3 August 2015 (UTC)
 * I'd still say yes. Japan is one of the "main 3" markets for video games, along with NA and EU. I think AUS, SK, and BRA dates are the ones that should be up for debate. ~ Dissident93  (talk) 22:08, 3 August 2015 (UTC)

Cabinet field
Could someone wikilink "Cabinet" in the infobox to Video game arcade cabinet? --Mika1h (talk) 22:15, 31 July 2015 (UTC)
 * ✅ - X201 (talk) 11:11, 6 August 2015 (UTC)