Steffen Häuser und Nico Barbat waren maßgeblich an der Umsetzung von Die Siedler 2 für den Amiga verantwortlich. Ich habe ihnen einige Fragen gestellt, und die Antworten fallen zum Teil sehr detailliert und technisch aus. So gibt es interessante Einblicke in die Entwicklung dieser Umsetzung.

AGF: Hallo, freut mich, dass ihr beide dabei seid. Dieses Spiel kam sehr überraschend und wirft einige Fragen auf.
Steffen: Ja, dass das überraschend kam, ist uns bewusst. Aber ganz ehrlich – ein Spiel wie Die Siedler 2 verdient den „Knalleffekt“! Und ich denke, es ist auch für Amiga-User sehr erfrischend zu hören: „Das Spiel kommt, an diesem Datum kommt es raus, und alles – Entwicklung und Betatest – ist schon fertig“, statt immer weiter verschobene Releasedaten, unter denen wir alle schon bei Amiga-Produkten litten. Und das bei einem Spiel, das Amiga-User seit über 25 Jahren wollten!
Nico: Die Idee einer Amiga-Portierung von Die Siedler 2 war schon lange ein Traum von uns. Schließlich wurde uns das Spiel seinerzeit verwehrt, also wollten wir das ändern. Mitte 2023 traten wir schließlich an Ubisoft heran, die dem Projekt von Anfang an sehr aufgeschlossen gegenüberstanden. Der gesamte Prozess bei einer solchen Portierung – die aufwändigen Lizenzvereinbarungen, zusätzliche Geschäftsdeals, Produktionswege und natürlich die eigentliche Entwicklung des Ports samt Betatesting – verlief seither kontinuierlich. Es gab ein paar Hindernisse zu umschiffen, aber ich bin überzeugt, dass sich die ganzen Bemühungen gelohnt haben.

AGF: Wie kamt ihr auf die Idee, Die Siedler 2 für den Amiga umzusetzen? Ergab sich die Gelegenheit oder gab es den aktiven Wunsch dafür? Was bedeutete euch das Spiel vorher?
Steffen: Ich kam erst später dazu, mit einem „Ach ja, würdest du gern Die Siedler 2 auf den Amiga portieren?“ (Was antwortet man da wohl? Jaaaaaaaaa!)
Nico: Das war tatsächlich ein langjähriger Wunsch – praktisch seit dem Moment, als klar wurde, dass Die Siedler 2 damals nur für den PC und nicht für den Amiga erscheinen würde. Diese Ungerechtigkeit gehörte korrigiert! Deshalb sind wir aktiv auf Ubisoft zugegangen.
Die Siedler ist für uns nicht nur der beste Teil der Serie, sondern ein Meilenstein des Genres. Der erste Teil legte den Grundstein und war bereits ein wunderbares Spiel, aber Teil 2 schöpfte erst das volle Potenzial aus. Diese Einschätzung teilen offenbar viele – erst kürzlich setzte GameStar Die Siedler 2 auf Platz 2 der besten Aufbauspiele aller Zeiten, direkt hinter dem großartigen Anno 1800. Das zeigt, wie zeitlos und bedeutend dieses Spiel auch heute noch ist.

AGF: Wie habt ihr es geschafft, die Rechte von Ubisoft zu bekommen? Was waren die Bedingungen? Gab es Probleme dabei?
Steffen: Nico weiß mehr.
Nico: Es war eigentlich erstaunlich unkompliziert. Auch wenn sich die vertragliche Ausarbeitung hingezögert hat, war doch allen Beteiligten immer klar, dass wir zum Ziel kommen würden.
Wie alles anfing? Simon (Verlagspartner Simon Neumann) meinte irgendwann bei einem Bier: „Komm, jetzt fragen wir sie endlich!“ Also haben wir eine E-Mail geschrieben, und bereits wenige Tage später hatten wir einen Videocall mit Ubisoft Frankreich, gefolgt von vielen weiteren Gesprächen mit Ubisoft Blue Byte in Düsseldorf.
Hilfreich war sicherlich, dass bereits eine lose Geschäftsbeziehung zu Ubisoft bestand – wir hatten zuvor ein lizenziertes Artbook zu Assassin’s Creed Valhalla veröffentlicht. Außerdem konnten wir nachweisen, dass wir bereits erfolgreiche Produkte entwickelt hatten, mit Steffen einen erfahrenen Portierungsprofi und ein bestehendes Team aus Betatestern an Bord haben. Wir konnten glaubhaft vermitteln, dass wir es ernst meinen mit der Entwicklung und dem Vertrieb des Spiels. Wichtig war für Ubisoft Blue Byte, dass wir verstanden haben, wie bedeutsam die Marke Die Siedler für Ubisoft ist, und dass wir entsprechend respektvoll damit umgehen würden.
Von Anfang an spürten wir, dass Ubisoft Blue Byte das Spiel sehr gerne auf dem Amiga sehen wollte. Die Unterstützung war außergewöhnlich – dafür möchte ich mich hier noch einmal ausdrücklich bedanken. Ein besonderes Dankeschön geht an Kay Bennemann, Senior Business Developer bei Ubisoft. Ohne seinen persönlichen Einsatz wäre Die Siedler 2 definitiv niemals auf dem Amiga erschienen.
[interne Anmerkung: Über die Vertragsbedingungen dürfen wir natürlich nicht sprechen.]

AGF: Die Siedler 2 wurde in C geschrieben – anders als Teil 1, der in Assembler programmiert war. Wie hat Steffen es geschafft, diesen Code Amiga-tauglich zu machen? Wie geht man dabei vor?
Steffen: Eigentlich in C++ – was übrigens für moderne Amiga-Spiele die übliche Programmiersprache ist. Ich bezweifle, dass noch viel in Assembler geschrieben wird, außer vielleicht bei reinen A500-Projekten. Und selbst bei denen vermutlich nur ein kleiner Teil (eher mit Spezialsystemen wie der Scorpion Engine). Den Rest beantworte ich in der übernächsten Frage, da die sehr verwandt ist.
Nico: Das ist Steffens Part. Man kann nur ergänzen, dass die Quellcodes der bereitgestellten Versionen anfangs nicht vollständig waren und wir erst mit der Mac-Version und mit Support des ehemaligen Entwicklers wirklich schnell vorankamen.

AGF: Wurde die Grafik komplett übernommen? Wie sieht es mit dem Sound aus?
Steffen: Bei Portierungen übernimmt man natürlich die kompletten Datenfiles. Anders geht das gar nicht (evtl. aus Ladegeschwindigkeits-Erwägungen das Auspacken von .dat-Files). Lustige Geschichte: Die Grafiken bei Die Siedler (innerhalb von .dat-Files) liegen im LBM-Format vor – das ist IFF ILBM. In der PC-Version waren da Endian-Switches eingebaut, um die Big-Endian-Grafikdateien zu laden 😉 Die Siedler 2-Datenfiles verraten die Amiga-Vergangenheit der Marke.

Wo es Änderungen gab, war beim Sound (im Original viele verschiedene Frequenzen – mal 5 kHz, mal 11 kHz, mal 22 kHz … je nach Datei verschieden). Ein „on-the-fly“-Ändern der Frequenz ist zwar möglich, hat aber speziell für langsamere Systeme Performance-Nachteile. Deshalb wurden die Frequenzen auf eine gemeinsame Frequenz angepasst, sodass diese Nachteile beim Mixen nicht entstehen.

Eine weitere Sache betrifft das Intro-Video: Dies existiert in drei Versionen (MPEG2 Highres, MPEG2 Lowres und CDXL – letzteres, damit auch auf AGA ein flüssig abgespieltes Video möglich ist. Wir wollen ja nicht, dass nach über 25 Jahren ein Amiga-User als Allererstes ein ruckelndes Video von Die Siedler 2 sieht). Das CDXL-Video belegt übrigens fast die Hälfte der genannten „600 MB Plattenplatz“ (ca. 260 MB). Der hohe Platzbedarf gegenüber der PC-Version ergibt sich aus diesem Punkt und den 170 MB Musik-Dateien (in der PC-Version CD-Audio-Tracks). Wir entschieden uns für PCM-WAVs. Die sind zwar größer, aber die Konvertierung aus CD-Tracks ist verlustfrei – sprich: Die Musik hat die gleiche Ausgabequalität wie in der CD-Version und benötigt keine performance-intensive Dekomprimierung.

Nico: Steffens Part. Ergänzend: Grafik komplett übernommen, auf die verschiedenen Auflösungen angepasst; Sound wurde konvertiert und etwas runtergerechnet, ohne hörbare Unterschiede.

AGF: Wie viel musste letztlich noch angepasst werden? Was war besonders schwierig bei der Umsetzung?
Steffen: Optimierung. Optimierung. Optimierung. Und die Erschaffung einer Lowres-Version, wozu der gesamte GUI-Code komplett ersetzt werden musste. Und sehr oft kam eine Nachricht eines Betatesters: „Dieser Dialog sieht in Lowres abgeschnitten aus, wenn man etwas weiter gespielt hat, etwa mit diesem Spielstand.“ Dann musste erst mal gesucht werden: „Wo im Code wird dieser Dialog erzeugt?“

Des Weiteren gab es Code-Aspekte, bei denen anscheinend schon bei der PC- und Mac-Version sehr viel geändert wurde. Wenn da dann noch einmal etwas angepasst werden musste, war das sehr aufwendig. Allgemein war es komplex, das Ganze vernünftig auf AGA zum Laufen zu bringen. Und natürlich der WarpUP-Compile (ohne selbst ein WarpUP-System zu haben – an dieser Stelle Danke an Dennis Boon, der bei dem WarpUP-Aspekt extrem geholfen hat).

Nico: Steffens Part, bezugnehmend auf die Sources.

AGF: Wie lange dauerte die Entwicklung?
Steffen: Habe es nicht mehr genau im Blick, aber über mehr als ein Jahr auf jeden Fall.
Nico: Schwierige Frage, weil sich der gesamte Prozess natürlich vom ersten Gespräch bis zur Veröffentlichung über zwei Jahre gestreckt hat und die verschiedenen Versionen bearbeitet werden mussten. Vielleicht hat Steffen ein Gefühl für die Entwicklerseite; zur Producerseite kann ich sagen, dass „bestimmte Vorgänge ihre Zeit brauchen, bis sie spruchreif sind“.

AGF: Die Hardwareanforderungen sind für den Amiga nicht gerade niedrig. Warum sind sie so hoch? Ist das Spiel von Grund auf wirklich so viel anspruchsvoller als Teil 1, oder liegt es an der Umsetzung des Codes, z. B. wegen des Compilers?
Steffen: Ohne Optimierung wäre das auf 68k nicht machbar gewesen (ja, auf dem 100 MHz 060 wäre es auch ohne Optimierung gelaufen …).
Also eigentlich sind die Anforderungen niedrig. Es ist ein Spiel von 1996. Spiele aus dieser Zeit haben typischerweise höhere Anforderungen (Heretic 2 von 1998 – gerade zwei Jahre später – braucht etwa mindestens einen PiStorm in der Amiga-Version). Und gerade, dass ein solches Spiel auch noch auf AGA läuft – das sind keine hohen Anforderungen. Für die Einschränkungen der Hardware kann ich nichts. Und Optimierung kann beschleunigen, aber keine Wunder wirken. Wegen der Optimierung läuft es immerhin auf 40 MHz 040 + AGA.

Woran es liegt? Es liegt am 68030. Der ist zu langsam. Das beschränkt sich nicht nur auf einzelne Bereiche im Code (wobei es natürlich Bereiche gibt, wo dies besonders deutlich wird, wie etwa die KI für die „Männchen“ 😉 ). Aber zum Glück sind PiStorm-Turbokarten recht günstig.
Nico: Technische Frage für Steffen, gehe darauf aber auch in der nachfolgenden Frage ein.

 

AGF: Also wäre eine geringere Anforderung kaum sinnvoll möglich gewesen.
Steffen: Ursprünglich war der Plan, dass es ab 030 läuft. Aber trotz Optimierung – das war einfach nicht möglich. (Auf der Mac-Version steht übrigens „ab 030“, aber der Mac hatte ein besseres Speicherinterface – und diese Version lief nicht wirklich gut auf dem 030. Das habe ich direkt vom Autor der Mac-Version – es war quasi eine politische Entscheidung, dass da „030“ steht.) Will nicht ganz ausschließen, dass es vielleicht auf einem A3000 mit 030 und guter Zorro-3-Grafikkarte dennoch halbwegs läuft – aber das dürfte eher die exotische Variante sein.

Man hätte natürlich noch probieren können:
a) Darstellung in 64 Farben (ECS EHB) – Beschleunigung durch geringere Datenmengen, da nur 6-Bit-Grafik.
b) 2×2-c2p-Variante statt 1×1 (GUI in 2×2 Pixeln? Ouch ^^).

Aber ich glaube, der grafische Output von diesen beiden Varianten hätte Ubisoft nicht wirklich gefallen 😉

Rein theoretisch – es hindert niemanden, sich den Source der magicsystem-Library downzuloaden (die Library, die den Grafikoutput macht, ist Open Source) und da einen anderen c2p einzubauen 😉 Ist auf meinem GitHub. Mit Blitter-basiertem c2p habe ich sogar etwas rumgespielt, hatte aber den Eindruck, das war eher langsamer als schneller.

Ein großes Problem scheint die KI zu sein. Einmal dachte ich schon, ich hätte den 030 geknackt. Dann stellte sich leider heraus, dass diese Beta einen schweren Bug hatte, wodurch die KI nicht anlief. Aber ohne KI kein Spiel, natürlich … So habe ich auch gelernt, dass auf dem 030 nicht nur ein Videorefresh-Problem besteht, sondern die Gegner-KI auch viel zu langsam ist.

Option c) Beschränkung der maximalen Anzahl sich gleichzeitig bewegender „Männchen“.
(Da wäre unter Garantie das Veto von Ubisoft gekommen – das hätte das Spiel ja vollkommen verändert.)

Was man tatsächlich machen kann, ist:

echo „640“ >env:Settlers2/ResX 

echo „256“ >env:Settlers2/ResY

Auf einem 060 läuft 640×256 echt recht sauber (kein so großer Unterschied zu 320×256), aber in 640×256 sieht alles so langgezogen aus. Haben wir auch nicht in die Standardoptionen getan – ich glaube, das wäre bei Ubisoft auch nicht so gut angekommen. Und beim 030 hätte es eh nicht geholfen.

AGF: Wie setzt man so etwas um, wo fängt man da an? Es ist ja nicht so, dass der C++-Code einfach so auf dem Amiga läuft.

Steffen: Das wird nun aber sehr technisch.

1. A) Makefile

Erster Schritt: Code, der für den Visual-Studio-Compiler gemacht ist, verwendet ein Projektfile. Für den CodeWarrior auf dem Mac (ich glaube, der wurde damals für die Mac-Version genommen) ebenfalls irgendein eigenes Projektfile. Diese Files geben praktisch an, welche Namen die zu übersetzenden C++-Dateien haben und welche Optionen gesetzt werden („Compiliere für 486 CPU“ oder „für PowerPC G4“ oder was auch immer). Das muss ich als ersten Schritt durch ein Makefile ersetzen.
Makefiles werden zum Compilieren bei AmigaOS, Linux und vielen anderen Betriebssystemen genutzt – heute auch bei MacOS, aber damals, als die MacOS-Version entstand, noch nicht. Also habe ich ein Makefile erstellt (bzw. eines für 68k, eines für OS4 und eines für WarpUP, da diese jeweils andere CPUs haben).

In dem einen steht dann etwa:

ppc-amigaos-gcc -mcpu=750 …

während in dem anderen steht:

m68k-amigaos-gcc -mcpu=68040 …

1. B) Compiler

Jeder Compiler (gerade ältere) hat Eigenarten, bei denen er vom Standard abweicht. Das kann zum Beispiel sein, dass man bei manchen Compilern statt

char *blabla = malloc(300);

schreiben kann (malloc liefert einen „allgemeinen Pointer“ zurück, blabla in dem Beispiel erwartet einen Pointer auf char-Daten).

Der gcc (egal ob auf Amiga, Linux oder heute auch MacOS-gcc) erwartet dagegen:

char *blabla = (char*)malloc(300);

Also, dass char*-Daten geliefert werden. Beim ersten Compilieren gibt es viele solcher Stellen. Oder: #include <stdlib.h> heißt auf älteren Compilern #include <memory.h> (beim Amiga dann stdlib – bzw. die Sachen, die früher in memory waren, sind nun auch in stdlib; stdlib gab es früher schon, aber es enthielt nicht alles). Das muss alles geändert werden.

Das ganze OS-spezifische (Video-Refresh, Sound, Tastatur/Maus etc.) lässt man erstmal weg.

90 % des Codes lassen sich direkt auf dem Amiga übersetzen, weil er nicht OS-spezifisch ist. Code wie die KI des Spiels ist es völlig egal, ob er für PC, Amiga oder was auch immer läuft – das ist derselbe Code und den muss man nie ändern. Aber die verbleibenden 10 % verursachen 90 % der Arbeit. ^^

1. C) Endian

Wenn ein PC Daten so speichert:

0x12 34 56 78

und man lädt die einfach so in den Amiga (etwa Datenfiles des Spiels), dann kommt an:

0x78 56 34 12

Sprich, man muss das während des Ladens „tauschen“. Das nennt sich „Endian-Konflikt beheben“.

Aber aufpassen: Manche Daten sind wie Textfiles – wenn man die tauscht, kommt nur Blödsinn raus. Man darf nur 16- und 32-Bit-Daten tauschen. Nun ist es leider bei Siedler 2 etwa so, dass er alle Daten erstmal wie Textfiles lädt und sie erst später auf die richtigen Strukturen verteilt. Da musste man erstmal analysieren: „Sind das hier Daten, die wirklich wie Textfiles sind, oder 16/32/64-Bit/Float-Daten?“

In diesem Fall ging der Port aber von der MacOS-Version aus. Die hat das alles schon gemacht, denn der Mac ist auch Big Endian (zumindest 68k- und PPC-Macs; x86-Macs sind natürlich Little Endian, aber der S2-Port für MacOS entstand, bevor es x86-Macs gab).

Das Problem: Der ganze OS-spezifische Kram ist einfacher vom PC zu portieren als vom Mac. Sprich: Bei manchen Files habe ich den Code der PC-Version als Ausgangspunkt genommen, bei manchen die Mac-Version – um mit dem Endian-Kram nicht durcheinanderzukommen. 😉
(MacOS-9-Code für Bildschirm öffnen, Sound etc. ist echt „fremdartig“. 😉 )

1. D) OS-spezifischer Code

Da habe ich meine eigene Library geschrieben: Bildschirm öffnen, ein Sample spielen, mehrere Samples zusammen „mischen“ usw. Sie ist sogar eine OpenSource-Bibliothek, die dann vom Siedler 2-Exe geladen wird (dieser Mechanismus musste natürlich auch erst eingebaut werden).
Ein spezieller Punkt beim OS-spezifischen Code ist da noch …

1. E) Memory-Mapping

Das ist ein sehr eleganter Mechanismus, der nur auf PC/Mac/Linux usw. funktioniert. Ja, entgegen den Puristen ist hier die „Amiga-Art“ extrem unelegant und die PC-Art wahnsinnig elegant. Warum? Weil der Amiga standardmäßig keine MMU hat. Die braucht man für Memory-Mapping. Und zusätzlich Support dafür im OS (Support, der über Mungwall etc. hinausgeht, wie es 68060er auf dem Amiga haben).

Worum geht es da? Statt eine Datei komplett zu laden, sagt der Programmierer dem PC: „Tu einfach mal so, als ob diese Datei in den Speicher geladen wäre, und jetzt gib mir Bytes 200–300 von dieser Datei.“ Ein PC muss dazu nur 100 Bytes Speicher belegen (ah, 101 Bytes ^^). Ein Amiga dagegen so viele Bytes, wie die Datei groß ist, da er kein Memory-Mapping hat und sie komplett laden muss.

Wenn Leute immer jammern: „Auf dem PC braucht Spiel XY viel weniger Speicher, der Amiga-Port ist so ineffizient programmiert“ – nein, das hat nichts mit ineffizient zu tun, sondern nur damit, dass der Amiga kein Memory-Mapping kann.

Das ist zum Beispiel der Grund, warum bei Gorky 17 128 MB RAM nicht reichen, während auf dem PC 64 MB genug sind. Gorky 17 verwendete massiv Memory-Mapping bei riesigen Files – und zwar so, dass „dann splitte sie einfach in mehrere kleinere Dateien auf“ nicht funktioniert hätte (das waren komprimierte Dateien 😉 ).

Alles mit Memory-Mapping muss man also ersetzen durch „Vogel friss oder stirb“ – Komplettladen. Oder man überlegt, ob es Alternativen gibt. Beim Musikabspielen in Siedler 2 habe ich z. B. eine Methode verwendet, bei der das Musikstück Stück für Stück geladen wird, in 1-KB-Häppchen. In dem Fall ging das als Alternative zum Memory-Mapping.

1. F) Wenn dann alles compiliert

Dann geht es ans Linken. Oft wird irgendeine Funktion verwendet, die es auf dem Amiga nicht gibt. Dann schreit der Linker. Das muss man dann ersetzen. Ist meistens eher eine Kleinigkeit, z. B. dass es auf dem Amiga stricmp heißt und auf dem PC strcasecmp, aber beide Funktionen exakt gleich funktionieren. Da muss man nur den Namen ersetzen.

1. G) Erster Start

CRASH. Bang. Dann muss man schauen: „Warum crasht es?“ Irgendwas stimmt noch nicht. Und wenn man ins Menü kommt: „Warum zum Geier reagiert er nicht auf meine Mausklicks?“ Oder: „Warum sehen die Menüeinträge im Game-Menü wie Random-Pixelmüll aus?“ So in der Art.

Hier beginnt die eigentliche Arbeit. Das Anpassen auf Amiga ist im Prinzip die Kleinigkeit – im Vergleich. Kann natürlich auch schon Wochen oder Monate dauern, je nachdem, wie das Spiel programmiert ist.

Meist sind Open-Source-Sachen einfacher zu portieren. Weil der Code „offen“ ist, schreiben die Programmierer ihn so, dass niemand denkt: „Was programmiert der denn für einen Mist?“ Zumindest meistens. Bei kommerziellen Produkten, wo nie jemand den Code sieht und wo Abgabetermine existieren, ist das manchmal anders. Natürlich legen auch viele „Chief Programmers“ Wert auf saubere Programmierung, damit alles besser wartbar ist. Gerade die Verwendung von C++ statt C ist da eine gute Maßnahme. Eine andere: Assembler zu verbieten.

Aber man kann auch in C++ Chaos verbreiten.

1. H) Es läuft soweit

Da sind wir dann immer noch Monate von der Release entfernt. Aus irgendwelchen Gründen crasht es in „Situation XY“. Oder es sieht komisch aus. Oder was auch immer.

Da passiert dann Betatesting und Bugfixing parallel (die Tester müssen die Bugs ja finden!!!). Und ab und zu muss man die Tester auch ermahnen: „Testen heißt nicht, dass ihr das Spiel startet und schaut, ob es im ersten Level läuft. Testen heißt, bei jeder Betaversion das Spiel von vorne ganz weit zu spielen. Und auch eure alten Spielstände nochmal zu probieren.“ Die Leute, die schon länger dabei sind, wissen das. Neue Tester oft nicht.

1. I) Optimierung
   (und dass es überhaupt mal auf AGA läuft – damit befasst man sich vorher noch nicht)

Da gab es Dinge wie:

• S2 unterschied nicht zwischen Logikframes und Grafikframes. Sprich: Wann immer in der Hauptschleife der Displaycode erreicht wird, wird ein neuer Frame generiert – also schneller, als der Monitor überhaupt kann. 200x pro Sekunde oder so. Auf langsamen Geräten hat das Video dadurch lahm gemacht, dass die FPS völlig eingebrochen sind. (Ein AmigaOne X1000 oder auch ein 68060 mit 100 MHz und Grafikkarte hatte weniger Probleme damit.) Das musste geändert werden. Sonst hätte am Ende „Mindestens 68060“ dabeigestanden.
• Die Soundmixing-Sache, die ich schon erwähnte.
• Input-Abfrage nicht so oft wie möglich – auch das bremste sicher 10 % oder so, beim Scrollen der Karte sogar noch mehr.
• Automatische Optimierung des Compilers (bringt nicht so viel wie Handoptimierung, aber sicher auch 10 %). Das Problem hier: die Ansicht „wir wollen auf maximale Geschwindigkeit und minimalen Speicher optimiert“. Nein, Leute, so funktioniert das nicht. Unrolling-Optimierung bedeutet schnellere Geschwindigkeit und höheren Speicherbedarf. Also muss man sich entscheiden zwischen wenig Speicher und hoher Geschwindigkeit. Oder einen Kompromiss. Da Lauffähigkeit mit 16 MB eh nicht geklappt hätte, bin ich auf maximale Geschwindigkeit gegangen. Nur eine -Ofast-Optimierung habe ich mich nicht getraut (destruktive Optimierung – kann auch Sachen kaputt machen, da hätte man den Betatest von vorne starten können). Vielleicht gibt es ja irgendwann ein Update mit -Ofast. Wobei: -Ofast im Vergleich zu -O3 (was ich genommen habe) bei einem reinen Integer-Math-Spiel nicht sooo viel bringt.
• Handoptimierungen an verschiedenen Stellen.
• Wie wird der Grafikspeicher kopiert? Wird da zu oft hin und her kopiert? (Jaaa, wurde. ^^) Und bei AGA kam dann konzeptionell noch ein c2p-Schritt dazu. Aber zu sagen „Ich bau den Bildschirm auf und mache DANN NOCH c2p“ ist blöd – dann wird ja alles quasi doppelt kopiert. Das habe ich so umgeschrieben, dass bei AGA der c2p das „normale Kopieren“ ersetzt.

Und sicher vieles weitere, was ich nun vergesse.

1. J) Amiga-spezielle Optimierungen

Dieser Schritt kommt oft bei einem reinen Amiga-Produkt. Das mussten wir hier weglassen, da der Lizenzgeber solche „Optimierungen“ sicher nicht akzeptiert hätte und wir vielleicht sogar die Lizenz riskiert hätten.

1. a) 640×256 statt 640×480

Sieht dann langgezogen aus. Ja, ich habe es nicht ganz weggelassen. Einfach mal:

echo „640“ >env:Settlers2/ResX

echo „256“ >env:Settlers2/ResY

Und schon rennt Siedler 2 in 640×256 ^^ (Es öffnet immer noch einen 640×480-Screen, da das Menü weiterhin in 640×480 laufen muss, aber es ist deutlich schneller als 640×480 auf AGA).

Ist halt seeeehr langgezogen. Man kann natürlich auch auf 400×300 oder 480×270 oder sowas gehen. Das ist sogar im Readme erwähnt. 640×256 habe ich nicht erwähnt, aber ich bin sicher, irgendein findiger Amiga-User wird drauf kommen, da einfach mal 640×256 einzugeben ^^
Hmmm, 550×256 sieht, finde ich, nicht so schlecht aus, auch wenn es dann Briefmarken-Siedler 2 ist. Vermutlich würde ich, wenn ich auf einem 060 wäre, entweder 320×256 oder 640×480 spielen ^^

1. b) 6-Bit-Display

64 Farben könnten einen Speedup bringen. Aber ich fürchte, das würde SEHR hässlich aussehen und vermutlich NIE an der QA von Ubisoft vorbeikommen. Habe ich daher gar nicht erst versucht.

1. c) 2×2-c2p-Modus

Dasselbe wie b ^^

Theoretisch könnte b) und c) ein findiger 68k-Programmierer immer noch machen. Der Screenrefresh steckt ja in dieser OpenSource-Bibliothek. Niemand hindert einen Programmierer daran, dort den Kalms-1×1-8-Bit-c2p rauszuschmeißen und etwa durch einen 2×2-c2p zu ersetzen …

1. K) Der Rest

Dann kommen Sachen wie Installer erstellen, Disk-Struktur des Masters, Dokumentation (auch Readmes im Spiel – dass etwa die Copyright-Message richtig ist, ist dem Lizenzgeber immer total wichtig).

AGF: Euch ist sicher klar, dass nur wenige Amiga-Nutzer diese Hardwareanforderungen erfüllen können.
Somit werden nur wenige das Spiel spielen können. Auf dem PC im Emulator wirkt es für manche irgendwie sinnfrei.
Wie steht ihr zu diesem Kritikpunkt, dass es „nicht mehr wirklich Amiga“ ist?
Welcher Grundgedanke steckt hinter diesem Projekt?

Steffen: Ist das so? Ich muss zugeben, nur wenige meiner Amiga-Bekanntschaften haben Amigas, die diese Anforderungen NICHT erfüllen können. 040er kenne ich da eigentlich nur als Dritt- oder Viert-Amiga. Aber ja, die Classic-Community ist sehr im Auftrieb. Und noch hat nicht jeder dort einen 040 oder höher, habe ich gehört (kenne ich dann aber nur vom Hörensagen – bei den Amiganern, die ich so kenne, hat jeder mindestens einen 060 oder Vampire oder AmigaOne/Sam oder PiStorm). Hoffe natürlich, dass auch hier in den nächsten Monaten die Leute upgraden.

Aber letzten Endes – „Das läuft nicht auf meinem Amiga“ hilft nicht, wenn der 68030 einfach zu langsam für dieses Spiel ist, selbst nach einem halben Jahr Optimierung. Was wollen diese Leute, die das sagen? Dass wir das Spiel canceln? (Nein, das machen wir nicht, keine Sorge.)
Der Optimierung ist zu verdanken, dass es auf AGA läuft. Dass es auf dem A1222 in höchster Auflösung läuft. Dass es auf dem 040 läuft. Dass es auf dem Vampire in 800×600 läuft (mit „läuft“ meine ich jeweils „flüssig läuft“).

Zum Thema, dass es kein „wirklicher Amiga“ mehr sei:
Für mich ist das kein Kritikpunkt, sondern pure Propaganda.

Ich glaube, das sollte jedem klar sein, dass eine solche Behauptung ziemlicher Unsinn ist. „Nur mein Amiga ist ein Amiga – 11elf“. Viel mehr sage ich da mal nicht dazu. Mal ganz ehrlich: Was soll es denn sonst sein, ein Atari ST? Glaube nicht …

Und ebenso ganz ehrlich: Wenn man mal so einen modernen Amiga ausprobiert hat – will man da noch was Anderes? 😉

Das sind gleich mehrere Dinge:
„Dem Amiga das Spiel zurückgeben, das ihm vorenthalten wurde.“
„Die Tür für weitere Amiga-Spieleports wieder weit öffnen.“
„Dem Amiga wieder etwas Bekanntheit auch außerhalb der Community geben.“
Und am wichtigsten: „Den Amiga-Usern ein Spiel geben, das ihnen Spaß macht.“

Natürlich wollen wir auch ein wenig Geld damit verdienen, klar 😉

Bei reinen Emulationslösungen sehe ich das aber ähnlich (PiStorm ist keine reine Emulationslösung, nur die CPU wird emuliert). Da ist zudem die Frage, wie viel Software solche User dann überhaupt kaufen. Unterstützen werde ich solche Lösungen natürlich. Ich verhindere Lauffähigkeit bei KEINER Plattform. Ich habe Siedler 2 sogar selber auf QEmu, Amiberry und UAE getestet.

Ich weise nochmal darauf hin: Amiga-User sind so wenige, alle Fraktionen müssen zusammenhalten. Sonst sind zukünftige Projekte ähnlich Siedler 2 nicht machbar.
Ich versuche, alle Amigas zu unterstützen – aber bei einzelnen Projekten gibt es dann manchmal eben Minimal-Anforderungen (etwa wurde der Vampire bei Gorky 17 und Siedler 2 unterstützt – bei Heretic 2 dagegen nicht. AGA wurde bei Siedler 2 unterstützt – bei Gorky 17 und Heretic 2 wiederum nicht).
Die ergeben sich aber immer spät im Projekt (nach Abschluss der Optimierung), was denn wirklich das Minimum ist. (Ich hatte übrigens vor langer Zeit eine WarpUP-AGA-Version von Heretic 2 – im HAM8-Modus –, die Performance war aber so schlecht, dass sie nicht released wurde. Sah außerdem etwas merkwürdig aus im HAM8 ^^).

Nico: Das ist eine Frage, die immer wieder aufkommt. Was bedeutet denn „wirklich Amiga“? Für mich war der Amiga immer ein 68k-basierter Computer, dessen große Stärke in seiner Erweiterbarkeit lag und liegt. Natürlich respektiere ich jeden, der unter „Amiga“ einen Standard-A500 versteht – das ist eine völlig legitime Sichtweise.

Gleichzeitig sollten wir uns daran erinnern, dass diese Haltung Mitte der 90er Jahre mit dazu beigetragen hat, dass Publisher den Amiga nach und nach verlassen haben. Viele Nutzer haben damals ihre Systeme nicht aufgerüstet und sich dann gewundert, warum moderne Spiele nicht mehr für den Amiga erschienen. Ein Teufelskreis.

Unser Grundgedanke ist einfach: Wir möchten zeigen, was mit dem Amiga möglich ist, wenn man seine Fähigkeiten voll ausschöpft. Die Siedler 2 für eine erweiterte Amiga-Konfiguration zu entwickeln, ist für uns genauso „Amiga“ wie Spiele für den Basis-A500. Es geht darum, diese wunderbare Plattform am Leben zu halten und zu zeigen, dass sie auch heute noch zu großartigen Dingen fähig ist.

Emulation ist übrigens natürlich ein wichtiger Teil der Amiga-Community, aber dieses Spiel ist nicht in erster Linie für User von WinUAE und Co. portiert worden.

AGF: Man könnte es auch als Beispiel sehen, wie es mit dem Amiga hätte weitergehen können.
Wie stellt ihr euch eine perfekte Weiterführung des Amiga-Systems vor?

Steffen: Ein Ende der endlosen Rechtsstreite vor allem. Ein Release von AmigaOS 4.2. Ein neues AmigaOS 3.3. Eine Möglichkeit, in PiStorm ARM-nativen Code auszuführen, vielleicht so ähnlich wie damals auf PPC mit ppc.library und WarpUP? Ein Release von PiStorm 3D. Weitere Spielelizenzen. Ein Release der Mirari-Hardware. Generell ein absolutes Ende der Streitereien zwischen verschiedenen AmigaOS-Fraktionen. Wir müssen alle zusammenhalten. Allein schafft es keiner.

Nico: Absolut, genau so sehe ich es auch! Technisch würde ich mir einen bezahlbaren, ARM-basierten Desktop-Computer mit einem kuratierten, modernisierten Open-Source-AmigaOS vorstellen. Das wäre ein moderner Ansatz, der die Amiga-Philosophie in die heutige Zeit trägt.

Noch wichtiger wäre mir aber, dass die verschiedenen Parteien in der Amiga-Welt endlich an einen Tisch kommen und gemeinsam an einer Lösung arbeiten. Jetzt ist noch Zeit dafür – die Community lebt und ist aktiv, aber es müssen die Weichen für die Zukunft gestellt werden. Die Zersplitterung schadet uns allen. Wenn wir die Kräfte bündeln würden, könnte der Amiga eine kleine Renaissance erleben.

Projekte wie unsere Siedler-2-Portierung sollen auch zeigen: Der Amiga ist nicht tot, er hat noch so viel Potenzial. Aber das können wir nur gemeinsam ausschöpfen.

AGF: Wer war alles am Projekt beteiligt?

Steffen:

• Programmierung: 100% ich (mit etwas Beratung und Debugging-Hilfe von Alexander Christoph, dem Autor der Mac-Version, und etwas Hilfe bei der Zusatzlib für WarpUP von siehe unten).
• Das dynamische Library-Loading auf AmigaOS 3.x WarpUP (das ist dieser Hack, um PPC-Karten in einem Classic Amiga zum Laufen zu bringen; Siedler 2 hat eine Spezialversion für diese Kisten – läuft dann auf einem Amiga 4000 oder Amiga 1200 mit 400 MHz PowerPC-Karte in 1024×768 flüssig): Dennis van der Boon (Autor der powerpc.library für G3/G4-Karten). Dennis hat mir auch geholfen, den gcc-Compiler für WarpUP zu installieren.
• Projektleiter: Simon Neumann
• Produzent: Nico Barbat
• Betatesting: Bill Borsari, Rene Engel, Arkadiusz Hucko, Paul Koster, Andreas Ochotta, Marc Schmidt, Sebastian Teichmann, Dennis van der Boon, Justin F. Webb, Kymon Zonias, Marton Imre Gaspar
• Erstellung der Icons: Martin „Mason“ Merz
• Design der Verpackung: Martin Cornelius
• Support von Seiten Ubisoft: Kay Bennemann

Arkadiusz hat außer Testing sich auch um die Konvertierung des Intros in verschiedene Formate und die Optimierung der Videofiles gekümmert (damit es auf allen Rechnern flüssig läuft).

Justin war mehr oder weniger der Betatesting-Lead (oder zusammen mit Arkadiusz). Marc war primär Tester für diverse 68k-Systeme (zusammen mit Simon).

Simon war derjenige, der die Amiga-Version als allererstes durchgespielt hat.

Übrigens: Dieser Bug in einer der letzten Missionen, der auf golem.de im Forum diskutiert wurde, tritt nur in der PC-Version auf. In der AmigaOS-Version tritt er nicht auf (gefixed). Generell enthält die AmigaOS-Version viele Bugfixes (die meisten davon allerdings schon in der MacOS-Version gefixed, die ja unser Ausgangspunkt war).

AGF: Warum war das Projekt so geheim? War es schwer, das durchzuhalten?

Steffen: Lasse ich mal Nico beantworten. Aber das hat auch seine Vorteile. Keine mögliche weitere Vaporware. Das Spiel ist fertig, der Betatest abgeschlossen. Release ist am 18. Oktober. Keine endlosen Verschiebungen. Leider musste ich etlichen Anfragen zur Teilnahme am Betatest eine Absage erteilen: „Der Betatest ist bereits abgeschlossen.“

Nico: Der Grund ist ganz einfach: Ich spreche nicht gerne über Projekte, solange nicht hundertprozentig feststeht, dass sie auch tatsächlich erscheinen werden. Die Amiga-Community hat in der Vergangenheit schon zu oft Enttäuschungen erleben müssen – das wollten wir unbedingt vermeiden.

Deshalb bin ich sehr dankbar für die Professionalität aller Beteiligten, die absolute Diskretion wahrten, bis das Projekt vertraglich abgesichert und wirklich spruchreif war – vom internen Kreis gemeinsam mit Ubisoft und weiteren Kooperationspartnern über die Externen wie Grafiker und Marketingleute bis zu den Betatestern. Ich bin sehr froh, dass nichts in die Öffentlichkeit gedrungen ist, bis wir endlich Nägel mit Köpfen machen konnten.

AGF: Das war es dann erstmal – danke für eure Zeit!

Steffen: Gerne.

Nico: Sehr gerne! Vielen Dank für euer Interesse. Wir hoffen, dass Die Siedler 2 der Amiga-Community viel Freude bereitet!

Interview:
Martin Becker
Steffen Häuser
Nico Barbat