IT-Universitetet i København
 
  Tilbage Kursusoversigt
Kursusbeskrivelse
Kursusnavn (dansk):Experimental Interaction 
Kursusnavn (engelsk):Experimental Interaction 
Semester:Efterår 2014 
Udbydes under:cand.it., spil (games) 
Omfang i ECTS:7,50 
Kursussprog:Engelsk 
Kursushjemmeside:https://learnit.itu.dk 
Min. antal deltagere:12 
Forventet antal deltagere:20 
Maks. antal deltagere:30 
Formelle forudsætninger:Awareness of and interest in artistic and playful installations.
Some programming experience, e.g. in a C-based language (e.g., C, C++, C#, Java) or in Processing.
Skills in tinkering with electronics (such as the Arduino board and various sensors) might be handy, but can be picked up as we go. 
Læringsmål:After the course the student should be be able to:

  • Work as part of a team

  • Discuss the cultural, social, political and historical contexts within
    which games are located

  • Identify, describe, apply, communicate and discuss conceptual models of
    interactive design

  • Generate original concepts, and produce high quality previsualization, proof of
    concept and prototyping materials for concept development and pitching

  • Design and develop unique interactive projects from start to finish

  • Create and integrate media elements, such as images, text, sound, video

  • Playtest at expert level

 
Fagligt indhold:Motivation
The computer needs to come out of the box, so much is obvious. Not only the boxes that sit on desktops, but also the smaller boxes people carry around, and the very small boxes that were formerly used as phones. The solution to real-life problems is not general-purpose computers and the digitalisation of everything. But tangible computing, physical devices with material properties, situated, custom-made, special-purpose. A tendency that is visible on the mainstream consumer market for about ten years, and in the academic and artistic discourses at least for 20. Many people enjoy tangible interaction. Touching, moving, acting, collaborating. This is a clear tendency in games.
But why? Why go tangible? Why is it enjoyable to handle a well-made musical instrument, to ride or drive a vehicle, or to dance together? What does tangible mean? Why is pushing a button on a piano considered physical, but pushing a button on a computer keyboard digital? What can we learn for the design of digital games? What is the relationship between the interface/interaction device and the game mechanics?
One framework to understand tangible interaction is phenomenology. It offers a language to discuss, for instance, space, time, movement, action, our bodies, collaboration and communities of practice. From the start, phenomenology was concerned with what makes us human and on the role of technology in life. For many years, the way people thought about computer interaction was firmly anchored in modern (i.e. pre-1930) philosophy. An engineering-perspective was maintained and is still influential that focusses on what the machine is good at: Reducing high-level behavior to low-level, divide-and-conquer, mechanical explanations, formalizing through rationality – a Cartesian seperation between mind and matter, cognition and action. But it has no words for many processes that are essential to interaction. Phenomenology proposes that living is not about abstract existence, reasoning and problem solving; but about bodily existence and lived experience; activities which are always connected to location and situation, and appropriating these.
The course does not propagate particular design guidelines but attempts to introduce phenomenology as a generative language to discuss what is happening in in everyday life, artworks, interactive installations and games, to explain and analyse and to make and design. The course establishes connections between phenomenology, tangible interaction and play. It follows (among others) Husserl, Heidegger and Merleau-Ponty who highlight and develop different aspects of phenomenology, to people such as Suchman, Dreyfus and Dourish who apply ideas of phenomenology to computer interaction. Since the 1980s an increasing awareness and influence of phenomenology in digital media design can be spotted. Phenomenology turns out to be a powerful approach to creative work within the domain of interactive systems. In the course, participants discuss, analyse, design and create artworks, interactive installations and games.

Content
Electronic hacks, interface devices, sensors, coding basics, development and test of a prototype, several stages of design process, realizing final work, discuss design in relation to a specific conceptual framework (phenomenology), establish connections to own practice, uncover and present relevant ideas.

Semester Plan
Teaching starts in the week of August 25, 2014.
Week 35 Lecture: Course overview, plan, projects, marking
Week 36 Lecture: A short history of interaction
Presentations: Project 1: Art works that involve playful tangible interaction
Tutorial/lab: Coding Basics 1, work on Space Invaders
Week 37 Project 2: Embodied interaction
Tutorial/lab: Coding Basics 2
Week 38 Lecture: Tangible computing
Presentations: Project 2: Space Invaders-style games, tournament
Week 39 Lecture: Sensors and interfaces
Presentations: Project 3: Design sketch
Week 40 Presentations: Project 4: Philosophers of phenomenology
Week 41 Presentations: Project 5: Final concepts
Mid-semester break 1 week (October 13th to 19th)
Week 43 Lecture: Social computing
Presentations: Project 6: Workplans
Tutorial/lab: Prepare prototype test drive next week
Week 44 Lecture: Thoughts on Phenomenology, Meaning and Design 1
Presentations: Project 7: Prototype test drive with written feedback (Project 8)
Week 45 Lecture: Thoughts on Phenomenology, Meaning and Design 2, course evaluation
Week 46 Production final project
Week 47 Production final project
Week 48 Presentations: Project 9: Final work
Tutorial/lab: Play it
Week 49 Lecture: Post-phenomenology
Tutorial/lab: Course feedback collected

I will attempt to update the course information before teaching starts. If this is not possible, the definite version of the course outline will be published on the course web site in LearnIT.

Daniel (dace@itu.dk), 25.4.2014 
Læringsaktiviteter:14 ugers undervisning bestående af forelæsninger og øvelser

Experiment with new modes of interaction in play; design, make and test games; uncover theory and see how it relates to what we do.
The specific technical realisation (e.g. Arduino hardware and Processing or Kinect and XNA) depends on what is best suited to the design, and is discussed on a case-by-case basis.

In this course, I ask you to be active and take the initiative. Not because I can't do it, but because this is the way to learn effectively. I could tell you about the answers I have, and we could do what I think best, but I'd rather like you to decide where you want to go. This is difficult. I can't guarantee that it will be interesting where you are going. We will discuss everything, and I am happy to advise you. But nobody is taking your hand in real life. People do and learn what they need and use to their benefit. There is no substitute for a learner to figure out what he/she is interested in and do it. If you need skills you don't have, find a work around or compromise or focus or translate, which can be very exciting and rewarding, or aquire the skills; I help, but you will become the experts doing the work.

Beware: Uncertainty, doubts and hard questions (What should I be doing? Did I do the right thing? Did I nail it?) are part of the process, not a fault of the method. I am not spoon-feeding you; it is an open explorative process, and nobody knows what is coming. We face real problems and need to find real solutions. There are no pre-made perfect solutions to artificial educational exercises here. We do things to try out, to experiment and to experience; and we ask what we don't know.

Project 1: Find Art!
Find one interesting art work that involves playful tangible interaction and present it in three minutes: Describe it in one minute, show pictures or a video in one minute, and explain its critical impact in one minute.
Everybody write one page to give us an overview about the works you present. Put your name and your email address on the document.
Individual project; presentation in class in week 36, pdf hand-in per email before the presentation
Project 2: My own private Space Invaders (grade weight 10%)
This project is meant for you to familiarize yourself with programming and designing a simple game, and to get a grip on organizing such a task. It is the only project that is more or less prescribed. The other projects are much more open, and challenge you to articulate a particular take on them.
Form 3-person groups (or two person pairs). See that the abilities and skills are somewhat evenly spread between the groups. It can be interesting and most rewarding to work with people who have a different take on things than oneself. Implement your own multiplayer version of Space Invaders. Interpret the game concept in an original and exciting way, do not aim to copy the 1978 Space Invaders game. There are lots of possibilities to stay true to the idea and modify it creatively, and I trust that you will find and try some. Be bold! Do not take large chunks of code from the net without really understanding it. Do not worry about 3D graphics, modelling and game engines, but use what you have to make a clever little game.
Use classes and objects for shots and enemy space ships etc. Compensate for different computer hardware speeds (i.e. the bullet is not moved 1 pixel (or whatever) every time it is updated/displayed, but is moved 1 pixel per microsecond) – do not use something like Processing's framerate() for this, ever.
Example of using classes and objects in Processing (which is very similar to C++):
Casey Reas, Ben Fry. Processing: A Programming Handbook for Visual Designers and Artists. Cambridge, MIT Press, 2007, p. 481pp.
millis() gets you the number of milliseconds the Processing program is running (similar to SDL_GetTicks()): processing.org/reference/millis_.html
Try out a digital joystick such as the Competition Pro USB as input device (can be borrowed from me), or build a very simple interface yourself . Have a clear start to the game, and a clear end, and enable competition between players or teams, e.g. through some kind of hiscore list, so we can play a tournament and have a winning team. Figure out how to play such a tournament. Name your group and your game.
Optional features: Sound effects. A weapon and armour shop between levels with a helpful space monster clerk and a space diner car 'To the Dog and the Duck'. Have the game read the ship data from a file, so every player can play the game with his/her own customized ship – how to the data is used is up to the implementation, though. The filename is ships.dat, and the file's format is:
Argonaut;6;3;5 //P1 name;gun size/model;ship's speed;ship's skin or color
Bazillo;7;2;7 //P2
Cybernoid;1;8;3 //P3
Durango;8;1;4 //P4
...
The game play should reference the background story in some way: On the planet Teddy-3 which is not very far from here, there was once a powerfull alien teddy bear species with a very high level of technology. But these aliens got bored, lazy and decadent and subsequently became extinct. They left behind huge numbers of little self-contained robots, called TeddyBots, which are programmed to serve, help and protect teddy bears everywhere. These robots found out that on Earth, there is a huge number of teddy bears held captive by humans. They set out to rescue these teddy bears to bring them back to Teddy-3.
Present your game in class (10 minutes plus questions), explain your code and set the game up for everybody to play. We will have a tournament with the best version. There will be a prize for the winning team.
Group project; presentation in class in week 38, hand-in source code, executable, readme file (with short manual, i.e. keys) and three screen shots per email before the presentation
Project 3: Design sketch
Develop an original concept draft for an installation. The installation should focus on playful tangible interaction, that is, connect play (or art), space, location, interface(s) and objects.
Present your idea to class (10–15 minutes) as precisely as possible. Explain why it is interesting and how it is relevant to our course. You may want to show drawings, an interactive mock-up, or anything else that will explain your proposal to us. Compare your concept to other works (e.g. games, installations, artworks); has your idea been realized before? Be critical, state open questions and indicate a specific direction (or directions) for exploration. Questions about how to realize your idea are not important at this stage. Do not let your vision be limited by your technical skills. Don't focus already on a certain technology. We will discuss your concept and how to best realize it. Be inventive and creative! If you have a sweet (conceptual) idea chances are we will find a (practical) way to make it happen!
The next steps after the presentation are taking up the feedback received and (re-) developing the concept (further), as well as defining the project structure, e.g. laying out classes, functions and their parameters, define file formats, looking for electronic parts and circuits, researching input and output possibilities, etc., and having the overview who is doing what.
Group project; presentation in class in week 39
Project 4: Philosophers of phenomenology (grade weight 25%)
Select a philosopher of the tradition of phenomenology, e.g. Husserl, Heidegger, Satre, Schutz or Merleau-Ponty, and present him/her to class. People such as Wittgenstein and J. J. Gibson also have a particular stance towards phenomenology that can be interesting to discuss. Although some contemporary philosophers follow phenomenological ideas and (re-) articulate them (such as Dreyfus with Heidegger's ideas), I suggest to start from the original players. Describe the person's life and times, motivation, main questions, work and reception. Critically discuss his/her ideas, relate them to other theories, point out the relevance for and connections to tangible interaction and your work (i.e. the design sketch). Prepare a two-page document with key arguments and ideas. The main issue in this project is to get the perspective and the scope right; to recognize and communicate the essential points.
Plan for 20 minutes plus five minutes questions.
Individual project; presentation in class in week 40, pdf hand-in per email before the presentation
Project 5: Final concept (grade weight 35%)
Develop and present a final concept for your project. Explain how your concept relates to phenomenological ideas . Compare your concept to other works, be critical and state open questions. You can revise your design sketch, or start over. But now you need to produce the goods: State precisely what you want to do, why and how.
Every group has 15 minutes for a presentation plus 5 minutes for questions. The more specific you can be about your project, the bigger is the opportunity to get qualified feedback - be open to suggestions. Pick the most appropriate way to communicate your ideas (e.g. sketches, mock up, performance). Produce a three-page description; this document is not only for me, but also for you, so you can come back to it during development.
Group project; presentation in class in week 41, pdf hand-in per email before the presentation
Project 6: Workplans
Present a plan who is doing what in the remaining weeks of the semester (this project is due in the first week after the semester break; after the break you have two weeks to produce a prototype, and four weeks after that to produce the final work).
Group project; presentation in class in week 43
Project 7: Prototype test drive
Produce a playable prototype, an interactive proof of concept of your final design. Demo the prototype. Every group has 10 minutes for a presentation. Then set it up for everybody to play.
Tell us what it is, that is, explain which aspects are already realised, which are missing and which questions you hope to get answered with it. Feedback about which parts would be most helpful? The prototype should demonstrate how your concept will be realised. For the prototype test drive to give you relevant information, the basic interaction of the game has to work, otherwise we can't test it. We have already seen two concept presentations and want action. You have now four more weeks to turn the prototype into the final work.
Group project; presentation in class in week 44
Project 8: Written feedback
Play the prototypes of the other groups and give written feedback. When you test the other prototypes, find out if the idea is any good, and if the proposed way of realising the concept is plausible and interesting. Seriously consider the presented work. What is working well, what needs to be changed? Be critical, constructive and specific. Relate and compare the prototype to existing games/installations you are familiar with, that address issues similarly or differently. Name problems and (possibly) suggest solutions. Base each of your arguments in theory or on experience. Write one page per prototype. Be outspoken. This is the last opportunity for the other group to substantially change something before the final version. If the prototype is not working or boring or replicating exactly what another installation is doing, say so! Send your feedback to the other groups and to me by 1pm the next day.
This project is quite useful for the groups which receive the feedback, but it also shows your understanding and handling of the topic. What I want to say is: You are not doing this project for them, you are doing it for yourself.
The reason why I'd like you to give written (instead of only verbal) feedback is, that I believe the results will be more considerate, more reflected and weighted. Also, some people are more vocal than others, which says nothing about the relevance of their contribution. On the other hand, do not take too long to write it up. I suggest to take notes, write them up right away, revise them the next morning.
Individual project; pdf hand-in per email on the day after the Interaction Test Drive, before 1pm
Project 9: Final work (grade weight 30%)
Realize your project. Implement the code, draw graphics, record sounds, build the hardware, etc. Take up the (verbal and written) feedback you received. Test with people who are not involved, e.g. put it up in the atrium or in the Game/IxD/PIT Lab and invite people to try it. When you let somebody play for 10 seconds you will receive feedback you have never heard before, and it will be all true – the player is never wrong.
Demo and present your work (every group has 10 minutes for this, plus time for questions). Set it up so everybody can play it!
Group project; presentation in class in week 48, source code hand-in per email before the presentation 

Obligatoriske aktivititer:Der er ingen obligatoriske aktiviteter. Vær venlig KUN at ændre denne tekst når der er obligatoriske aktiviteter./
There are no mandatory activities. Please, change this text ONLY when there are mandatory activities. 
Eksamensform og -beskrivelse:X. experimental examination form (7-scale; external exam), 7-trins-skala, Ekstern censur

Everything participants do is presented and discussed in class. There are nine theoretical and practical projects. Projects 1, 3 and 6–8 are not graded, projects 2, 4–5 and 9 are graded. Because the projects build on, rely upon and feed into each other to a large extend, I ask you to do all the projects. Only three of the nine projects are to be done individually and the rest in three-person teams, so most of the time participants work collaboratively. They can change their groups but need to keep me informed. Part of most projects is a hand-in (e.g. source code or a pdf). Read the project descriptions ahead of time and be prepared. The projects must be done on time, including the presentations and hand-ins. Projects that are submitted late will be marked down. Write your name(s) on everything you hand-in. This course relies heavily on students' participation, so expectations in this department are high.

Relevant criteria for assessing the contributions are active participation and constructive criticism in discussions, asking interesting and relevant questions, doing the assigned projects and handing-in the material that is asked for on time, self-initiated research and independend learning as appropriate, developing an focus in your work relevant to the course's topic, relating lecture content to your own practice, managing your time to arrive at good results, developing a reflective habit and being able to talk about your work, support peer learning, and being receptive to new ideas and willing to learn.  

Litteratur udover forskningsartikler:Recommended Reading
Hubert L. Dreyfus. Being-in-the-world: A Commentary on Heidegger's Being and Time, Division 1. Cambridge: MIT Press, 1991 (The movie (www.beingintheworldmovie.com) is not about this book.)
Paul Dourish. Where the Action Is: The Foundations of Embodied Interaction. Cambridge: MIT Press, 2001
Michael Lewis, Tanja Staehler. Phenomenology – An Introduction. London: Continuum, 2010
These are all secondary sources which are moderatly easy to understand and to engage with. The primary works e.g. by Heidegger (Being and Time) and Merleau-Ponty (Phenomenology of Perception) are interesting but can be challenging to read.
Other books relating to game design, play, culture and art:
Patrick Crogan. Gameplay Mode: War, Simulation, and Technoculture. Minneapolis: University of Minnesota Press, 2011.
Johan Huizinga. Homo Ludens: A Study of the Play-Element in Culture. Boston: Beacon Press, 1955.
Stefanie Kreuzer (ed.). Experimente in den Künsten. Transmediale Erkundungen in Literatur, Theater, Film, Musik und bildender Kunst. (Experiments in the Arts.) Bielefeld: Transcript, 2012. (German)
Katie Salen, Eric Zimmerman. Rules of Play. Game Design Fundamentals. Cambridge: MIT Press, 2004.