Schlagwort-Archive: Fortschritt

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.

Ein Besucher meines Blogs hat mir vor einigen Wochen die absolut berechtigte Frage gestellt, ob die Entwicklung an meinem kleinen SPACOLA-Remake-Projekt denn inzwischen eingestellt wurde. Ich möchte diese Gelegenheit für ein ehrlich gemeintes Lebenszeichen und wieder einmal ein wenig Selbstkritik nutzen. Ich bin zudem dankbar für jedes bisschen Aufmerksamkeit, das mir immer wieder einzelne Leser des Blogs schenken, die sich für das Projekt interessieren. Das zeigt mir zumindest, dass ich die Arbeit nicht alleine für mich mache (obwohl das natürlich nach wie vor der Hauptgrund ist).

Die gute Nachricht: Nein, die Entwicklung an dem Spiel ist definitiv NICHT eingestellt. Ja, ich arbeite Monat für Monat daran weiter. The show must go on.
Die schlechte Nachricht: Ich arbeite sehr langsam, und meine Motivation schwankt leider von Woche zu Woche. Es tut mir leid, so ist es eben. Manchmal hänge ich mich so richtig rein und kann mich kaum bremsen. Manchmal kriege ich aber auch wochenlang mal so überhaupt nichts gebacken. Das ärgert mich dann meist selbst, so dass ich versuche, Strategien zu entwickeln, um wieder in das Thema hineinzufinden.

Ein Release von SPACOLA ECLIPSE liegt also eher in ferner als in naher Zukunft. Das mag enttäuschend sein, aber das heißt nicht, dass ich aufhöre. Und es heißt vor allem nicht, dass ich zwischenzeitlich nichts gemacht habe, denn kleine Fortschritte gibt es ständig. Das möchte ich heute mit diesem Beitrag zeigen. Vor allem die Farbversion des Remakes hat in den letzten Wochen erneut Fahrt aufgenommen. Und da Bilder bekanntlich mehr sagen als 1000 Worte, möchte ich einfach mal drei aktuelle Impressionen der neuesten Work-In-Progress-Version 0.85 zeigen.

Work-In-Progress-Version 0.85 im verbesserten „SPACOLOR“-Spielmodus

Ich habe versucht, einen Screenshot zu erstellen von einer möglichst hektischen und actionhaltigen Szene, auf der viele Elemente gleichzeitig zu sehen sind. Das komplette HUD ist quasi fertig. Wie zu erkennen ist, sind die Stationsgeschütze noch nicht koloriert, aber vieles andere schon. Außerdem sorgen die vielen Explosions- und Antriebs-Partikel schon für eine Menge Bewegung und Gewusel auf dem Bildschirm. Um meinen neuen Lenkraketen-Code zu testen, habe ich die Stationsgeschütze so eingestellt, dass sie eine größere Anzahl Lenkraketen auf den Spieler abfeuern, anstelle kleinerer Geschosse. Die gefährlichen Stationsgeschütze eingeschlossen, sind hier immerhin drei Gegnertypen zu sehen, die allesamt Jagd auf den Spieler machen. Der kann in der Szene allerdings mit seinem Schutzschild (noch) dagegen halten kann. Mehrere Lenkraketen werden demnächst von allen Seiten einschlagen, was die Situation sicherlich nicht verbessert.

Level-Auswahl-Bildschirm vor jeder Runde

Am Anfang des Spiels kann man stets nur ein einziges Level auswählen. Die schwierigeren Sonnensysteme werden dann nach und nach zugänglich, sobald man in der Galaxie ein wenig Geld verdient hat. Das gesamte Spiel mit allen Menüs ist inzwischen in Farbe verfügbar, darunter natürlich auch die Schriftarten, die Mauszeiger, das Level-Auswahl-Panel, und alle Schaltflächen. Am unteren Rand analog zur TOS-Demo des Ur-SPACOLA prangt ein kleiner Hinweis bezüglich der Unfertigkeit des Remakes. Authentizität und Originaltreue ist bei der Entwicklung immer ein entscheidendes Grundprinzip. Jeder einzelne Pixel muss immer genau dort sitzen, wo er im Original auch platziert worden wäre. Hierzu nehme ich mir viel Zeit, um Screenshots zu vergleichen und Abstände zu messen.

Künstlerische Freiheiten nehme ich mir ausschließlich dort, wo sie absolut sinnvoll und vor allem nötig sind. So ist zum Beispiel der gesamte Metallic-Look der Farboberfläche eine alte Idee von mir, die ich schließlich möglichst perfekt mit dem Original-Design in Einklang bringen wollte. Selbst den Farbverlauf des Remake-Schriftzugs habe ich nicht einfach irgendwie aus dem Ärmel geschüttelt, sondern es basiert auf einem Design von der alten Dongleware-Webseite, wo es bereits eine frühe eingefärbte Fassung zu bewundern gab.

Der gute alte „SPACoLASSIC“-Spielmodus mit handgepixelter Monochromgrafik

Selbstverständlich lässt sich das Spiel auch komplett in der Originalgrafik spielen, bei der alles soweit unangetastet bleibt (verständlicherweise bis auf Details im Intro). Für Fans und Puristen gibt es dann „nur“ Monochrom-Sprites bei limitierten 36 Bildern pro Sekunde, und keinerlei Partikeleffekte oder sonstige neue Spielereien. Das Gameplay bleibt allerdings identisch.

Wer wissen möchte, an welchen Details ich mich da eigentlich so aufhalte, der möge gerne weiterlesen: Im Remake gibt es inzwischen ein Weapon-Interface, das es allen Schiffen im Spiel (Spieler, Mitspieler und Feinde) dynamisch ermöglicht, quasi auf Befehl eine andere Waffe zu aktivieren, seien es die Spieler-Standardwaffe, Lenkraketen, Laserwaffen, zwei Arten von Turret-Waffen, Minen, oder beispielsweise schlagkräftige Kanonenkugeln. Darüber hinaus habe ich eine AimHelper-Klasse geschrieben, die alle im Spiel bekannten Arten von Anvisier-Techniken der Gegner wiederverwendbar implementiert und mühelos auf alle möglichen Spielobjekte anwenden lässt. Wie präzise oder wie schlecht ein feindliches Schiff zielt, kann ich so dynamisch ohne Quellcode-Änderungen bestimmen. Damit kann sogar der Spieler eine Art „Aimbot“ bekommen, wenn man denn möchte. Das wäre jedenfalls eine Idee für ein zusätzliches Powerup.

Im Dezember habe ich übrigens das SPACOLA-Codebuch abgetippt. Nein, nicht die Koordinaten. Die gibt es schon in digitaler Form und sind im Remake auch zu 100% enthalten. Die Rede ist von den Powerups, also die Extras, die als kleine Symbole neben den Koordinaten im Buch abgedruckt sind. Mein innerer Perfektionist wollte partout nicht damit leben, dass dieser Teil des „Sternenatlas“ nicht im Remake nutzbar sein wird. Also habe ich angefangen, die Extras mühsam abzutippen, wo sich allerdings nach zwei Buchseiten bereits zeigte, dass ich so niemals fertig werden würde. Also habe ich mir ein kleines Progrämmchen geschrieben, das mir die Eingabe der Zeichen erleichtert: Ich musste quasi nur noch das jeweils passende Symbol anklicken und das Ergebnis wird direkt in eine CSV-Datei geschrieben.

Aber im Endeffekt bleibt alles Handarbeit. Es geht hier schließlich um 154 Buchseiten á 3 Blöcke pro Seite á 64 Symbole. Summa summarum sind das 29568 Symbole. Also 29568 Netto-Mausklicks. Und dann ist da noch gar nicht eingerechnet, dass ich mich recht oft verklickt oder verlesen habe, und einige Seiten im Buch von so schlechter Druckqualität sind, dass man praktisch nur noch raten kann, was da steht. Zum Glück gibt es eine Methode um zu validieren, ob die Eingabe stimmt, sonst wär die Fehlerquote einfach zu hoch. Und ja, es hat einige Tage gedauert, aber am Ende war ich mit allem fertig. Somit kann ich nun stolz behaupten, dass das Remake nicht nur sämtliche Koordinatenangaben akkurat wiederverwendet, die im Sternenatlas abgedruckt sind, sondern auch alle Powerups in die Levelkarten einbindet, so wie es im Originalspiel war.

Und wann wird SPACOLA ECLIPSE endlich fertig … oder wenigstens mal spielbar? Tja, keine Ahnung. „When it’s done“ ist ja mittlerweile ein geflügeltes Wort in der Spielebranche, das immer wieder gerne gewählt wird und auch sehr gut passt. Ich weiß nicht wann es fertig wird. Aber ich weiß, dass ich weitermache. Und so langsam fügen sich die vielen kleinen Puzzleteile immerhin zu einem erkennbaren Bild zusammen. Vielleicht dauert es gar nicht mehr so lange, bis das erste komplett spielbare Level veröffentlicht wird.

Die Situation ist irgendwie absurd: Bei uns im Büro werden die Mitarbeiter mit Firmen-Notebooks abgespeist, die kümmerliche 250 GB Festplattenkapazität mitbringen. Im Jahr 2018! Und dabei sind das sogar recht aktuelle Modelle. Mein letztes privates Notebook habe ich mir vor rund zehn Jahren gekauft, zu einem Spottpreis, und das hatte bereits eine ebenso winzige Festplatte. Kürzlich während der Arbeit ist mir der Festplattenspeicher dann tatsächlich ausgegangen. Das war vielleicht eine Überraschung. Eine äußerst negative. Ich musste ernsthaft meine alten Projektdateien durchforsten auf der Suche nach etwas, was ich am ehesten entbehren könnte, um Platz für Neues zu schaffen. Irgendwelche wehrlosen Daten zu löschen, hat mir Schmerzen bereitet. Ich war felsenfest der Meinung, wir wären endlich dem Zeitalter entwachsen, in dem wir Speicher sparen müssten, und uns die Festplattendimensionen nicht ausreichen würden. Waren wir eigentlich auch!

Tja, und dann kamen die SSDs. Plötzlich werden wieder brandaktuelle Notebooks regulär mit Pipi-Festplatten zwischen 80 und 250 GB verkauft. Und das zu einem Preis, bei dem mir die Augen bluten. Ab in die Steinzeit. Ach, die tollen SSDs sind ja so viel schneller, das rechtfertigt natürlich, dass wir endlich wieder jedes Byte zweimal umdrehen müssen. Zwei Spiele deinstallieren, damit gerade genug Platz für ein neues ist. Das waren lustige Zeiten – jedenfalls so um 1998 rum, also vor 20 Jahren. Heute ist das in jeder Hinsicht peinlich. Da scheiße ich doch auf den Geschwindigkeitsgewinn, wenn DAS der Preis ist. Festplatten sind für mich Daten-Endlager, und was zählt ist das Fassungsvermögen, sonst nichts.

Stimmt schon, der PC startet damit viel schneller. Aber da der PC eh nur morgens einmal startet, während ich mir ohnehin gerade einen Kaffee hole, hält sich der Vorteil für mich hier stark in Grenzen. Was sich für mich aber sehr stark bemerkbar macht, ist die ständig drohende, rote Festplatten-Füllstandsanzeige von Windows, die mir permanent Sorgen macht. Das ist doch wie als würden wir irgendwann mit der ersten Generation von Raytracing-Grafikkarten den Windows-Desktop endlich in fotorealistischer Darstellung rendern können, aber nur in der Auflösung 640×480 – auf unbestimmte Zeit. Mit 256 Farben! Das muss einem die wahnsinnige Bildqualität dann schon wert sein. Dieser Rückschritt ist eben der Fortschritt. Ich will sowas nicht mehr. Hätte man mich gefragt, hätte ich eine interne 2 TB-Festplatte verlangt, also mal eben mit der achtfachen Kapazität, und die wäre noch weitaus günstiger gewesen. Ja, dann dauert das Compilen halt mal ein paar Sekunden länger, dann kann man in der Zeit wenigstens auf die zahlreichen E-Mails antworten, die tagsüber so reinkommen.

Und wie sieht das aktuell eigentlich mit der Preisentwicklung bei den SSDs aus? Gibts bald die bezahlbaren 4 TB SSDs für Jedermann? Die, die schon seit Jahren von den SSD-Fans vollmundig angekündigt werden? Die, die die antiquierte Magnetfestplattentechnik endlich ins Museum schicken werden? Nein, gibts nicht. Wer hätte es gedacht. SSDs bleiben weiterhin klein und teuer. Erst kürzlich habe ich in einem Artikel einen Ausblick auf die SSD-Preislage der kommenden Monate gelesen, nach dem nicht zu erwarten ist, dass der Preis pro GB bei SSDs signifikant fallen wird. Es scheint als würde sich das Thema allmählich einpendeln. Keine Sorge, die SSDs werden permanent größer, aber eben auch linear teurer.

Und die museumsreifen Magnetfestplatten? Wenn man mal vom hohen Preis absieht, sind 12 TB Festplatten bereits käuflich zu erwerben (derzeit bei 37 EUR/TB), die ersten 14 TB-Modelle kommen noch in diesem Jahr, die Technik für 16 TB HDDs steht für 2019 in den Startlöchern. Und wenn die HAMR-Technik mal Marktreife erlangt, werden die Magnetfestplatten sogar in Regionen jenseits der 20 TB vorstoßen. Von bis zu machbaren 100 TB im folgenden Jahrzehnt ist da die Rede. Günstige Festplatten gibt es für knapp 24 EUR/TB, wo man aktuell im Bereich zwischen 3 und 8 TB das beste Geschäft macht. Und das beste daran ist, bei dieser Art Festplatte ist der sinkende Preis quasi garantiert: Jede neue Generation auf dem Markt sorgt für einen Preisrutsch bei den vorangegangenen.

Auch nach aktuellem Stand ist nicht anzunehmen, dass SSDs so bald das alleinige, dominierende Produkt sein werden, sondern beide Formate noch viele Jahre nebeneinander existieren werden. Da können die SSD-Fans noch so sehr schimpfen über die schrottreifen, anfälligen, steinzeitlichen, (weitere Schmähbegriffe bitte hier einfügen) Magnetfestplatten, die eigentlich alle sofort vom Markt genommen und abgewrackt werden müssten. Aber zum Glück sehen das nicht alle so eindimensional.

gez. Einer, der 14 HDDs und 3 SSDs im Einsatz hat

Alle Jahre wieder, wenn auf irgendeiner Technik- und Hardware-Webseite oder an sonst irgendeinem Ort im Netz Neuigkeiten über ein aktuelles Festplatten-Flaggschiff, das alle bisherigen Festplattenkapazitäten in den Schatten stellt, berichtet wird, kommen sie ans Tageslicht: ich nenne sie die „Wer braucht denn soviel Platz?“-Trolle. Sie stürzen sich auf das Diskussionsforum und verärgern mit dieser billigen Provokation sämtliche Technikfans. Auch im eigenen Freundeskreis verbergen sie sich gerne, um dann im geeignetsten Augenblick zuzuschlagen.

Es vergeht kaum ein Jahr, in dem ich mir nicht eine neue Festplatte mit immer größerem Speicher zulege: 20 MB, 512 MB, 2.1 GB, 4.2 GB, 30 GB, 200 GB, 400 GB, 500 GB, 1 TB, 1.5 TB, 2 TB … ich hab praktisch alles mitgemacht. Eine 3 TB -Platte kommt mir sicher auch noch ins Haus. Doch kaum wird das Thema in heiterer Runde angeschnitten, folgt wieder die obligatorische Frage: „Wer braucht denn schon soviel Platz?“. Umgekehrt könnte ich natürlich fragen: „Was sind das eigentlich für Witzfiguren, die ernsthaft eine solche Frage stellen?“. Aber ich fürchte, damit begebe ich mich dann auch nur auf dasselbe Niveau herab.

Von dem „Wer braucht denn soviel Platz“-Troll gibt es viele verschiedene Formen. Wird das Gespräch gerade auf die kommenden 12-Kern-Prozessoren gelenkt, schlägt der Troll wieder zu: „Wer braucht denn soviele Kerne?“. Oder bei den Auflösungen der Monitore ab 24 Zoll: „Wer braucht denn so eine hohe Auflösung?“. Oder bei der Internetanbindung: „Wer braucht denn 50 MBit/s Downstream?“, respektive „Wer braucht denn mehr als 1 MBit/s Upstream?“. Es sind vermutlich dieselben Leute, die sich bei einer Digitalkamera von Red fragen: „Wer braucht denn Videos im 4K-Format?“ mit dem intelligenten Zusatz „720p reicht doch!“

Was bleibt mir in einer solchen Situation? Was mache ich also Jahr für Jahr, wenn wieder jemand halbklug daherlabert, sobald es um technische Neuerungen geht? Ganz einfach, ich erkläre es ihm: Wer denn soviel Platz bräuchte? ICH! ICH und viele andere Menschen, die die Technik gerne ausreizen, die eine ebenso große Sammelleidenschaft haben und die wissen, dass sich alles weiterentwickeln muss. Wo wäre die Technik heute, wenn sich von Anfang an immer jemand zunächst gefragt hätte: „Moment mal, wer braucht denn überhaupt mehr als 640 KByte RAM?“, um sich dann von seiner Idee angewidert abzuwenden und lieber noch eine Runde Dune II zu spielen.

Nur weil euch eine kleine Festplatte reicht, ihr Augenschmerzen von großen Desktopauflösungen bekommt, ihr im Monat nicht mehr als 200 MB Download-Volumen ansammelt und euch alles mit mehr als 2 Prozessorkernen und mehr als 2 GB RAM suspekt vorkommt, müsst ihr Trolle doch trotzdem einsehen, dass es Leute mit höheren Ansprüchen an die Technik gibt. Denkt bitte in Zukunft nochmal nach, bevor ihr wieder dämliche Fragen stellt. Wir wissen es zu schätzen.