Eden, by Pablo Holmberg, Drawn & Quarterly, 2010

Yes, these comics sometimes veer into the extremely sappy, but they’re metafictional and wonderfully fabular throughout. Eden collects more than 100 simple four-panel strips featuring a diminutive, somewhat rabbit-like king, or at least, someone who wears a crown, in a magical land. An extremely insightful naïvite, of the sort that one hears in the occasional oracular pronunciation of a child, comes through at times. But these comics do not overlook death or other serious subjects. Holmberg, who writes and draws in Buenos Aires, has Eden and more available on his website, in Spanish. Odd that to learn about a Web comic, I had to go into my local comic store and buying a book, but it goes to show that book-based institutions have more than a retail function. And, it seems unlikely that Holmberg’s work would have appeared in translation without a publisher such as Drawn & Quarterly. Through such everyday efforts, we sometimes find the extraordinary.

The typographical treatment of “Fuck You” in the video is much more straightforward than in the well-linked “Say What Again” video by Jarratt Moody, which sets dialogue from Pulp Fiction to animated type. The words and letters in “Say What Again” aren’t demanding to be read as insistently, and they’re doing so much that it’s a joy to see them in motion. When there’s not as much happening, getting presented visually with the same words that are being sung to me seems a bit like having someone slap me repeatedly while saying “Slap! Slap! Slap!”

Of course, type can be used with music to do other things besides writing out the lyrics. An even simpler typographical treatment can be seen in Flash pieces by Young-Hae Chang, including the excellent “Dakota.” In those, though, the text doesn’t repeat something in the audio channel, it proceeds at a rapid pace but is legible to the attentive viewer, and it all makes for compelling reading and listening. By the way, in case you think I’m wandering off topic, the first word of “Dakota” is “fucking.”

I wonder if a straightforward animated type video, a sort of blank slate, tends to encourage remixing and the creation of new videos? In any case, Cee-Lo’s song has already been mashed up with other videos. You can see what the last scene in Dirty Dancing is like when set to that tune, for instance.

Oh, and let’s not forget Ray Bradbury. This purports to be a picture of the famous writer watching Rachel Bloom’s video.

• There’s an amusing jab at corporate executives, people who “stop exciting things from happening.” Even though the makers of the commercial may not have known or cared, this no doubt resonated among programmers at Atari.
• “Muffy, Buffy, Biff Junior, and I …” Nuff said.
• The family’s incredible, fun experience begins as they are picked up by the hand of god, which also destroys their car.
• There’s an amazing, rocking song called Playing Pole Position. Or maybe Playing Poh-oh-oh-ol, oh-oh-ol, ole Position.
• The ad is for the Atari 5200 version of the game. The original was a 1982 arcade game by Namco, later licensed to Atari; there are ports for the Atari 2600 and many other platforms.
• Although the billboard in the ad has something on both its front and its back, the Atari 5200 game’s billboards are all blank. The arcade game’s billboards featured one of the first examples of in-game advertising.
• The ad suggests that four people can play at once, particularly if you’re thinking of today’s racing games (or even Mario Kart), but the Atari 5200 Pole Position, like the arcade game, is for one player only.
• A few seconds from the end, you can see where they got the idea for the Segway.

I got some great answers, including “It does a lot with a little” (Chris Funkhouser) and “ppg combines atoms of language” (John Cayley). But at this point I’ll skip right to the one from Travis Kirton, who did the following without having any previous experience programming in Perl:

perl -le '@a=split/,/,"illmn,imgn,ltr,mut,pxl,popl,strlz,pnctu,typfc,poetc,glmr,idl,ion,cptl,cpsl,cvl,atom,pltc,txtul,erotc,rvl";sub f{pop if rand>.5}sub w{$a[rand@a]}{print f("de").f("over").w."izes ".w."ation".f("s")."\n".(" "x45)."IS WHAT ppg DOES!";sleep 5;redo}'

The program is a modification of ppg256-5, one that answers the questions that ppg256-5 generates. That’s not only clever; it showcases the expressive power of small programs and the many, if not arbitrary, uses to which a language generator can be put. This certainly earns the reward. Travis, here’s an base64-encoded version of a 32-byte DOS intro, matisse, by orbitaldecay. When you run it after decoding it with a base64 decoder, it should look like this. The base64-encoded string, you will notice, is exactly 50 characters in length:

sBPNEMUPHgeLFwmXQAEJVwFL4vSsQKq5ZQDkYEh16cM=

Okay, I lied. It’s only 44 characters long. Please accept base64 as the remaining part of the prize.

Now, I think Mark Markino’s explanation of ppg256, which I wrote about yesterday, is also great and will suffice. It’s a wide-ranging and deep study of the series of generators, similar programs I’ve discussed, and some relevant contexts of techneculture. I can’t really decide which of these explanations is best, as they both work excellently for what they are. So I am going to offer Mark Marino a 50-character generator, too. Mark, here is an ASCII encoding of a set of tools that, used properly, will allow you to draw any image:

())___RED___))_> ())__GREEN__))_> ())___BLUE__))_>

Enjoy!

Beautiful Code is an edited collection of 33 articles by a well-known publisher of technical books. The articles deal with how programmers solved a variety of problems, some of them very general computational problems, others quite specific to particular systems and applications. Several of the authors discuss their own code. The book is part of the Theory in Practice series with Beautiful Data, Beautiful Architecture, and Beautiful Security.

Beautiful Code is a success in several ways. It widens the conversation about code and the innovative development of it beyond particular programming languages, which have often been silos for such discussion has taken place in the past. At least, book-length discussion of programming – in textbooks, in introductory and reference books, and in “tips and tricks” books – has often been language-specific. While encompassing many systems and code in many languages, the book doesn’t take the position that the programming language can be abstracted away, that knowing about data structures, algorithms and an arbitrary programming language allows on to say all that can be said about how to program.

The first article is a particularly excellent one. In it, Brian Kernighan discusses 30 lines of regular expression matching C code which Rob Pike wrote as an example in an hour or two. This concise article deals with how to solve the core of the regular expression problem elegantly and correctly, but it also touches on many other important aspects of code and programming. By suggesting a series of modifications, Kernighan shows that code is an element of future programs rather than simply a fixed solution. Kernighan mentions how the code takes advantage of C pointers and suggests converting it to Java to see how the result would be slower and would require a lengthier program. If you can only read one essay in Beautiful Code, be glad that the editors have placed this one in the front, allowing you to retrieve it in a constant-time operation.

I was also interested in how several of the essays dealt with the need to consider hardware specifics, something one might expect pure, beautiful code to avoid touching. There’s some hint of this specter in chapter 7, which discusses how Jon Bently’s official, “proven” algorithm for binary search has a bug when it’s implemented on most real systems. When the code finds a midpoint within the array by computing (low + high) / 2, the sum of low and high can, in very extreme cases, exceed the maximum integer value, giving a negative (and obviously wrong) result. Later chapters deal with more productive connections between hardware and code. In chapter 10, Henry S. Warren, Jr. delves into the amazing intricacies involved in efficiently computing the population count or sideways sum: the number of bits in a word, or an array of words, that are 1. The current best way of doing this for an array involves using a special circuit called a carry-save adder. Chapter 14, “How Elegant Code Evolves with Hardware: The Case of Gaussian Elimination,” explores the relationship of leading matrix algorithms to changing hardware architectures.

Several other articles interested me; I suspect that programming language researchers, professional programmers, and others will find that a good number of the selections are worthwhile.

But despite the title and some compelling discussion inside, this is really isn’t a book about “beautiful code.” There is almost nothing in it about beauty or what that concept means when applied to code. “Aesthetics” isn’t in the index. When beauty is mentioned, it seems obligatory and stands for whatever the author of a particular chapter values. This, for instance, by Travis E. Oliphant:

“Iterators are a beautiful abstraction because they save valuable programmer attention in the implementation of a complicated algorithm.” (p. 318)

Could one say anything similar about paintings? Sunsets? Or even something that has an important functional aspect, like a building? “Frank Ghery’s Stata Center is a beautiful building because the layout of its hallways saves valuable programmer time.” That doesn’t sound quite right, does it? There are more reasonable-sounding, if not very elaborated, statements about code and beauty in the book, but some of those seem to express a very narrow perspective. For instance, Adam Kolawa writes:

“In sum, I believe that beautiful code must be short, explicit, frugal, and written with consideration for reality.” (p. 266)

Michael Mateas and I have written about obfuscated code, a topic that isn’t mentioned at all in this book. While obfuscated programs are usually short, they are also the opposite of explicit, gratuitous rather than frugal, and written without any concern for “realities” like re-use, practicality, and legibility. An obfuscated program isn’t good programming practice – that’s part of the point. For reasons that Michael and I have written about, we consider the best examples of obfuscated code to be beautiful, and I suspect we’re not the only ones. They simply display a different kind of beauty, an aesthetic of complexity and extravagance that shows us things about programming and about the language in which the obfuscated code is written – things that technical essays don’t reveal. You may share this aesthetic and be willing to consider obfuscated code beautiful, if, for instance, you saw beauty in the exorbitant Ok Go video “This Too Shall Pass.”

A final disappointment: There are no articles on the creative, artistic use of code, on programming projects that are meant to create beautiful output – no music, poetry, story, or terrain generators, lightsynths, demos, intros, or Processing sketches. Certainly a book about beautiful code, even if it is targeted at the professional programmer, would benefit from investigating a program or two of this sort?

This isn’t to say that valuing conciseness and clarity is a bad idea, or that having a book about utilitarian programming practice, particularly a wide-ranging one with many interesting articles of great technical depth, is a problem. It just means that much work remains to be done on matters of beauty and code. Perhaps we’ll soon see a book that brings together the diversity and depth of technical discussion that’s displayed here with consideration of the nature of beauty, of what it means for code to be beautiful, and of how the workings, conception, code expression, and wider contexts of a program are all involved in its beauty.

Beautiful Code is an edited collection of 33 articles by a well-known publisher of technical books. The articles deal with how programmers solved a variety of problems, some of them very general computational problems, others quite specific to particular systems and applications. Several of the authors discuss their own code. The book is part of the Theory in Practice series with Beautiful Data, Beautiful Architecture, and Beautiful Security.

Beautiful Code is a success in several ways. It widens the conversation about code and the innovative development of it beyond particular programming languages, which have often been silos for such discussion has taken place in the past. At least, book-length discussion of programming – in textbooks, in introductory and reference books, and in “tips and tricks” books – has often been language-specific. While encompassing many systems and code in many languages, the book doesn’t take the position that the programming language can be abstracted away, that knowing about data structures, algorithms and an arbitrary programming language allows on to say all that can be said about how to program.

The first article is a particularly excellent one. In it, Brian Kernighan discusses 30 lines of regular expression matching C code which Rob Pike wrote as an example in an hour or two. This concise article deals with how to solve the core of the regular expression problem elegantly and correctly, but it also touches on many other important aspects of code and programming. By suggesting a series of modifications, Kernighan shows that code is an element of future programs rather than simply a fixed solution. Kernighan mentions how the code takes advantage of C pointers and suggests converting it to Java to see how the result would be slower and would require a lengthier program. If you can only read one essay in Beautiful Code, be glad that the editors have placed this one in the front, allowing you to retrieve it in a constant-time operation.

I was also interested in how several of the essays dealt with the need to consider hardware specifics, something one might expect pure, beautiful code to avoid touching. There’s some hint of this specter in chapter 7, which discusses how Jon Bently’s official, “proven” algorithm for binary search has a bug when it’s implemented on most real systems. When the code finds a midpoint within the array by computing (low + high) / 2, the sum of low and high can, in very extreme cases, exceed the maximum integer value, giving a negative (and obviously wrong) result. Later chapters deal with more productive connections between hardware and code. In chapter 10, Henry S. Warren, Jr. delves into the amazing intricacies involved in efficiently computing the population count or sideways sum: the number of bits in a word, or an array of words, that are 1. The current best way of doing this for an array involves using a special circuit called a carry-save adder. Chapter 14, “How Elegant Code Evolves with Hardware: The Case of Gaussian Elimination,” explores the relationship of leading matrix algorithms to changing hardware architectures.

Several other articles interested me; I suspect that programming language researchers, professional programmers, and others will find that a good number of the selections are worthwhile.

But despite the title and some compelling discussion inside, this is really isn’t a book about “beautiful code.” There is almost nothing in it about beauty or what that concept means when applied to code. “Aesthetics” isn’t in the index. When beauty is mentioned, it seems obligatory and stands for whatever the author of a particular chapter values. This, for instance, by Travis E. Oliphant:

“Iterators are a beautiful abstraction because they save valuable programmer attention in the implementation of a complicated algorithm.” (p. 318)

Could one say anything similar about paintings? Sunsets? Or even something that has an important functional aspect, like a building? “Frank Ghery’s Stata Center is a beautiful building because the layout of its hallways saves valuable programmer time.” That doesn’t sound quite right, does it? There are more reasonable-sounding, if not very elaborated, statements about code and beauty in the book, but some of those seem to express a very narrow perspective. For instance, Adam Kolawa writes:

“In sum, I believe that beautiful code must be short, explicit, frugal, and written with consideration for reality.” (p. 266)

Michael Mateas and I have written about obfuscated code, a topic that isn’t mentioned at all in this book. While obfuscated programs are usually short, they are also the opposite of explicit, gratuitous rather than frugal, and written without any concern for “realities” like re-use, practicality, and legibility. An obfuscated program isn’t good programming practice – that’s part of the point. For reasons that Michael and I have written about, we consider the best examples of obfuscated code to be beautiful, and I suspect we’re not the only ones. They simply display a different kind of beauty, an aesthetic of complexity and extravagance that shows us things about programming and about the language in which the obfuscated code is written – things that technical essays don’t reveal. You may share this aesthetic and be willing to consider obfuscated code beautiful, if, for instance, you saw beauty in the exorbitant Ok Go video “This Too Shall Pass.”

A final disappointment: There are no articles on the creative, artistic use of code, on programming projects that are meant to create beautiful output – no music, poetry, story, or terrain generators, lightsynths, demos, intros, or Processing sketches. Certainly a book about beautiful code, even if it is targeted at the professional programmer, would benefit from investigating a program or two of this sort?

This isn’t to say that valuing conciseness and clarity is a bad idea, or that having a book about utilitarian programming practice, particularly a wide-ranging one with many interesting articles of great technical depth, is a problem. It just means that much work remains to be done on matters of beauty and code. Perhaps we’ll soon see a book that brings together the diversity and depth of technical discussion that’s displayed here with consideration of the nature of beauty, of what it means for code to be beautiful, and of how the workings, conception, code expression, and wider contexts of a program are all involved in its beauty.

There are eye-catching creative projects by mIEKAL aND & Liaizon Wakest and by Lawrence Upton and John Levack Drever. There are also pieces by Young-Hae Chang Heavy Industries and Molleindustria. (We can only hope for further industrialization of this sort and more of these compelling productions in future issues.) The issue also includes a piece by Abraham Parangi, Giselle Beiguelman’s mobile tagging, Sandy Baldwin’s plaintive piece “** PLEASE REPLY MY BELOVED **,” and Jorge Luis Antonio’s wide-ranging article on digital poetry.

The item that particularly caught my eye, though, was this article by Mark Marino: “The ppg256 Perl Primer: The Poetry of Techneculture.” Marino is an officer of the Electronic Literature Organization with me and a current collaborator of mine, although he completed this article before joining me on our current project. The discussion he developed for the first issue of ELP is really in-depth. Marino not only considers the workings and connotations of my ppg256 series of poetry generators, and considers related code and literary traditions from Perl Golf to the Oulipo – he also considers other programs that interest me and that I’ve discussed publicly in various contexts, sometimes with collaborators. And, he connects the coding traditions relevant to ppg256 to technical practices in boy culture and (via needlework) girl culture.

In one section near the beginning of the article, Mark relates a line of BASIC that I posted on his Critical Code Studies forum and notes (partly in jest, I think) the following:

I cannot include the full discussion here (over 5000 words) because as Montfort told me over the phone (in jest, I think), he is planning a book-length anthology of readings about the program.

Well, that’s more or less the project Mark and I, along with several others, are now embarked upon. However, we’re writing this book in a single voice rather than collecting articles about the program. More on that before too long; for now, go and enjoy the new Emerging Language Practices.

New Scientist is running an article about the use of data mining in computer games. The article focuses on research being presented at the IEEE Conference on Computational Intelligence and Games (CIG 2010). Catch live coverage of the conference here.

Tipped off by my book Twisty Little Passages: An Approach to Interactive Fiction, Jason Scott got in touch with me way back in 2005, before he had started filming interviews for Get Lamp. He came to Philadelphia, where I was working on my Ph.D. at Penn. I ended up doing one of several interviews with him there and bringing him to Autostart, a digital literature festival I helped organize at the Kelly Writers House, where he interviewed a few of the participants – just a handful of the many dozens of interviews Scott did for the documentary. I’ve gotten to see the documentary develop. I listened to audio files of the interviews, discussed the project on ifMUD, and got to see screenings of early versions with audiences at the Penny Arcade Expo East and @party.

Get Lamp is an essential film for the interactive fiction enthusiast – as I think more or less all of us know already. It’s also going to be an important film for students of electronic literature or computing history. There are some good short YouTube videos explaining interactive fiction, such as Exploring Interactive Fiction, which I did with Talieh Rohani, and Jason McIntosh’s The Gameshelf #8: Modern Interactive Fiction. These are great for people whose interest has been piqued already and who want to know a bit more about IF history and how to play. But it’s really difficult to get contemporary, non-IF playing students to understand why they should give interactive fiction a chance. Those who put a few short games on a syllabus often return to classrooms of perplexed or disgruntled people who have made no progress. Screening at least the “non-interactive” cut of Get Lamp will be time well spent. It will provide ideas for discussion and will give students permission to appreciate interactive fiction in several new ways, allowing them to better engage with assigned games.

It’s people and their stories that are always the focus of a documentary, and that’s certainly the case with Get Lamp, which assembles quips, and the occasional longer argument or rant, from players and authors of different eras. The statements from people in the film give a great sense of the many ways in which interactive fiction was and is important. This is something you don’t get in Twisty Little Passages, because my method wasn’t to interview people about their experiences; I focused more on the printed and digital record, on describing how interactive fiction works, and on scholarly questions about the status and history of the form, for instance, as it relates to the literary riddle. While people are central to the documentary, Scott certainly doesn’t shy away from archival materials such as printouts, maps, and notes or from original early packages in the documentary, though. He uses those worth-a-thousand-words pictures to give a sense of the contexts in which interactive fiction has been played from the early days of Adventure through today. Which I guess means, as everyone’s favorite retail site says, “Buy these items together!” (Actually, though, you should go to the Get Lamp order page to buy the documentary.)

Scott has done a great deal to provide coverage of today’s “modern era” of interactive fiction development while also covering its origins in Adventure, the ties that game has to caving, and the commercial heyday from Adventure International through Infocom. The history of the IF Comp is explained by current organizer Stephen Granade and others, and the emergence of short-form IF (and its relationship to the comp) is discussed as well. But the documentary’s perspective on interactive fiction clearly gazes longingly over the “golden age” of commercial IF, when Infocom was king. There’s the sense – which several people share – that interactive fiction has managed to continue in some ways from that time, which was its finest hour.

That’s not the perspective some contemporary IF authors have, though. For some, Infocom is a happy but dim memory rather than the holy city of Byzantium. Others never even played an Infocom game before playing modern IF and writing their own IF. And of course, games are not just shorter now; they are written in a wider variety of styles on a wider variety of topics. It won’t be tough for enthusiasts to find other favorite aspects of IF which didn’t manage to fit into this full and rich documentary: the relationship to MUDs or the graphical adventure, commercial games in English outside the US, or global communities working on IF in recent years. Which is just to note that while Get Lamp relates an important and untold story, it’s not the only story of interactive fiction. It’s the kind of movie that leaves me listening to my fellow IF authors and aficionados and being constantly surprised about how much I share certain people’s perspectives and how different, at other times, my view of IF is. That’s not just informative; it’s also thought-provoking.

Yes, despite the breadth and unusual textures of the topic, the film goes beyond being a great introduction to IF and the people who play and write it. There are many surprising discussions outside the main line of IF history. The academic study of IF is discussed by Mary Ann Buckles, whose 1985 dissertation on Adventure is the first study of IF and probably the first long example of work in game studies. John Romero explains the debt that computer games in general owe to text adventures. Robert Pinsky, who has served as poet laureate in addition to writing the IF Mindwheel, discusses puzzles and the pleasures of literature. Other less-than-usual suspects chime in, including fellow academics and collaborators of mine Jeremy Douglass, Ian Bogost, and Stuart Moulthrop.

One of my favorite points in the movie is when Brian Moriarty says empathetically of the Infocom catalog, “It was for literate people – it was for people who like to read!” Get Lamp is also for people who like to read, explore, and see from different perspectives. It’s not only for those who have already discovered interactive fiction, but it will delight most those who are enthusiastic about computing and what the computer can do with storytelling, language, and the modeling of words.

Jason Scott is now preparing for a “Jet Lamp” tour in September, in which he’ll show the film around the country. Perhaps you’ll get to catch it at a theater near you.

Meanwhile, the government is ineffectively trying to combat ‘internet addiction’ (or what game industry folks there call ‘overindulgence,’ as it is a type of behaviour, not a particular substance) and considering blocking underage gamers from logging in from midnight to 6am.

The gamers argue that there is no proof that internet use or game playing is dangerous.

Kurt Reinhard of the Zurich University of Applied Sciences and Arts has posted a 10-part video series about storytelling in our networked, digital age. The first part (“Change of Storytelling”) includes comments by:

• Ian Condry (MIT)
• Joshua Green (UCSB)
• Dean Jansen (Participatory Culture Foundation)
• Henry Jenkins (USC)
• Joe Lambert (Center for Digital Storytelling)
• Nick Montfort (MIT)
• Clay Shirky (NYU)

I also appear in part 7 (“Risks of Social Media”) and part 10 (“Bits and Pieces”). Besides the august company listed above, you can see that the videos get to some of the critical issues in storytelling today: fans attired as stormtroopers and “Charlie Bit My Finger – Again!”

The Secret History of Science Fiction, edited by James Ptrick Kelly & John Kessel, Tachyon Publications, 2010

This book seeks to prove that science fiction cannot really be distinguished from mainstream literature, arguing this in the introduction and in quotes before each story. Whether it prevails or not, it offers stories by some of the usual suspects (powerful ones by Ursula K. LeGuin and Connie Willis) some liminal figures (Johnathan Letham, who presents a prison made of criminals) and others – e.g., Don DeLillo, in whose story two men orbit Earth during World War III. (In a beautiful scene, they begin saying whatever they feel like as they calibrate the lethal system to their voiceprints.) There are non-human primates: T. C. Boyle’s tale of a man whose primatologist wife leaves him and George Saunders’s “93990,” a deft critique of science. Carter Scholz’s “The Nine Billion Names of God” has its own take on that author Pierre Menard, created by Borges. (Was he a science fiction author?) Even the weakest stories in here are well-written and worthwhile; most go far beyond that, making for a truly great collection.

The 2010 AAUW research report Why So Few? Women in Science, Technology, Engineering, and Mathematics (STEM) presents evidence that can help to explain this puzzle. Primarily, the research points to environmental and social barriers – including stereotypes, gender bias and the climate of science and engineering departments in colleges and universities. These elements persist to block women’s participation in STEM, but the report does recommend things everyone can do to help the associated fields open up. A collection of related recent reports can help flesh out this picture. The good news: Women are slowly on the increase in academic departments in these areas. The bad news: women continue to earn less $ than their equally educated and experienced male counterparts, across the board in almost every career category.

The memory locations beginning at 54272 are mapped on the Commodore 64 to the registers of the SID (Sound Interface Device). By POKEing random values into them, the SID, although it is a musical chip, is stimulated to produce sounds in what probably seems like a non-musical way: based on the effect of register settings and the sequence produced by the system’s random number generator, a polynomial counter.

I’m listening to the piece running on a hardware C64 now, which is soothing, although it seems like it shouldn’t be. Looking at the code, I note that the program

10 poke 54272+rnd(1)*25,rnd(1)*256 : goto 10

will put the same values into the same memory locations (and therefore SID registers) in the same order. The INT function is unnecessary because all arithmetic in C64 BASIC is done in floating point and then cast to integer whenever necessary. It’s possible that removing these functions will cause the piece to speed up, however, and I suspect it will, even though a BASIC interpreter could skip the unnecessary INT calls to begin with. There would be various ways of determining this, but the one I’d like to try involves getting two C64s, each with one version of the program, and seeing if they go out of phase.

By the way, I say that these two programs will put the same values in the same order because RND(1) returns a deterministic sequence. Any time either of these programs is invoked before other calls to RND are made, they will produce the same sequence. Using RND(0) would seed the random number generator on the jiffy clock, so would do different things depending upon how long the computer had been on before startup.

Thanks to sound artist and digital media scholar Kevin Driscoll, a.k.a. Lone Wolf, for letting me know about this.

Command your space bovine!

In space, social interactions are sparse. Space Cow Clicker overcomes this problem. In this parody of a satire, you command a battlecruiser (Space Cow) in an epic battle  to click enemy units. The first player to click all of the opponent forces wins: To click is natural, to command is Bovine!

2nd International Conference on Computational Creativity

April 27-29, 2011
Mexico City, Mexico
http://iccc11.cua.uam.mx

Original contributions are solicited in all areas related to Computational Creativity, including but not limited to:

1. computational paradigms for understanding creativity, including heuristic search, analogical and meta-level reasoning, and re-representation;
2. metrics, frameworks and formalizations for the evaluation of creativity in computational systems, note: quasi-formal approaches that, for example, argue for recognition without definition or that define the absence of creativity may have interesting implications for computational creativity);
3. perspectives on computational creativity, including philosophy, models of cognition and human behavior, and intelligent systems;
4. development and assessment of computational creativity-support tools;
5. creativity-oriented computing in learning, teaching, and other aspects of education;
6. innovation, improvisation and related pursuits investigating the production of novel experiences and artifacts within a computational framework;
7. computational accounts of factors that enhance creativity, including emotion, surprise, unexpectedness), conflict, diversity, motivation, knowledge, intuition, reward structures, and technologies, e.g. modeling, simulation, human-in-the-loop, human/machine collaboration, etc.);
8. computational treatment of social aspects of creativity, including the relationship between individual and social creativity, diffusion of ideas, collaboration and creativity, formation of creative teams, and creativity in social settings, e.g. modeling, simulation, human-in-the-loop, human/machine collaboration, etc.);
9. specific applications, with a computational component) to music, language, narrative, poetry, the arts, architecture, entertainment, mathematical and scientific discovery, programming and/or design;
10. detailed system descriptions of creative systems, including engineering difficulties faced, example sessions and artifacts produced, and applications of the system;
11. domain-specific vs. generalized creativity — does the domain of study affect, the perception of) creativity? Are there general, computational) creative principles that can be applied across domains?

PAPERS

We invite papers that make a scientific contribution to the field of computational creativity and report work that involves computation, e.g., fully autonomous systems, modeling, support for human creativity, simulation, human/machine collaboration, etc.).

We welcome studies of human creativity that in some way propose a computational model for that creativity.

When papers report on creative computer systems, we particularly encourage them to discuss systems having general or at least multiple sorts of results, to detail the methods used to design and develop the system, or to include useful related theoretical discussion.

We invite papers that go beyond simply documenting interesting systems to describe advances in cognitive science, assessment methods, design methods, or other research areas.

DEMOS/ARTS SHOW AND TELL

We invite proposals for demonstrations of computational systems exhibiting behavior that would be deemed creative in humans and for the exhibition of artifacts created using computational means, either primarily or as support for a human creator).

More information will soon be available at: http://iccc11.cua.uam.mx

Or, send email to: iccc11@correo.cua.uam.mx

IMPORTANT DATES

December 13, 2010 — Submission deadline

February 14, 2011 — Authors’ Notification

March 14, 2011 — Deadline for final camera-ready copies

April 27-29, 2011 — ICCC in Mexico City

CONFERENCE ORGANIZATION

General Chair:
Graeme Ritchie, University of Aberdeen

Program Chair:
Dan Ventura, Brigham Young University

Local Chair:
Rafael Pérez y Pérez, Universidad Autónoma Metropolitana – Cuajimalpa

Publicity Chair:
Nick Montfort, Massachusetts Institute of Technology

Senior Program Committee:

• Pablo Gervás, Universidad Complutense de Madrid
• Fox Harrell, Massachusetts Institute of Technology
• Mary Lou Maher, University of Sydney
• Alison Pease, University of Edinburgh
• Geraint Wiggins, Goldsmiths, University of London

Program Committee:

• John Barnden, University of Birmingham
• David Brown, Worcester Polytechnic Institute
• Win Burleson, Arizona State University
• F. Amílcar Cardoso, Universidade de Coimbra
• John Gero, George Mason University
• Ashok Goel, Georgia Institute of Technology
• Paulo Gomes, Universidade de Coimbra
• Kaz Grace, University of Sydney
• Kyle Jennings, University of California, Berkeley
• Robert Keller, Harvey Mudd College
• Brian Magerko, Georgia Institute of Technology
• Ramon López de Mántaras, IIIA-CSIC
• Ruli Manurung, University of Indonesia
• David C. Moffat, Glasgow Caledonian University
• Diarmuid O’Donoghue, National University of Ireland
• Sarah Rauchas, Goldsmiths, University of London
• Mark Riedl, Georgia Institute of Technology
• Juan Romero, Universidade da Coruña
• Rob Saunders, University of Sydney
• Ricardo Sosa, Tecnologico de Monterrey
• Carlo Strapparava, Istituto per la Ricerca Scientifica e Tecnologica

device design by Ed Flanagan

We’re taking a moment to reflect on the lab’s move to Dartmouth. First, we found some press to share if you’d like to chart our progress with us! In an upcoming post, we’ll review all of our new games. It has been a lot of fun setting up camp at Dartmouth and we’re thankful for the support and enthusiasm around us. Thanks to colleagues near and far, friends, advisory board, the administration at our home institution, our emerging program, staff, interns, and STUDENTS!
Go Tilt!

+ + +

Barber, Bonnie. “A Humanist Approach to Game Design.” Dartmouth Now, June 5, 2010

In 18 minutes, TEDx tackles issues, By Linday Brewer Published on Monday, April 19, 2010

Profs. discuss ‘digital humanities’, By Annie Jones Published on Monday, May 17 2010

“Games provide insight into society, culture, Flanagan says” By Conor Galligan Published on Tuesday, January 15, 2008

Digital Humanities professor to open new game lab at College, By Marielle Battistoni Published on Thursday, September 25, 2008

Pearce gives lecture on video games, Published on Wednesday, February 4, 2009

Prof. discusses text-based games, By Robert Szypko Published on Thursday, February 12, 2009

‘Digital humanities’ merges art, technology, philosophy, By Brittany Coombs Published on Wednesday, February 18, 2009

College professor designs online video game ‘Layoff’, By Erin Jaeger Published on Tuesday, March 31, 2009

[Eric] Zimmerman discusses future of game design, By Jamila Ma Published on Tuesday, April 14, 2009

Mobile exhibit space to arrive on campus, By Alex Duckles Published on Wednesday, July 1, 2009

National / International:
Sullivan, Adam. “Can Videogames Help Kids?” WCAX.com (Print and Video) 29 September 2009

Gondek, Chris. “Mary Flanagan Talks Radical Game Design.” MIT Podcast, October 2009

Abbott, Michael. “Interview with Mary Flanagan.” Brainy Gamer Podcast – Episode 23. 6 May 2009.

Beja, Marc. “Labeling Library Archives Is a Game at Dartmouth College.” The Chronicle of Higher Education. August 25, 2009

All Business. “Dartmouth Humanities Professor Awarded Grant to Design Internet Game that will Assist Libraries with Archival Data Tagging.” Via States News Service, Thursday, September 3 2009;

Elder, Robert K. “Save money, not your conscience: Online video game personalizes layoffs, poses difficult choices about cutting positions.” The Chicago Tribune, 23 March 2009

Smith, Lauren. “Dartmouth professor’s “Layoff” depicts today’s recession in video game format.” College News, 19 March 2009.

Abrams, Stephanie. “‘Layoff’ Game Gives Players Points For Job Cuts“ CBS2, 22 March 2009

Kneale, Klaus. “The Weekly Layoff Report: This Is Not A Game.” Forbes, 20 March 2009

Molina, Brad. “Play Layoff the Game!” USA Today, 18 March 2009

Wired Campus, Chronicle of Higher Education, 18 March 2009

McWhertor, Michael. “Layoffs the Videogame is Depressing Fun.” Kotaku, 16 March 2009

Heibel, S. “Layoff Game: Biting Satire Permeates Challenging Online Play,” Hispanic Business 19 March, 2009

Takahashi, Dean. “Layoff game meant as salve for corporate doublespeak,” Venture Beat March 17 2009

Perman, C. “Layoffs The Videogame-There’s Got To Be A Pony In Here Somewhere,” cNBC 20 March 2009.

Boomer, Kim. “Be the Boss: Play the Layoff Game,” WQAD, 20 March, 2009.

Downs, Martin. “Video Games Designed for Better World.” A1, 10 September 2008. Valley News, NH

Downs, Martin. “”Social Activist’ with a Joystick.” 11 September 2008. Concord Monitor, NH

Brooks, David. “New endowed humanities professor at Dartmouth has got game.” 9 September 2008, Nashua Telegraph, NH

“Acting for embodied interactive narrative”

Ken Perlin, NYU

Date: July 16th, 2010
Time: 1:15pm
Place: Engineering 2, Room 192

This lecture is free and open to the public, but visitors should purchase a parking pass from the visitor kiosk at the main entrance. There they can also provide a map showing the best parking for the School of Engineering.

Abstract

The transition from game play to emotionally believable embodied interactive protagonist-driven narrative requires something more radical than better animation blending or motion capture.  It requires rethinking the process of virtual acting from the ground up.  We must abandon linear thinking altogether and create virtual actors that can move, emote, interact and respond in real time with plausible expression, emotion and body language.

This talk will consist of two parts.  The first will build a bridge between the genres of linear film narrative and embodied interactive narrative, establishing which principles need to be preserved and which need to change.  The second part of the talk will show how these principles are guiding the creation of true acting for embodied interactive narrative.

There will be cool demos.

Ken Perlin, an NYU professor of Computer Science, directs the NYU Games For Learning Institute, was founding director of the Media Research Laboratory, directed the NYU Center for Advanced Technology, researches graphics, animation, user interfaces and science education, received an Academy Award for Technical Achievement, the 2008 ACM/SIGGRAPH Computer Graphics Achievement Award, the TrapCode award for computer graphics achievement, the NYC Mayor’s award for excellence in Science and Technology, the Sokol award for outstanding NYU Science faculty, an NSF Presidential Young Investigator Award, has been a featured artist at the Whitney Museum of American Art, received his Ph.D. in Computer Science from NYU, B.A. in mathematics from Harvard, was Head of Software Development at R/GREENBERG Associates, System Architect for computer animation at MAGI, served on the Board of Directors of the New York chapter of ACM/SIGGRAPH and the New York Software Industry Association, and is 2010 general chair of UIST.

What happens to game designers when they don’t know the “right” answers?

This is especially important in situations where designers need to somehow verify crowdsourcing data. What data can we obtain with the resources we have?

Well, what do we have?

1) In the case of our Metadata Games project for Archives, we have a huge collection of photographs.

2) Users who might want to interact with these photographs, and the user accounts they create.

3) The competitive relationships between players that might be fostered within our games.

4) The relationships between tags based upon how often they appear in images together.

5) Eventually, defined groups of associated images based on the tags that they share.

Sounds great, but what don’t we have?

We don’t know the right answers, the correct tags for any of the photos we’re asking people to tag. This is kind of a big deal, because games usually involve the user solving something the system already knows! We have no way of checking whether a user’s input is correct, so we’ll have to use the competitive relationships between users to prevent false entries.

How? By giving players a VETO button, allowing the crowd to moderate itself by disagreeing with the entries of their peers.

In single player situations we’ll be completely unable to check if entries are correct.

But it turns out our entries don’t even have to be correct. At least, not all of them. With the patterns that emerge from massive quantities of tags, we can quickly tell which entries are valid by keeping track of how many times they have been agreed upon and how many times they have haven’t been flagged. A picture tagged with the word “Dog” a thousand times and “cat” once is probably a dog. Ideally the tag “cat” will have been flagged as incorrect by someone…

In his work “Metadataing The Image”, Lev Manovich explains how automation helps humans manage an otherwise overwhelming amount of information:

“What is important in this paradigm –- and this applies for computer media in general – is that storage media became active. That is, the operations of searching, sorting, filtering, indexing and classifying which before were the strict domain of human intelligence, become automated. A human viewer no longer needs to go through hundreds of hours of video surveillance to locate the part where something happens – a software program can do this automatically, and much more quickly. Similarly, a human listener no longer needs to go through years of audio recordings to locate the important conversation with a particular person – software can do this quickly. It can also locate all other conversations with the same person, or other conversations where his name was mentioned, and so on.”

So this means that all we really need to do is to prompt users for semi-specific information and  give players a way to flag or reinforce previously existing tags.

In order to avoid the stray “cat” tag, our users should be rewarded for entering tags that are approved of by others later on. How can we get people to 1) care about whether their tags are approved by people they know and 2) invest in contributing/editing our network of tags over a long period of time?

Well Facebook seems like a pretty solid option for us if we stay away from annoying tendencies of some FB games.

Approving / flagging tags on a given photo might be a slow process to build rewards for, but so are many popular facebook games! If we keep track of who enters what tag and reward them for user approvals of said tag later on, then we can grant experience points over time. Experience grants users levels and level progressions can be broadcast to friends on facebook as a form of social reward for playing our game over an extended period.

So we’ll need to mobilize human players to filter out their own bad tags over extended periods of time. The question now is how to promote the experience in such a way that users WANT to become a part of the information salvation process. Isn’t it more fun to be bad?

Try our online version of the Grow-A-Game© cards!

We are currently waiting for the arrival of our new editions of Grow-A-Game, so our ordering area is offline for the moment until they are in.

About 2 weeks ago, at Asilomar in Pacific Grove, CA for Foundations of Digital Games Conference, professionals gathered to present academic efforts in “all areas of research and education involving games, game technologies, gameplay and game design. The goal of the conference is the advancement of the study of digital games, including new game technologies, capabilities, designs, applications, educational uses, and modes of play.”

In case you missed it (and other than what you’d find in the conference proceedings), we shared every meal, played several games of poker, and sang show tunes as Jesper Juul played the piano (for not one but) two nights in a row. I have to admit that I’m lucky enough to both love what I do and all those in my professional family.

All that aside, here is a sample of notable presentations at this year’s FDG…

Keynote: Game Design = Learning Design = Game, James Gee

James Gee gives the opening keynote to start off the Foundations of Digital Games Conference. He asserts that kids are built to be limited for their own good, and those are the principles of which the game designer must be aware. How do you walk the balance between giving the player an overwhelming amount of content and dumbing down the experience too much? What is the optimal concentrated sample at a given point in time? “Games are a guided experience on concentrated samples” and are designed with “preparation for future learning” in mind, tying learning to some affective/emotional charge.  He concludes, “it took a casual video game to teach kids in America that they have rights.”

Industry Talk: Microsoft Games Studios, Designing for Kinect, Shannon Loftis

Shannon Loftis, from Microsoft, gives a live demo of key features from Xbox’s Kinect.

• Natural User Interface: full body skeletal tracking, multi-array voice recognition and chat, human identification, digitization of people and objects
• Kinect Pillars: avateering (monkey-see-monkey-do), approachable, social, as fun to watch as to play, players play how they want to play
• Kinect detects with IR and heat-maps

She emphasizes the idea of “letting the consumer lead your design.” For instance, there are different ways people may prefer to steer a car in a racing game. Shannon demos a racing game, a pet training game, and a sports game.

Paper: “Outrun,” De-Simulating of 8-bit driving, Garnet Hertz

Hertz combines arcade console with golf cart to augment reality through computer vision. Notably, driving in real life is much slower than in any racing game, so the reproduction in 8-bit appears faster than the actual run. It will be out and running in October 2010.

Tutorial: Applied Game Design: The MDA of Bartok, Robin Hunicke and Ben Smith

Sets of poker cards, index cards, sticky notes, and a pen are laid across the room for the interactive tutorial on game design. The group splits up into fours and play games of uno. After a couple games, Robin asks us to rotate through three specified rules: (1) cumulative 2’s – where 2’s can compound the drawing with each subsequent 2, (2) show last card – where the last card must be revealed, and (3) out of turns – where there are no turns and everyone just goes.

Hunicke asks how each rule, a mechanic, creates a different dynamic in the given aesthetic. She instructs that we come up with an aspect of game (such as strategy, revenge, or suspense) and create a rule that makes it so. My rule was cumulative 2 with reverse on the change of suite (for revenge!), another was swap hands on 7, another no turns on Queen, and finally, play with all cards shown. It’s interesting how adding a rule changes how a game feels, and how Robin and Ben were able to recreate that experience at their tutorial.

Paper: Toward Effective Game-Based Social Skills Tutoring for Children, James M. Thomas and Melissa E. DeRosier

Computer science in conjunction with psychology do studies to show that game behavior of children share similarities to real life behavior. Experiments tested for in social literacy and behavior. The investigation aims to identify causes and solutions for children with unhealthy psychological tendencies.

Panel: Developers with Opinions, Jon Blow, Chris Hecker, Rod Humble

Developer panel opens acknowledging that the sky’s the  limit; however, no one seems to be reaching for the sky. Blow quotes three questions:

1. What are the toughest problems in your field?
2. Are you working on one of them?
3. Why not?

If you don’t work on an important problem, you won’t do important work. Paraphrased analogy: Even if you believe life is all about luck and you want to get struck by lightning, you should stand where you are likely to be struck, not hide in safety. “The gaming industry has a lot of McDonalds but not a lot of fine dining.”

Paper: In search of lost time: On game goals and failure costs, Jesper Juul

Jesper Juul talks about failure. Players don’t like games where they fail all the time, and also do not like games when they fail, never. Failure design is not just about difficulty. Consider time, communication, repetition.

Time: are games too long or too short? Do people play for the goal or play for the process? Do we lose time with failure? Juul distinguishes between transient and permanent goals (Bejeweled versus Bioshock). Communication: How should failure be communicated? Let the player know how “uniquely stupid” they are? Repetition: what is cost of repetition from transient to permanent experiences?

Panel: Good, Bad, or just plain Ugly? Morality and Heavy Rain, Colleen Macklin, Karen Schier, Jose P. Zagal

“The real message of the game is about how far you’re willing to go to save someone you love.” -David Cage

The panel agrees that Heavy Rain is a unique experience. Macklin finds the ethics and genre in creating culture to be overlooked by Heavy Rain’s portrayal of characters and their obvious stereotypes. Schrier has issue with inaction in the game, sometimes it’s a mistake and sometimes it’s a valid choice– “failure of the game as a game.” Zagal finds the sex scene to be just an out-of-place thrill with little narrative significance. In regards to significance, Zagal notes that the game draws significance to the more mundane experiences in life.

Macklin concludes that Heavy Rain’s media identity crisis misleads the player into commitment, and that games should, instead, “enable play instead of feeling played as a player.”

Panel: Before It’s Too Late: The Preservation of Digital Games, John Romero, Matthew Kirschenbaum, Henry Lowood

Lowood asks, how do we archive virtual worlds and digital games? For example, building archives of what the developers do in cultural repositories and encouraging collections/libraries of games in libraries and museums. Finally, Lowood suggests that collaboration among player communities, archivists, and researchers as an integral function in digital game preservation.

Kirchenbaum fills us in on the nuances of the library congress and software. For instance, materials selected for the selection must be able to run on the library’s computers (PC not Mac). Within preservation of digital worlds, He identifies many preservable facets.

Romero started a project, the “Romero Archives,” interviewing developers and designers, providing the information freely available online. It presents a complete picture of the programming process in games. Romero aims to completely document the full works of designers and their thought processes via interviews. He’s interviewed developers such as Chris Crawford and Sid Meier. As advice to developers, Romero suggests that every idea, concept, and version be well maintained. “Throwing stuff away is a bad thing.”

I left out the talks given by my EIS lab mates, including my own on “RoleModel.” You can find the complete list of proceedings online, and also: here and here and here.

The sure way to distinguish the computer’s messages from the human’s is to recognize that the computer has a rather sentimental attachment to the apostrophe and the comma.

This statement reflects Carr’s view that the internet is making us stupid. Carr recently appeared on The Colbert Report to promote his new book “The Shallows: What the internet is doing to our brains”.  He claims that as the internet helps facilitate the ability to multitask, we lose our ability to think deeply and perform reflection and introspection. Carr believes that if EISBot passes the Turing Test in StarCraft, “it won’t be because computers have become smarter; it will be because humans have become dumber”.

Carr's appearance on The Colbert Report