A workshop about interaction.
After last year’s One Button Workshop (with mouse-hacking) we tried a new approach with very constrained interaction: “design a game with zero buttons”. Good projects emerged featuring audio input, accelerometer (both: from iPhone or the computer itself), mouse and multiple-mice, analog-sticks, trackpads, cameras, etc.
Focus was on interaction so the first two days were used to experiment with different input devices and on how to smooth noisy signals (for example data coming from accelerometer inputs).
Very handy came AccSim for iPhone-computer communication.
A Processing workshop about polymorphism and reflection.
The idea behind The Abyss project was to build a system and then let everyone contribute, with a good balance between individual and collaborative work.
Students could build new creatures or expand features of the abyss itself. For beginners it was easy enough to contribute with a basic creature, more advanced students could train their graphic skills or even build creatures which interacted with other creatures.
After several requests I decided to publish the (far from perfect) source code of The Abyss.
I left a few of my own example creatures but student’s creatures are not included as I didn’t ask their permission to publish the code.
Feel free to use the concept and code for your own workshops or lectures or contribute with your own leviathan on github: github.com/ertdfgcvb/TheAbyss
Rules:
Extend the SuperCreature class and build your own creature.
Allowed colors are white with alpha shades. Not a strict rule.
Each creature must implement the “move()” and “draw()” methods. (see the SuperCreature class for details).
Transforms should use the pos, rot, sca vectors.
Animations can be timed with frames or actual time.
The name of the new creature class is built with the authors initals and the creature name (not an optimal naming convention but it works with 10-20 people).
The .pde file must have the same name of the class (for example: AGCubus.pde).
Insert your name, the creature name and the version in the constructor (to do: annotations?).
Break all rules and build something new.
During a workshop in december 2010, students of the 1st and 3rd year at ECAL in Lausanne learned how to create and then extended a generic “SuperCreature” class. A creature manager took care of the creatures (via Java reflection) and added them to The Abyss. 52 different types of creatures populated the deep waters at the end of the five days workshop.
“In how many ways and with what techniques can one produce variations on the human faces seen from the front? The graphic designer works without set limits and without rejecting any possible combinations and methods in order to arrive at the precise image he needs for the job in hand, and no other.
Looking at the technique of the past we notice that a human face made in mosaic has a different structure from one painted on the wall, drawn in chiaroscuro, carved in stone, and so on.
The features—eyes, nose and mouth—are ‘structured’ differently. In the same way if one is thinking of making a face out of glass, wire, folded paper, woven straw, inflatable rubber, strips of woods, plastic, fiberglass, or wire netting.
The relationship between the features will have to be adapted to each material.”
in Bruno Munari, Arte come mestiere, 1966
(english version, Design as Art, Penguin Books)
For the first three days we (Alain Bellet from ECAL and me) used processing to build some very basic (almost trivial) tools to cover a set of six topics we identified around the human face:
Second edition of the Race! workshop. This time for three days in a beautiful villa in Vico-Morcote over the lake.
Thanks to all the participants, to MAInD for the organisation, to Renato and Serena.
Race! was a five days programming workshop at ECAL in Lausanne.
I asked the students to develop a race game. A video-game is a very good subject if you want to experiment with interaction, but I was scared about the complexity even a basic a.i. system could achieve. So the game had to be for two (or more) players, this simplified the code a lot and it also was a lot more fun.
I also didn’t want the students to invest too much time in developing graphics, sceneries, backdrops: we used real objects/architecture as “levels” and simply mapped the software around it. This approach is very fast and can produce some interesting concepts.
Technical aspects touched:
Input devices (joypads, keyboard, microphone, etc)
Video projection and mapping
Interactivity
Graphics and kinematics
As programming environment we used Processing.
