Kursusbasen

Kursusoversigt

Kursusbeskrivelse

Kursusnavn (dansk):	Experimental Interaction
Kursusnavn (engelsk):	Experimental Interaction
Semester:	Efterår 2013
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 Everything gets more interesting, challenging or intense the closer it gets to the edge, and play is no exception. The questions discussed here are what is (still) play and what is not (or no longer) play. We will look at one particular theory of play and discuss how, in which ways and to which effect a number of games push the boundaries of play. We will then produce some conceptually-driven projects that do likewise. Notions of play that are challenged include play as a harmless waste of time confined to certain times or places. Games that question such notions are, for instance, the PainStation, professional sports, America's Army, pervasive/mobile gaming and live action role playing. Huizinga's concept of play is applied to the questions. It is argued that in addition to a number of characteristics that mark an activity as play, play is essentially a subjective perspective and individual decision of the player. Huizinga calls this special attitude the play spirit, which informs a player's actions and is in turn sustained by them. The clear distinction of play and non-play is elementary for play; it is not reducing participation or engagement but, on the contrary, enables them to occur. Play needs restrictions to create tension, like an artist's repertoire or an engineering problem. If there were no borders, nothing meaningful could happen. But it is the players who decide on these borders. The boundaries of play do not need to be physical or visible, in fact, they are conceptual in the first place – based on an agreement and understanding the players share. New/digital/mobile games do not challenge this concept, but provide it with a new appearance. They make it more obvious than traditional games that play is a concept, not only an activity. Content The course develops conceptual aspects, creative processes and technical skills of game design. It covers critical, provocative and subversive aspects of cyberculture. Participants discuss theory, play (computer and non-computer) games, and conceive, design and realize games that challenge play. The games might be realized using a programming language of their choice. Hardware interfaces for the game can be constructed. Participants are free to decide what their works are about, e.g. genre and topic, local or online/network, single or multiplayer; they can create games (with scores and winning etc.) or playful (open-ended) artistic installations.
Læringsaktiviteter:	14 ugers undervisning bestående af forelæsninger og øvelser Participants are expected to engage actively in a feedback loop in which action and reflection invite, necessitate and challenge each other. Participants: develop game concepts (software-only or hardware and software) research, understand and explain which boundaries are pushed, in which direction, to what effect present them peer review them produce prototype mock-ups playtest them write critical reflective statements explaining and relating their work Project 1: The Mascot Form groups of up to three people. Build a mascot from materials you find e.g. in the studio/lab/outside on the street. Do not use anything you paid for (e.g. tape, glue, paint). Name the mascot. Send me an email with a photo of the mascot, its name, the names of all members of the team and their email addresses. Group project; hand-in per email on the same day by 10pm and presentation in class in week 36 Project 2: Find two Games Find and prepare two games for us to play in class that challenge traditional notions of play. Tell us why you think this is the case. Being 'cool' is not a valid category. Produce a one-page document per game describing it and outlining why you think it is play on the edge. Bring everything we need for the games to class and explain them to us. We all will play a few rounds or matches of each game for about one hour. I favor non-computer games at this point because they invite interaction between people. In computer games (even in multiplayer games) players tend to focus their attention on the screen, not on the other players. But if you find an exceptional computer game you want to show us, go ahead! But a YouTube video is not what we are looking for. We have to play the game for ourselves. During the playing of the games we will not talk about anything else, but afterwards we will discuss our experiences and how the borders of play were touched. Prepare one game for week 37 and the other for week 39. Group project; presentations in class in week 37 and week 39, pdf hand-in per email before the presentations Project 3: Poti Pong (grade weight 15%) Implement a multiplayer Pong version with Processing, and build your own interface devices. Use an Arduino board for paddle input with (linear) potentiometers and for score output with LEDs.1 The paddles and the ball are to be displayed on the (computer) screen/projection. Sound is optional. Do not take large chunks of code from the net without understanding it – it might be more efficient to write your own code. Use classes for the ball and the paddles. Compensate for different computer hardware speeds (i.e. the ball is not moved 10 pixels (or whatever) every time it is updated/displayed, but is moved 10 pixels per second). Present your game in class (10 minutes plus questions) and set it up for everybody to play. Because we will play a tournament with the best version, a game with two teams with three players each would be great. There will be a prize for the winning team. This project is intended for you to familiarize yourself with designing and programming a simple game with a hardware interface, get a grip on organizing such a task, and as a possible starting point for your later developments. For the hand-in, submit your source code, an executable (e.g. for Windows or Mac), three screen shots, a text file how to play (if this is not obvious), and your custom-made hardware (if any). Group project; presentation in class in week 38, hand-in per email before the presentation Use an Arduino board with Processing: www.arduino.cc/playground/Interfacing/Processing Connect a potentiometer to an Arduino board and use Processing to access its values: arduino.cc/en/Tutorial/Potentiometer arduino.cc/en/Tutorial/AnalogReadSerial 1 You will need to buy your own hardware parts. 2 If you don't know the email addresses, ask. arduino.cc/en/Tutorial/AnalogInput Example of using classes and objects in Processing: Casey Reas, Ben Fry. Processing: a programming handbook for visual designers and artists. Cambridge, MIT Press, 2007, p. 481ff. millis() gets you the number of milliseconds the Processing program is running: processing.org/reference/millis_.html (www.arduino.cc/en/Tutorial/Potentiometer; arduino.cc/en/uploads/Tutorial/AnalogReadSerial_sch.png; arduino.cc/en/uploads/Tutorial/graph-circuit3.png; sandbox.yoyogames.com/extras/image/name/san2/66/307066/original/pong_nerd.jpg (all 9/2/2012); background image on page 1 www.thecircusblog.com/wp-content/uploads/2011/08/Unkonwn-Wire-walker-SBC.jpg (14/2/2012)) Project 4: Design Sketch (grade weight 15%) Develop an original concept draft for a game that challenges Huizinga's notion of play we discussed in the lecture. The result has to be a game, it has to be fun for the players, and it has to use software (do not plan to e.g. organize a vampire-themed LARP in the city). The game might or might not involve hardware (e.g. like the PainStation). Questions about how to realize your idea are not important at this stage. Do not let your vision be limited by your technical skills. Do not focus already on a particular hardware. We will discuss your concept and how to best realize it. Be inventive and creative! If you have an exciting (conceptual) idea chances are we will find a way to make it happen! Present your idea to class (10–15 minutes) as precisely as possible. You may want to show drawings, an interactive mock-up, or anything else that will explain your proposal. This project needs to have a substantial theoretical part: Explain why your project is interesting and how it is relevant to our paper. Why is your game on the edge? What notions of play are challenged? Compare your concept to other works (e.g. games, installations, artworks); has your idea been realized before? Be critical, state open questions, indicate a specific direction (or specific directions) for exploration, discuss feedback you received from peers. In my experience, the quality of the presentation has a considerable influence on the quality of the feedback participants will offer. Prepare a one-page handout with the above information, print a copy for everybody, and send me a pdf. Group project; presentation in class week 41, pdf hand-in per email before the presentation Project 5: Interaction Test Drive Produce a playable (digital) prototype, an interactive proof of concept of your final design. You may revise your idea from the Design Sketch or come up with a new idea. Take up the feedback you received earlier. Demo the prototype and 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. 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 cannot test it. We have already seen a concept presentation and now want action. Every group has 10 minutes for the presentation. Set the game up so everybody can play it. Observe players and take notes. Expect substantial written feedback from everybody the next day. Cleary label your work (i.e. a piece of paper with the name of the project, all team members and email addresses). Group project; presentation in class in week 44 Project 6: Give 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. What is working well, what needs to be changed? Seriously consider the presented work. Be critical, constructive and specific. Relate and compare the prototype to existing 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 groups2 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 quality 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 execise; pdf hand-in per email on the day after the Interaction Test Drive, before 1pm Project 7: Final Work (grade weight 35%) 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 studio or 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 15 minutes). Set it up so everybody can play it! For the hand-in, submit your source code, an executable (e.g. for Windows or Mac), three screen shots, a text file how to play (if this is not obvious), and your custom-made hardware (if any). Group project; presentation in class in week 48, hand-in per email (or CD) before the presentation Project 8: Reflective Statement (grade weight 35%) Write a reflective statement. Focus, relate, explain! State what you wanted to do, and why this is interesting. Topics you might want to talk about are (this is not a suggested outline): What does it mean to play on the edge? Where does play start, and what is the end of play? What makes it thrilling? What did you try? Which ideas worked, which didn't? Why? What was your expectation? Explain your reasoning behind your actions. You may look back unto your Design Sketch. What experiences did you make with the interactive prototype? What feedback did you get from players? Take informed positions to a number of the questions raised and the arguments discussed in the lecture. Relate and compare your work to existings works, put it into context. State open questions. Address feedback you received, be serious, critical and reflective of your own work. Taking notes during the semester as a basis of this discussion might be quite useful. 2 If you don't know the email addresses, ask. The reflective statement is not a personal note how your life has been in the last months. There is an opportunity to give feedback about the lecture and the projects in week 49. Also, do not recount and describe in detail what you did and who did what, and how much trouble it was and which software you used. Start with a target of three pages, and it should be hard to put it all in. Then shorten it to two pages, where only the really relevant issues are competently discussed. You will have done a good job if you find it difficult to fit everything on the two pages after throwing out all uninteresting material. We will have short (five minute) presentations in which participants can highlight the most interesting findings, insights, experiences, etc. they had. Focus on one or two e.g. challenging or disturbing aspects. These presentations are more speaker's corner kind of presentations than summaries of the statements. Individual project; presentation in class in week 49, pdf hand-in per email before the presentation
Obligatoriske aktivititer:	Project 3,4,7 and 8 are mandatory activities.
Eksamensform og -beskrivelse:	X. experimental examination form (7-scale; external exam), 7-trins-skala, Ekstern censur The written exam will be based on project 7 and 8
Litteratur udover forskningsartikler:	A number of experimental games and other forms of software may be assigned for students to play as a potential source of inspiration. The course blog will form an important part of students' reading during the course, with material of interest being posted regularly and contributed to by the students themselves.

Afholdelse (tid og sted)

Kurset afholdes på følgende tid og sted:

Ugedag	Tidspunkt	Forelæsning/Øvelser	Sted	Lokale
Fredag	10.00-11.50	Forelæsning	ITU	DesignLab
Fredag	12.00-13.50	Øvelser	ITU	DesignLab

Eksamen afholdes på følgende tid og sted:

Eksamensdato	Tidspunkt	Eksamenstype	Sted	Lokale
2013-12-11	No later than 2 PM	Skriftlige arbejder	ITU	Student Affairs and Program (wing 3D)