WHY PRESERVE TWITCH?
Twitch—a series of minimal one button game—is an epitome of the Processing evolution. Preservation of Twitch, therefore, allows the game to be a gateway to the history of Processing. Moreover, preservation of Twitch can be a pilot project for the growing numbers of software artwork that incorporate Processing.
The latter rationale is especially of import, concerning the immediate stakeholders of Processing. According to Casey Reas, co-creator of Processing and the creator of Twitch, the creative community is the primary audience of Processing. In a 2008 interview, Reas spoke about Processing as follows:
It’s not very common for artists and designers to be the primary authors of programming environment, but this is changing. I hope Processing has helped to demonstrate that we don’t need to rely only on what software companies market to us and what engineers think we need. As a creative community, we can create our own tools for our specific needs and desires.
As a matter of fact, within seven years since Reas and Ben Fry released Processing under the Open Source policy, the developing community has developed 70+ libraries. Processing users’ fields include: 12K and higher education, music industry, journal publishing, design and art industries. As a result, the language initially developed to teach computational graphic design literacy can now process audio, electronics, and animation. (You can learn more about the diverse user base in this Vimeo of a Carnegie Mellon lecture delivered by Reas and Fry.)
WHAT TO COLLECT OF TWITCH?
Preserving the source code of Twitch, together with the historical narratives surrounding its production would serve as the documentation of how an Open Source project thrives and comes to be. Here is a preservation package for the Twitch ecosystem.
1. Source Codes: Twitch is composed of (at least) 13 files*—3 JavaScript and 10 HTML files. They need to be stored in a file titled “play.” The following are the existing files that are accessible from any users’ web browser.
* see the ACQUISITION PLAN below
| File Name | Notes on Credits |
| init.js | This code searches for all the <script type= “application/processing” target=”canvasid”> in a page and loads each script in the target canvas with the proper id. It is useful to smooth the process of adding Processing code in a page and starting the Processing.js engine. |
| processing.js | Build script for generating processing.js. The version used for Skitch is 1.4.8. Written by John Resig (http://ejohn.org/), MIT Licensed (http://ejohn.org/blog/processingjs/). |
| windowScript.js | Prompts the size and position of windows as they open in sequence. |
| window0.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. TWITCH written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window1.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. FLOW written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window2.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. PERILOUS BELT written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window3.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. SLENDER VINES written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window4.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. BOOMING CANNON written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window5.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. ELECTRIC PYRAMID written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window6.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. SMUGGLING written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window7.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. SLIPPERY STREAM written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window8.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. BATTLE FRONT written by REAS (www.reas.com). Ported from Processing to Processing.js. |
| window9.html | Pattern example written by Casey Reas and Ben Fry, saved on http://ejohn.org/apps/processing.js/examples/topics/pattern.html. EERIE LABYRINTH written by REAS (www.reas.com). Ported from Processing to Processing.js. |
2. Hosting Environment: In order to allow users an interaction with Twitch, the source files need to be generated on a web browser. Web browsers need to support HTLM5 <canvas> element. As of April 2016, browsers that quality this requirements are: Chrome 4.0, Internet Explorer 9.0, FireFox 2.0, Safari 3.1, and Opera 9.0.
3. Creators & Contributors: There are at least five key figures who contributed to the fruition of Twitch. While there are many more developers, artists, and educators who shape the Processing community, the following persons have playd the crutial roles.
- Casey Reas: See my Statement of Significance
- Ben Fry: See my Statement of Significance
- John Resig: In 2010, Resig—an author of jQuery—developed Processing.js (a JavaScript port of Processing) to enable better implementation of visualization and animation. Written in JavaScript, Processing.js converts Processing codes written in Java and uses HTML5’s <canvas> element to render images. The idea of translating Java to JavaScript suggests a wonderful adaptation strategy to the changing programming environment. Owning to Resig’s work, Processing users do not need to abandon Processing (which operates in now-close-to-obsolete-Java). All Processing users need to do is to include Resig’s JavaScript file “processing-1.0.0.min.js” to their .pde file, just as they have always done.
- John Maeda: See my Statement of Significance
- Muriel Cooper: See my Statement of Significance
ACQUISITION PLAN?
1. Source Codes: It is best to acquire source codes from Casey Reas. This approach allows me to acquire .pde source file. *Otherwise, a web brower’s “View Page Source” function (such as the one that Google Chrome offers) lets me have a look at most of the source codes. With the latter method, I can reconstruct the initial Twitch page (window0.html) and the first game window (window1.html). However, as this approach only allows me to inspect the source code generated on the web browser; the files listed above in the table are not complete enough to proceed to the second and consequent game windows.
2. Hosting Environments: The current common web browsers support HTML5 <canvas> elements. Should the future update of web browsers results in malfunction of Twitch, there is a web browser emulation project such as oldweb.today that may be of use.
3. Documentations of Creators & Contributors: Documentation of each individuals’ contribution requires some research. Reas and Fry’s rationale behind the development of Processing has become a part of core philosophy of Processing community and is thus well documented in the official websites such as Processing.org and Processing Foundation. So, too, are the anecdotes and praises of John Resig. His blog post entry, interview, and the reddit’s reaction to Processing.js are some of the records that can be preserved. Additionally, Resig’s role as a leading figure of Khan Academy’s Computer Science and how he utilizes Processing.js as a part of his pedagogy are relevant; and these records should assist us in understanding the climate of Twitch ecosystem.
This is great work. I like how you are focusing on both the actual files as well as putting together a set of materials that round out and further contextualize them and their purpose. This reminds me a bit of how the Chan and Cope article thought about acquiring a piece of software. It is great to focus on documenting what the run environments for these are (that is what browsers they worked in) as that information will be critical for future use. One thing I think you might want to consider adding is some screen recordings of what the games look like and play like so that someone in the future also has that for reference in terms of how the games work.