Archiv für den Monat: Mai 2020

Wieder ist beinahe ein Jahr vergangen, seit ich den letzten Statusbericht zum SPACOLA-Remake abgeliefert habe, daher ist es nun ganz dringend an der Zeit, ein bisschen über die aktuellen Neuerungen seitdem zu plaudern. Bekanntlich habe ich eine ausgedehnte Winterpause eingelegt, so dass die Änderungen sich insgesamt in Grenzen halten, aber ein paar Fortschritte gab es durchaus. Die Entwicklung an dem Spiel verhält sich ein wenig wie ein Gletscher: Egal ob man sich heute, morgen, nächsten Monat oder nächstes Jahr danach erkundigt, wie weit das Spiel fortgeschritten ist, wird es immer so aussehen, als habe sich nichts bewegt – aber es bewegt sich doch! Und jede Änderung wird sogar schriftlich in meinem Devlog dokumentiert.

Smart-Aim

Die neueste Work-In-Progress-Version 0.92 bringt einige nette, aber hauptsächlich experimentelle Spielereien mit, die ich unbedingt ausprobieren wollte. Letztmalig kündigte ich die Möglichkeit eines Aimbots (Smart-Aim) für den Spieler an. Diesen habe ich nun tatsächlich eingebaut. Mit per Menü aktiviertem Smart-Aim muss der Spieler nur noch grob in die Richtung eines Gegners zielen und die automatische Zielhilfe passt den Schusswinkel bis zu einem gewissen Grad so an, dass ein Treffer garantiert ist. Wenn kein Treffer garantiert werden kann, greift die Zielhilfe dagegen nicht ein. Die Arbeit am im letzten Update-Artikel erwähnten Weapon-Interface ist vollständig abgeschlossen. Zusätzlich lassen sich nun ganz einfach per Mausrad die verschiedenen Waffen des Spielers durchschalten und im Spiel verwenden. Das muss nicht bedeuten, dass der Spieler im Endeffekt mehrere Waffen besitzt, aber er könnte theoretisch.

Eingabequellen

Nach dieser kleinen großen Baustelle eröffnete ich dann gleich die nächste, und so überarbeitete ich skrupellos die komplette Spielsteuerung. Meine Idee war die Entwicklung eines flexiblen InputReceiver-Interfaces, das es ermöglichen sollte, verschiedene Eingabequellen für Spieler-Inputs an die Spielerschiffe anzuschließen. Dies wird spätestens im Multiplayer-Modus ein sehr wichtiges Thema. Die konkreten InputReceiver-Implementierungen erzeugen getaktet (pro Update) einzelne „ControlActions“, also gekapselte Eingabedaten, die auf eine abstrahierte Maus und Tastatur anwendbar sind, um ein Spielerschiff und somit die Spielwelt zu beeinflussen. Genauer gesagt habe ich nun einen MouseInputReceiver, der (wie der Name schon sagt) direkt die Maus (und Tastatur) anzapft. Aber zusätzlich habe ich auch einen RemoteInputReceiver, der Benutzereingaben von anderen Mitspielern aus dem Netzwerk empfängt, einen ReplayInputReceiver, der Benutzereingaben aus einer persistierten Datenquelle einlesen und ausführen kann, und zuletzt einen BotInputReceiver, der in Echtzeit künstliche Benutzereingaben anhand eines vorgegebenen Regelwerks erzeugen kann. Moment … Replays? Bots?

Bots

Als ich über die technischen Möglichkeiten meiner dynamischen Gegner-KI, des fertigen Aimbots und der InputReceiver-Logik sinnierte, ist mir plötzlich aufgefallen, dass ich im Grunde schon die halbe Arbeit erledigt hatte, die nötig wäre, um einen kompletten Spieler-Bot zu entwickeln. Diese Idee hatte ich eigentlich schon zu Beginn des Projektes für Skirmish-Multiplayer-Spiele, wenn mal nicht genügend menschliche Mitspieler zur Verfügung stünden. Außerdem würde ein funktionaler Spieler-Bot mir die Arbeit beim Testen erleichtern, da ich nicht mehr gleichzeitig spielen und debuggen müsste, sondern mich auf das Wesentliche konzentrieren könnte. Allerdings fiel mir beim Implementieren auf, dass es wohl doch nicht so ein Spaziergang werden würde, wie ich zunächst dachte. Im Gegensatz zur Gegner-KI, die die Raumschiffe immer direkt steuern kann (drehen, beschleunigen, bremsen, schießen…), darf ein Spieler-Bot im Grunde nur Maus und Tastatur übernehmen, das Spieler-Raumschiff also indirekt mit simulierten Mausbewegungen und Mausklicks steuern. Mit Hilfe der InputReceiver war dies nun zumindest technisch kein Problem mehr. Aber natürlich musste die Logik dafür trotzdem erstmal geschrieben werden.

Nach einigen Tagen des Grübelns, Ausprobierens und auch Scheiterns hatte ich einen halbwegs glaubhaften Bot entwickelt, der in jedem Level losfliegen, bei Bedarf nützliche Powerups einsammeln, Gegner und Asteroiden beschießen und auch ins Ziel fliegen kann. Um das zu bewerkstelligen darf er im Grunde nur die Maus im Kreis bewegen, sowie die linke und die rechte Maustaste drücken. Er kann leider noch nicht ausweichen und ist auch sonst relativ blind und stur, aber er zielt immerhin ganz gut und gewinnt daher auch fast immer. Das Potenzial für Verbesserungen ist dafür enorm, z.B. müsste er verlorene Waren wieder einsammeln. Meine finalen Bemühungen, die Bewegungen des Bots realistischer zu machen, waren begrenzt erfolgreich. Dennoch ist das Ergebnis aus meiner Sicht schon beachtlich. Nebenbei fand ich eine deutlich bessere Methode, einen Abfangvektor zu einem beweglichen Zielobjekt im Level zu berechnen. Diese Methode habe ich mir sogar vorgemerkt, um sie bei der Gegner-KI einzubauen, als ich feststellte, dass das Ergebnis exakt genauso aussieht wie bei etlichen Gegnern im Originalspiel. Endlich war ich auf der richtigen Fährte, nachdem ich jahrelang keine Ahnung hatte, wieso meine KI sich immer irgendwie anders bewegt als im Original.

Replays

Gleich der nächste Knüller: Mit der Idee der InputReceiver konnte ich endlich Benutzereingaben im Spiel aufzeichnen und theoretisch jederzeit erneut ausführen. Fürs Aufzeichnen gibt es im Spiel nun einen ReplayRecorder, der die ControlActions pro Update ableitet und in einem Replay-Objekt speichert. Am Ende wird das Replay-„Tape“ finalisiert und kann im Speicher gehalten oder komprimiert in eine Datei gespeichert werden. Ein ReplayInputReceiver kann dieses Objekt wieder als Eingabequelle für den Spieler wählen. Vereinfacht gesagt, das komplette Gameplay eines Levels lässt sich aufnehmen und anschließend nochmal exakt identisch als Replay abspielen. Da die Aufzeichnung natürlich kein Film ist, sondern nur ein Protokoll aller Benutzereingaben auf einer Zeitachse, ist der Speicherbedarf geringer, aber das Replay anfällig für Veränderungen. Was ich damit meine, wird jetzt deutlich, wenn ich die nächste kleine große Baustelle erwähne, an der ich seit einigen Tagen arbeite.

Die Replays lassen sich zwar endlich perfekt aufnehmen und auch wieder abspielen, aber sie ergeben danach keinen Sinn mehr: Der Replay-Spieler macht zwar alles exakt so, wie das Tape es vorgibt, aber die Spielwelt eben nicht. Das Level sieht anders aus, die Gegner verhalten sich anders, nichts ist da wo es sein sollte. Folglich kracht der Spieler plötzlich wie ein Betrunkener überall dagegen, schießt meilenweit an den Gegnern vorbei, fliegt in die völlig falsche Richtung, und ist quasi nach wenigen Sekunden Gameover. Das Gameplay verlässt sich an sehr vielen Stellen auf Zufallszahlen, und auch die Levelgenerierung ist zufällig. Daran ist im Grunde gar nichts auszusetzen, da Spielentwicklung ganz ohne Zufallsgeneratoren kaum möglich wäre. Was mir nur noch fehlte, war der programmweite Einsatz von reproduzierbaren Zufallszahlen, die auf Basis eines gespeicherten Seeds funktionierten. Gleicher Seed bedeutete dann: Gleiches Level, gleiche Gegner, gleiches Verhalten, alles exakt gleich. Die Spielwelt musste vollständig deterministisch zufällig werden, und die Replays müssten den Seed speichern, der dann die Grundlage für das Replay bildet. Diese Umstellung ist leider sehr aufwändig und umfasst das Umschreiben vieler Bausteine der Levelgenerierung.

Spielereien

Nach diesem schwergewichtigen Problem möchte ich zum Schluss noch kleinere Physikspielereien erwähnen, die ich ins Remake eingebaut habe. Als kleine Option im Enhanced-Modus lassen sich die Stationen der Piraten quasi kugelsicher schalten, so dass die Geschosse des Spielers daran mit passendem Soundeffekt abprallen. Hierzu musste ich meinen Bounce-Code umschreiben, denn der sah bisher nur Kollisionen zwischen zwei beweglichen Objekten vor. Im Spezialfall einer Kollision zwischen einem unbeweglichen und einem beweglichen Objekt durfte eine Reaktion logischerweise nur auf das bewegliche Objekt erfolgen. Das Feuern auf die kugelsichere Station sieht schon recht witzig aus und die abgelenkten Kugeln fliegen einem um die Ohren. Ob das im fertigen Spiel Verwendung findet, steht natürlich auf einem anderen Blatt, aber es schadet nicht, wenn die Funktion schonmal eingebaut ist. Achja, eine weitere Option erlaubt jetzt das Zerstören der Stationen. Ich wollte einmal testen wie es aussehen könnte, wenn im Spiel ein großes Objekt gesprengt wird, und dabei kam diese kleine Funktion heraus. Es werden Unmengen an Explosionspartikeln erzeugt und die Station verabschiedet sich mit einem lauten Knall. Wie gesagt, natürlich nur eine Spielerei. Ergibt auch keinen Sinn, besonders dann nicht, wenn es die Zielstation war.

Eine letzte neue Option im Optionsmenü ist die Wahl der Spielgeschwindigkeit. Hierdurch lässt sich das Spiel mittlerweile erheblich verlangsamen. Für den Anfang kann man die Updaterate daher auf 1/2, 1/4, 1/8 oder 1/24 stellen. Dies ist allerdings nicht nur sinnlose Spielerei, sondern die erste Vorbereitung auf einen Rewrite der Spielengine, der früher oder später dringend nötig sein wird: Das völlige Entkoppeln von Update- und Drawrates, und die stufenlose Wahl der Spielgeschwindigkeit. Es muss also möglich sein, die Spielgeschwindigkeit z.B. drastisch zu reduzieren, aber trotzdem alle Spielobjekte weiter mit bis zu 72 fps flüssig zu bewegen. Denn aktuell bedeutet eine reduzierte Geschwindigkeit nur, dass die Spielwelt weniger oft aktualisiert wird, und dann spielt die Framerate eben keine Rolle. Das Spiel sieht dann leider nicht nach Zeitlupe aus, sondern nach Diashow.

Meilenstein

Es gibt da zwar noch so ein Thema, einen wichtigen Meilenstein, den ich unbedingt erläutern möchte, aber das werde ich demnächst in einem separaten Artikel abhandeln, da es sehr umfangreich wird.

Eine seltsame, geradezu verschrobene Person wie ich, die mit ihren Gedanken sowieso bei jeder Gelegenheit in der Vergangenheit ist, ständig der Vergangenheit nachhängt, ihr beinahe nachweint, verbringt auch übermäßig viel Zeit damit, nach Wegen zu suchen, die Vergangenheit für sich zu erhalten. Und die Nostalgie ist stark in mir. Praktisch schon als Jugendlicher wurde ich regelmäßig nostalgisch gegenüber sämtlichen Dingen, die ich aus der (damals noch gar nicht so lange zurückliegenden) Kindheit kannte. Das betrifft das übliche Spektrum typisch nostalgiegeladener Dinge von Spielsachen, Zeitschriften, TV-Serien, über Personen, alte Schulsachen, Musik, bis hin zu Orten, Snacks und Süßigkeiten, und in meinem Fall eben auch ganz besonders: Computer, Computerspielen und anderer Software.

Schon in den späten 90er Jahren befasste ich mich durchgängig mit Emulatoren für den Atari ST, den Amiga, den C64, sowie sämtlichen beliebten Spielekonsolen meiner Kindheit, bastelte an Konfigurationen und verwendete gerne Programme und Spiele, die praktisch als ausgestorben galten. Allein die Vorstellung, für mich wichtige veraltete Hardware auf einem einzigen modernen Notebook bzw. Rechner zu vereinen, komplett mit einer umfangreichen Softwarebibliothek, jederzeit auf Knopfdruck abrufbar, erfüllte mich mit einem wohligen Gefühl. An diesem kleinen Traum arbeite ich praktisch seit Jahrzehnten. Und die technischen Möglichkeiten werden von Jahr zu Jahr besser, weil die Prozessoren immer leistungsfähiger und die Festplatten immer größer werden.

Während ich etwa das Feld der Amiga- und Atari ST-Emulation, sowie der meisten Spielekonsolen von vor 1994 weitestgehend abgearbeitet und durchleuchtet habe, kam vor knapp 15 Jahren ein weiteres großes Thema auf meiner Agenda hinzu: PC-Emulation. Dabei mag es vordergründig zunächst schwachsinnig klingen, einen PC auf einem PC emulieren zu wollen. Doch so unlogisch ist das nicht. Der PC als Plattform ist mittlerweile so alt, ausdauernd und langlebig, dass er viele Äras und Iterationen von Hardwarestandards und Betriebssystemen durchlebt hat. Das ist zwar eigentlich fast überall so, aber nirgends waren die Schritte so groß wie hier: Die Spanne reicht mindestens von den ersten x86-Prozessoren in den IBM PCs von Anfang der 80er mit MS-DOS, über den 486ern, Pentiums, dem K5 und z.B. den Cyrix-Prozessoren Mitte der 90er mit Windows 3.x/Windows 95, bis hin zu deutlich modernerer Hardware wie Mehrkernprozessoren und vollständig multitasking- und multiuserfähiger Betriebssysteme wie Windows XP/Vista/7/8/10 und Linux. Und dabei habe ich nur einen ganz groben Querschnitt aufgezählt. Diese sich permanent verändernde Umgebung innerhalb der Plattform bringt es mit sich, dass Software, die beispielsweise heute noch tadellos läuft, morgen schon nur noch eingeschränkt mit Tricks zum Laufen gebracht werden kann, während sie übermorgen wegen Hardwareinkompatibilitäten und weggefallener Betriebssystemstandards überhaupt nicht mehr startet, und das ist nur völlig natürlich und irgendwo auch notwendig, denn manchmal müssen alte Zöpfe zum Wohl des Fortschritts abgeschnitten werden. Das haben wir bei Spielen und Programmen unter MS-DOS beobachtet, danach mit 16-Bit-Windows-Software, die heute garantiert nirgends mehr läuft, und inzwischen gehen auch 32-Bit-Programme allmählich unter. Gegensteuern kann man hier nur mit Kompatibilitätschichten, Virtualisierung und Emulation.

PC-Virtualisierung bzw. -Emulation gibt es schon sehr viel länger als ich mich damit befasse. „Bochs“ gibt es seit 1994 und „QEMU“ immerhin seit 2003. Mit beiden bin ich leider nie besonders gut klargekommen, sie sollen aber, in den richtigen Händen, äußerst leistungsfähige Werkzeuge sein. Bei den Virtualisierern erprobe ich VMware, VirtualBox und Virtual PC schon seit langem. Letzteres fand sogar in Form des vorkonfigurierten „Windows XP-Modus“ einst offiziell seitens Microsoft Einzug in Windows 7, um erwartete Kompatibilitätsprobleme zumindest abzufedern. Mit „DOSBox“ gibt es seit 2002 einen Emulator, der einen typischen DOS-Rechner mit allen Schikanen nachstellt, und der speziell für Spiele optimiert wird. Dieses kleine aber äußerst kräftige Tool ist so gut, dass es von Spieledistributionsplattformen wie GOG offiziell verwendet wird, um die Nutzung sämtlicher DOS-Spiele unter modernen Betriebssystemen zu ermöglichen. DOSBox emuliert den PC heute so akkurat und schnell, dass man im emulierten DOS sogar Windows 95 installieren und darunter Spiele spielen kann – leider mit diversen technischen Einschränkungen.

Soviel also zur Einleitung. Vor wenigen Monaten entdeckte ich eher zufällig einen weiteren Mitstreiter auf dem Gebiet der PC-Emulatoren: PCem. Dieses Programm ist vereinfacht gesagt das Windows-Gegenstück zu DOSBox, wenn auch noch lange nicht auf Windows beschränkt. PCem emuliert grundsätzlich eine ganze Vielzahl von alten Mainboards, Prozessoren, Grafikkarten, selbst einst beliebte 3D-Beschleuniger wie Voodoo und Voodoo2. Entsprechend lassen sich damit die allerersten PCs, bis hin zu PCs der Pentium MMX Ära emulieren. Die akkurate Low Level Emulation fordert jedoch ihren Tribut, so benötigt man zur Nachbildung meines damaligen 200 MHz Pentiums von 1997 heutzutage über den Daumen gepeilt knapp 4 GHz Taktrate auf einem einzelnen Kern, denn selbstredend lässt sich die Emulation eines Singlecore-Prozessors nicht einfach auf mehrere Kerne aufteilen. Das ist also mal eben das 20-fache an Leistung.

Das beste an PCem ist, dass er mit dem Ziel entwickelt wird, Spiele perfekt zu unterstützen, also einer der hardwareforderndsten Formen von Software, was mich insgesamt sehr begeistert hat. Wenn man den Gerüchten glauben durfte, soll die Voodoo2-Emulation inzwischen so brauchbar sein, dass hardwarebeschleunigte 3D-Spiele aus der Zeit kurz vor der Jahrtausendwende mit Abstrichen problemlos spielbar sein sollen. Dies wollte ich unbedingt selbst testen und so versuchte ich mich einmal an einer kleinen Demo-Installation, die einen halben Tag in Anspruch nahm.

Ich will hier an dieser Stelle bewusst nur einen Erlebnisbericht und kein Tutorial schreiben, weil die Installation leider relativ aufwändig ist, und es schon diverse brauchbare Anleitungen im Internet gibt. Der Aufbau einer lauffähigen Konfiguration in PCem ist nicht sehr intuitiv im Gegensatz zu DOSBox oder VirtualBox, aber die Mühe lohnt sich. So ist PCem nach der Installation leider völlig nutzlos, benötigt er doch eine ganze Reihe an BIOS-Dateien für die ganze Hardware, die man haben möchte. Die Verwendung derselben ist wohl nur so halblegal, die entsprechenden Dateien lassen sich aber an vielen Ecken finden. Hat man diese Hürde überstanden, darf man seinen emulierten Pentium zum ersten Mal einschalten und findet eine nicht bootfähige, unformatierte Festplatte vor. Nach einigen Fehlversuchen gelang es mir schließlich tatsächlich, mit Hilfe mehrerer Bootdisketten und meiner eigenen CD ein taufrisches Windows 98 SE zu installieren, das auch fehlerfrei bootete. Die größte Zeit aber beanspruchte die nervenaufreibende Schnitzeljagd im Internet nach Treibern für die SoundBlaster 16, der Voodoo2-Karte und DirectX 7.0, zudem generische Maus- und CD-ROM-Treiber, die ich ganz klassisch in die CONFIG.SYS und AUTOEXEC.BAT einpflegen durfte. Oh wie lange ich diese beiden Dateien schon nicht mehr gesehen habe. Nostalgie pur!

Das Betriebssystem machte einen stabilen, schnellen und vor allem makellosen Eindruck, im Gegensatz zu so mancher gleichförmiger Installation unter VMware Workstation, die mit Windows 9x oft schon beim Sound überfordert schien. Aber ich wollte mein neues altes System definitiv einer Feuerprobe unterziehen und beschloss daher, einen Klassiker aus meinen alten Tagen zu installieren, den ich wirklich sehr gerne und sehr lange gespielt habe: Need for Speed III: Hot Pursuit.
Die Installation von CD-Image verlief in PCem ausgesprochen gemütlich, und das Spiel startete schließlich (nach Korrektur der Hardwarekonfiguration und Installation noch fehlender Treiber) sogar ohne weitere Schwierigkeiten und plötzlich lief das actiongeladene Introvideo von NFS3 – fast ohne Ruckler. Eigentlich hatte ich erwartet, dass das Spiel mir zunächst via Dialogbox meldete, dass ich doch bitte die CD einlegen solle, so wie das früher (durch den CD-Kopierschutz) bei gebrannten Datenträgern ein generelles Thema war. Aber möglicherweise ist auch das in PCem gar kein Problem mehr.

Nun, was soll ich sagen. Schon kurz darauf drehte ich meine ersten paar Runden in der Corvette über meine Lieblingsstrecke, den Gebirgspass, in gnadenlosen Rangkämpfen gegen Lamborghinis, Ferraris, Aston Martins und anderen Sportwagen, teils auf der Flucht vor der Polizei, teils auch nur gegen die Zeit. Anfangs noch ein wenig wackelig mit etlichen Kollisionen, gewann ich mein altes Fahrgefühl bald wieder zurück und ehe ich mich versah, driftete ich wie vor über 20 Jahren mit Begeisterung in die Kurven, gab Vollgas auf den Geraden, versuchte die perfekten Bremspunkte zu finden, und schlängelte mich zwischen den gegnerischen Boliden hindurch auf dem Weg an die Spitze des Fahrerfeldes. Die Kompatibilität ist wie erwartet einwandfrei, es gibt keine Fehler oder grafische Glitches. Die Performance ist auf meiner Kiste nicht bahnbrechend, aber ausreichend schnell. Für die Standardauflösung des Spiels von 640×480 reicht es allemal, mehr ist nicht zu empfehlen. Die größte Schwierigkeit hierbei wird sein, dass die 3D-Beschleunigung paradoxerweise in Software emuliert wird, und so natürlich keine Vorteile von der Leistungsfähigkeit der physischen Grafikkarte erfährt. Dennoch gibt es spürbare Performanceverbesserungen durch den Einsatz der Voodoo2-Schnittstelle im Gegensatz zum Software-Renderer.

Die Demonstration war für mich ein voller Erfolg, vielleicht nicht komplett repräsentativ, aber in jedem Fall sehr beeindruckend. PCem erlaubt keine Festplatten-Snapshots wie bei Virtualisierungssoftware üblich, aber meine perfekt eingerichtete, unberührte Konfiguration habe ich für die Zukunft weggesichert und werde auf diese künftig regelmäßig zurückgreifen. Auch erwarte ich weitere Verbesserungen durch die jährlich erscheinenden, neueren Versionen von PCem, so dass das Retro-Spielvergnügen immer besser wird und auch die mit ziemlicher Sicherheit existierenden Grenzfälle unterstützt. Mal sehen welches Spiel ich als nächstes installiere. Vielleicht Interstate ’76. Es sollte jedenfalls ein echter Problemfall sein, der heute nur noch sehr schwer lauffähig gemacht werden kann.

Nach anfänglichen Zweifeln vor etlichen Jahren ob wir jemals in der Lage sein würden, die früheren Windows-Spiele (ab circa 1993 bis Anfang der 2000er) jemals lückenlos in spielbarer Form zu bewahren, abseits natürlich vom Weiterbetrieb der echten Legacy-Hardware, bin ich nun überzeugt, dass für Retrogamer wie mich endlich goldene Zeiten anbrechen. Mit DOSBox, PCem, VirtualBox, VMware und diversen anderen Lösungen, die glücklicherweise allesamt nicht nur für Windows sondern auch Linux und mitunter anderen Plattformen verfügbar sind, dürfte die sich stetig verbessernde Kompatibilität endlich flächendeckend ermöglichen, auch hartnäckige Fälle von Spielen perfekt spielbar zu machen und somit vernünftig zu erhalten. Und natürlich muss man sich auch nie wieder Sorgen über eine ewige Abhängigkeit von Windows machen, denn egal ob Spiele für DOS, Windows 95/98 oder XP: Heute läuft endlich (fast) alles überall. Und hey, mit Wine und Proton sind wir sogar schon für die Spiele danach wirklich gut aufgestellt, mit unzähligen Optimierungen und Verbesserungen, die monatlich dazukommen. Wahrlich goldene Zeiten sind das.

Als ich heute Mittag meinem Blog mal wieder einen kurzen Besuch abstatten wollte, war ich etwas verwirrt. Offenbar hat das doofe Ding monatelang überhaupt keine Artikel veröffentlicht, sondern einfach ohne meine Erlaubnis einen ausgedehnten Winterschlaf gehalten. Das war vielleicht eine unschöne Überraschung. Ich habe meine Webseite natürlich sofort aufgeweckt und wieder an die Arbeit geschickt. So geht das nämlich nicht!

Okay, ich gebe es zu, die Geschichte mit dem Winterschlaf war nur erfunden. In Wahrheit hat mein Hund nämlich meine ganzen Artikel gefressen. Also genau die, die ich zwischen Dezember und Mai so aufwändig verfasst und liebevoll vorbereitet habe, und immer wenn ich sie dann auf meinem Blog veröffentlichen wollte, hat der Hund die Diskette sofort geschnappt und verspeist. Inzwischen ist die zottelige Töle im Tierheim gelandet, so geht das nämlich nicht!

Okay okay, ich hatte nie einen Hund. Ich hatte auch keine Artikel, ich hab nämlich gar keine geschrieben. Das ging leider nicht, weil ich … weil ich wirklich ganz arg krank war. Akute Männergrippe! Ich musste monatelang das Bett hüten, konnte kaum meine Buchstabensuppe trinken, geschweige denn Buchstaben am PC eintippen. Meine Hände waren einfach zu schwach.

Alles klar, ich geb’s auf. Es war wohl vielmehr ich derjenige, der einen ausgedehnten, geistigen Winterschlaf gehalten hat. Und obwohl ich währenddessen teilweise sogar recht umfangreich an meinem kleinen Spieleprojekt gearbeitet habe, wollte mir andererseits wirklich nichts einfallen, worüber ich unbedingt auf dem Blog hätte schreiben wollen. Und nein, Corona hatte absolut nichts damit zu tun. Man sollte eigentlich meinen, dass man in der wochenlangen Isolation sehr viel mehr Zeit haben würde, sich einfach mal hinzusetzen und einige schriftliche Beiträge zu verfassen. Plot Twist: Nicht die Zeit, sondern die Motivation war der Mörder. Aber da auf den Regen bekanntlich immer Sonnenschein folgt, versuche ich hiermit meine ersten wackeligen Schritte hin zu etwas mehr Beteiligung, raus aus der lähmenden Inaktivität.

Heute habe ich die Zeit bereits genutzt, um einige Updates am Blog durchzuführen, ein fehlerhaftes Widget rauszuwerfen. Und SuccessDenied.com hat seit heute endlich ein eigenes, richtiges Icon (am Browser-Tab erkennbar), der pixelige Mario-Platzhalter, den ich seit 2010 verwendet habe, war mir eigentlich immer irgendwie ein Dorn im Auge, aber doch nie wichtig genug, um ihn zu ersetzen. Damit wäre also ein weiterer, winziger Punkt von meiner Todo-Liste erledigt.

Ich habe inzwischen sogar eine ganz konkrete Idee für einen neuen Artikel, ach was rede ich, eine ganze Artikelserie! Daran sollte es also auch nicht mehr scheitern. Dann melde ich mich hiermit vorerst mal wieder zurück und erkläre das Fest für eröffnet.