State-of-the-Art: Design of the Semantics Acquisition Games - Semantic Acquisition Games: Harnessing Manpower for Creating Semantics - page 98

Regardless of the artifact validation model used, each SAG can (and often does)
commence a secondary, after-game validation: it simply seeks for the consensus
between candidate solutions (artifacts) from different game sessions where the same
task has been used. This can be done offline, because there is nomore need for provid-
ing feedback to the player. Using this, any wrong solutions that accidentally passed
the primary, in-game validation would mostly be filtered. In fact, many SAGs [ 7 , 19 ,
21 , 27 , 29 ] depend heavily on this second step. Nevertheless, we must remember that
this secondary validation cannot exist alone within a SAG—each SAG must have
some primary artifact validation model implemented.
All of the mentioned (primary) models for artifact validation have several draw-
backs (will it be cold start problems, need for data to bootstrap on, or problem
dependencies). Therefore, there is a space and need for new models that would over-
come these issues. Responding to this, we came up with the helper artifacts scheme,
which we describe and demonstrate using the PexAce SAG, in Chap. 8 .
7.2.2 Problem Decomposition and Task Difficulty
The quantitative potential of SAGs, inherited from crowdsourcing, lies in the massive
parallelization of the task being solved, meaning that “a task” is in fact composed of
many independent “task instances” which can be assigned to players at will. At the
same time, the task instances must be simple enough, so they can be solved in short
gameplay sessions. For most currently existing SAGs, the task instances are naturally
existing in such a manner: image annotation [ 9 , 27 , 29 ], music annotation [ 12 ], term
relationship exploration [ 26 ]. Note that such SAGs usually use motivation schemes
which are not based on challenging of the player by task difficulty, because the
players would quickly get bored, but by other means (e.g. socialization).
If a SAG aims to solve a bigger problem (e.g. its abstract representation is com-
plex), which cannot be solved by a player during a game session, it has to be decom-
posable into many sub-tasks. This is a mandatory pre-condition for a SAG: if a big
problem cannot be decomposed to lesser problems, then it has a very low chance to
be solved by a SAG, because the designer would probably have a problem in making
the solving of the problem fun, and there would also be a large “understandability”
barrier in acquiring new players to play.
To some extent, a SAG may overcome this problem by introducing a system
of gradual increase of difficulty of tasks for a progressing player. After all, it is
a common practice of regular games too: over time, the player is confrontedwithmore
and more difficult problems. This keeps the player constantly challenged (a positive
effect to game's retention) and by solving more complex problems, the player also
gains more skill. The best example of a crowdsourcing game implementing this
scheme is FoldIt, where players train to create more and more complex proteins [ 4 ].
In this particular case, the truly valuable artifacts are created by experienced players
only. It is also important to note that the players do not have to possess any special
“talent” for the job, they learn how to do it during the game.