Page MenuHomePhabricator

building more games using Wikidata's data
Open, MediumPublic

Description

Games are an engaging way to get to know Wikidata. We should have more of them.

Things to keep in mind:

  • We do not want gamification!
  • We do not want to incentivice people to do bad edits and other actions on Wikidata

Some great existing games:

Inspirations for new games:

  • a memory game
  • http://kevan.org/wikitext
  • bring a set of items into the right order (for example order actors by number of movies)
  • 20 questions
  • T315162
  • catch phrase (give a catchphrase and let the player guess who it is from)
  • named after (give the player a famous person and images of things. let them guess which of the things is named after the person.)
  • https://wiki-race.com
  • https://www.nytimes.com/games/connections
  • https://redactle-unlimited.com
  • show several images (related to different Senses) of a Lexeme and make the player guess the word. Query for Lexemes in English with more than 2 senses having an image that this game could be based on: https://w.wiki/BYAN
  • show 2 movies and let the player figure out which one is higher rated/more popular
  • Give 4 or 5 related Items and let the player chose which one is the odd one out
  • Give the player a handful of actors and let them guess which actors starred together in a TV show or movie

Steps to get started on a new game:

Event Timeline

To avoid bad edits with games, it would be interesting to combine the following strategies:

  • Reject statements that violate a property constraint.
  • From time to time, repeat questions that a certain user has previously answered. If, most of the time, a certain user provides different answers to identical questions, that user should be prevented from playing the game.
  • From time to time, ask questions with known answers (those already available in Wikidata, using a reference and not violating any property constraint). If a certain user usually provides answers that don't match to these, the user should be prevented from playing the game.
  • From time to time, include stupid, fake options as possible answers between the actual ones. If a certain user often selects the stupid answers, that user should be prevented from playing the game.
  • Show all the possible answers in random order each time.
  • Always include a visible option "I don't know", "Skip", "Ignore question", etc.
  • Use redundancy between different users and define an absolute minimum number of identical answers and a minimum percentage of identical answers divided by the total number of answers for each problem that users have to solve. Having exceeded these two minimums, the corresponding answer should be included in Wikidata as an actual edit. This strategy can be useful in the following situations:
    • The user interface lets users answer many questions in a short period of time.
    • The game isn't using other mechanisms to ensure data quality.
    • There's a very limited number of possible answers (e.g. male or female, yes or no, etc.).
    • There's a limited number of different questions to be shown.
  • Give detailed textual explanations each time that a certain user makes a bad decision. This have two desired effects: guides and helps good-faith users, who are interested in collaborating in a constructive way; and makes vandals angry, as they just want to have fun without caring about data quality. To increase this effect, prevent users from closing some warnings for a few seconds, time during which good-faith users will be reading the text.

Game suggestion: perhaps something like Anno Domini? Bring a set of events into the right chronological order. (Events would be either items with their own “point in time”, or the “date of birth”/“date of death”/“start time”/“inception”/… of other items.)

Game suggestion (to show people how much Wikidata knows, rather than to generate edits or new data): Twenty Questions, which is a guessing game where one player thinks of a thing and the guesser tries to figure out what it is with up to 20 yes/no questions. It's been turned into a handheld game called 20Q which learned what questions to ask by having people play on a website and asking for new questions when it lost the game. It seems like the hierarchy of Wikidata properties would provide a similar way to find a specific thing based on careful guessing—and guesses wouldn't have to be binary, either.

... Twenty Questions, which is a guessing game where one player thinks of a thing and the guesser tries to figure out what it is with up to 20 yes/no questions. ... It seems like the hierarchy of Wikidata properties would provide a similar way to find a specific thing based on careful guessing—and guesses wouldn't have to be binary, either.

I love the idea! Although I guess that designing an effective, general 20Q on Wikidata will be a challenge. Wikidata has around 50 million items and 20 yes/no questions only let us distinguish 2^20 = 1048576 things, so we would probably have to select the most relevant items, 1% or less, in advance, and/or make the most of non-binary guesses, as you suggest. Also, the number of items having all the data to answer a certain list of 20 relevant questions may not be enough. Sadly, people often consider classes (the idea of "chair", "table", "computer", "book", "goat", etc.), while Wikidata classes have almost no useful statements for this game apart from the "subclass of" (P279) hierarchy.

I was pointed to this thread by the Telegram group, who recommended I mention this game I have made: https://wikitrivia.tomjwatson.com.

It uses wikidata as the data source for "cards", which need to be placed on a chronological timeline. The aim of the game is simply to get the longest streak possible. It can get quite addictive! I'd love to hear what you guys think.

The code is open source and comes in two parts, the scraper - https://github.com/tom-james-watson/wikitrivia-scraper - and the web app - https://github.com/tom-james-watson/wikitrivia.

Lydia_Pintscher renamed this task from games using Wikidata's data to building more games using Wikidata's data.Aug 11 2022, 10:46 AM

@VIGNERON got a ton of Lexeme related ideas he should add :-)

Ideas around words (more or less from easy to hard, not all need lexemes) :

  • Hangman
  • Categories / Stadt, Land, Fluss
  • Bulls and cows (most famous variation being Wordle)
  • Spelling bee (or variation like Boggle)
  • finding anagrams
  • Lexicant
  • Scrabble
  • Crossword
  • Puzzle words
  • something around etymology, finding cognate?
  • Taboo (need semantic field?)
  • Cemantle (?)
  • find words related to an image (via items or files with a lot of "depicts")

Make variation (to avoid potential copyright problems and to make it more fun/appealing).
Maybe offer some hint/answer/explanation.

See examples of word games on https://www.merriam-webster.com/games or https://www.nytimes.com/crosswords

See also https://www.lehir.net/solving-wordle-sutom-and-gerdle-with-sparql-and-wikidata/ by @Envlh ;)

(I'll probably add more later).

Bouncing off my last point, here is a more refined idea: to show several images (related to different senses) of a lexeme and make the player guess the word.
Here is a query https://w.wiki/BYAN (Lexemes in English with more than 2 senses having an image, some results are less "fun" than others but still good enough for a game I think).

An arcade of games from a recent Game Jam that has some Wikidata usage:

https://playwiki.games/