1. Introduction¶

Problem statement: We need to be able to: (a) accept, include, and make available playable artifacts submitted as part of contributions; (b) archive such artifacts to ensure that they will be accessible in 5 or 20 years; and lastly, (c) find a way to index such artifacts, so that they are citable themselves.

Plausible scenarios:

1. Authors submit a videogame artifact as part of an article/contribution
2. ?Authors submit a videogame artifact as a contribution in itself ?(as in research for the arts and design, Frayling 1993)
3. Authors submit a non-playable artifact (for example a software tool) as, or as part of, a contribution
4. Authors submit source-code as part of the above or by itself.

2. Standalone and browser videogames, and how to include them¶

Firstly, we have two categories of playable artifact formats:

1. Standalone games that need to be downloaded and run (platform-specific)
2. Browser games that run on a web browser (potentially cross-platform)

Both categories of playable artifacts can be included in articles of this project:

1. Standalone games can be included in the library. The ⁄library can host ZIP files (in addition to ebook file formats). These can be ZIP files of standalone games. Like all library entries, these can be referenced and cited by an entry of this journal. This, by referencing its library id (the last bit of a library item’s URL ), in the format below:

   ![](bib:edbc6048-fa27-4ad1-a2e1-ba1b32c3c7e6)
   

   If no text is provided in the square brackets, as above, Sandpoints will automatically generate a bibliographic reference of the library item including a library link, according to item’s metadata, as in:
   Stefano Gualeni, Nele Van de Mosselaer, Diego Zamprogno, Rebecca Portelli, Eva Škerlj Prosen & Costantino Oliva, 2021. bib⁄Doors [playable artifact]. Stefano Gualeni.

2. Browser games can be embedded via iframes. There are §⁄two examples below which embed external games (the embed code needs refining):

   • §⁄test embed of Unity game from itch.io (Brendan’s Dressage)
   • §⁄test embed of JS game (Pippin’s Ancient Greek Punishment)

   Additional considerations regarding browser games are:

   • Archiving: These examples embed external content meaning that if at any point Brendan or Pippin decide to take down these games, if, say itch.io goes under, or if for any reason the host websites don’t work, then the iframes would not run – which is a problem for us considering that these should be part of contributions. In practice, we should host and archive these games here (it should be possible to host them in a static folder; and they can also be added to the library).
   • Whether to embed web games inside an article. Although possible, this might not be the most practical thing to do, discussed in the §⁄following section.

3. Embedding videogame artifacts in practice¶

Practically, it might not be optimal to include games as iframes in the body of an article, for a few reasons:

• web games could be large in size, which (a) beats the purpose of having a light-weight website/article, and furthermore (b) if a page will load a 50mb web game, for example, the user should be aware.
• the examples below are loading automatically, which can be a nuisance: the game might start playing sounds (like below), the webpage starts getting heavier, and mouse and keyboard could focus on the game or the article, all while a user might be trying to read the article.

Eventually, if one is reading an article, even about a videogame artifact, it might be more practical for the game and the article to be somewhat distinct. Besides, reading an article and playing a game are most likely distinct activities and could be done one after the other (depending on the authors suggestion: play the game and then read the article (example¹) or vice versa. Even doing so in parallel (for example trying a game while reading its description/documentation), essentially requires two windows: one to read, and one to play.

There are two suggestions below:

• §⁄Suggestion 1: Include web games in a separate tab, accessible via image-link provided in the body of the text
• §⁄Suggestion 2: Make entry items specific to videogame artifacts (or other software contributions)

3.1. Suggestion 1: Web game iframes in new tab: click-picture-to-play¶

Add an image to the article which serves as sign and link to the game, and can include a caption. Quick example:
www⁄

• The game will play on a separate window, and in full screen.
• Nothing interactable will load in the article page.
• This workflow can ensure that the article is properly printable.
• Such images can include more deliberate content than the example above; and could be differentiated from normal images through styling.

3.2. Suggestion 2: Make entries specific to playthings¶

Another idea is to create separate entries for artifacts. For this example, I created a new item type called artifact, and I made two test entries. I also enabled backlinks for artifact items, so that mentions (citations) of artifact items, will appear at the artifact page (at mentioned in). The first is Pippin’s Let’s play from the examples below and includes the game as iframe, and the second is Doors by Gualeni (from the library) which includes a download link from the library:

• artifact⁄Let’s Play: Ancient Greek Punishment
• artifact⁄Doors

• Having a separate entry for playable artifacts, can also allow us to make them cite-able individually from the text-counterpart of a contribution (cite them as software/games by including metadata like platform, repository, etc.).
• This is not contradictory with the previous suggestion, but primarily pertains to how videogame artifacts are archived and indexed by a journal. In fact, in the body of an article, a picture with a click-to-play message can be made to link to the artifact entry of the game (this can be implemented by customizing layout partials), to combine the following:
  1. artifact⁄Let’s Play: Ancient Greek Punishment
  2. 

4. Iframe embedding examples (WIP)¶

The following examples serve just as proof of concept. The embed code needs improvement (click-to-load, full screen option, etc.).

4.1. Example embed of Unity game from Itch.io¶

Game link: www⁄Dressage (Brendan Keogh)

• requires multiple dependencies (gps etc., check if they actually work)
• figure out scroll window

4.1.1. Embed code¶

<div> 
<div style="position:relative;padding-top:56.25%;"> 
<iframe src="https://v6p9d9t4.ssl.hwcdn.net/html/431998/Dressage1.0/index.html?v=1542808136" frameborder="0" allowfullscreen="true" style="position:absolute;top:0;left:0;width:100%;height:100%;">
</iframe> 
</div>
</div>

4.2. Example embed of JS game from external website¶

Game link: www⁄Let’s Play: Ancient Greek Punishment (Pippin Barr)

4.2.1. Embed code¶

<div> <div style="position:relative;padding-top:56.25%;"> <iframe src="https://pippinbarr.com/lets-play-ancient-greek-punishment/" frameborder="0" allowfullscreen style="position:absolute;top:0;left:0;width:100%;height:100%;"></iframe> </div> </div>

5. Archiving & Indexing¶

5.1. Archiving videogames and other software¶

• Archiving videogame artifacts can be done via the ⁄library (which includes as example a ZIP of the Windows Standalone version of the game Doors by Gualeni and colleagues).
• Web games can be hosted in a static folder of this website and embedded as iframes.
• In the same way the library can host non-playable software, for example contributions that involve software tools.
• In addition, such library items can have corresponding journal entries, for example as ⁄artifacts, as in §⁄suggestion 2 above.

5.2. Archiving source code¶

There can be cases that warrant archiving, publishing and making available the source code for a software, related to a contribution.

The following was informed by research I did for my article⁄DiGRA 2023 paper, where I submitted an extensively documented Python Notebook and CSV files as part of my contribution (this, for corroboration of findings/data and possible extension of the source code by others). The two options I recommended to the DiGRA board are:

1. §⁄Republish original repository via fork at the GitHub account of the publication venue.
2. §⁄Archive and index via persistent DOI at an open repository – which is standard practice for dataset and other artifacts in the hard sciences,² and what I did for the source code of my paper.

5.2.1. Archiving source code via Repository Fork¶

Assuming that a publication venue can start a GitHub account (for example github.com/jgdr), contributions that include or concern public repositories, can be forked by the venue GitHub account. This would create a copy of the original repository at the account of the publication venue, maintaining its content as well as version and authorship history. This also ensures that whatever happens to the original repository, the fork hosted by the venue will persist and will be unaltered.

5.2.2. Archiving and indexing software and/or source code¶

One way to archive and make indexable software and source code is to submit them to repositories such as Zenodo,³ which is a common workflow for hard science fields.² Zenodo is a general purpose open repository established by the European commission in 2013, and operated by CERN. Zenodo archives data sets, reports, articles, software, source code, etc., and also creates a persistent DOI for each entry, that also supports versioning. Furthermore, it is fully compatible with GitHub (Zenodo can archive a repository release).

6. Bibliography¶

Frayling, Christopher. ‘Research in Art and Design’. Royal College of Art, Research Papers, 1, no. 1 (1993): 1–5.

Juul, Jesper. ‘The Game of Video Game Objects: A Minimal Theory of When We See Pixels as Objects Rather than Pictures’. In Extended Abstracts of the 2021 Annual Symposium on Computer-Human Interaction in Play, 376–81. Virtual Event Austria: ACM, 2021. www⁄https://doi.org/10.1145/3450337.3483449.