ich habe mich in den letzten Monaten recht intensiv mit einigen (und oberflächlich mit anderen) Teilen des Quellcodes beschäftigt. Natürlich kenne ich mich lange nicht so gut aus damit wie TheCoder, aber ich glaube mittlerweile einen guten Überblick zu haben.
Ich will jetzt nicht auf die Idee eingehen, ASC im Browser neu zu implementieren. Für ein Spiel mit der Komplexität von ASC ist das (noch) keine gute Idee, glaube ich (das kann ich gerne weiter ausführen, aber jetzt grade nicht
ASC ist über viele Jahre entstanden, und das sieht man dem Code an. Es finden sich teilweise noch Relikte aus der Zeit, als ASC in Pascal geschrieben war und auf DOS lief (aber das ist jetzt ein Extrembeispiel, kein echtes Problem). Vieles vom älteren Code benutzt auch die STL (die C++ Standardblibliothek) nicht wirklich und re-implememtiert Datentypen, die in der STL oder Boost (einer Art Erweiterung der STL) sind oder sich auf Basis der STL oder Boost besser lösen lassen. Vieles, das später dazugekommen sind, sind in modernerem C++ geschrieben. Es wäre eine wichtige Arbeit, insbesondere grundlegende Klassen und Funktionen von ASC, die sich mit IO-Streams und Stringbehandlung und so beschäftigen, konsistent in modernem C++ zu implementieren. Das würde den Code auch schlanker und übersichtlicher machen.
Auch andere Sachen haben mit dem Alter des Codes zu tun: ASC benutzt Loki als Bibliothek für einige Patterns, zum Beispiel für Singletons oder Functors. Loki ist eine sehr clevere Bibliothek, ist aber seit mindestens 4 Jahren tot, d.h. die Software wird weder weiterentwickelt noch gewartet. Mittlerweile unterstützt Boost alle Sachen, die Loki kann, daher wäre es eine gute Idee, von Loki auf Boost zu migrieren, um einerseits nicht den gesamten Code von Loki mitzuschleifen, und andererseits zu wissen, dass auftretende Bugs in den genutzten Bibliotheken auch gefixt werden. Boost wird ohnehin genutzt, das heißt, es kommen keine zusätzlichen Abhängigkeiten hinzu. Das ist alles keine schwierige Arbeit, gehört aber zur Code Maintenance.
In ASC sind viele Dinge hardgecoded, wie die Spieleranzahl und weitere Dinge, die eigentlich nicht in eine Engine gehören. Mit anderen Worten: ASC ist direkt als Neu-Implementation von Battle Isle gedacht und erstmal nicht mehr. Diese Vorstellung ist implizit überall im Code drin. Da geht es nicht nur im irgendwelche Konstanten, die geändert werden müssen, sondern um einige Algorithmen, die man anders (dynamisch) implementieren muss. Viel mühselige Arbeit.
Weiterhin gibt es im Code zu viel state, d.h. Dinge sind in einem globalen Zustand. Dadurch lassen sich viele Funktionen schlecht neuimplementieren, weil sie z.B: Nebenwirkungen haben, die an ganz anderer Stelle im Code Verhalten ändern, oder von einem Zustand abhängen, der sonstwo gesetzt wird. Ganz ohne globale Zustände kommt man natürlich nicht aus, aber da sollte viel mehr explizit passieren (also zum Beispiel ein Wert als Parameter übergeben werden anstelle eine Eigenschaft der globalen GameMap-Instanz zu verändern). Außerdem verhindert der jetzige Zustand das Nutzen von Multithreading, weil viel zu viele Dinge gelockt, also vor parallellem Zugriff geschützt, werden müssen, was sehr aufwändig ist und die Vorteile von Multithreading auffrisst.
Wie Ihr seht, habe ich bisher das Thema Grafik noch nicht einmal angeschnitten
Das sind wohlgemerkt alles noch erste Eindrücke von einer meist noch oberflächlichen Beschäftigung mit dem Code. Die Essenz ist aber: Eine Neuimplementation ist ziemlich utopisch, weil sich wahrscheinlich kein Held wie TheCoder findet, der das alles im jahrelanger Arbeit aufzieht. Der jetzige Code hat den Vorteil, dass er hier und jetzt funktioniert. Wenn man sich die Arbeit macht, ihn an vielen grundlegenden Stellen zu modernisieren (und das ist viel Arbeit), dann kann man ihn in Zukunft als Basis für alle möglichen neuen Funktionen nutzen, aber eben noch nicht jetzt. Und: TheCoder wird das unmöglich alleine schaffen.




