Home Risen Risen Risen2 Forum English Russian
Login
Username: Passwort: angemeldet
bleiben:

Noch nicht registriert? Klicke hier
Shop Picture of the Moment
Screenshots
Live Ticker
Risen-Twitter-Ticker
Von Deep Silver betriebener Ticker auf Twitter.com zu Risen.

Neuster Eintrag:
RisenTicker: Zum Start ins Wochenende haben wir für euch noch ein kleines Video zusammengeschnitten. http://t.co/K5cTJP5A
Zum Ticker
Statistik
Zur Zeit sind 7 User online.
348 Besucher Heute
2.194 Klicks Heute
9.657.893 Besucher gesamt
49.782.874 Klicks gesamt

28.09.2009 09:55 [Test: Risen] Risen Test: 6. Technik
Risen Test: 1. Gameplay | Risen Test: 2. Story | Risen Test: 3. Bedienung | Risen Test: 4. Kampf | Risen Test: 5. Fazit | Risen Test: 6. Technik |

RISEN Test: Technik


Einführung

Worum geht es hier? In diesem Unterartikel werden wir unsere technische Analyse der Preview-Version von RISEN vorstellen. Das bezieht sich sowohl auf Leistungswerte wie auch auf Eigenschaften der Engine, Grafikfunktionen und Einstellungsmöglichkeiten (Detailgrad, etc.).

Wir haben uns bemüht, einen umfassenden Test vorzunehmen. Doch uns waren auch gewisse Grenzen gesetzt. So ist die Version, die wir erhalten haben, mit DRM gesichert und jeder von uns bekam nur eine einzige, nicht widerrufbare Aktivierung. Es konnte also jeder nur eine einzige Hardware- und Betriebssystemkonfiguration für RISEN freischalten. Damit fielen alle geplanten Tests mit diversen Grafikkarten und Prozessoren, die sich in unserem privaten Fundus noch hätten auftreiben lassen, ebenso ins Wasser wie eine Untersuchung der Frage, ob RISEN unter Linux/Wine oder Windows 7 problemlos läuft.

Testsysteme

Da wir vier Testversionen bekamen, hatten wir also nur vier Testsysteme zur Verfügung. Dies waren:

Komponente Don-Esteban foobar Jodob v000nix
CPU Intel Core Duo E6600 (2x2,4 GHz) AMD Phenom II X4 955 BE (4x3,2 GHz) Intel Core 2 Quad Q6600 (4x2,4 GHz) Intel Core 2 Duo T7250 (2x2,0 GHz)
Grafik ATI Radeon 1950 XTX NVidia GTX 260 NVidia GTX 285 NVidia 8400M GT (256MB, Shared Memory 1024MB)
RAM 2 GB DDR2-800 4 GB DDR2-1066 4 GB DDR2-800 2 GB DDR2
OS Windows XP 32bit (SP3) Windows XP 32bit (SP3, PAE) Windows Vista 32bit Windows Vista 32bit

Eigenschaften der Engine

Screen Space Ambient Occlusion (SSAO)

SSAO-Vergleich

Ein als Pixelshader implementiertes Verfahren zur besseren Darstellung von Schatten in Echtzeit, was eine Szene plastischer wirken lässt. Bei dem Verfahren wird berücksichtigt, dass Objekte in der Szene selbst den Lichteinfall von dahinter liegenden Objekten verdecken. Nachteile der Technik sind Blickwinkelabhängigkeit der Schatten, mögliches "Ausbluten" von Licht bzw. Schatten in Objekte hinein sowie ein schwacher Halo um Objekte herum.


High Dynamic Range Imaging (HDRI)

Eine Technik, bei der das Spiel intern mit mehr als den sonst üblichen 256 Helligkeitsstufen pro Farbkanal rechnet. Dadurch ist es möglich, Szenen mit hohem Dynamikumfang zu rendern, beispielsweise eine dunkle Höhle, durch deren Eingang helles Sonnenlicht einfällt. Normalerweise würde entweder der Eingang überstrahlen oder die dunklen Bereiche der Höhle im Schwarz absaufen. Mit HDRI kann beides erfasst werden. Natürlich erfolgt noch ein sogenanntes Tone-Mapping, bei dem das Bild wieder (möglichst optimal) auf den geringeren Dynamikumfang des Monitors herunter gebrochen wird. HDRI kann nur über die INI-Datei abgeschaltet werden und dann kommt es zu Darstellungsfehlern, insbesondere bei transparenten Objekten wie Fensterscheiben.


Volumetric Lighting

Strahlenbüschel

Bei dieser Technik wird der Lichtkegel in einer Szene als transparentes Objekt behandelt, das ein echtes Volumen hat (daher der Name). Entsprechend kann er die Eigenschaften der Objekte, die es schneidet, verändern. Damit lassen sich Strahlenbüschel simulieren, ein natürlich auftretender Effekt, auch als "Godrays" bezeichnet, der durch Trübungen in der Atmosphäre (z.B. Staubpartikel) hervor gerufen und bei Abschattung der Sonne (z.B. durch Wolken oder Vegetation) sichtbar gemacht wird.


Parallax Occlusion Mapping

Eine Technik, die es erlaubt, Texturen mit simulierten Höheninformationen zu versehen, ohne dabei wirklich neue Geometriedaten zu generieren. Dies geschieht mit einer sogenannten Displacement-Map, die die Höhenwerte kodiert.

Der technisch uninteressierte Spieler braucht nur zu wissen, dass mit dieser Technik alle Strukturen plastischer und tiefer wirken.


Speedtree

Die Darstellung der Vegetation erfolgt mittels Speedtree. Zwar drehen sich die Flächen bei den Bäumen und Sträuchern nach wie vor mit der Blickrichtung des Spielers, die Feinabstimmug ist dafür gut gelungen, sodass es selbst bei starkem Wind noch ansehnlich aussieht.


Zusätze: Anisotrophes Filtering / Antialiasing

Die anisotrope Filterung ist in den üblichen 2er-Potenzen bis zu 16 fach einstellbar und schärft vor allem Texturen mit schrägem Blickwinkel sehr stark.

Antialiasing ließ sich leider auf keinem der Testsysteme erzwingen, weder über die Einstellung in den Treibern (CCC bei ATI, Systemsteuerung bei NVidia), die Umbenennung der .exe, noch durch Zusatztools wie den NHancer bei NVidia-Karten. Auch das sogenannte Downsampling ließ sich nicht auf RISEN anwenden, da die Engine keine überdimensionierten Auflösungen akzeptierte.


Grafikoptionen

Das Spiel bietet über sein Menü folgende Einstellungsmöglichkeiten.

Einstellung Mögliche Werte Bemerkungen
Texturqualität Niedrig, Mittel, Hoch Niedriger aufgelöste Texturen können bei kleinem Grafikspeicher zu einer Beschleunigung führen.
Texturfilter Linear, 2xAF, 4xAF, 8xAF, 16xAF Lineare Texturfilterung verbraucht die wenigste Leistung, anisotrope Filterung sieht besser aus.
Schattendetails Aus, Niedrig, Mittel, Hoch Das Deaktivieren bzw. Herabstellen der Schattenqualität kann die Leistung auf schwächeren Systemen spürbar verbessern.
Vegetationsdetails Aus, Niedrig, Mittel, Hoch Beeinflusst die allgemeine Sichtweite der gesamten Vegetation. Eine Möglichkeit, Gras und Bäume getrennt zu regeln, existiert nicht.
Effektqualität Niedrig, Mittel, Hoch Wenn es bei "Spezialeffekten" wie auftretenden Staubwolken oder Zaubersprüchen ruckelt, kann man versuchen, hier zu drehen.
Sichtweite Niedrig, Mittel, Hoch Allgemeine Sichtweiteneinstellung; kann spürbaren Einfluss auf die Leistung haben
Tiefenunschärfe Aus, Ein Versieht entferntere Objekte mit einer deutlichen Unschärfe
Schaderqualität Niedrig, Mittel, Hoch Kann bei Grafikkarten mit geringer Shaderleistung interessant sein

Damit man sich die Auswirkungen der obigen Einstellungen besser vorstellen kann, haben wir ein paar Screenshots angefertigt. Dabei wurde die Tiefenunschärfe stets abgeschaltet, da man ja wissen möchte, wie sich die Einstellungen auf den Detailgrad der Welt auswirken und eine künstliche Kurzsichtigkeit hier kontraproduktiv wäre. Das verwendete System war ein AMD Phenom II X4 955 BE mit einer NVidia GTX260 Grafikkarte.

Screenshot Einstellungen Durchschnittliche Framerate
Niedrigst Alles auf "Niedrig", Schatten und Vegetation auf "Aus" 60 FPS*
Niedrig Alles (inkl. Schatten und Vegetation) auf "Niedrig" 60 FPS*
Mittel Alles auf "Mittel", 2xAF 52 FPS
Hoch Alles auf "Hoch", 4xAF 46 FPS
Höchste Alles auf "Hoch", 16xAF 39 FPS
* Durch vertikale Synchronisierung auf 60 FPS (Bildwiederholrate des TFT-Displays) begrenzt.

Benchmarks

Um die Leistungsfähigkeit der unterschiedlichen Testsysteme bei gleichen oder veränderten Einstellungen vergleichen zu können, haben wir folgenden Benchmark definiert: Bei sonnigem Wetter, um 12 Mittags, geht man eine bestimmte Strecke durch die Hafenstadt (von Dick zu Belschwur zu Sonja). Dieser Weg wurde gewählt, weil sich die Hafenstadt als besonders anspruchsvoll in Bezug auf die Systemleistung erwies.

Zunächst einmal eine allgemeine Übersicht über die Frameraten der verschiedenen Systeme. Dabei erfolgten die Testläufe stets bei einer Auflösung von 1280x1024. Zuerst bei maximalen Einstellungen:

System Minimale Framerate Maximale Framerate Durchschnittliche Framerate
Phenom II X4 955, GTX260 18 FPS 61 FPS 36 FPS
Core2Quad Q6600, GTX285 31 FPS 61 FPS 46 FPS
Core2Duo E6600, Radeon 1950XTX 12 FPS 46 FPS 18 FPS
Core2Duo T7250, GeForce 8400M GT abgebrochen, da nicht mehr als 3 FPS

Und hier zum Vergleich noch einmal die Werte bei minimalen Einstellen (gleiche Auflösung):

System Minimale Framerate Maximale Framerate Durchschnittliche Framerate
Phenom II X4 955, GTX260 46 FPS 61 FPS 58 FPS
Core2Quad Q6600, GTX285 38 FPS 62 FPS 52 FPS
Core2Duo E6600, Radeon 1950XTX 14 FPS 63 FPS 41 FPS
Core2Duo T7250, GeForce 8400M GT 8 FPS 24 FPS 15 FPS

Auffällig sind hier die teilweise starken Schwankungen der Framerate. Zum Teil liegt das an der gewählten Teststrecke, die in den Randbereichen der Stadt noch relativ unkompliziert ist und mit zunehmender Dichte an NPCs insbesondere die CPU stark belastet.

Die Ladezeiten erwiesen sich als sehr unterschiedlich. Bei der Größenordnung, in der die Zeiten lagen (jeweils über 30 Sekunden) genügte eine einfache Genauigkeit, wie man sie durch das manuelle Messen mit der Stoppuhr ermittelt. Natürlich waren für Messungen die Virenscanner und sonstige I/O-lastige Hintergrundprogramme deaktiviert.

System Zeit für Programmstart* Zeit zum Laden eines Spielstandes
Phenom II X4 955, GTX260 37 Sekunden 17 Sekunden
Core2Quad Q6600, GTX285 63 Sekunden 24 Sekunden
Core2Duo E6600, Radeon 1950XTX 83 Sekunden Keine Messung
Core2Duo T7250, GeForce 8400M GT 100 Sekunden 43 Sekunden
* gemessen vom Aufruf der EXE-Datei bis zum Erscheinen des Hauptmenüs bei deaktivierten Logo-Videos.

Am Besten schnitt hier das Phenom-System ab. Die 1-TB-SATA-Platte lieferte allerdings auch ideale Voraussetzungen: Betrieb im AHCI-Modus, 7.400 U/min, kein Akustikmanagement, hohe Datendichte der Scheiben, frisch defragmentiert. Lediglich mit einem RAID 0, das den Durchsatz auf Kosten der Datensicherheit erhöht, mit schnellen SAS-Platten oder mit einer RAM-Disk sollten sich hier noch deutliche Verbesserungen erzielen lassen.

Detaillierte Lastanalyse

Eine häufige Frage ist, ob RISEN eher die CPU oder die GPU belastet und wie gut es von CPUs mit mehreren Kernen profitiert. Wir haben dies anhand des Testsystems mit den größten Schwankungen in der Framerate, dem Phenom II X4 955, genauer untersucht.

I/O-Last (Streaming)

Als vergleichsweise typisch erweist sich das Streaming. Beim ersten Durchlauf fällt erwartungsgemäß viel I/O-Last an, wie man dem linken Diagramm entnehmen kann. Alle Daten müssen von der Festplatte in den Arbeitsspeicher geladen werden, was sich auch in stärkeren Rucklern während des Spiel äußert. Das betreffende System verfügte übrigens über eine frisch defragmentierte SATA-Festplatte mit 7.400 U/min, die im AHCI-Modus mit NCQ betrieben wurde.


Wie man auf dem rechten Bild sieht, reduziert sich diese Last jedoch beim zweiten Durchlauf drastisch. Somit dürfte man lediglich beim Betreten neuer Gebiete (insbesodere durch Teleportation) mit Rucklern aufgrund von Streaming zu kämpfen haben. Während man sich dann in diesen Gebieten bewegt, kommt alles aus dem Cache und die gefürchteten Nachladeruckler entfallen weitgehend.


Grafikleistung

Um den Einfluss der Grafikkarte auf die Framerate zu bestimmen, haben wir auf dem Testsystem schrittweise die Auflösung reduziert (stets mit maximalen Details) und die resultierenden Frameraten gemessen.

Auflösung Minimale Framerate Maximale Framerate Durchschnittliche Framerate
1280x1024 19 FPS 61 FPS 38 FPS
1024x786 25 FPS 61 FPS 37 FPS
800x600 28 FPS 61 FPS 41 FPS

Wäre die Grafikkarte im Testsystem der limitierende Faktor, hätte man einen deutlichen Gewinn durch die verringerte Auflösung messen müssen. Tatsächlich jedoch hat sich kaum etwas geändert. Auf 800x600 ist die zu berechnende Pixelmenge nur noch 36% der ursprünglichen Auflösung von 1280x1024, doch der durchschnittliche Gewinn liegt bei gerade einmal 3 FPS. Lediglich bei der minimalen Framerate hat sich eine kleine Verbesserung von 9 FPS ergeben, die in manchen Fällen den Unterschied zwischen "spielbar" und "nicht spielbar" ausmachen kann.

CPU-Belastung

Kommen wir zum letzten verbleibenden Flaschenhals, der CPU. Im linken Diagramm sehen wir, dass sich die Last des Spiel nicht gleichmäßig auf die zur Verfügung stehenden Kerne verteilt. Ein einzelner Kern trägt die Hauptlast des Programms, die anderen Kerne langweilen sich größtenteils bei einer Auslastung, die nicht über 50% klettert. Zudem liegt der Hauptthread stets nahe am Vollausschlag. Der Kern, auf dem dieser Thread läuft, ist beinahe überlastet, was man auch an den immer wieder auftretenden Ausschlägen in der Warteschlange (weiße Linie) sehen kann. Obwohl jeder Kern des Phenom-Prozessors mit 3,2 GHz läuft, erweist sich also der Hauptprozessor als Ursache für die teilweise recht niedrige Framerate bei max. Einstellungen.

Der Intel-Quad-Prozessor, der trotz langsamerer Taktung in etwa ein vergleichbares Leistungsniveau hat, erweist sich im anderen Testsystem als etwas weniger problematisch. Dies könnte allerdings auch an der leicht stärkeren Grafikkarte liegen.


Kern-Nutzung

Um unsere Vermutung, dass RISEN keine signifikante Optimierung für Vierkernprozessoren aufweist, zu überprüfen, haben wir in einem weiteren Test die Anzahl der Kerne reduziert, auf denen RISEN laufen durfte. Erkennbar ist, dass beim Übergang von einem auf zwei Kerne tatsächlich ein Performancegewinn sicht- und spürbar wird. Danach erfolgt jedoch keine merkliche Änderung mehr, die Unterschiede liegen im Bereich der Messungenauigkeit.

RISEN erweist sich somit als eher "Quad-untauglich".


PhysX-Probleme

Erstaunliche Ergebnisse erhielten wir, als wir der Frage nachgingen, ob - und wenn ja, wie - sich die GPU-Beschleunigung von PhysX-Berechnungen bei NVidia-Grafikchips auf die Performance auswirkt. Wir hatten erwartet, dass die GPU-Beschleunigung entweder keinen Effekt hätte, weil RISEN sie nicht nutzt, oder, dass sie die CPU spürbar entlastet (was ja der Sinn von PhysX-Berechnungen auf der GPU ist).

Tatsächlich jedoch offenbarten unsere Tests einen leichten Verlust, wenn man die GPU-Beschleunigung für NVidia-Chips aktiviert. Das Mainboard des Phenom-Testsystems hatte einen Onboard-Grafikchip von NVidia. Da dieser eigentlich nicht verwendet wurde, lag es nahe, PhysX-Berechnungen dorthin auszulagern und so sowohl CPU als auch Grafikkarte zu entlasten. Dies erwies sich aber als kontraproduktiv. Wie man dem Diagramm entnehmen kann, kam es bei dieser Einstellung zu Einbrüchen bis auf 19 FPS (siehe auch obigen Leistungsvergleich der Testsysteme).


Auch in der CPU-Auslastung spiegelt sich dies wieder. Wenn man PhysX in der NVidia-Systemsteuerung komplett deaktiviert, dann geht die Belastung des tragenden CPU-Kerns deutlich zurück (wenngleich sie immer noch recht hoch ist).

Paradoxerweise führt also die Verwendung von PhysX-GPU-Beschleunigung, die die CPU eigentlich entlasten sollte, zu einer zusätzlichen Belastung für den einen, ohnehin übermäßig belasteten Thread. Wer PhysX komplett abschaltet, kann also ein paar FPS damit gewinnen.


RAM-Belastung

Gerade rückblickend auf Gothic 3 und seinen für damalige Verhältnisse großen Hunger auf Arbeitsspeicher, ist die Frage interessant, wie RISEN sich denn in diesem Bereich verhält.

Erwartungsgemäß (schließlich ist die Welt nun viel kleiner) verhält sich das Spiel hier unauffällig. Der Verbrauch an Arbeitsspeicher klettert nicht über 1 GB.


Systemempfehlungen

Wie sieht er also aus, der "optimale" PC für RISEN? In eine Systemkonfiguration spielen viele unterschiedliche Faktoren hinein und nicht zuletzt ist manches auch subjektiv. Don-Esteban war beispielsweise selbst davon überrascht, dass ihm die ca. 17 FPS seines Systems als "ausreichend flüssig" erschienen. Aber wenn man unsere Ergebnisse zugrunde legt, lassen sich einige allgemeine Empfehlungen aussprechen.

Grafikkarte

Hier muss man eigentlich nichts besonderes beachten. Wenn die vorhandene bzw. für den Kauf angepeilte Karte die Spiele der letzten zwei Jahre auf der gewünschten Auflösung ansehlich darstellen kann, dann sollte sie auch mit RISEN kein Problem haben.

Insbesondere ist es egal, ob man ATI oder NVidia nimmt. RISEN verwendet zwar die PhysX-API für physikalische Berechnungen, aber die "Beschleunigung", die NVidia-Karten hier anbieten, kann man getrost abstellen. ATI-Besitzer, die RISEN mit GPU-beschleunigtem PhysX simulieren wollen, können beim Spielen ja nebenher Prime95 laufen lassen.

Arbeitsspeicher

RISEN bleibt unter 1GB, dazu kommt noch das System selbst. Wer also die heute üblichen 2 GB hat, ist ausreichend bedient. Mehr Speicher schadet nicht, bringt aber auch keine Vorteile.

Es sei denn natürlich, man plant, RISEN bei jedem Hochfahren in eine RAM-Disk zu kopieren und dann von dort zu spielen, um die Streaming-Ruckler vollständig zu eliminieren.

CPU

Wer hier budgetbedingt die Wahl zwischen einem höher getakteten Zweikern-Prozessor und einem gleich teuren, aber langsamer getakteten Vierkerner hat, dem sei der Zweikerner angeraten. RISEN erweist sich (in diesem Fall muss man "leider" sagen) als Spiel alter Schule und profitiert eher von GHz als von Kernen. Intel oder AMD dürften kaum eine Rolle spielen. In der Kombination aus CPU und passendem Mainboard scheinen die Leistungen pro Euro in etwa vergleichbar zu sein. Wer allerdings nicht nur auf RISEN schielt, der möchte vielleicht für andere Anwendungen bzw. Spiele dennoch auf einen Vierkern-Prozessor setzen.

Fein raus ist natürlich, wer sich einen Core i5/i7 leisten kann, der mit seinem eingebauten Turbo-Boost die Taktfrequenz einzelner Kerne hochfahren kann, wenn andere dafür unausgelastet bleiben.

Dateisystem

RISEN legt in seinem Installationsverzeichnis zwei Unterverzeichnisse an: "bin" und "data". Ersteres enthält Binärcode (also die EXE und DLLs), letzteres die PAKs mit den Spieldaten sowie einige INIs und Videos. In den INI-Dateien kann man Logovideos deaktivieren, am LOD schrauben und einige Einstellungen zur Physik (Kollisionsgruppen) verändern.

Spielstände landen bei XP in der Standardeinstellung unter %userprofile%\Eigene Dateien\Risen\SaveGames, was sich aber in der Registry unter HKCU\Software\Deep Silver\Risen umändern lässt. Unter Vista lautet der Pfad: %userprofile%\Saved Games\Risen\SaveGames

Screenshots werden in einem eigenen Verzeichnis unter %userprofile%\Lokale Einstellungen\Anwendungsdaten\Risen abgelegt, wo übrigens auch die benutzerspezifischen Konfigurationsdateien (ganz modern als XML) deponiert werden.


Streamingsystem / LOD

In RISEN gibt es abgesehen vom Spielstart und beim Teleportieren keine Ladebalken. Die Welt ist dank eines Streamingverfahrens frei erkundbar. Die benötigten Texturen und Modelle werden je nach Bedarf nachgeladen. Das zum Einsatz kommende LOD (Level of Detail), sprich die Distanzdarstellung, erfolgt ähnlich wie in G3: Ab einer gewissen Entfernung werden die Texturen gegen eine niedriger aufgelöste Version ausgetauscht, Objekte werden zu 2D Grafiken. Der Übergang ist in Risen bei den Modellen und Umgebungstexturen ist sehr harmonisch und fällt kaum auf (im Gegensatz zur "Trennlinie" aus G3). Bei der Distanzdarstellung der Vegetation ist das Ergebnis nicht ganz so überzeugend, da die Billboards (2D Elemente) vor allem bei Sträuchern und einigen Bäumen sehr niedrig aufgelöst sind und dadurch ins Auge fallen. Die Tiefenunschärfe in Risen fügt sich besser in das Gesamtbild ein als bei G3. Die Performance ist bei allen 3 Systemen bei entsprechenden Settings ausreichend, selbst der Laptop kommt mit den niedrigsten Settings gut aus, und entspricht somit den Minimalanforderungen. Unvermeidbar bei der Streamingtechnik sind Einbrüche in der Framerate beim Nachladen neuer Bereiche. Wer bei den Frameraten keine bequeme Sicherheitsspanne hat, kann diese Einbrüche durchaus als Ruckler wahrnehmen. Sie sind jedoch nicht mehr so extrem wie beispielsweise bei Gothic 3. Es wurden einige Optimierungen in die Engine eingebaut, die das Problem der Nachladeruckler spürbar entschärfen - wenn auch nicht ganz beseitigen.


Physik

Die Physikdarstellung kommt vor allem beim Kampf zum Einsatz, wenn der Gegner das Zeitliche segnet. Die Sterbeanimationen wirken größtenteils realistisch, die Wackelpuddingleichen aus G3 sind Geschichte. Dafür sind die Flugeigenschaften von getroffenen Gegnern teils etwas zu gut. So fliegt ein Wolf je nach Finishing Move bis zu 20 Meter weit oder er rutscht noch ein wenig zu lange über den Boden.


Animationen

Die Animationen sind in RISEN ausschließlich von Hand erstellt, es kam kein MoCap oder ähnliches zum Einsatz. Inwiefern dies ein Vor- oder Nachteil war, zeigt sich im folgenden:

Ein besonderes Highlight sind die Animationen im Kampf. Durch die unterschiedlichen Skillstufen ziehen sich komplett andere Bewegungen, die immer ausgereifter und flüssiger werden. Ansonsten fallen viele Details auf, so zum Beispiel die Bewegung der Schnauze bei den grunzenden Wildschweinen oder generell die Schlaf- und Aufwachanimationen der Tiere. Gnome nehmen mit wackelnden Nüstern Witterung auf und wackeln mit den Zehen, wenn sie vor dem Lagerfeuer sitzen.

Weniger gut sind die Animationen der NPCs in Gesprächen. Zwar sind auch dort Details vorhanden wie animierte Finger, allerdings ist das Gesamtreportoire sehr begrenzt, sodass hier sehr viele Wiederholungen vorkommen. Individuelle Animationen sind sehr selten, Gefühlsausdrücke auf den Gesichtern Mangelware. Auch die Sprunganimationen wirken etwas hölzen. Der Held macht beim normalen Springen keine Hechtrolle mehr, wenn er Akrobatik gelernt hat. Dafür rollt er sich aber ab, wenn er aus größerer Höhe hinunter springt oder (falls er noch ungelenkig ist) fängt sich mit einer Hand am Boden ab.


KI / Verhalten

Was die NPCs angeht, so sind viele Techniken aus Gothic 1 und 2 wieder zum Einsatz gekommen. So bemerken die NPCs einen Diebstahl immer nur dann, wenn ein Sichtkontakt besteht, nicht wie in G3 automatisch nach einer bestimmten Diebstahlrate. Für Diebe bietet RISEN also wieder viel Arbeit (was besonders in Kombination mit den von Hand gefüllten Truhen sehr viel Spaß macht).

Auch bei gezogener Waffe erfolgen wieder entsprechende Reaktionen. Dabei reagieren auch NPCs der verschiedenen Fraktionen entsprechend aufeinander. Neu ist, dass die NPCs die meisten Tricks des Helden beherrschen, somit kann man nicht einfach wie früher immer auf ein Dach klettern und die Feinde aus sicherer Entfernung bekämpfen, nein, ab und zu klettern und springen diese einem einfach hinterher! Wird man beim Diebstahl erwischt und vom Hausbesitzer niedergeschlagen, zeigt sich aber das seltsame Bild, dass dieser den Helden nicht ausplündert (weder dessen Gold noch die gstohlenen Güter). Statt dessen kommt ein wildfremder NPC von der Straße hinein und bedient sich an unserem Gold.

Das Übernachten in fremden Betten ist von NPC zu NPC unterschiedlich, so findet man in der Gosse der Hafenstadt stets eine Übernachtungsmöglichkeit, wohingegen in anderen Gebieten des öfteren ein "Raus aus meinem Bett!" zu hören ist. Eine weitere Variable dabei spielt der Zustand des Helden. Ein gesunder Held bekommt weitaus öfter eine Absage erteilt als ein Held, der nur noch wenige Lebenspunkte hat.

Das Verhalten der verschiedenen Figuren scheint sich vor allem an der Mitgliedschaft zu Gilden und bereits gelösten Quests zu orientieren. Die effektive Kampfstärke des Helden spielt offenbar keine Rolle. Cheatet man einen Helden auf Level 40 mit 200 Stärke, Schwertkampfstufe 10, Hauptmannsrüstung und Dämonenklinge, wird er immer noch vom ärmsten, nur mit einem Knüppel bewaffneten Bauern der Stadt bedroht, wenn er seine Waffe zieht. Diese Situation dürfte natürlich bei normaler Spielweise auch nie vorkommen. Erringt man die o.g. Fähigkeiten und Ausrüstung im normalen Verlauf des Spiels, dann stören sich selbst gestandene Stadtwachen und Ordenskrieger nicht mehr daran, dass man mit gezogenem Schwert herum läuft.

Offensichtliche KI-Probleme, beispielsweise bei der Wegfindung, sind uns kaum untergekommen. Es kam ein paar Mal vor, dass sich ein Gegner ohne Gegenwehr aus einer Ecke heraus mit dem Bogen oder Magie beschießen lies. Das waren jedoch vereinzelte Ausnahmen.


Steuerung

Bei der Steuerung mit Maus und Tastatur gibt sich RISEN kaum Blößen. Dass die Kampfkontrollen auf der Maus und nicht der Tastatur liegen, führt beim Anfänger fast unweigerlich zum Dauerklicken. Das muss man sich erst mühsam abgewöhnen, da es einen (außer bei den ersten, leichten Gegnern) nicht weiter bringt. Dennoch besteht die Gefahr, in einer hektischen Situation wieder ins Geklicke zu verfallen. An sich reagiert der Held jedoch präzise auf die Befehle, die der Spieler ihm gibt. Gelegentliche Verzögerungen, beispielsweise beim Wegstecken der Waffe, sind gewöhnungsbedürftig. Man denkt, der Befehl sei nicht angekommen und wiederholt ihn. In der Folge steckt der Held kurz darauf die Waffe weg und zieht sie sofort wieder.

Eine komplette Steuerung mit nur der Tastatur ist nicht möglich. Im Inventar kann man zwar mit den Pfeiltasten durch die Gegenstände blättern (wobei der Held gleichzeitig auch entsprechende Bewegungen macht, man also aufpassen muss, dass man ihn nicht versehentlich eine Schlucht hinunter stürzen lässt). Es fehlt jedoch an einer Möglichkeit, den ausgewählten Gegenstand auch zu benutzen. Hier scheint nur die linke Maustaste möglich zu sein. Ebenso fehlt es an Tasten, um den Neigungswinkel der Kamera zu verstellen (siehe auch den nebenstehenden Screenshot mit der kompletten Tastenbelegung). Dies ist ebenfalls nur mit der Maus möglich. Wer eine reine Tastatursteuerung bevorzugt, kann höchstens versuchen, mit einem externem Action-Mapping (bspw. mit AutoHotkey) die fehlenden Funktionen nachzurüsten.

Manche Tasten konnten wir nicht umbelegen und mussten mit der Vorgabe arbeiten. Im Screenshot erkennt man diese Tasten an dem eingerasteten Schloss. Aus welchem Grund die Tasten für Schnellladen und Schnellspeichern nicht änderbar direkt nebeneinander lagen, verschloss sich uns im Test. Es kam durchaus vor, dass wir mal daneben langten und einen alten Spielstand luden anstatt den gerade mühsam errungenen zu speichern.

Ebenfalls ist es nicht möglich, mit den zugewiesenen Richtungstasten (z.B. WASD) oder dem Mausrad in Dialogen eine Option auszuwählen. Dies funktioniert nur mit den Pfeiltasten und ENTER. Wer mit WASD arbeitet, muss hierzu umgreifen, was die Sache uninteressant machen dürfte.

Wettersystem

Besonderes Lob verdient das dynamische Wettersystem. Es gibt viele verschiedene Wettersettings, die ja nach Tageszeit die gesamte Stimmung des Bildes verändern können. Ist der Wald einmal sonnendurchflutet und hell, kann er bei einem nächtlichen Gewittersturm zu einer rabenschwarzen Dunkelheit verkommen, die nur von gelegentlichen Blitzen aufgehellt wird. Bei Gewittern werden die Wolken von Wetterleuchten erhellt und wenn es neblig ist, wirkt alles trübe und grau. Da der Himmel mit den Wolken keine einfache Textur ist, sondern prozedural berechnet wird, dürfte man kaum jemals zweimal die exakt gleiche Wolkenformation im Spiel vorfinden.

Wir haben ein paar Screenshots zusammengestellt, die eine Auswahl der unterschiedlichen Wettersetting (stets am selben Ort) zeigen.

Musiksystem / Sound

Die Übergänge von einer "Musikzone" zu einer anderen überlappen sich nun, so dass man nicht mehr ständige Wechsel in der Hintergrundmusik hört, nur weil man zufällig genau auf der unsichtbaren Grenzlinie entlang läuft. Hier sei als Beispiel einmal der Übergang in das Banditenlager genannt. Den Sumpf betritt man über einen Steg und jeweils an dessen Ende wechselt erst die Musik. Man betritt den Steg also zu "The Island" und erst, wenn man ihn verlässt, wechselt die Musik zu "Don Camp". Dreht man sich nun um und geht zurück, begleitet einen "Don Camp" wieder den ganzen Steg entlang. Erst am anderem Ende wechselt die Musik zurück zu "The Island". Zudem gibt es definierte Übergangsklänge zwischen den einzelnen Musikstücken, die den Wechsel sehr gut kaschieren.

Hinweis: Auf dem nebenstehenden Screenshots haben wir die Übergangszone zum Zwecke der vereinfachten Darstellung auf den Steg begrenzt. Natürlich funktioniert es auch, wenn man abseits des Pfades durch den Schlamm stiefelt.

Auch an den sonstigen Umgebungsgeräuschen gibt es wenig auszusetzen. Und ja, auch Wasserfälle haben diesmal einen Klang spendiert bekommen. EAX unterstützt RISEN nicht, was allerdings kaum ein Spiel der letzten zwei Jahre macht. Die Lautsprecherkonfiguration übernimmt das Spiel aus der Systemsteuerung, aber ob echte Unterstützung von 5.1- oder 7.1-Surround-Systemen vorhanden ist, konnten wir nicht testen, da uns die dafür nötige Hardware fehlte.






  geschrieben von foobar