First European symposium on Computer Games and Emotions

… will be held at ITU on Monday 27.11.2006.

From the official page:

Monday November 27th 2006, 8:30-16:15

IT University of Copenhagen, Rued Langgaards Vej 7, 2300 Copenhagen s, Auditorium 2. How to get here.

The emotional dimension of computer games has has in the recent years became a popular focus for game research and development. While new games appear dubbed as “emotional rollercoaster rides”, academic research projects attempting to understand games and emotions pop up on the fields of game studies, psychology and HCI, to name a few. Even if one does not subscribe to David Freeman’s statement that the next revolution in games is emotional, the topicality of emotions as both a subject and an approach for computer games research seems evident.
Continue reading First European symposium on Computer Games and Emotions

As we may watch

Ex-co-PhD student Martin Sønderlev Christensen (of nowuseit fame) defends his thesis masterpiece at ITU tomorrow (14:00, Auditorium 4 or 2).

The thesis is here (draft version).

Update:



By stilleben [‘stelle:bƏn] http://www.flickr.com/people/stilleben/

The abstract reads:

Abstract
This dissertation offers a cultural theoretical interpretation of the emergence of personal affective mobile media [PAMM]. By interpreting the apparent cultural changes and representation of mobile devices, the dissertation provides a description that emphasizes a conceptual shift from understanding technology as efficiency to using it affectively.

Continue reading As we may watch

The hills are alive with the sound of mergers

The skies over ITU
These days, Danish universities are in a high state of alert (or ’emergency’ in some cases). The government has proposed drastic structural reforms in the form of mergers between various institutions (we have 13 university level institutions of various sizes. Or is it 14? Anyway…).

Particuarly interesting is the suggestion that the IT University of Copenhagen (us!; 1500 students) be subsumed under the vastly larger University of Copenhagen (33.000 students).
Problem (for merger fans) is that the ITU resists these plans, now backed by the largest opposition party and IT labour organizations.

In a discussion thread at IT news outlet Computerworld.dk, one participant makes a statement which probably causes brief episodes of smugness around the house:

I’m having a hard time seeing the problem – after having been a student in both places I feel that it would be greatly beneficient for the University of Copenhagen to be subsumed under the IT University of Copenhagen.

We’ll see what happens…

Update: Lisbeth also comments

Advice for ITU project writers

The web is awash with writing guidelines. And as I’ve mentioned before the Danish book “Den gode opgave” cannot be recommended enough. But here are a few tips which I have found relevant for ITU students in particular:

  • Be more critical. Theories and research cited and used must be evaulated critically. Even the grandest old men/women of whatever field are not above critique. Particularly if coupled to modesty towards your own contribution (and a clear eye for your own problems) such criticism is a good idea (if it’s relevant, of course).
  • Consider the role of theory. Understand the relationship between theory and data in your project. Using theory as a framework for understanding (as opposed to something which is specifically tested etc. in a study) is fine but you risk leaving a gap between a long theory chapter and a much more concrete study.
  • Avoid circular arguments. Be careful of arguments and motivation statements without any content. E.g. “I’ll use X’s theory because I find it relevant”. For Danish writhers this can mean considering carefully each “fordi” and “derfor”.
  • Emphasize important stuff. If you find interesting results or reach surprising conclusions consider placing these at the fore of the project. Avoid placing every observation on the same level without emphasis. Why not put your most important finding in the very title?
  • Novelty is not relevance. You don’t need to write about newly born technologies (although there’s nothing wrong in doing so). And you certainly don’t need to use only recent literature. Don’t believe the hype – check the library. (And it can often be quite impressive to show relationships between classical thinkers and new communication phenomena, it demonstrates a breadth of knowledge).
  • Use examples. Please. It’s so obviously illustrative, so please use screenshots. Also note that by using examples you display your ability to see the abstract in the concrete and vice versa
  • Turn weakness into strength (to be used in small doses). Often students worry about “problems” which may as well be considered advantages. Two leading theoreticians disagree? Well, that’s their problem not yours. And you may well have discovered something crucial
  • Choose a reference style. Unless you have very strong opinions about how to make references use one of the hundreds of existing systematic styles such as the MLA style (http://owl.english.purdue.edu/handouts/research/r_mla.html). You need not follow their specifications about manuscript formatting (although you may want to ask your supervisor)
  • Never walk the reader through theories. Okay, that may a bit strong. How about: Never spend more than 5 lines describing a theory on its own terms. It’s much better to describe the implications of a theory or to contrast/compare it to other theories. In general, use your time on your results/conclusions and cut down theory chapters (based on the average ITU approach – doesn’t apply to everybody)
  • Don’t overestimate the user perspective. You don’t have to engage in qualitative user studies. There are other, legitimate approaches. Numbers can be fun.
  • Take a stand (and stop worrying). This is closely related to coming up with a sensible problem statement (covered in-depth in “Den gode opgave”). Avoid writing about a topic. Instead try answering specific questions. Examining specific hypotheses/questions means ignoring a multitude of interesting aspects of your topic, but this is generally preferable to lists of observations or characterizations which only stop when you run out of space. Also, don’t worry too much about being too close-minded and not open enough towards the complexities of reality. Spend your energy on sharpening your methodology and describing your approach in detail. If your methodology is strong, you can (as a general rule) be as biased as you want to in your assumptions – the results will prove you wrong. And interesting things might come of it.
  • Mention implications of the seemingly important. Within limits you’re free to base your argument on non-obvious assumptions. Economists are particular good at this, often noting how the argument to come is based on the assumption of Perfect Competition (for instance). When you do so, you must specify the character of the assumption and what’s at stake. For instance, how realistic is the assumption? And what would mean for your argument if you had chosen a different assumption? If you do not, the reader will be left with the feeling that something important is happening, but unable to identify the implications. For instance, if you state that “Phenomenology is based on the assumption that people’s subjective perceptions are interesting in themselves and this thesis is based on that same assumption” you need to explain why and to what extent your argument is invalid to someone who doesn’t share your assumption.
  • Review the literature. All projects must, in some form, discuss previous work. This means using a library to uncover the state of the field. Your review of previous research should focus on results, i.e. what we know at this point.
  • Back up your claims. Any claim which is not protected by clear consensus must be backed up by A) citing literature or by B) arguing/showing why it is correct. There’s no exact recipe for what constitutes “clear consensus” but check research articles within the same topic to see what kind of claims the authors allow to pass without backup. Also, if you’re in doubt, you probable do need a reference.
  • Find a problem. A project or master thesis sets out to answer a research question (“problem statement”). This research question should be thought of as a “problem” – if there is no problem for anybody then there is no reason to conduct the study in question. A topic (“I want to write about political games”) is not a research question. Variations of “I want to apply Model X to Phenomenon Y” may under some circumstances lead to a worthwhile project, but it is a much safer bet to find a genuine problem.

More to come…