Sexismus ist in unserer Gesellschaft ein ernsthaftes Problem. Kein Problem allerdings ist, dass er in Videospielen auftaucht. Ich hatte gehofft, dass wir das in mehr als zehn Jahren Killerspieldebatte gelernt hätten. Wer würde ernsthaft bestreiten, dass es in Videospielen Gewalt gibt? Freunde virtueller Gewalt relativieren manchmal, wenn es um dargestellte Grausamkeit geht.

Virtuelle Gewalt ist OK, weil wir verinnerlicht haben, dass reale Gewalt es nicht ist. Wir sehen den Krieg – und wollen, dass er auf der anderen Seite des Bildschirms bleibt. Bei Sexismus ist es vielleicht nicht so einfach. Jeder ist nun mal ein bisschen sexistisch (oder so ähnlich). Und da dürfte es durchaus helfen, sich auch über Vorurteile in Videospielen bewusst zu werden. Problematisch ist, wenn wir Dinge als gegeben hinnehmen, sie nicht hinterfragen. Denn dann verfestigen sie womöglich unser Weltbild – samt aller damit verbundenen Probleme.

In diesem Sinne: Sexismus in Videospielen ist OK – solange er auf der anderen Seite des Bildschirms bleibt.

Letzteres ist leicht zu realisieren: Man müsste einfach abhängig von der Relativgeschwindigkeit einen Farbfilter über das Bild legen. Klassische 3D-Engines berechnen aber immer alle Ereignisse, die im Moment der Anzeige passieren – und geben sie direkt auf den Bildschirm. Das klappt natürlich nicht, wenn man jeweils sieht, “was da mal war“.

Für eine 4D-Engine könnte man also alles im Arbeitsspeicher behalten, was der Spieler noch sehen könnte. Oder aber man berechnet Ereignisse in der Vergangenheit erst, wenn sie für die Spielergegenwart relevant werden. Für statische Objekte ändert sich praktischerweise ohnehin nichts, Bewegungen müssen parametrisiert werden. Eine Kugel, die zu einem bestimmten Zeitpunkt abgeschossen wurde, ist ein sehr einfaches Beispiel. Wenn diese nicht zwischenzeitig mit anderen beweglichen Objekten zusammentrifft, ist ihre Position zu jedem beliebigen Zeitpunkt leicht zu ermitteln. Doch eine statische Welt, in der ohne Zutun des Spielers nicht passiert, ist eher langweilig, sodass auf Simulationen außerhalb der Sichtweite nicht verzichtet werden sollte.

Doch wie hält man den Speicherbedarf gering? Ständig von jedem Punkt virtuell Photonen aussenden zu lassen ist sehr aufwändig. Wenn man sie nur in solche Richtungen abstrahlen lässt, in die der Spieler kommen könnte, bevor das Licht diese Stelle passiert hat, reduziert sich der Aufwand merklich. Im Grenzfall eines sehr langsamen Spielers wäre man bei klassischem Raytracing angelangt. Ist der Spieler aber schnell, müsste man quasi Raytracing für alle Orte machen, an die der Spieler noch kommen könnte. Keine besonders effiziente Idee.

Rettung verspricht schließlich die gute alte Demo, wie man sie aus dem E-Sport kennt. Dort werden alle Bewegungen der Spielfiguren aufgezeichnet, um das Spiel im Nachhinein noch einmal ansehen zu können. Und zwar nicht nur aus der Perspektive des Spielers. Für eine 4D-Engine muss nun allerdings die Anzeige von der Berechnung der Bewegungen abgekoppelt werden: Was gerade passiert, hat auf dem Bildschirm nichts zu suchen. Angezeigt wird nur, was sich vor einer beliebigen Zeit T genau im Abstand c×T vom Spieler befunden hat.

Kernkonzepte und Schwächen
Die zentralen Elemente sind das Fangen und das Kämpfen. Beide müssen erhalten bleiben, um den Charakter des Spiels nicht zu zerstören. Auch Weiterentwicklung und Erlernen von neuen Attacken sind nicht zu ersetzen. Als Mechanismus hierfür wurde bisher der Levelzuwachs der Pokémon genutzt. Trotz EP-Teiler bereitet das „Trainieren“ der Pokémon oftmals eher Arbeit als Vergnügen. Vor allem, wenn man in Anfangsgebiete zurückkehrt, nervt die Differenz der Level. Auch vom Storytelling ergibt es keinen Sinn, dass die Trainer aus den verschiedenen Regionen im oder gegen den Uhrzeigersinn stärker werden. Warum ist die Göre aus der letzten Stadt deutlich stärker als der fünfte Arenaleiter? Das ergibt einfach keinen Sinn… Dass dagegen ein gut trainiertes Pokémon auch gegen eigentlich bevorteilte Typen gewinnen kann, ist durchaus eine valide Designentscheidung.

Fitness: Level Down
Die Lösung wäre die Abschaffung der bisherigen Level. Pokémon, die nicht trainiert werden, verlieren wieder Level. Um das neue Konzept greifbar zu machen, könnte man es „Fitness“ nennen. Gut trainierte Pokémon kämpfen besser, legt man sie nur in die Box (und sie sich auf die faule Haut), werden sie so träge, dass Vögel selbst im Kampf gegen Käfer versagen. Man könnte noch implementieren, dass sich träge Exemplare leichter fangen lassen, um das bisherige Fanggefühl nachzubilden. Das im Spiel zentrale Kämpfen funktioniert mit Fitness sogar besser als mit Levels: Die absurde Situation, dass die Pokémon je nach Region um Größenordnungen unterschiedlich stark sind, würde behoben.

Orden
Die Orden, die es im Spiel für das Besiegen von Arenaleitern gibt, ermöglichen einem bisher, Pokémon mit einem höheren maximalen Level zu kontrollieren. Das ergibt mit der Fitness nur noch begrenzt Sinn: Es ist nicht unbedingt motivierend, sein Team nur bis zu einem bestimmten Fitness-Level trainieren zu dürfen und sie dann wieder verfetten zu lassen. Fitness soll sich ja viel schneller verändern als das bisherige Level. Möglich wäre hier, das maximal erreichbare Fitness-Level mit der Zeit zu erhöhen: Pokémon von Anfänger-Trainern werden nicht so fit wie die von Profi-Trainern. Eine vermutlich bessere Alternative wäre, den Fitness-Zuwachs pro Kampf zu erhöhen und die Abnahme zu reduzieren. Oder man führt Autorität ein: Zuneigung der Pokémon zum Trainer ist ja schon seit der ersten Generation (gelben Edition) Spielelement. Ein fittes Pokémon wird einem Trainer, dem es vertraut, weiterhin gehorchen. Misstraut es dem Trainer, muss dieser eine gewisse Autorität ausstrahlen (sprich: Orden haben), damit es seinem Ruf folgen.

Weiterentwicklung und neue Attacken
Nicht direkt von Levels auf Fitness übersetzt werden sollte das Erlernen von neuen Attacken: So müsste man sein Team nur ein mal fit machen, damit es alle Attacken beherrscht, bei späterem Training würde nichts mehr passieren. So würde das Spiel sehr langweilig, wenn man nicht ständig Pokémon auswechselt. Noch absurder wird es mit den Weiterentwicklungen: Entweder die Entwicklung kostet Fitness oder es würden bei mehreren Stufen alle direkt nacheinander erfolgen. Danach wäre auch hier Langeweile angesagt.

Im Pokémon-Reboot bietet hier ein bisher nicht erwähntes Kernelement der Serie die Lösung: Der Zufall. Man könnte noch nur die erscheinenden Gegner im hohen Gras (und in Höhlen, etc.) auswürfeln, sondern auch gelernte Attacken und Weiterentwicklungen. Je nach Fitness-Level variiert die Wahrscheinlichkeit, eine bestimmte Attacke zu erlernen oder sich weiter zu entwickeln. Es können natürlich noch weitere Einflussgrößen hinzu kommen, um das Spiel interessanter zu gestalten: Beherrscht der Gegner eine Attacke, verdoppelt sich die Wahrscheinlichkeit, dass das eigene Pokémon die Attacke selbst erlernt. Hat sich ein Pokémon noch nicht entwickelt? Motiviere es, indem du es mit guten Beispielen (höheren Entwicklungen von anderen Pokeḿon) umgibst! Und zu guter Letzt könnten natürlich auch die Orden – also der Fortschritt des Spielers – eine Rolle spielen. Damit wäre das Spielgefühl fast wieder klassisch.

Wie schon im Original spawnen in der Spielwelt Asteroiden, denen der Spieler mit seinem Raumschiff ausweichen muss, bis die durch Beschuss immer kleiner aufspaltenden Trümmer auf unschädliche Größe geschrumpft sind. Ebenfalls wie im Original handelt es sich um ein zyklisches Universum: Was auf der einen Seite hinaus fliegt, kommt zur anderen wieder rein. Entgegen der Urversion bremst das Raumschiff jedoch nicht mehr von allein ab, stattdessen gilt das Trägheitsgesetz. Da jedoch der Treibstoff weiterhin unbegrenzt ist, kann der Spieler sein Fluggerät bis nahe der Lichtgeschwindigkeit beschleunigen – zur Geschwindigkeitslimitierung wurde den die Gesetze der Speziellen Relativitätstheorie implementiert. Bei hohen Geschwindigkeiten nimmt also statt der Geschwindigkeit vor allem die relativistische Masse zu, zudem nimmt die Umgebung durch Längenkontraktion ein gewöhnungsbedürftiges Aussehen an.

Um Flüge die Lichtgeschwindigkeit in einem handelsüblichen PC simulieren zu können, wurde etwas geschummelt – das allerdings sehr stilecht. Die Ingame-Lichgeschwindigkeit beträgt nur etwa 250 Raumschifflängen pro Sekunde, dafür wird jedoch auch die Zeit berücksichtigt, die das Licht zum Spieler braucht: Ein Asteroid in 1000 Raumschifflängen Entfernung wird mit einer Verzögerung von vier Sekunden angezeigt – so lange braucht das Licht schließlich bis zur Position des Spielers.

Die Steuerung wirkt durch den Einfluss der Lichtgeschwindigkeit etwas schwammig, muss aber wohl – entsprechend große Raumschiffe vorausgesetzt – als realistisch bezeichnet werden. Aufgrund fehlender Story wird es definitiv nicht mein Lieblingsspiel, doch fasziniert es, eigentlich unbegreifliche physikalische Effekte im Spiel erleben zu dürfen. Eher störend ist nur die Gamepad-Unterstützung bei eingeschaltetem Force Feedback: Nahe Lichtgeschwindigkeit sind Zusammenstößen mit Asteroiden in jedem Fall sehr heftig und der Controller hört kaum noch auf zu vibrieren. Aber ein wenig Strafe muss schon sein, wenn man seinen Raumgleiter zerdeppert – und so muss man abwarten, bis dieser durch Kollisionen so weit abgebremst wurde, dass das virtuelle Ich endlich aussteigen kann.

ARME wurde bisher nicht angekündigt und ist einem mit mir befreundeten Physiker eingefallen. Vielleicht wird es aber doch irgendwann einmal umgesetzt…

PS: Viele Grüße an Marco.

Seit Ende November ist Steam für Linux erhältlich, sogar mit Counter-Strike: Source (seit vorgestern). Doch offiziell unterstützt wird leider nur Ubuntu in der Version 12.04. Für die meisten Linuxnutzer ist das kein Problem, weil es meistens trotzdem läuft. Mit Debian ist das leider nicht der Fall. Ein bekanntes Workaround ist das Setzen von Umgebungsvariablen, was aber leider den Paketmanager umgeht. Eine in meinen Augen elegantere Möglichkeit ist die Benutzung von chroot.

Die Installation der Chroot-Umgebung mit Ubuntu ist denkbar einfach. (Zu den angegebenen Befehlen: #: als Root ausführen, $: als User ausführen; in eckigen Klammern meint in der Chroot-Umgebung.) Es empfiehlt sich, direkt nach der Installation die Repositories zu bearbeiten und dem Nutzer (in meinem Fall patrik) die Nutzung des chroots zu erlauben:

#: debootstrap --arch i386 precise /srv/chroot/ubuntu/ http://archive.ubuntu.com/ubuntu
#: echo -e "deb http://archive.ubuntu.com/ubuntu precise main\n
deb http://archive.ubuntu.com/ubuntu precise-updates main\n
deb http://archive.ubuntu.com/ubuntu precise-security main\n"
> /srv/chroot/ubuntu/etc/apt/sources.list
#: echo -e "[Ubuntu 12.04]\n
description=Ubuntu Precise\n
directory=/srv/chroot/ubuntu\n
aliases=precise,default\n
users=patrik\n"
>> /etc/schroot/schroot.conf


Zur Vorbereitung der neuen Umgebung sollte man zudem die Benutzereinstellungen in die neue Umgebung einfügen. Ich habe das teilweise per mounts gemacht, teilweise einfach kopiert:

#: echo -e "# Ubuntu chroot\n
/home /srv/chroot/ubuntu/home none bind 0 0\n
/tmp /srv/chroot/ubuntu/tmp none bind 0 0\n
/dev /srv/chroot/ubuntu/dev none bind 0 0\n
/proc /srv/chroot/ubuntu/proc proc defaults 0 0\n
/run/shm /srv/chroot/ubuntu/run/shm none bind 0 0\n"
>> /etc/fstab
#: cp /etc/group /srv/chroot/ubuntu/etc/group
#: cp /etc/passwd /srv/chroot/ubuntu/etc/passwd
#: cp /etc/shadow /srv/chroot/ubuntu/etc/shadow
#: cp /etc/hosts /srv/chroot/ubuntu/etc/hosts
#: mount -a


Um in der Chroot-Umgebung auch auf den XServer zugreifen zu können, kann man (als Nutzer!) xhost erlauben, alle lokal laufenden Prozesse anzuzeigen:
xhost + local:

Damit läuft das Chroot-System auch schon. (Ja, ich hätte auch einfach ein Script bauen können, dann hätte niemand Befehle abtippen oder kopieren und einfügen müssen. Aber man soll ja auch was lernen.) Allerdings hatte zumindest ich Probleme mit der (nicht installierten) Lokalisierung. Also geht es erst einmal ab in die neue Umgebung:

#: dchroot -d

Dort angekommen, habe ich zuerst die Locale auf C gesetzt, um dann ohne Fehlermeldung in der Chroot die Locales installieren zu können. Direkt darauf folgen xterm (das installiert schon mal automatisch Xserver, etc mit) und wget. Beides ist nützlich für die spätere Installation von Steam. Außerdem installiere ich jockey-common und python-apt, weil Steam sonst später sudo startet, was ich nicht benutze(n möchte).

[#:] export LANG=C.UTF-8
[#:] export LANGUAGE=C
[#:] apt-get update
[#:] apt-get upgrade
[#:] apt-get install language-pack-de
[#:] export LANG=de_DE.UTF-8
[#:] export LANGUAGE=de_DE
[#:] apt-get install xterm wget
[#:] apt-get install jockey-common python-apt


Jetzt kann Steam auch schon installiert werden. Direkt danach werden die Abhängigkeiten nachinstalliert.

[#:] wget http://media.steampowered.com/client/installer/steam.deb
[#:] dpkg -i steam.deb
[#:] apt-get -f install


Damit ist Steam installiert. Um es nutzen zu können, muss die Chroot-Umgebung aber noch wissen, wo der Xserver zu finden ist. Um sicher zu gehen, dass es klappt, habe ich vor dem Start von Steam noch eben die DISPLAY-Variable gesetzt.

$: dchroot -d
[$:] export DISPLAY=:0
[$:] steam


Gratulation! Jetzt sollte Steam in der Chroot-Umgebung laufen. Allerdings ist das noch alles andere als komfortabel. Um nicht jedes Mal ins Terminal gehen zu müssen, legen wir ein kleines Skript an. Es liegt /usr/local/bin/do_dchroot und hat folgenden Inhalt:

#! /bin/bash
/usr/bin/dchroot -d "`echo $0 | sed 's|^.*/||'` $*


Dieses Skript ruft automatisch Befehle in der Chroot-Umgebung auf, die den Namen des Skripts haben. Ein direktes Aufrufen würde also „do_dchroot“ innerhalb der Chroot-Umgenung aufrufen. Das ist natürlich nicht nützlich, aber mit einem kleinen Kniff wird es sehr praktisch:

#: ln -s /usr/local/bin/do_dchroot /usr/local/bin/steam

Man kann Symlinks mit beliebigen Namen auf das Skript^[1] verweisen lassen, die dann automatisch den Namen des Links im Chroot ausführen.

Wenn ich nichts vergessen haben sollte, müsste Steam jetzt genau so laufen, als wäre es normal unter Ubuntu installiert.

Update 11. Februar 2013: Einige Flüchtigkeitsfehler behoben.

1. ^[1]Gefunden habe ich diese Idee bei Ubuntuforums↩

Faktisch zeigen allein die benötigten 30 FPS, dass das komplette Modell kaum zu gebrauchen ist: Das menschliche Gehirn kann nur 14 bis 16 Bilder pro Sekunde verarbeiten, was auch bis zu den ersten Tonfilmen im Film Standard war. Erhöht wurde die Wiederholrate dort vor allem, um die Tonqualität(!) zu erhöhen^[1]. Warum aber ist ein Film mit um die 20 FPS flüssig, während ein Computerspiel über 20% mehr Bilder braucht?

Der Grund ist sehr einfach: Bei Bildern pro Sekunde handelt es sich um einen Mittelwert. Und während im Film jedes Bild immer im gleichen Abstand auf dem Schirm erscheint, kann die Berechnung in Computerspielen auch unterschiedlich lange dauern. Selbst wenn mal eine ganze Sekunde lang kein einziges neues Bild erscheint, bleibt die Framerate auf zehn Sekunden gemittelt bei 30 FPS, solange vorher und nachher jede Sekunde 33 Bilder gezeigt werden. Von einem flüssigen Spielerlebnis kann aber nicht mehr die Rede sein.

Eine einfache Lösung wäre, neben der Bildwiederholrate auch eine Standardabweichung anzugeben. Auf diese Weise arbeiten Naturwissenschaftler. Ein Kinofilm hätte hier 24±0 FPS, das oben genannte Computerspiel käme auf 30±10 FPS. Leider ist auch dieser Wert erst dann aussagekräftig, wenn man auch die Verteilung kennt. Sprich: Wie schlimm das subjektive Ruckeln ist, kann auch so nicht gesagt werden. Hätte man die Hälfte der Zeit 20 FPS, die andere Hälfte 40 FPS, käme man auf 30±11 FPS, wird aber trotz schlechterem Wert kein Ruckeln feststellen können.

Neulich habe ich^[2] aber bei techreport.com eine Lösung entdeckt: Dort wird (unter anderem) die Zeit angegeben, die länger als 50 ms für einen Frame gebraucht wird. 20 FPS entsprechen genau 50ms pro Frame. Der einmalige Megaruckler von einer Sekunde würde in diesem System einen Wet von 950 ms bekommen, Kino und ruckelfreies Computerspiel bekämen einen Wert von 0 ms. Vorteil ist, dass man auf diese Weise auch sogenannte Microruckler zählbar machen kann.

So kommen eine Geforce GTX 660 Ti und eine HD 7950 auf etwa gleich viele FPS, bei der Grafikkarte mit zwei Grafikchips ist allerdings die Zeit mit „verspäteten Frames“ deutlich höher (je nach Spiel z.B. 15 ms zu 30 ms). Bekannt ist dieses Problem schon seit mindestens 2007. Damals wurde bei 3dcenter vor SLI gewarnt. Ein Nutzer berichtet, die Grafikkartenverdoppelung liefere immer zwei Bilder fast gleichzeitig, wodurch sich die Framerate natürlich verdoppelt, das Spiel aber weiterhin genau so flüssig/ruckelig bleibt wie mit nur einer Karte.

Auch wenn das Problem bei Multi-GPU-Karten mittlerweile nicht mehr ganz so schlimm zu sein scheint, halte ich es für ein Armutszeugnis, dass weiterhin an reinen FPS-Angaben festgehalten wird, obwohl diese doch in Wirklichkeit kaum etwas aussagen.

1. ^[1]vgl. Bildfrequenz bei Wikipedia↩
2. ^[2]Danke an Chemical_Brother von Linuxgaming.de für den Hinweis.↩

Ubuntu ist überhaupt ein gutes Stichwort: Steam unterstützt bisher nur diese eine Distribution und wird (wie man das von Windows kennt) auch nur als 32-Bit-Version ausgeliefert. Neben der bequemen Installation über den Paketmanager ist auch die Integration in den Starter (das Dock auf der linken Seite) vorbildlich gelöst. Weitere Linux-typische Features werden allerdings (noch?) nicht unterstützt. So wäre eine engere Verzahnung mit dem Paketmanager^[1] zumindest möglich. Valve könnte hierfür ein Repository anbieten, sodass Software über Steam gakauft und genutz, aber von systemeigenen Funktionen aktuell gehalten würde.

Hier bietet Linux einen bisher von Steam nicht genutzen Vorteil über Windows: Beim Redmonter System ist es ja bisher nicht möglich, jegliche installierte Software zentral (z.B. über Windows-Update) auf dem neuesten Stand zu halten. Der Windows-8-Appstore bringt hier zwar Verbesserung, dass Microsoft aber alle Angebote vor der Einstellung kontrolliert und z.B. den Verkauf von Spielen für Erwachsene einschränkt, ist für Valve aber ein Grund gewesen, jetzt Ubuntu zu unterstützen. Linux-Repositories auf der anderen Seite bieten nämlich den Vorteil, ohne zentrale Kontrollinstanz auszukommen: Auf diese Weise kann jeder Nutzer selbst entscheiden, welche Software er im „Appstore“ sehen will.

Valve wird sich aber vermutlich zunächst darauf konzentrieren, alle von Windows bekannten Features auch in die Linux-Version zu implementieren. Hier sind bereits gute Fortschritte zu sehen, die „Beta“ trägt ihren Namen vermutlich zurecht – alle wichtigen Features sind vorhenden, müssen aber noch getestet werden. Selbst der Offline-Modus wird bereits angeboten – und startet auch (bevor er abstürzt). Leider ist das alles bisher noch nicht sehr nützlich, wenn man – wie ich – nicht zu den 1000 ausgewählten Teilnehmern der Closed Beta gehört. In diesem Fall kann man nämlich nichts spielen, sondern wird nur mit der Aufforderung konfrontiert, sich mit einem für die Beta zugelassenen Account einzuloggen.

1. ^[1]Der Paketmanager ist vergleichbar mit Appstores: Er bietet Software zur einfachen Installation an und hält diese automatisch auf dem neuesten Stand. Nur eine Funktion zum Bezahlen ist nicht eingebaut.↩

Da der Grund hierfür vermutlich darin liegt, dass die Streichung vom Index noch nicht all zu lange her ist, habe ich mal den Support angeschrieben. Hier die Antwort:

Hallo Herr Schönfeldt,

vielen Dank für Ihre Nachricht an das Steam Support Team.

Leider steht dieses Spiel derzeit nicht in Ihrem Land auf Steam zur Verfügung.
Wir können Ihnen im Moment auch keine weiteren Informationen darüber geben.

Wenn Sie Fragen zu diesem Spiel haben, wenden Sie sich bitte an den technischen Support für dieses Spiel:

Title: Max Payne series
Link: http://support.steampowered.com/kb_article.php?ref=4322-WEPK-1652&l=german

Beste Grüße,

Steam Support Team

Toll! Weil Steam das Spiel nicht an Deutsche verkauft, habe ich mich ja gerade an den Support gewandt. Wäre ich illegalen Kopien gegenüber etwas aufgeschlossener, hätte ich das Spiel wahrscheinlich schon durch, so lange wie ich jetzt schon nach einer legalen Quelle gesucht habe…

Ein Videospieler verdient das Recht,

1. bezahlte Videospiele jederzeit und ohne weitere Bedingungen möglichst vollständig zu nutzen,
2. den Grad der Öffentlichkeit beim Spielen selbst zu wählen,
3. Verbesserungen und Modifikationen zu erstellen und nutzen.

Die erste Freiheit^[1] würde ich als „Recht auf Eigentum“ bezeichnen, die dritte als „Recht auf Kreativität“. Die zweite Freiheit umfasst sowohl das Recht auf Privatsphäre als auch das Recht, andere am eigenen Spiel Teil haben zu lassen. Hierfür passend wäre die wenig prägnante Formulierung „Recht auf Datenschutz oder selbstbestimmte Teilhabe anderer“. Ich werde sie vorerst Recht auf Datenschutz und Gemeinschaft nennen, mit der Anmerkung, dass die erwünschte Gemeinschaft selbst gewählt wird und eine ausschließliche Gruppe darstellen kann.

Recht auf Eigentum

Wenn ein Spieler Geld bezahlt, sollte ihm das, wofür er bezahlt hat, auch wirklich gehören. Und zwar unabhängig von weiteren Bedingungen wie dem Zeitpunkt, an dem das passiert ist. Die Funktionsfähigkeit von Spielen sollten nicht verfallen oder von der Funktionsfähigkeit von Servern des Anbieters abhängig sein. Ebenfalls kritisch zu sehen sind bereits auf dem Datenträger befindliche Inhalte, die aber nachträglich ein (weiteres) Mal bezahlt werden müssen (On-Disk-DLC).

Recht auf Datenschutz und Gemeinschaft

Der Anbieter eines Spiels sollte nur die für den Betrieb wirklich essenziell benötigten Daten obligatorisch erheben und diese löschen, sobald sie nicht mehr benötigt werden. Statistiken über Hardware und Spielverhalten des Nutzers sollten nur auf freiwilliger Basis erstellt werden, nicht aber ohne dessen explizite Einwilligung. Dies gilt insbesondere auch für an Spiele mit angegliederten „sozialen Funktionen“, die z.B. in Form von Achievements Einblick in die Vorlieben des Spielers erlauben.

Auf der anderen Seite sollte der Spieler aber auch das Recht besitzen, seine Freunden, Bekannte oder jeden beliebigen anderen an seinem Spiel Teil haben zu lassen. Hiermit sind nicht nur Spielberichte oder Lets-Plays gemeint, sondern auch das Spiel mit mehreren, selbst gewählten Personen. Es sollte immer möglich sein, sich mit seinen Mit- und Gegenspielern zu verabreden.

Recht auf Kreativität

Ein wichtiges Element des Spiels ist das der Abwandlung. Viele heute bekannte Spiele sind nicht von Professionellen sondern von Fans erdacht worden, als bekannte Beispiele seien nur „DotA“ und „Counter-Strike“ genannt. Auch Leveldesign ist ein kreatives Element des Videospiels, welches nicht immer ausreichend gewürdigt wird. Positiv kann z.B. „Portal 2“ hervorgehoben werden, das seit neuestem einen sehr einfach zu bedienenden Editor besitzt. Auf der anderen Seite gibt es aber Beispiele, in denen Entwickler die eigenen Fans als Konkurrenz sehen und gegen deren Kreativität vorgehen. Aber es gibt auch Titel wie, die (erst) durch Verbesserungen von Fans gut geworden sind und deren Entwickler sogar sogenannte Fan-Patches empfehlen; hierzu zählen „Gothic 3“ und „Vampires the Masquerade – Bloodlines“.

1. ^[1]Von Freiheiten spreche ich in Anlehnung an die vier Freiheiten der Free Software Foundation.↩

Ich persönlich halte jeden, der jetzt mit original Datenträger vor seinem Computer sitzt und nicht spielen kann, für einen Sieg der Cracker-Szene – ganz besonders diejenigen, die extra Urlaub für das Spiel genommen haben. Und um ehrlich zu sein, halte ich es für moralisch durchaus vertretbar, selber nachzubessern, damit man das bezahlte Spiel auch starten kann. Eigentlich aber ist es traurig, dass es überhaupt möglich sein kann, mit Softwareschnippseln aus irgendwelchen oft dubiosen Quellen sein Spielerlebnis zu verbessern.