Liebes Tagebuch,

heute ist der 21. Tag hier in der Apokalyptischen Nekrose. Ich erinnere mich nicht an vieles von früher, aber ich glaube das ist die längste Zeit, die ich bis jetzt am Leben war. Die Heerscharen vor den Toren werden immer größer und ich weiß nicht, wie lange wir sie noch aufhalten können. Dank Grolnar haben wir die letzte Nacht gerade so überlebt. Er meinte, dass wir noch schnell ein paar Notfallkonstruktionen errichten und dass die Verbesserungen an unseren Wassergeschütztürmen sie stoppen können. Das hat uns wohl den nochmal den Arsch gerettet. Keiner der geschätzten 2800 Untoten hat unsere Verteidigung überwinden können, obwohl es kurzzeitig echt knapp aussah.

Ich frage mich die ganze Zeit, wo die nur immer herkommen und woher sie wissen, wo wir sind. Besonders helle scheinen sie nicht zu sein. Wir haben uns auch bemüht tagsüber Ihre Reihen zu lichten. Ich habe eine alte AEG-Waschmaschine in der Wüste gefunden und sie zum Wurfgeschoss umfunktioniert. Ich bin so stolz auf mich, denn ich habe ganze acht dieser widerlichen Kreaturen damit umbringen können. “Umbringen” wirkt dabei echt ironisch: Ich glaube ja nicht, dass die wirklich leben. Jedenfalls hoffe ich, dass unsere Streifzüge so erfolgreich bleiben und ihre Anzahl nicht weiter steigt, sonst haben wir bald keine Chance mehr.

So, oder so ähnlich muss man sich fühlen, wenn das Browserspiel, das ich derzeit spiele, Realität wäre. Das Spiel heißt Die Verdammten, was dem Ungläubigen den Titel dieses Eintrages erklären sollte. Es stammt von dem Hersteller Motion-Twin, der für außergewöhnliche Spielkonzepte bekannt ist.

OK, ein weiteres Browserspiel unter Vielen wird der Eine oder Andere jetzt sagen, aber weit gefehlt: Dieses Spiel ist nicht wie jedes x-beliebige Andere. Hier ist Kooperation gefragt. So befindet man sich mit 39 Weiteren Spielern in einer Stadt innerhalb einer postapokalyptischen und lebensfeindlichen Umwelt, die weigehend von Zombies bevölkert wird. Diese gilt es Tag für Tag, besser gesagt Nacht für Nacht abzuwehren. Denn zu jeder Mitternachtsstunde erfolgt der Angriff der Horden.

Um den Kooperationscharakter zu forcieren, stehen dem einzelnen Spieler pro Tag nur eine sehr begrenzte Anzahl von Aktionspunkten zur Verfügung (6 pro Person). Mit diesen muss man durch Expeditionen in der Wüste Gegenstände finden, die einem helfen, die Stadtverteidigung zu erhöhen oder es einfach erlauben die Stadt auszubauen, wofür wiederum Aktionspunkte investiert werden müssen. Zusammenhalt ist dabei wichtig, damit alle an einem Strang ziehen um die teilweise absurd wirkenden Projekte, die über 500 dieser Aktionspunkte benötigen errichten zu können.

Die am Anfang überwältigenden Möglichkeiten, die dieses Spiel bietet, kann man zunächst gar nicht überblicken. Zudem lässt sich Vieles auch nur nach und nach entdecken, was nicht zuletzt dem begrenzten Handlungsspielraum durch die wenigen Aktionspunkte pro Person geschuldet ist. Diese lassen sich aber mit entsprechenden Utensilien, wie Nahrung und Wasser wiederherstellen. Dieses sollte man mindestens alle zwei Tage zu sich nehmen, um nicht zu dehydrieren. Dabei stehen aber der Gemeinschaft nur eine begrenzte Anzahl an Wasserrationen in einem Brunnen zur Verfügung. Weitere Aktionspunktelieferanten sind Drogen oder Alkohol, wobei man von Ersteren abhängig werden kann und Letztere einen Kater verursachen, welcher es verhindert, dass man am nächsten Tag wieder Alkohol zu sich nehmen kann. Auch dieses Maß an Realismus macht dieses Spiel echt faszinierend.

Zum Koordinieren der gemeinschaftlichen Aktionen stehen dabei Foren zur Verfügung. Hier kann und muss diskutiert werden, wie die jedes Mal meist zufällig zusammengewürfelte Gruppe das Überleben so lange wie möglich sichern kann.

Soweit zum kostenlosen Umfang des Spieles. Natürlich möchte der Hersteller auch Geld verdienen. Hierfür gibt es die Helden. Für einen bestimmten Betrag kann man sich eine Handvoll Heldentage kaufen. Helden haben zu den bereits umfangreichen Funktionen des Spiels noch weitere Fähigkeiten. So gibt es verschiedene Berufe, die ein Held ausübt. So kann ein Aufklärer von den Untoten unbemerkt die Wüste durchkämmen, ein Buddler besser Gegenstände im Wüstensand ausfindig machen und ein Wächter sich und seine Mitmenschen gegen mehr Zombies verteidigen. Zudem wachsen die Fähigkeiten eines Helden noch mit der Anzahl der gespielten Heldentage.

Jedoch früher oder später müssen alle sterben. Aber Sterben gehört zum Spiel dazu. Mit der eigenen unsterblichen Seele ist die Reinkarnation in einer neuen Stadt sicher.

Warum schreibe ich hier diesen artfremden Eintrag? Nun, ich habe in den letzen Monaten eine externe Anwendung basierend auf PHP/MySQL und JavaScript/AJAX geschrieben, die mittlerweile die meisten der Verdammten bei Ihrem täglichen Überlebenskampf unterstützt. Es handelt sich um Die verdammte Karte, die hier auf einer Subdomäne bereitgestellt ist. Um sie allerdings betrachten und nutzen zu können, benötigt man ein Konto im Spiel. Und warum man sich mal anmelden sollte, habe ich versucht darzustellen.

Direkt zum Spiel kann man mit der folgenden Bildverknüpfung gelangen:

Zunächst benötigt man natürlich ein entsprechendes Werkzeug, um die Verbindung mit dem SVN-Server herzustellen und seine Quelltexte zu verwalten. Auf Dateiebene bietet sich für Windows das frei verfügbare Programm TortoiseSVN an. Dieses integriert sich in das Kontextmenü des Windows Explorers. Dies sei aber nur als weitere Information genannt.

Aber auch direkt für Visual Studio gibt es ein feines Programm, das sich perfekt in die Oberfläche integriert und ebenfalls kostenlos erhältlich ist. Auf der Homepage von Collabnet findet man AnkhSVN.

Zunächst muss man dieses natürlich herunterladen und installieren. Zusätzlich ist es auch praktisch, etwas an Quelltext zu haben, der veröffentlich werden soll und jemand anderen auch interessieren könnte. Aber das liegt im Ermessen von jeden selbst und hat mit diesem Artikel wenig zu tun.

Wenn man sein Projekt an einem Stand hat, der veröffentlicht werden soll, benötigt man ein entsprechendes Repository, in dem es eingestellt werden kann. Wie bereits erwähnt, bietet SourceForge für OpenSource-Projekte diesen Service kostenlos an. Dazu muss man das entsprechende Projekt auf der Homepage zunächst anlegen. Ist dies geschehen, findet man in dem angelegten Projekt einen Menüpunkt “SVN” unter dem man in etwa folgende Abbildung wiederfindet, wobei es sich hier beispielhaft um eines meiner Projekte handelt.

Wichtig ist dabei für die Verwendung mit AnkhSVN lediglich die Serveradresse “https://*.svn.sourceforge.net/svnroot/*”. Diese wird im folgenden benötigt und kann direkt von dieser Seite kopiert werden. Den Rest des Befehls benötigt man nicht.

Hat man AnkhSVN erfolgreich installiert, erweitert dieses die Menüs von Visual Studio und fügt zusätzliche anzeigbare Fenster hinzu. Für den aktuellen Zweck benötigt man den “Repository Explorer”, dem man im Menü “Ansicht” bzw. “View” findet.

Wählt man den Menüpunkt aus, öffnet sich folgendes Fenster. Hier ist im Normalfall noch nichts eingetragen. Über die einzige aktive Schaltfläche (Die Weltkugel mit dem kleinen Pluszeichen) lässt sich ein neues Repository anlegen.

In dem sich öffnenden Dialogfenster gibt man einfach die Adresse des SVN-Servers an. In diesem Beispiel die Adresse, die auf der SourceForge-Seite angegeben wurde.

Nach kurzer Zeit, die dafür verwendet wird, den Server entsprechend abzufragen, wird das Repository in etwa wie folgt im Repository Explorer eingetragen. Selbiges Fenster kann man dann auch wieder schließen, da es nun nicht mehr benötigt wird.

Als Nächstes wählt man im “Solution Explorer” bzw. der “Projektmappe” diejenigen Projekte oder besser gleich die gesamte Solution aus, die veröffentlich werden sollen. Im Kontextmenü findet sich der Menüpunkt, mit dem Ihr Projekt unter Versionskontrolle gestellt werden kann.

Es öffnet sich das folgende Fenster, in dem das eben erstellte Repository in dem Mehrfachauswahlfeld mit der Bezeichnung “Repository URL” ausgewählt werden muss. Weiterhin selektiert man das entsprechende Verzeichnis, so dass sich in dem Textfeld am unteren Ende wieder genau die Adresse des SourceForge-SVN-Servers ergibt.

Beim Bestätigen mit der Schaltfläche OK dauert es ein wenig. Dies bedeutet aber nicht, dass man bereits fertig ist. Das Programm fragt zunächst, ob die gewählte Projekte mit Symbolen markiert werden sollen, die deren Status über die Versionskontrolle angeben. Dies kann man beruhigt mit “Ja” beantworten.

Nun wurde der Quelltext aber immer noch nicht veröffentlich. Dafür existiert das Fenster “Pending Changes”, das ebenfalls im Menü “Ansicht” (“View”) gefunden werden kann. Hier sieht man alle Dateien, die man selbst seit der letzten Veröffentlichung verändert hat. Am Anfang beinhaltet dies natürlich alle sich im Projekt befindlichen Dateien.

Über die Schaltfläche “Commit” lassen sich diese Änderungen übertragen. Dazu werden noch Nutzername und Passwort für den Zugriff auf den Server abgefragt. Diese sind dieselben, die für den Zugang auf SourceForge verwendet werden.

Hat man alles richtig eingegeben erfolgt nach Bestätigung mit “OK” die Übertragung der Quellen auf den Server.

Bei einer Anwendung müssen im Regelfall bestimmte Einstellungen, die ein Nutzer innerhalb des Programmes macht, gespeichert werden. Bei einem Neustart des Programms sollen die Einstellungen dann wieder eingelesen werden. Am besten sollte es so sein, als hätte der Nutzer das Programm nicht geschlossen. Nun, der letzte Punkt ist nicht ganz so einfach, aber bei den anderen beiden braucht man sich als Entwickler nicht mehr allzu viele Gedanken machen. C# unterstützt Einen auch hier.

1. Zunächst muss man im Solution Explorer in seiner Solution nach der Datei “Settings.settings” suchen.

2. Mittels Doppelklick öffnet sich ein Einstellungsfenster, indem man angeben kann, wie die Konfigurationseigenschaften heißen und welche Typen sie haben sollen. Wenn diese festgelegt wurden, können zusätzlich noch die Standardwerte angegeben werden.

Visual Studio legt dabei automatisch entsprechende Klassen an, über die auf die angelegten Eigenschaften zugegriffen werden kann.

3. Der folgende Codeausschnitt zeigt, wie man die Einstellungen zum Beispiel beim Starten des Programms laden kann.

private void LoadSettings()
{
    int value = Properties.Settings.Default.WindowX;
    if (value > -1)
    {
        this.Left = value;
    }
    value = Properties.Settings.Default.WindowY;
    if (value > -1)
    {
        this.Top = value;
    }
    menuItem_English.Checked = Properties.Settings.Default.Language.Equals(Language.EnglishCulture.Name);
    if (menuItem_English.Checked)
    {
        System.Threading.Thread.CurrentThread.CurrentUICulture = Language.EnglishCulture;
    }
    menuItem_German.Checked = Properties.Settings.Default.Language.Equals(Language.GermanCulture.Name);
    if (menuItem_German.Checked)
    {
        System.Threading.Thread.CurrentThread.CurrentUICulture = Language.GermanCulture;
    }
    ApplyLanguage();
    //...
}

4. Das Speichern von veränderten Einstellungen erfolgt einfach über das umgekehrte zuweisen von Werten an die Settings-Klasse. In dem folgenden Beispiel erfolgt das Sichern der letzten Position des Formulars beim Schließen desselben:

        private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
        {
            Properties.Settings.Default.WindowX = this.Left;
            Properties.Settings.Default.WindowY = this.Top;
            Properties.Settings.Default.Save();
        }

Wichtig dabei ist, dass die Save-Methode abschließend aufgerufen wird, damit die veränderten Einstellungen auch persistent gemacht werden, also in Dateiform auf die Festplatte geschrieben werden.

Unter Serialisierung versteht man in der Softwareentwicklung die Abbildung von Objekten auf eine externe Darstellungsform, um diese persistent zu machen. Im Allgemeinen könnte man die Eigenschaften der Objekte händisch in einem selbst definierten Format in Dateien schreiben. Die Serialisierung macht es dem Programmierer aber einfacher, indem dieser einfach komplette Objekte übergibt und das System übernimmt die strukturierte Ablage. C# bietet neben binärer Serialisierung Ihrer Objekte auch die Möglichkeit, Objekte in eine XML-Struktur zu serialisieren. Dies hat den Vorteil, dass die erzeugten Dateien in einem bestimmten Maße noch menschenlesbar sind. Dies wird allerdings dadurch erkauft, dass die Strukturierung durch XML im Verhältnis zur gepseicherten Menge vergleichsweise viel Speicherplatz verschwendet.

Vorbereitung

Betrachten wir eine einfache Klasse Mitarbeiter. Wie Sie sehen, speichert jedes Objekt dieser Klasse nur den Namen und den Vornamen einen Mitarbeiters, wobei diese Werte im Konstruktor gesetzt werden. Über die Properties ist der Zugriff auf die Eigenschaften nachträglich möglich.

public class Mitarbeiter
{
    private string _name;
    private string _vorname;

    public string Name
    {
        get
        {
            return _name;
        }
        set
        {
            _name = value;
        }
    }

    public string Vorname
    {
        get
        {
            return _vorname;
        }
        set
        {
            _vorname = value;
        }
    }

    public Mitarbeiter(string name, string vorname)
    {
        this._name = name;
        this._vorname = vorname;
    }
}

Der öffentlich Zugriff ist zum Serialiseren wichtig. Nur öffentliche Eigenschaften oder Properties können serialisiert werden. Für einfache Datenklassen könnte man also auch auf die Properties verzichten und die Eigenschaft veröffentlichen. Bevor Objekte dieser Klasse aber in XML serialisiert werden können, müssen die öffentlichen Mitglieder entsprechent markiert werden, damit das System ‘weiß’, in welcher Form diese schließlich in der XML-Datei abgelegt werden. Als wichtige Deklarationen sind dabei “XmlAttribute” und “XmlElement” zu nennen. Nicht zu serialisierende öffentliche Mitglieder können mit “XmlIgnore” gekennzeichnet werden. Um diese nutzen zu können, muss der namespace “System.Xml.Serialization” eingebunden werden. Für die Deserialisierung, also das Wiedereinlesen der XML-Datei ist ein parameterloser Konstruktor Pflicht, da dieser dabei aufgerufen wird. Die Werte der Attribute werden anschließend über die Property-Setter bzw. über direkt in die öffentlichen Eigenschaften gesetzt.

public class Mitarbeiter
{
    //[...]

    [XmlAttribute]
    public string Name
    {
        //[...]
    }

    [XmlAttribute]
    public string Vorname
    {
        //[...]
    }

    //[...]

    ///
    /// Konstruktor für Deserialisierung
    ///
    public Mitarbeiter()
    {
    }
}

Serialisieren

Wenn Sie nun ein Objekt der Klasse Mitarbeiter serialisieren möchten, reichen diese wenigen Zeilen Quelltext bereits aus:

Mitarbeiter ma = new Mitarbeiter("Max","Mustermann");
XmlSerializer serializer = new XmlSerializer(typeof(Mitarbeiter));
FileStream fs = new FileStream("mitarbeiter.xml", FileMode.Create);
serializer.Serialize(fs, ma);
fs.Close();

Die resultierende XML-Datei sieht dann in etwa folgendermaßen aus (unwichtige Details ausgelassen). Da die Eigenschaften des Mitarbeiters als “XmlAttribute” serialisiert werden, erfolgt die Speicherung direkt im Mitarbeiter-Tag.

<?xml version="1.0"?>
<Mitarbeiter xmlns:xsi="..." xmlns:xsd="..." Name="Max" Vorname="Mustermann"/>

Verwendet man anstelle von “XmlAttribute” die Deklaration “XmlElement” erhält man dagegen folgendes Ergebnis:

<?xml version="1.0"?>
<Mitarbeiter xmlns:xsi="..." xmlns:xsd="...">
  <Name>Max</Name>
  <Vorname>Mustermann</Vorname>
</Mitarbeiter>

Nun ist das ausgewählt Beispiel sehr trivial gewählt und es wird in Realität eher nicht der Fall sein, dass solch ein einzelnes kleines Objekt serialisiert werden soll. Viel wahrscheinlicher ist die Speicherung von Listen von Objekten oder gar Aggregationen oder Kompositionen von verschiedenen Objekten. Wenn Sie die bisherigen Ausführen soweit verstanden haben, stellt das aber auch kein größeres Problem dar. Wir passen den Code zunächst auf die Speicherung von Listen von Mitarbeitern an:

List<Mitarbeiter> malist = new List<Mitarbeiter>();
malist.Add(new Mitarbeiter("Max","Mustermann"));
malist.Add(new Mitarbeiter("Martina","Musterfrau"));

XmlSerializer serializer = new XmlSerializer(typeof(List<Mitarbeiter>));
FileStream fs = new FileStream("mitarbeiter.xml", FileMode.Create);
serializer.Serialize(fs, malist);
fs.Close();

Wie man schön sieht, ändert sich der eigentliche Quelltext für das Serialisieren nur unwesentlich. Einzig der übergebene Typ und das konkrete zu serialisierende Objekt wurden verändert. Die resultende XML-Datei schaut dann ungefähr so aus:

<?xml version="1.0"?>
<ArrayOfMitarbeiter xmlns:xsi="..." xmlns:xsd="...">
  <Mitarbeiter Name="Max" Vorname="Mustermann"/>
  <Mitarbeiter Name="Martina" Vorname="Musterfrau"/>
</ArrayOfMitarbeiter>

Schauen wir uns nun an, wie sich Aggregationen serialisieren lassen. Dazu erstellen wir eine Klasse Abteilung. In einer Abteilung arbeiten für gewöhnlich mehrere Mitarbeiter. Das Listing ist diesmal bereits mit den nötigen XML-Deklarationen. Ich möchte an dieser Stelle darauf hinweisen, das die dargestellte Klasse kein gutes Beispiel für Objektorientierung ist. Für die Verdeutlichung der XML-Serialisierung sollte es aber ausreichend sein.

public class Abteilung
{
    [XmlAttribute("Abteilungsname")]
    public string Bezeichnung;

    [XmlArray("Angestellte")]
    [XmlArrayItem("Mitarbeiter", Type = typeof(Mitarbeiter))]
    public Mitarbeiter[] Mitarbeiter;

    public Abteilung(string bezeichnung)
    {
        this.Bezeichnung = bezeichnung;
    }

    public Abteilung()
    {
    }
}

Der Quelltext zum Serialisieren ist nun natürlich wieder entsprechend anzupassen. Es ist darauf zu achten, dass alle aggregierten Typen ebenfalls serialisiert werden können. In unserem Fall haben wir die Klasse Mitarbeiter bereits vorher behandelt und dies ist sichergestellt.

Existieren verschiedene Unterklassen der Klasse Mitarbeiter, so lassen sich die verschiedenen möglichen Objekte die die Klasse Abteilung führen kann folgendermaßen erweitern:

[XmlArray("Angestellte")]
[XmlArrayItem("Mitarbeiter", Type = typeof(Mitarbeiter)),
 XmlArrayItem("Abteilungsleiter", Type = typeof(Abteilungsleiter))]
public Mitarbeiter[] Mitarbeiter;

Ein mögliches Resultat für eine serialisierte Abteilung mit entsprechenden aggregierten Objekten könnte dann folgendermaßen aussehen. Man beachte, wie für die XML-Elemente und XML-Attribute die Zeichenketten verwendet wurde, die bei der Deklaration zusätzlich angegeben wurden.

<?xml version="1.0"?>
<Abteilung xmlns:xsi="..." xmlns:xsd="..." Abteilungsname="Buchhaltung">
  <Angestellte>
    <Abteilungsleiter Name="Klaus" Vorname="Freundlich"/>
    <Mitarbeiter Name="Max" Vorname="Mustermann"/>
    <Mitarbeiter Name="Martina" Vorname="Musterfrau"/>
  </Angestellte>
</Abteilung>

Deserialisieren

Nachdem die Serialisierung ziemlich umfangreich erörtert wurde, braucht man evtl. noch eine kleine Information, wenn man die entsprechenden XML-Daten später wieder einlesen möchte. Hierzu genügen, ähnlich wie es beim Serialisieren der Fall ist, nur wenige Zeilen Quelltext. Dieser kurze Ausschnitt passt zu dem ersten Quelltext der Serialisierung, bei dem nur die einfache Mitarbeiter-Klasse gespeichert wurde:

string filename = "mitarbeiter.xml";
if (File.Exists(filename))
{
    XmlSerializer serializer = new XmlSerializer(typeof(Mitarbeiter));
    FileStream fs = new FileStream(filename, FileMode.Open, FileAccess.Read);
    Mitarbeiter ma = (Mitarbeiter)serializer.Deserialize(fs);
    fs.Close();
}

Wie man unschwer erkennen kann, könnte man für das Serialisieren und Deserialisieren dasselbe XmlSerializer-Objekt verwenden. Zum Deserialisieren der anderen beiden Beispiele müsste man ähnlich verfahren. Die Typen und der Cast sind dabei entsprechend anzupassen. Der Quelltext für das Serialisieren und Deserialisieren ist stets äquivalent zu betrachten.

Die Ausrichtung der Seite wird sich auch etwas ändern. Ich versuche, demnächst einige Kniffe in Sachen Programmierung hier festzuhalten. Alle Besucher und nicht zuletzt ich selbst kann dann ab und zu hier nachschlagen.