Slashdot Mirror

Btw. does anyone use IronPyhton and F#, or they just look good in PR blurbs?

Seriously, F# is awesome. These course notes and code examples explain why in far more detail than I ever could. http://www.itu.dk/courses/BPRD/E2010/.

The aim of the competition is not merely to create random levels, but to generate levels that are tailored to particular players' playing styles and skills. The level generator gets as inputs how well a player performed on a test level and various metrics detailing e.g. how much time the player spent jumping and running and how many fireballs were fired. The level will then be judged by the player who played the test level. See more about the rules at: http://www.marioai.org/LevelGeneration/Interface Also, please note that those who submit a level generator can also submit a paper about it to the CIG conference. http://game.itu.dk/cig2010/?page_id=483

For those interested, the IEEE Conference on Computational Intelligence and Games is being hosted by the IT University of Copenhagen, and Mario AI isn't the only competition. There's also simulated car racing, Ms. Pac-man, 2k Bot Prize and the Starcraft RTS AI Competition (!!!).

Whoever modded parent 'funny' hasn't heard of Dark Room Sex Game[No images, mostly SFW], playable with wiimotes and computers with blue tooth. It's obviously not a Nintendo title. But if there were games similar to this for the console itself, there would be a fair amount of money to be made.

What you are missing is that it's a *good* thing that Java generics are not "real" generics.

It appears that you're confusing CLI generics and C++ templates. I must admit that I have little knowledge of C++ templates, but a comparison of Java's Generics by Type Erasure and C#/CLI's true generics definitely favours the latter.

The following set of slides by Peter Sestoft sums up the differences pretty well: http://www.itu.dk/courses/PFOO/F2006/diku-javacsha rpgenerics.pdf

Slide no. 23 sums up the major advantages of the C#/CLI implementation:

In C#, a type parameter can be used almost as an ordinary type:

class C<T> {
void M(Object o) {
T[] arr = new T[10]; // Array creation
if (o is T) { // Instance-of test
T t = (T)o; // Type cast
...
}
T d = default(T): // Get default value for T
Type ty = typeof(T); // Get type object (reflection)
}
void MO(T x) { ... } // Overloading on type parameters
void MO(IMyList<T> x) { ... } // and type instances
}

Java simply does not allow this (slide no. 32):

[...] in Java, a generic type parameter in many respect cannot be used as an ordinary type:

class C<T> {
void m(object o) {
T[] arr = new T[10]; // Declaration OK, array creation not
if (o instanceof T) { // No instance-of test
T t = (T)o; // Type casts are "unchecked"
...
}
Class ty = T.class; // No getting the type object
}
void mo(T x) { ... } // No overloading on type parameters
void mo(MyList<T> x) { ... } // and type instances
}

Then of course there's the fact that C# type arguments can be value types, not only reference types. No boxing or unboxing is needed for value type arguments; hence better performance and less memory usage.

will everyone be willing to relearn how to type?

Probably not.

You can read my Ph.D-dissertation (PDF, big) (abstract) (PDF, small) for more information, but frankly it is very hard to beat the QWERTY keyboard, as it is very very efficient at the task it is used for. Please note that the dissertation does not focus on QWERTY per se, but rather on various alternatives to QWERTY, and the factors involved in attaining good usability, ergonomics and performance in diverse text input scenarios.

will everyone be willing to relearn how to type?

Probably not.

You can read my Ph.D-dissertation (PDF, big) (abstract) (PDF, small) for more information, but frankly it is very hard to beat the QWERTY keyboard, as it is very very efficient at the task it is used for. Please note that the dissertation does not focus on QWERTY per se, but rather on various alternatives to QWERTY, and the factors involved in attaining good usability, ergonomics and performance in diverse text input scenarios.

Whether Aarseth is correct or not, he is certainly not an amatuer.
He is the author of Cybertext which is cited in practically every paper on videogames.
He is also the co-founder of the Department of Humanistic Informatics at the University of Bergen as well as the co-founder of Games Studies an academic e-journal about videogames.
Finally, he is Associate Professor, Principal Researcher at the Center of Computer Games Research at the Department of Digital Aesthetics & Communication at the IT University of Copenhagen which is pretty much the largest group of videogame academics in the world.

So again, whether or not he is right, and i haven't yet read this latest article so i don't have an opinion, one cannot correctly say that he is an amatuer.

Although if they combine this with other projects to help guide less-than-sober people home, get drunk (In Soviet Russia) and traffic cone takes you home!

Not much reason to learn Danish. International master programmes are available.

Heh. But seriously, they have a lot in common - listen to these samples of background ambience to accompany the voice. Here's a bunch of nerds that actually understands how ambient sound can change the atmosphere completely.

For instance, in System Shock - the first time you hear SHODAN speak, she's just giving you a standard greeting ("Welcome back to Citadel Station.."). But all the time there's this evil drone in the background that starts low but keeps intensifying. SHODAN makes no threats, nor states anything evil - but that ambience, the drone, tells you that something's definitely wrong, and you should be very affraid:)

We learn from our mistakes and the world moves on... When I enrolled at comp sci at the U of Copenhagen there was no email, no web, no Java, no XP, no UNIX and no CSCW and HCI courses. That was a bad idea, so we learned.

We learn from our mistakes and the world moves on... When I enrolled at comp sci at the U of Copenhagen there was no email, no web, no Java, no XP, no UNIX and no CSCW and HCI courses. That was a bad idea, so we learned.

I'm currently working on my PhD project involving location based services. From my research, I've discovered that a much more accurate location estimate is possible than the simple "strongest cell tower". Basically you meassure the signal strengths from all available towers (or access points), and do some calculations based on this information. Finally you find the best match in a database of location/signal-strengths, and interpolate a position.

I first saw this technology used on WLAN. Ehahau uses this technology to provide location based services on WLAN, and it works great. In our test setup at the university, we get arround 1 meter error in the position.

I've been in touch with a group of people at The IT-University of Denmark, who are working on using this technology on GSM cellphones. The biggest problem here is getting access to the data. The cellphone companies simply do not want to provide this information. Our collaborative guess was that they want to keep this information to themselves, probably to sell extra services.

The main drawback of this technology is that a huge amount of calibration is needed to make it work. On WLAN our buildings have been calibrated in a grid of 3x3 meters, which makes quite a lot of calibration points when we want coverage of the entire campus. But the cool thing about it is that it does not require any extra hardware to do the localization. A labtop or PDA with wireless will do the job.

/Spiff

I'm not talking about Python. Python is positioned as a scripting language, and hence doesn't have a powerful compilation infrastructure. Although, Pysco does some very cool dynamic optimizations for Python.

In contrast, there are many high-level languages like Common Lisp, Dylan, Scheme, ML, Ocaml, etc, that have very powerful native compilers. They do optimizations that C/C++ compilers simply cannot do, because of the low-level C memory model. Literally decades of research has gone into making these compilers, and they have optimizations that (while not quite magical) are very impressive.

Variously:

- There are type-inference optimizations that eliminate the overhead of dynamic dispatch.
- There are heap-analysis optimizations that stack-allocate objects whenever possible, to avoid heap allocation.
- There are analysis that avoid heap-allocating closures.
- There are analysis that eliminate type checking and array bounds checking.
- There are analysis that perform large-scale optimization of class heirarchies, to eliminate the over head of OOP.
- There are memory allocation analysis that reduce the overhead of garbage collection (region inference).
- They do method specialization, allowing the C++ template advantage of generic functions optimized for a given type, without actually having to deal with explicit type parameters.

Some useful pointers:

Apple Dylan Wiki
Lisp vs Java vs C/C++ performane
Bigloo Scheme Compiler
Gwydion Dylan compiler
CMU Common Lisp Compiler
UW Vortex Compiler
MLKit ML Compiler
Ocaml Compiler

In Europe you'll find a Center for Computer Games Research at the IT University of Copenhagen.

They do not offer any specialized educational programmes, but students from the regular programmes can do projects with them. Their angle is quite humanistic. They tend to look more at the sociological aspect of games.

In Europe you'll find a Center for Computer Games Research at the IT University of Copenhagen.

They do not offer any specialized educational programmes, but students from the regular programmes can do projects with them. Their angle is quite humanistic. They tend to look more at the sociological aspect of games.

We are doing this at the IT University of Copenhagen right now. Se my post further down the page for more information.

And yes, this is great technology, but with quite a few limitations, which aren't all obvious. First and foremost is the problem that eye movements aren't 100% conciously controlled. Your eyes allways jitter slightly, and you have a tendency to track events outside the sceen with your eyes. The canonic illustration we use in discussions is, that you certaintly don't want the program to print your text, just because a bird flying close by your windows startled you, and made you look.

Second is the whole problem of when you "click". Dwell-time is quite popular, but has the drawback of not making you feel in controll, and leaving you all too often without a "safe harbour" on the screen. Using a "long blink" for clicking is a better option, but leaves you with another problem - distinguishing a shadow falling on the camera from a closed eye. Thus we often fall back on using a secondary device for clicking and doubleclicking.

Last is the whole issue of precision. Eye tracking today is rather unprecise, even under optimal conditions and with expensive "best of breed" equipment. As a rule of thumb, you shouldn't expect to be able to activate a button smaller than one square inch with any kind of precision, especially using dwell time for clicking.

So there you have it. Eye tracking certaintly is a usefull tool, but - for now - is rather far from the ultimate goal of direct mind interface to the computer. Actually it's a problem that eye controll sounds so fantastic, as it jacks the level of expectation from the users far too high for the state of the art. Right now you need specialized programs, and a lot of design effort to make the experience a good one - even under optimal conditions.

Just my 2 cents.