Floschi’s Blog

Ich habe ja bereits 2x über meine Spielerfahrungen beim Echtzeit-Browserspiel “Die Stämme” (kurz: DS) berichtet. Heute habe ich bei heise.de einen sehr interessanten Artikel gelesen, der für mich 1:1 auf meine Erfahrungen anwendbar ist. Ich bin zwar nicht mehr in der untersuchten Zielgruppe der 14-20 Jährigen, allerdings ist das meiner Meinung nach die am meisten bei DS vertretene Altersgruppe.

Spielsinn ist, alleine oder zusammen mit Gleichgesinnten in der virtuellen Umgebungslandkarte zu expandieren, indem man Dörfer erobert. Alleine ist das ab einem gewissen Alter einer Spielwelt schwierig, da die meisten Spieler sich zu unterschiedlichen Stämmen zusammenschließen und mehr oder minder erfolgreich gemeinsam agieren, d.h. zusammen angreifen und beim verteidigen sich gegenseitig aushelfen.

Während bei dem Spiel in der Anfangsphase das sogenannte Farmen (überfallen gegnerischer Dörfer mit dem Ziel mehr Rohstoffe zu erbeuten) nahezu den ganzen Tag betrieben werden kann und muss, sofern man erfolgreich sein möchte, nimmt mit steigender eigener Dörferzahl der Dorfausbau und Truppenaufbau mehr und mehr Zeit in Anspruch, das Farmen fällt dafür nahezu weg. Und wenn der eigene Stamm angegriffen wird, dann muss gemeinsam verteidigt werden, d.h. minutenlanges Browserklicken um Truppen von den eigenen Dörfern in die zu verstärkenden Dörfer zu verschicken.

Noch zeitintensiver ist das (gemeinsame) angreifen, denn ab einer gewissen Reife der beteiligten Spieler kommt es darauf an, Angriffe sekundengenau zu berechnen und die Truppen entsprechend loszuschicken. Oftmals gehen dadurch ganze Tage drauf, an denen alle 30-60 Minuten Truppen weggeschickt werden müssen. Dazwischen vertrödelt man die Zeit…

Stämme, die ausschließlich fachgetrieben agieren (also einzig den Spielsinn verfolgen), sind anfangs erfolgreich, aber irgendwann geht ihnen die Luft aus, die persönliche Motivation vieler Mitglieder sinkt und der Stamm wird von wenigen getragen.

Auf der anderen Seite stehen Stämme, die ausschließlich aus persönlichem Interesse bestehen (z.B. weil sich die Mitglieder im realen Leben kennen), genauso vor dem Scheitern, da es ihnen oftmals an notwendiger Zielgerichtetheit im Spielsinne fehlt.

Auch hier macht es die Mischung, Stämme die es schaffen, aus spieltaktisch Klugen Köpfen eine lebendige Community (auch mit “Lehrlingen”) zu bilden und dadurch persönliches Engagement (man kennt sich, kommt gut miteinander aus, ersetzt dadurch das real life) und Fachwissen zu verbinden, bestehen länger.

Im Oktober 2006 habe ich dort ganz klein angefangen und bin innerhalb eines Jahres, durchaus auch mit Glück, ein mittelgroßer Spieler geworden. Ich hatte zuletzt das große Glück, in einem sehr engagierten und dadurch vielen anderen überlegenen Stamm spielen zu dürfen. Neben den oben bereits geschilderten spieltaktischen Aufgaben wurde mir dort noch zusätzlich eine recht gut funktionierende Community geboten, bei der sich nahezu ganztags (und nachts!) Mitstreiter im Forum und im Chat tummelten. Es war immer was los.

Aber für mich war Ende Oktober schluss mit DS. Es ging einfach nicht mehr. Seit den Sommerferien (wobei ich ja gar keine Ferien mehr habe) war mir klar, dass DS eine schleichend kommende Sucht ist, die sich gerne festsetzt und Tagesabläufe nicht selten bestimmt - nicht mehr das kurze Reinklicken zum Zeitvertreib, sondern das gezielte Ausrichten der eigenen Zeitplanung, um beim Browserspiel erfolgreich zu agieren.

Im Nachhinein, nach nun 3 Wochen Abstinenz, kann ich DS auf der einen Seite weiterempfehlen. Ich konnte auch dort, wie schon bei einigen anderen Onlineprojekten davor, den Aufbau und die Wirkungsweise einer Onlinecommunity (Web 2.0 ) aktiv miterleben und zuletzt mitbestimmen. Die Gemeinsamkeiten sind verblüffenderweise enorm, es gibt ein Fachthema als Auslöser des Zusammentreffens und in der Folge bilden sich Gruppen Gleichgesinnter heraus. Die persönliche Wertschätzung der virtuellen Aktivität bestimmt dabei den Fortgang und Erfolg des Projektes.

Andererseits kann ich nur warnen, es ist definitiv eine Abhängigkeit, in die man sich mit fortschreitender Spieldauer begibt. Während viele den Spagat zwischen realer Welt und Freizeitbeschäftigung, die nicht viel Zeit in Anspruch nimmt, wunderbar hinbekommen, gibt es meiner Erfahrung nach genug Beispiele, bei denen das eben nicht mehr gelingt.

Um den Bogen zum Ausgangsthema (Artikel bei heise.de) zu schließen: ja, auch ich habe viel wichtige Freizeit im letzten Jahr vertrödelt. Jetzt ist Schluss damit! Gottseidank

Zuletzt drückte das Einfrieren von OpenOffice.org unter Windows unter gewissen Umständen auf die Stimmung einiger Migrationsbereiche. Für uns ein wirklich ekelhafter Bug, den wir da gemeldet hatten.

Gemeldet, bestätigt und schwupps im nächsten Build von OpenOffice.org (2.3.1) behoben: klasse, fällt mir da nur ein

Langsam wird’s komplex… auch wenn unser LiMux-Basisclient überwiegend auf die echten Debianpakete aus sarge (bald etch) setzt, ergeben sich durch viele Anpassungen immer wieder Situationen, in denen Tests notwendig sind.

Derzeit haben wir für die meisten Komponenten (z.B. KDE, OpenOffice.org, K3b) typische Anwendungsfälle als Testszenarien, dazu noch die Standardfunktionalitäten (Booten, Login, Neuinstallation) und jede Menge weiterer täglicher PC-Arbeiten (USB-Stick, Scanner, …). Bei kleineren Versionssprüngen ist das noch beherrschbar, zumeist werden grundlegende Funktionen und die geänderten Komponenten anhand der Szenarien getestet, mit mal mehr und mal weniger Erfolg.

Aber ist das noch machbar, wenn jetzt im Winter der komplette Austausch der Systembasis (sarge zu etch) und einige umfassende Erweiterungen der Pflege- und Verwaltungsoberfläche GOsa umgesetzt und in ein nächstes Release “LiMux Basisclient 2.0″ gepackt werden sollen?

Die klassischen Akzeptanztests (durch den Kunden) machen wir, klar. Wir arbeiten auch die definierten Testszenarien ab, auch klar. Nur, gibt’s da nicht etwas, das uns unser Leben vereinfacht?

Wir beginnen gerade mit der Suche - das Ziel ist, ein für uns sinnvolles, aber keinesfalls überzogenes Testkonzept zu entwerfen, dass die Aufwände für rein manuelles Testen senkt, die Qualität mindestens gleich bleibt (besser noch erhöht) und die neuen Aufwände zur initialen Automatisierung und fortlaufenden Pflege der automatisierten Tests im angemessenen Verhältnis zum Nutzen stehen.

Wer Erfahrungsberichte kennt oder Tooltipps hat, bitte melden

Wir setzen beim Projekt LiMux in der Landeshauptstadt München zur Verteilung und Verwaltung unserer Linuxdesktops derzeit eine angepasste Kombination von FAI und GOsa ein. Die Pflege und die gezielte Weiterentwicklung der münchenspezifischen Anforderungen an diese Lösung können und wollen wir nicht alleine voranbringen.

Wir suchen einen leistungsfähigen und mit den Softwarekomponenten FAI und GOsa² vertrauten Partner, der uns in den nächsten drei Jahren mit jährlich ca. 80 Personentagen unterstützt.

Den genauen Ausschreibungstext mit allen Details gibt’s auf unserer Webseite.