Template talk:Infobox Game

Add topic
From Looney Pyramid Games Wiki

When updating this, keep in mind that your changes affect every infobox already in use. If you add a category, that category will show up as a missing symbol in every other infobox. Try to make sure any additions are truly necessary. - brilk 22:29, 13 February 2012 (UTC)

Is there a way to make the parameters optional? For example, the infobox for Cardinal Connections has a blank "Mechanics" section, but if you just leave Mechanics out of the infobox markup, it makes it say Mechanics: {{{mechanics}}}. It would be better if it just didn't display that part of the box if there wasn't anything there. Can that be done? --Tophu 21:48, 27 Apr 2005 (GMT)

I don't know. I don't know of any way to do this, but I'm not an expert on the template language. You can prevent it from printing {{{mechanics}}} by including the mechanics parameter and leaving it blank, as follows: mechanics=|, but then you'll still get Mechanics: with a blank field in the infobox. We could also remove mechanics from the infobox template, and let people add it if they want in the footnotes, which is basically an area where you can add extra information to appear after all of the other information in the box. -- Lambda 22:03, 27 Apr 2005 (GMT)

Major update (Nov. 2016)[edit source]

With the launch of the Pyramid Arcade, the subsequent resurrection of the wiki, and the expected influx of new players it was high time we updated the Infobox design (and fixed the issues that came with updating the software)

Change list:

  • Added player count, game length, and rule complexity icons
  • Added options for "game_length", "trios", "game_mechanics", "game_status", "version_num", & "release_year"
  • Compressed min & max player count and min & max playing time to single lines separated by a dash when both variables are defined (note: the variables are still mapped to separate properties, only the infobox display is different)
  • Now powered by ParserFunctions and Lua!
    • Omitted or empty parameters will be automatically hidden. (looks cleaner)
    • Lua scripts are used to intelligently read certain data rows. (fixes processing errors)
    • "designer", "other_equip", & "game_mechanics" can now accept comma separated lists that will be split into separate multiple values of the same semantic property (better for searching).
    • "other_equip", "game_mechanics", and "theme" automatically generate links to the related wiki pages (easier browsing)

Note: all of the original parameters are included with the exact same variable names as the previous infobox. However, some of the old variables are not listed so as to encourage the use of the newer, comma separated fields. Eventually we will phase out the old, hidden parameters once we have updated most of the game infoboxes to include the new data (this may take a very long time)

Please let us know what you think and report any issue you run into! Additional suggestions are also welcome. I will try to keep and aye on this page and respond within a reasonable amount of time Umjahwa (talk) 21:02, 11 November 2016 (PST)

Updates (April 2024)[edit source]

The way the infobox parses and displays the following fields has be updated:

  • game_length - Values entered as "fast/short/quick", "medium", or "long" (ignoring case) will be linked to the correct page such as "Browse_games/Fast_playing_time". The Infobox will still display "Fast", "Medium", or "Long"
  • complexity - Was similarly updated to look for "simple/low", "medium/moderate", or "complex/high" and properly link to pages like "Browse_games/Simple_complexity"
  • strategy - Was similarly updated to look for "no/none", "low/little", "medium/some", or "high/great/lots" and properly link to pages like "Browse_games/No_strategy_depth"
  • random_chance - Was updated almost exactly the same as strategy, looking for "no/none", "low/little", "medium/some", or "high/great/lots" and properly link to pages like "Browse_games/No_random_chance"
  • status - Also now looks for a few variants on spelling to link to proper pages like "Games_in_Design_Stage_Initial_Design". Might want to move these pages under "Browse_games/" in the future.
  • release_year - Now prepends "Games_released_in_" to the page link so that "1999" will link to "Games_released_in_1999"
  • other_equip - I made a bigger change to how it works along with a change to the way this field should be used. Kataclysm and I feel that the Other Equipment field in the infobox shouldn't contain quantities and sentence-like descriptions, these details should be listed in the Equipment section of the page. It should contain standard items that will get linked to their proper "Equipment/thing" page. This does require entering the name properly like "Chessboard" rather than "Whatever chess board you have". This will also require updating most of the game pages and moving the existing equipment pages ("Chessboard" to "Equipment/Chessboard"). But it will allow for better searching of the other_equip field and a more readable output in the search results.

Dazeysan (talk) 17:21, 22 April 2024 (UTC)

Dice are a particularly chaotic value in this field. I think ideally it would be standardized to 2d6, 1d4, etc., while still leaving out the number on specialty linked equipment like Lightning die.--MCDeMarco (talk) 17:25, 3 May 2024 (UTC)
Kataclysm and I were thinking to limit it to "dice" when only regular D6's are needed, "polyhedral dice" when regular D4-D20 are needed, then the special dice with their own pages like "Treehouse Dice", and we'd probably need a generic "Custom dice" option for everything else. The thinking is that this field doesn't have to have the full inventory, that's for the text in the main body of the page. This field would let someone who just has some pyramids and a couple of plain old D6's find games, or maybe they got a set of "D&D" dice which opens up some other options. But maybe the infobox could recognize "3d6" and just link that to "dice"... I'll have to play around with the searches. The problem with having numbers of dice shown is then we get games with entries like this: "One Six-sided die (d6) per player plus one extra die", maybe it would get abbreviated to "#d6" or something?
On a related note, I dumped what data I could find a little while back and there are over 200 unique pieces of equipment. A lot of them are just different spelling of the same thing though like "1 d6", "1d6", and "one six-sided die". -Dazeysan (talk) 23:53, 3 May 2024 (UTC)

New Talk (2024)[edit source]

Is there a good way to indicate that a game is an adaptation of an existing game to use pyramids? Would Adaptation be a useful status category in infobox? Eclectics (talk)

Sort of like the "reimplements" field on BGG? I have run across a few games here that use the description field to say that the game was based off another game. Not that we can't add a separate adapts field. Dazeysan (talk) 14:06, 22 April 2024 (UTC)
Instead of a seperate field I was thinking it might be good as a Design status, since it's orthogonal with the others. All the others are about pyramid games, but Adaptation is also a type of complete status, but not designed originally for pyramids. --Eclectics (talk) 11:01, 23 April 2024 (UTC)
Do you have any specific games in mind? I scrolled quickly through a list of game pages and the few I checked that might have been direct adaptations actually had rules changes. For example, Oi! That's My Phish! is almost a direct adaptation, but adds a new rule at the end.Dazeysan (talk) 22:53, 23 April 2024 (UTC)
There's a number I've played that aren't on the wiki, but are on some bgg lists. Mijnlieff, King's Valley, Quarto, Diam, Gardens of Mars, Rincala, All Queen's Chess, Neutron, Docker etc. There's Hey, That's My Fish! on the wiki too. The only change required for these is using pyramid instead of other pieces. But you're right; there are many adaptations that are more substantial, for which adaptation is a better word. I'd like to add to the section on the Published Games page about other unrelated games that can be played with pyramids, but how should they be marked up? Does it matter? --Eclectics (talk) 12:45, 24 April 2024 (UTC)
There's no problem at all adding them to the list on the Published Games page. But if we want to have separate pages like Hey, That's My Fish! then I would assume they should have infoboxes as well so they show up in the various Browse Games list pages. It is nice to have more details about adapting a game to pyramids than just "you can play X". What if there was a field that marked a game as "Original Design/Designed for Pyramids", "Adaptation/Port", "Variant/Reimplements"? Something along those lines to indicate that a game was originally designed for pyramids, plays exactly the same as some other game but uses pyramids and other components, or if it's based off of another game but has rules changes, any other options? I don't think I would want to mess with the Status field as it would muddy up the meaning of it. Adding another field does mean having to touch each game page, but we're getting to that point anyways to clean up other infobox fields.Dazeysan (talk) 14:07, 25 April 2024 (UTC)
That sounds ideal. --Eclectics (talk) 15:06, 25 April 2024 (UTC)
I'd like to have the "reimplements" field as well. It would be useful for accuracy (I had to argue my way into getting BGG to change Zark City from reimplements Gnostica to reimplements Zarcana, and I have no idea how long it was that way), and for basic information about games that aren't at BGG. I'm not so concerned about the specifics of the reimplementation (is it just the game all over again with pyramids, or did it change) but the directionality and original authorship, so I wouldn't object to overloading one field for more than BGG-style reimplementations.--MCDeMarco (talk) 15:20, 28 April 2024 (UTC)
Are you thinking a "reimplements" field that contains a game name like "reimplements=Chess"? -Dazeysan (talk) 22:38, 30 April 2024 (UTC)
I suppose "reimplements=[[Martian Chess]]" or an external link.--MCDeMarco (talk) 00:32, 1 May 2024 (UTC)

Should there be a license field? The wiki defaults to CC BY-SA 4.0 in footer, but if an individual game is under a different licence it might be nice to specify it in the infobox? Oh, related; I uploaded an image and it offered licenses, but the CC one is old 2.5 version?

Would it be useful? I guess it would be nice to be able to search for or sort games based on license. It wouldn't be hard to add the field, just takes time to update each game page. Do you know if there was a default license on the old wiki? I'm not seeing anything at the bottom of the pages cached on archive.org. Do we just assume they were released under the CC version available at the time if not specified? -Dazeysan (talk) 22:28, 30 April 2024 (UTC)
In the footer of the old wiki on archive.org, there's a general disclaimer, that says its mostly like Wikipedia's general disclaimer, which in turn days "There is no agreement or understanding between you and Wikipedia regarding your use or modification of this information beyond the Creative Commons Attribution-Sharealike 3.0 Unported License (CC-BY-SA) and the GNU Free Documentation License (GFDL);". The old wiki's Help:licensing page is blank.... So I think CC BY-SA is reasonable assumption. --Eclectics (talk) 10:03, 1 May 2024 (UTC)

Proposed New Fields[edit source]

Adaptation[edit source]

  • A field specifying if a game was an original design for pyramids, direct adaptation to play with pyramids and no rules changes, or a reimplementation of another game with rules changes.

Is there a better name for the field itself? Origin, Designed For, etc.

What should the 3 (or more) allowed values be?

  • Designed for Pyramids / Original Design
  • Adaptation / Port
  • Reimplementation / Variant

-Dazeysan (talk) 02:09, 1 May 2024 (UTC)

if Adaptation= is blank, then that would count as original design? Adaptation could be Y/N, and if Y the game can be linked with the bgg link? Maybe the same with reimplementation, but it can also have a link to another pyramid game?
I'm just looking for a nice way to include other games that can be played (enjoyably) with pyramids that can credit the other game. It's nice to be able to search for designed-for-pyramid games though, since they should have greater pyramidicity
an adaptation would credit the original designer, and link to that game. Not sure about reimplementation?

--Eclectics (talk) 09:38, 1 May 2024 (UTC)

Now I'm wondering if 3 new fields would be needed:
  • "Designed for Pyramids" - (true/blank) Indicates if the game was originally designed for Looney Pyramids. (Pyramideto games should be an adaptation I think)
  • "Adaptation" - (name of page on wiki or left blank) Used only if this page/game shows you how to play the specified game with pyramids and other components, the only rules changes would be related to the changed equipment.
  • "Reimplements" - (name of page on wiki or left blank) Used when the game changes the rules of the game it's based off of.
The idea is that only one of these fields should ever have something in it. The infobox would display the information in the same spot regardless of which was used. On the back-end, a 4th field could be filled in automatically that would indicate which of these 3 was used. That way search results could show you which it was without having empty columns show up. I might even be able to make the infobox display an error if more than one of the fields is used. -Dazeysan (talk) 22:52, 2 May 2024 (UTC)
It sounds good in theory but it's probably too precise for human use. People will want to use the fields to somehow represent, e.g., that Zoning Out out is both an original game for pyramids and a reimplementation or adaptation of (the non-pyramid game) Sprawlopolis.--MCDeMarco (talk) 18:06, 3 May 2024 (UTC)
I like this idea. What about things like Caldera reimplementing Volcano (ignoring the looney name changes), but designed for Pyramids. Are these perhaps variants/subpages of the original instead of reimplementations? Are you thinking that BGG_Link for Adaptation and Reimplements would go to the original game? --Eclectics (talk) 07:55, 3 May 2024 (UTC)
There are variants that have a BGG link to a thread about the variant. I'm not sure I've seen many link to the original game; that's not necessary because the original game will link there. --MCDeMarco (talk) 17:59, 3 May 2024 (UTC)
Right, I forgot about games being designed for pyramids AND being an adaptation/reimplements... Then the "Designed for Pyramids" field could be used with or without the other 2, or dropped all together. BGG_Link should only go to this game's page on BGG. If it doesn't have a game page, then I guess a link to a thread is okay but that can also just be in an "External Links" section. Here are some examples I came up with, there are probably other combinations. (FYI: I won't be able to do much in the next couple weeks with other projects and family visiting) -Dazeysan (talk) 00:54, 4 May 2024 (UTC)

Reimplements[edit source]

  • A field that would contain a game name indicating what game this was a reimplementation of.

This information could also just be part of the description in the game page. But, having it saved in Semantic MW would also let us generate automatic "Reimplemented By" lists on game pages. Taking into account the back end Semantic MW data side of things, I would prefer this field only allowing a wiki page name. That would then be turned in to a link automatically. For example:

reimplements=Martian Chess

Would show up in the infobox something like this:

Reimplements: Martian Chess

It might be possible to get the field to recognize external links as well. My argument against this is that if we try and use that data programmatically we would probably have to filter out any game with a URL in this field. Meaning they wouldn't show up in whatever lists or counts using the reimplements field. Can we just make simple pages for external games? We already have basic pages for games like Chess and Scrabble. -Dazeysan (talk) 02:09, 1 May 2024 (UTC)

License[edit source]

  • A field specifying the license the game was released under.

I couldn't find a default license in archives of the old wiki. Some games specify a license at the bottom of their page which we can just enter in to this field. If we can't find a license do we default to "unknown", "reserved", or maybe the CC license version of the time the game was added? -Dazeysan (talk) 02:09, 1 May 2024 (UTC)

I don't have an opinion on what we should do about existing games.
Some games on external sites specify the licence, but of course it's often an older one rather than a current one. To bring CC and other open licence games in we need to show the license, so a standard way of doing this is appealing --Eclectics (talk) 09:26, 1 May 2024 (UTC)
We should be clear that board games do not have licenses; the text of game rules and, separately, of wiki pages is copyrighted (automatically, under US law) by their respective authors. That copyright may have been waived using a CC license. There's nothing we can do if it wasn't, besides take down (or rewrite) any unlicensed text we become aware of and make sure there's some sort of copyleft covering current contributions. --User:MCDeMarco
CC doesn't waive copyright, it just gives some permissions, and the SA version of the licences (and other open licences) specify that you have to include a link to the license if you copy the text, so if a game is published under a different open licence I think we need to reference it? --Eclectics (talk) 11:08, 2 May 2024 (UTC)
Sorry, I should have said waived partially or etc. My point was rather that games aren't licensed; there is nothing to track down and there is certainly no default value that could be applied to games qua games. If we're instead talking about researching the copyleft on a lot of existing wiki text, some of which may be exact reproductions of rules, we should be clear about it. --MCDeMarco (talk) 16:01, 2 May 2024 (UTC)
Yes, I was just concerned with specifying the correct licence where the license is known, and different from the CC BY-SA 4.0 which is the default for the wiki. --Eclectics (talk) 07:47, 3 May 2024 (UTC)

UX Improvements[edit source]

  • There is a tendency to describe the image using the "description" field, rather than the game. A sample of image markup with description could help, but is hard to show the user at the vital moment. It's not a big enough issue to rename the field (e.g., game_description or blurb).--MCDeMarco (talk) 18:26, 8 May 2024 (UTC)
  • There is an even stronger tendency to add text to the designer field, usually "Designed by". This could be avoided if the final display of the infobox already included similar text, say, By in light gray.--MCDeMarco (talk) 18:26, 8 May 2024 (UTC)