/
ThesisMain
21 lines (12 loc) · 6.45 KB
/
ThesisMain
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Initial Approach
My initial approach and research method to this work is based on the Agile Manifesto, a software development methodology that opposes siloed, top-down software development. I have paired Agile development with the work of Helene Cixous, whose "Laugh of the Medusa" provided a template for ecriture feminine, an argument for women writing of their own experience in order to be made visible. I have also examined works such as Vera Frenkel's \textit{String Games} and some of the history of conceptual video art within Canada.
This work is related to various texts of feminist and woman-oriented cybertheory that have appeared in the years since: Haraway's Cyborg Manifesto, TIQQUN's Preliminary Materials Towards A Theory of the Young-Girl. All of these are academic constructions of femininity as it is seen in relation to technology: they are feminist in the formal sense of the word. There are other senses of the term, which I will not be examining within the paper. Rather than expressing this work in context with Cixous as \textit{écriture feminine}, I will be using Cixous as a reference for the idea of the alien perspective as a perspective of resistance within a means of expression controlled by a neutral-to-hostile majority perspective.
This approach addresses women as an alien construct to the more conventional world of technology, which has been recently associated with a masculinist performance that is unnecessary for the pure structure of good rules and the development, through that, of good software.
My initial approach is to pair with an artist who had a game idea, take that idea, and then make it reproducible. Reproduction is, after all, the province of cyborgs: we control our biological systems, and in doing so, we have conquered what was once a hard-built destiny. By making the consequences of biological sex into a more pliant construct of gender, we have transformed what we must be to what we might be.
This work has been difficult, but I believe it to be important, not so much for the software itself - a proof of concept - but because it is important to provide software that permits people to access new technology. I am not alone in thinking this. The Arduino project, a microcontroller designed to make electronics more accessible to artists, and the Processing project, a simplified version of Java intended to improve the experience of scripting visual effects for artists, are both dedicated to the same ideals. Underlying both projects, as well as the broader Maker movement, is an ideal of participation in one's own work.
Put simply, people who write code, particularly using the Agile methodology, are engaging in creative practice themselves, and they then display that creative practice through the artists who repurpose their work. This is a different design pattern than technology conventionally pursues, where the work is designed in isolation and released. I am using the Agile method to develop software because it does not require that one knows what the end shape of the software will be in order to pursue the end goal. Agile requires instead that developers pursue goals in sight, always keeping their development loose enough that they can repurpose their work without much effort, and it is ideal for working with artists.
What might be is a developmental model for software that permits transition in scope from the singular, minimum-viable-product model, to a model that builds on itself until complete. A small, perfect thing that does one thing very well, which permits artists to pair their own practice with a software built expressly to make their lives easier, for not too much money. This is important, because my initial approach assumes artists to be undercompensated for their work. Although artists are the central agents of production of all the cultural capital - the invisible value - of the culture industry, they are not the prime beneficiaries of the financial system that backs, stores, and distributes that capital. Therefore, software for artists needs to be inexpensive, and set up to be almost trivially easy to use. This reserves the value of scarcity to the ability of the artist, rather than applying the majority value to the role of the engineer. This kind of invisibility is the invisibility of good management, of any type of good administration. Like housekeeping, code recedes until something goes wrong.
To test this idea, I have approached people to produce video|games with the screenPerfect software in the context of a voluntary game jam – a type of collaborative space where participants work with digital tools to generate new, raw games in a limited window – and then compiling the results into an arcade machine for presentation.
Document Structure
The remainder of this document is structured as follows: Chapter Three, Embodiment and Games, addresses some of the issues present in having only a limited context for machine work. In it, I address Anna Anthropy's Rise of of the Videogame Zinesters, the primary text of independent and self-reflective game based production, and contrast with Kristeva's Powers of Horror, the primary text of the abjectionist movement of the 1970s and 1990s. I argue that the text of masochism and the text of dis/embodied games are linked. Chapter Two, Literature Review, covers much of the reading I have done for this work and sets up the context of video games as big-budget escapism, while contrasting feminist writing on the cyborg and the history of computing to express that code is historically very much a women's discipline, and address some of how that has been lost. Chapter Four, Design Research, addresses the wins, losses, and trades of using a mix of open and closed-source software to answer the problem of accessible tools, with some thoughts on what access can be constituted to be. Chapter Five, Issues In The Economics of Open Creative Practice, addresses some pernicious issues in the economy of open hardware, such as the lack of quality control and the sense of second-class citizen status that such games may have, and offers a few paths forward. Chapter Six is my conclusion, which summarizes and re-states my arguments.
Appendix A is a list of my gitHub commit comments over the course of the writing of the game, which detail the direction of how someone reasonably confident with computers and programming learns a new language. Appendix B is a list of the games made to date with screenPerfect and their installation sites, along with links to where they might be found for future installation.