No subject

nd, there is a trend toward complexity (and inaccessibility) over time (as =
new versions are released over a number of years). A tool starts out as som=
ewhat =91easy=92 to use (for example, an introductory programming course is=
 not required). Artists from =91traditional=92 (e.g., =91sketching=92) back=
grounds are able to make use of these tools. However, over time, there is p=
ressure to augment these tools with scripting languages so that artists or =
authors have more control over the experience (or more importantly, are les=
s constrained by the assumptions of the tool=92s creators). Scripting langu=
ages are added. Ultimately, these scripting languages can grow as complex a=
s the programming languages noted in A above (consider the later variations=
 of Flash ActionScript). =0A=
=0A=
For this reason, although there is plenty of room for new tools that cater =
to an artist=92s sketching (and/or thinking) style, many feel that artists =
need (engineering or engineering-like) skills to build their own tools and =
game environments. Perhaps this approach could help improve the situation. =
However, this points to another issue that I will try to get at next.=0A=
=0A=
Hybrid artist-engineers created programming tools for artists. Many artists=
 on this list probably use Processing.org (created by Ben Fry and Casey Rea=
s, building upon the work of John Maeda, while all were at MIT [an engineer=
ing rich environment]). Processing.org is certainly a vast improvement over=
 many alternatives. Here are a few off of the top of my head (from when I u=
sed it for some projects a few years ago): First of all, unlike many (engin=
eering) oriented programming environments, it is easy to install. The secon=
d advantage is that it includes many built-in capabilities for producing (v=
isual) graphics from day one.  Instead of =91Hello World=92, an art student=
 is producing (=91visual=92) graphics (visual-spatial forms instead of text=
 strings). Another important factor is that Processing.org is open source. =
Thus, art communities are less constrained by the aims of large corporation=
s such as Adobe. =0A=
=0A=
However, the learning curve is still pretty steep. Processing was originall=
y described as a =91sketching tool=92 by its creators (by Fry and Reas, if =
I recall). However, in my experience, sketching (with graphite on paper, fo=
r example) can be non-rational (or perhaps =91irrational=92) in a way that =
programming is not. I want to send this message in a few minutes and ideall=
y I would take some time to make that last idea clearer! Instead, I will tr=
y to motion toward some important (potential) differences and similarities =
between (traditional) sketching and programming via an example.=0A=
=0A=
Mathematicians also sketch. Sketching often transpires during the early and=
 intermediate phases of problem solving. I=92ve looked into this a bit, and=
 I think that these sketches share many common properties with the sketches=
 of architects and artists. Perhaps I will be able to elaborate in another =
message, but to make a longer story overly short, I think that an important=
 property of sketching is that a mark can be taken to have multiple concept=
ual meanings (cf. Goldschidt=92s papers on sketching, if I recall correctly=
). If the end goal is a =91rational=92 conceptual structure (which is what =
a computer program could be thought of as), then ambiguous conceptual meani=
ngs (of a sketch), that become less ambiguous during the sketching process,=
 could perform an important role in the creation or design of a conceptual =
(perhaps computational) structure.=0A=
=0A=
So to make a super long story overly short, I think that this example somew=
hat points to the types of issues that must be addressed if the aim is to f=
oster the creation of experimental digital media of the genre described ove=
r the past few weeks. Like a sketch, a lot of experimental art explores ter=
ritory that is outside of science, engineering and mathematics precisely be=
cause it can express ideas ambiguously. I am not certain that turning artis=
ts into engineers is necessarily the (complete) answer. However, a lack of =
computational literacy will undermine the voice of artists who might desire=
 to access the malleability afforded by programming languages. There is a =
=96lot- more to say about this but I had better send this message before th=
e week concludes!=0A=
=0A=
Peter=0A=
=0A=
=0A=
---------------------------------------------------------------------------=
------------=0A=
Peter Coppin | Assistant Professor, Faculty of Design =0A=
OCAD University | www.petercoppin.org/academic=0A=
________________________________________=0A=
From: empyre-bounces at lists.cofa.unsw.edu.au [empyre-bounces at lists.cofa.unsw=
.edu.au] on behalf of Westecott, Emma (Academic) [ewestecott at faculty.ocadu.=
ca]=0A=
Sent: Thursday, March 20, 2014 11:47 AM=0A=
To: empyre at lists.cofa.unsw.edu.au=0A=
Subject: [-empyre-] Experimental game sketching=0A=
=0A=
----------empyre- soft-skinned space----------------------=0A=
=0A=
One of my interests in experimental games is in the processes of experiment=
ation on display in the ways that games are made. Hence my connection of ga=
me prototyping to sketching practices evident in more traditional art forms=
. Whilst the technical constraints of pencil and paper sketching include ch=
oices about both mark making (i.e. what type of pencil) and display form (e=
.g. what type of paper) there remains expressive freedom in content. Functi=
onally, sketching allows us to develop ideas, to fix and build towards a fu=
ture outcome. As mark making sketching builds skill and expressive range. F=
or me, this process of experimentation is less interested in proving anythi=
ng than it is about exploring expressive voice. I teach my students iterati=
ve development, a fairly standard approach, moving from concept to engageme=
nt with tools to feedback in the form of critique. One of the challenges is=
 how to foster experimentation with tools without being restricted by their=
 formal structu=0A=
 re. It is true that there are more tools more available than has ever been=
 the case, however game tools tend to enforce a particular way of working t=
hat impacts the types of games likely to be made. Whilst constraints are es=
sential to finishing anything I feel it is important to be explicit about t=
he histories and restrictions of digital game making tools in order to gene=
rate a flexibility that might push beyond them.=0A=
=0A=
I feel that the uptake of game making outside market-driven spaces is final=
ly seeding a loosening in both the content and structure of game culture mo=
re generally. For me, this connects to the trend for self-expression via ga=
me making. The uptake of these 'personal' games by game culture signals an =
interesting fracture as games move from a relatively mainstream form to one=
 in which marginalized voices can be heard. Now there remain many questions=
 about maintaining this dilation, in ensuring these makers make a decent li=
ving (as discussed in Alison's post), in avoiding exclusionary cliques and =
in building an ecosystem that can build virtuous circles to sustain experim=
entation practices across communities, but that is beyond my word count her=
e.=0A=
=0A=
Looking forward to the discussion!=0A=
=0A=
Emma=0A=
=0A=
"The master's tools will never dismantle the master's house." -- Audre Lord=
e=0A=
...........................................................................=
....................................................................=0A=
Emma Westecott=0A=
Assistant Professor, Game Design=0A=
Digital Futures=0A=
Director, game:play Lab (@gameplaylab)=0A=
=0A=
T 416.977.6000 x4656=0A=
C 416.659.3667=0A=
=0A=
Twitter @OCAD=0A=
Facebook www.facebook.com/OCADUniversity=0A=
=0A=
OCAD UNIVERSITY=0A=
100 McCaul Street, Toronto, Canada  M5T 1W1=0A=
www.ocadu.ca=0A=
...........................................................................=
....................................................................=0A=
=0A=
_______________________________________________=0A=
empyre forum=0A=
empyre at lists.cofa.unsw.edu.au=0A=
http://www.subtle.net/empyre=0A=