Pixelor

Zitat von »henrikf«

gleich mehrere MiB für eine Textur fällig.

Da isses wieder .

Zitat von »henrikf«

Dieses Thema mit den Mega-Texturen ... jaaaah, OK ... wenn da eine Textur ausgetauscht werden muss, dann sind natürlich immer gleich mehrere MiB für eine Textur fällig. Aber müssen die Texturen denn ausgetauscht werden? Ist es nicht oftmals auch eher das Programm, das Zicken macht? Noch nicht einmal die Engine? Es kann natürlich sein, dass die im Patch 1.08 eine ganze Menge geändert haben, nicht nur im Programm. Aber fast alle Texturen? Fast das das ganze Programm?

Für mich klingt das nach wie vor eher nachlässig.

Ich weiß nicht warum Patches manchmal riesig und manchmal klein sind. Klar ist das bei heutigen Spielen eine kleine Änderung im Code einen riesigen Rattenschwanz an anderen Sachen nach sich ziehen können. Man sehe sich doch mal den Source Code von z.B. Doom 3 BFG an. Unzählige einzelne Files, manche mit mehreren tausend Zeilen Code die alle ineinander greifen. Man kann bei der Entwicklung vieles beachten und auch einiges Sachen so gestalten das spätere Patches relativ leicht und zügig implementiert werden können, aber man kann halt nicht alles beachten.

Die meisten Spielehersteller machen solche riesigen Patches nicht mir Absicht. Manche Änderungen, egal wie klein die vielleicht sind, können halt nicht in 2 MiB gepackt werden. Viele Patches fixen auch Probleme die der Spieler nicht im Spiel sieht, oder auch nicht in den Patchnotes stehen. z.B. kann ja die Positionsangabe des Spielers wenn er an einer bestimmten Ecke steht und zweimal hintereinander zu schnell die Space Taste gedrückt hat, ein Teil der Texturen nicht mehr hinter einer Tür geladen werden. Trifft aber nur auf den Spieler zu der eine Nvidia 970, eine AMD CPU und im Level vorher ein Monster in den Kopf geschossen hat nachdem er eine Kiste geöffnet hat... Dann muss evtl. die Logik im Code getauscht werden, vielleicht ist die Logik in der Kiste ein Problem. Vielleicht müssen sie die Kiste entfernen, dazu die Texturen anpassen... Es gibt unendlich viele Dinge die bei komplexen Dingen schief gehen können.

Manche Patches bereiten auch einige Sachen für eine Erweiterung vor. Da müssen dann auch einige Sachen entfernt, hinzugefügt, etc. werden. Davon bekommt der Spieler erst einmal nichts mit und so etwas wird meistens auch nicht in den Patchnotes erwähnt.

Übrigens hat Gamasutra vor einen Tagen den Lead Programmer von Skyrim interviewed. Dort erzählt er auch von einem Bug in Fallout 3 (ab 31:50 im Video) der erst weit nach dem Release entdeckt wurde. Und zwar wenn man Megaton in die Luft gejagt hatte, lag da ein Roboterkopf den man mitnehmen konnte, und durch die gesamte Welt tragen konnte. Welches dann urplötzlich die Frames runtergezogen hat. Es lag daran das der Kopf nicht mehr beim Körper war, die Physik die die Körper berechnet war dadurch dann auch überlastet und sorgte dann auch für miese Performance.

Übrigens erwähnt er in dem Interview auch was ich weiter oben mit der Vorbereitung des Spiels für spätere Erweiterungen geschrieben habe. In Skyrim zum Beispiel ist alles was man sieht fertig modelliert. Das heißt die Häuser sind komplett, sie haben alle ein Dach auf dem man stehen könnte. In früheren Spielen waren Häuser nur teilweise fertig, also ohne Dach, oder ohne der Kollisionsabfrage, Es sollte nur so aussehen das dort ein fertiges Haus oder Burg stand. Wenn man aber dann eine Erweiterung rausgebracht at, bei der man z.B. Fliegen konnte, mussten extra Texturen, Kollisionsabfragen, etc. hinzugefügt werden, welches eine Patch oder die Erweiterung an sich, wieder vergrößerte.

Was ich damit sagen will, ist eigentlich nur das es sehr viele Gründe gibt warum manche Sachen so sind wie sie sind. Da wird vieles nicht mit Absicht gemacht. Der Hersteller macht so etwas auch garantiert nicht aus Jux und Dollerei.

Alles was Du schreibst ist richtig. Genau dessen sind sich Software-Entwickler bewusst, seitdem es so etwas wie Software-Entwicklung überhaupt gibt. Das Problem ist also ein uraltes. Deswegen hat die Software-Industrie einige Methoden entwickelt, um dem Wust und dem Chaos in Programmen Herr zu werden. Dazu gehört zum Beispiel das sog. »Test Driven Development«. Da programmiert man zusätzlich für alle Komponenten außerdem sog. »Unit Tests«, um so eben schnell sehen zu können, ob eine Komponente funktioniert oder nicht. Diese Vorgehensweise mit den »Unit Tests« hat den unglaublich genialen Vorteil, dass man schnell merkt, ob man eine Komponente überhaupt testen kann. Denn wenn man merkt, dass man einen »Unit Test« für eine Komponente irgendwie nicht gebacken bekommt, dann deutet das darauf hin, dass man schon bei der Komponente an sich irgendwo einen Denkfehler eingebaut hat. Du glaubst gar nicht, wie viele Software-Fehler man alleine schon dadurch vermeiden kann.

Damit man Komponenten aber wieder testen kann, unterteilt man eine Komponente in möglichst kleine Unterkomponenten, deren mögliche Test-Variablen möglichst klein ist. Das nennt man dann wieder »Refactoring«, die man zum Beispiel mittels der »Objekt-Orientierten Programmierung« hervorragend umsetzen kann.

Und im Team organisiert man sich dann mit Hilfe von »Agilen Methoden«. Das ist zum Beispiel ein »Vier Augen Prinzip«: Das sind Zwei-Mann-Teams, wobei einer programmiert und der zweite sieht sich den Code an und macht Verbesserungsvorschläge. Natürlich wechselt man sich ab und/oder programmiert parallel. Oder »Scrum«, das auf ein sich selbst organisierendes Team mit Hilfe eines »Scrum Masters« setzt, der sich NICHT - ganz wichtig! - um das Projekt an sich kümmert, sondern für die Software-Entwickler da ist. Von Scrum bin ich selber allerdings kein Fan, weil das auch hervorragend als Mobbing-Tool gegen die Software-Entwickler eingesetzt werden kann.

Und es gibt so etwas wie »Continuos Deployment/Delivery«, um nämlich die Zeiten zwischen den Patches kurz zu halten. Man wartet also nicht, bis man, sagen wir, 20 Fehler bearbeitet hat, sondern liefert nach jedem einzelnen Fehler den Patch auch aus. Damit das geht, wird eben genau nicht das ganze Projekt immer wieder neu installiert, sondern die Software wird in Komponenten aufgeteilt, die klein und handlich sind. Also genau das Gegenteil von dem, was Spiele-Entwickler machen.

Es gibt ohne Ende Ansätze, direkt auf der Programmierebene, auf der Algorithmen-Ebene und auf der Team-Ebene, damit das ganze nicht in Chaos ausartet. Natürlich kann man nicht alles erschlagen. Das größte Problem ist aber meistens, dass sich die Anforderungen während der Entwicklung ändern. Evtl. weil neue Features hinzu kommen sind, oder die ursprünglich gewünschten, programmierten und getesteten Features sind gar nicht praxisrelevant (ist bei meinem Projekten die Regel, dass dem Kunden kurz vor Schluss einfällt, alles anders machen zu wollen). Aber auch da helfen die oben genannten Methoden.

Wenn da ein Software-Entwickler von Bethesda (die werden mir sowieso gerade unsympathisch) sagt, dass ein aufgehobener Kopf - den man eigentlich sowieso nicht aufheben können sollte - die Framerate einbrechen lässt, weil die Physik-Engine die ganze Zeit aktiv ist ... dann fehlen da einfach Unit-Tests oder die wurden nicht durchgeführt. Das »riecht« für mich einfach nach Pfusch in der Entwicklung.

Und das ist wiederum klar, denn wenn man sich ansieht, wie Entwicklungs-Teams von großen Software-Firmen einfach mal so aufgelöst werden, dann hält sich die Motivation richtig gute Arbeit abzuliefern, vermutlich in Grenzen. Oder der Druck wird zu groß. Denn diese Methoden brauchen allesamt vor allem eines: Zeit. Und damit kosten sie Geld.

Zitat von »henrikf«

Dazu gehört zum Beispiel das sog. »Test Driven Development«. Da programmiert man zusätzlich für alle Komponenten außerdem sog. »Unit Tests«, um so eben schnell sehen zu können, ob eine Komponente funktioniert oder nicht. Diese Vorgehensweise mit den »Unit Tests« hat den unglaublich genialen Vorteil, dass man schnell merkt, ob man eine Komponente überhaupt testen kann. Denn wenn man merkt, dass man einen »Unit Test« für eine Komponente irgendwie nicht gebacken bekommt, dann deutet das darauf hin, dass man schon bei der Komponente an sich irgendwo einen Denkfehler eingebaut hat

Streng genommen, werden beim "Test Driven Development" zuerst die Tests geschrieben, die erst einmal fehlschlagen. Wird die Funktion richtig implementiert, geht der Test auf "Passed". So die Theorie. In der Praxis gibt es natürlich auch fehlerhafte Unit-Tests

Ein Unit-Test allein ist leider nicht ausreichend, vor allem dann nicht, wenn mehrere Technologien zum Einsatz kommen. Weitere Teststufen (Integrationstest, Systemtest, Akzeptanztests) mit ihren eigenen Möglickeiten zur Prüfung von funktionalen und nicht-funktionalen Qualitätsmerkmalen (darunter auch automatisiert) sind notwendig.

Zitat von »henrikf«

Und im Team organisiert man sich dann mit Hilfe von »Agilen Methoden«. Das ist zum Beispiel ein »Vier Augen Prinzip«: Das sind Zwei-Mann-Teams, wobei einer programmiert und der zweite sieht sich den Code an und macht Verbesserungsvorschläge. Natürlich wechselt man sich ab und/oder programmiert parallel. Oder »Scrum«, das auf ein sich selbst organisierendes Team mit Hilfe eines »Scrum Masters« setzt, der sich NICHT - ganz wichtig! - um das Projekt an sich kümmert, sondern für die Software-Entwickler da ist. Von Scrum bin ich selber allerdings kein Fan, weil das auch hervorragend als Mobbing-Tool gegen die Software-Entwickler eingesetzt werden kann.

Das 2-Entwickler-an-einem-Rechner-Prinzip wird schon einige Zeit in ein paar Abteilungen der Firma, in der ich arbeite, praktiziert. Das hat tatsächlich zu einer Qualitätsverbesserung geführt, sofern man aber zwei Menschen zusammensetzt, die auch miteinander umgehen können.

Wer Scrum zum Mobbing verwendet, arbeitet nicht wirklich nach Scrum. Ich war anfänglich auch kein Fan von Scrum. Inzwischen bin ich aber begeistert, auch wenn es gerade im Enterprise-Sektor hakt. Denn nach jedem Sprint, bei uns alle 2 Wochen, gibt es etwas, was man ausliefern und dem Kunden zeigen kann. Das schafft Vertrauen. Beim Wasserfall- oder V-Modell hört und sieht man lange Zeit nichts, bis es heißt, es verzögert sich und wird mangels Geld eingestampft oder man bekommt nur ein Bruchteil der versprochenen Funktionen

Zitat von »henrikf«

Und es gibt so etwas wie »Continuos Deployment/Delivery«, um nämlich die Zeiten zwischen den Patches kurz zu halten. Man wartet also nicht, bis man, sagen wir, 20 Fehler bearbeitet hat, sondern liefert nach jedem einzelnen Fehler den Patch auch aus. Damit das geht, wird eben genau nicht das ganze Projekt immer wieder neu installiert, sondern die Software wird in Komponenten aufgeteilt, die klein und handlich sind. Also genau das Gegenteil von dem, was Spiele-Entwickler machen.

Die Idee ist ja nicht neu. Der Trick ist, dass hier automatische Build- und Integrationsprozesse zum Zuge kommen. Das können die Software-Hersteller durchaus schon recht gut.

Das Problem ist nur, dass wir, die Kunden, da noch gerne "Zero Downtime" hätten. Wenn Windows einen Patch im Hintergrund installiert, mag mich das nicht stören. Auf die Nerven geht mir aber die Nötigung zum Neustart.

Zu der Größe von Patches:
Texturen und Musik-/Effekte-/Sprachdateien müssen vollständig ausgetauscht werden. Denn die meisten Kompressionsalgorithmen bauen, ganz vereinfacht gesagt, auf vorherige Datenwörter auf. Die Binärdatei hat eine innere Abhängigkeit.

Bei kompiliertem Code hängt es davon ab, ob und wie viele Bibliotheken statisch oder dynamisch eingebunden werden. Viele kleine DLLs sind deutlich leichter einzeln auszutauschen, allerdings auf Kosten der Performance beim Laden der Software. Aber auch das ist kein Garant, wenn keine ABI-Kompatibilität vorliegt, was ja oft schon bei der Verwendung eines anderen oder einer anderen Version des gleichen C++-Compilers der Fall ist (allein schon durch "Name Mangling").

Ich habe mir gerade mal das Witcher3-Verzeichnis angeschaut: 50 .bundle-Dateien nehmen 13,3 GB, ich verwende hier bewusst die SI-Präfixe, und damit 43,8% der gesamten Größe ein. Die Datei "movies.bundle" hat schon allein 3,2 GB.

Hier fragt man sich zurecht, warum man das macht. Sicherlich spielt da die Kompression eine Rolle. Dass es aus mehreren Dateien besteht, beweisen die Modding-Tools "bundle-explorer" oder ".bundle extractor tool". Vielleicht ist der Patcher hier schlau genug, die Patches wie bei ZIP-Dateien zu injizieren. Ich vermute aber, dass Bundle-Dateien komplett ausgetauscht werden, vor allem das Movie-Bundle.

30 .w3speech-Dateien belegen 5,9 GB und damit 19,4% der Größe des Spieleordners. 46 DLLs und 3 Exe-Dateien belegen mit rund 200 MB nur 0,6% der Gesamtgröße. Hier zeigt sich, dass die 49 Code-Binärdateien einzeln wohl einfach ausgetauscht werden könnten, wenn die Interfaces sich in diesen nicht ändern und / oder keine tiefer gehende Abhängigkeit besitzen.

In Plain-C geschriebene Applikationen verhalten sich in puncto ABI-Kompatibilität besser. Und Skriptsprachen lassen sich am besten (mit Patch-Files) patchen.... In C dauert die Spiele-Entwicklung wohl zehnmal so lange und mit Skriptsprachen bekommt lediglich so etwas oder ähnliches programmiert.

Also wenn ich eurer Diskussion hier folge, bin ich eigentlich froh darüber, dass ich mit Entwicklung praktisch überhaupt nichts mehr zu tun habe und zwischendurch lediglich mal ein (Power-)Shell-Skript schreibe...

Zitat von »technetikum«

Das 2-Entwickler-an-einem-Rechner-Prinzip wird schon einige Zeit in ein paar Abteilungen der Firma, in der ich arbeite, praktiziert. Das hat tatsächlich zu einer Qualitätsverbesserung geführt, sofern man aber zwei Menschen zusammensetzt, die auch miteinander umgehen können.

Das natürlich voraus gesetzt. Wir haben das in der Bank mit einem Drei-Mann-Team praktiziert, und wir konnten sehr gut miteinander. Das hat nicht nur zu schneller Auzftragserfüllung geführt, sondern hat auch noch echt Laune gebracht.

Zitat von »technetikum«

Wer Scrum zum Mobbing verwendet, arbeitet nicht wirklich nach Scrum. Ich war anfänglich auch kein Fan von Scrum. Inzwischen bin ich aber begeistert, auch wenn es gerade im Enterprise-Sektor hakt. Denn nach jedem Sprint, bei uns alle 2 Wochen, gibt es etwas, was man ausliefern und dem Kunden zeigen kann. [...]

Natürlich, aber wenn man in so einer Scrum-Mobbing-Mühle gefangen ist, dann hat man aber so richtig die Popokarte gezogen. Ich habe da mal schlechte Erfahrungen gesammelt ... verbranntes Kind und so. Der 2-Wochen-Turnus ist für den Kunden natürlich genial. Und ich habe auch einen Ex-Kollegen, der ebenfalls von Scrum begeistert ist.

Zitat von »technetikum«

Zu der Größe von Patches:
Texturen und Musik-/Effekte-/Sprachdateien müssen vollständig ausgetauscht werden. Denn die meisten Kompressionsalgorithmen bauen, ganz vereinfacht gesagt, auf vorherige Datenwörter auf. Die Binärdatei hat eine innere Abhängigkeit. [...]

Die Frage ist nur, ob auch immer - bei jedem Patch - die Texturen ausgetauscht werden MÜSSEN?

Ich habe eher das Gefühl, dass die Spielehersteller ihre Spiele nicht im Griff haben, und deswegen sicherheitshalber lieber alles austauschen. Ich lasse mich aber gerne vom Gegenteil überzeugen.

Zitat von »Gunlord«

Also wenn ich eurer Diskussion hier folge, bin ich eigentlich froh darüber, dass ich mit Entwicklung praktisch überhaupt nichts mehr zu tun habe und zwischendurch lediglich mal ein (Power-)Shell-Skript schreibe...

Nein, glaube ich nicht. Da würdest auch sofort die Vorteile bemerken. Die genannten Methoden sind nicht einfach nur akademischer Natur; also irgend welche schlauen Leute haben sich etwas ausgedacht, und das arme Programmierer-Fußvolk muss das dann ausführen. Genau das Gegenteil ist der Fall: Man merkt ganz direkt in der tagtäglichen Arbeit, dass diese einfacher und transparenter wird, und das etwas voran geht. Mir ging es jedenfalls bei der »Objektorientierten Programmierung« (meine Meinung Stand heute: nie wieder ohne) und beim »Vier-Augen-Prinzip« so.

Ich könnte STUNDENLANG Vorträge über die Vorteile der »Objektorientierten Programmierung« gegenüber der normalen »Prozeduralen Programmierung« halten. Vor allem einfach aus dem Gesichtspunkt: Was bringt es für Vorteile. Wenn man das einmal geschnallt hat, was da plötzlich möglich wird, dann ist das so, als öffne sich eine völlig neue Welt. So'n bischen wie »C64 gegen Amiga«.

Aber das geht jetzt, glaube ich, hier ein bsichen zu weit.

Zitat von »Acrid«

Haben die Raubkopien von Moonstone nicht allesamt einen Fehler? Irgendwas habe ich im Hinterkopf... Oder spielst du es mit den Originaldisketten?

<ne zocke es auf der cd32 in so einer compilation cd.
original kann sich das doch keiner leisten.
Aber das spiel selbst hat kein cracker intro o.ä.

Zitat von »firattas«

Zitat von »Acrid«

Haben die Raubkopien von Moonstone nicht allesamt einen Fehler? Irgendwas habe ich im Hinterkopf... Oder spielst du es mit den Originaldisketten?

<ne zocke es auf der cd32 in so einer compilation cd.
original kann sich das doch keiner leisten.
Aber das spiel selbst hat kein cracker intro o.ä.

Ein Original ist das dann bestimmt nicht. Aber ob darin der Fehler ist, weiß ich nicht.
Moonstone als Original ist wirklich ganz schön teuer. Glücklicherweise fällt das nicht in mein Beuteschema

Zitat von »henrikf«

Ich könnte STUNDENLANG Vorträge über die Vorteile der »Objektorientierten Programmierung« gegenüber der normalen »Prozeduralen Programmierung« halten. Vor allem einfach aus dem Gesichtspunkt: Was bringt es für Vorteile. Wenn man das einmal geschnallt hat, was da plötzlich möglich wird, dann ist das so, als öffne sich eine völlig neue Welt. So'n bischen wie »C64 gegen Amiga«.

Aber das geht jetzt, glaube ich, hier ein bsichen zu weit.

Mich musst du jedenfalls nicht überzeugen...

Selbst die C-Verfechter müssen zugegeben, dass sie selbst immer an ähnliche Konstrukte basteln. Nicht umsonst hat z.B. die GTK-Lib eine makrobasierte Pseudo-OOP, was leider viel Boilerplate-Code erforderlich macht. Und selbst Teile des Linux-Kernels enthalten rudimentäre OO-Patterns .

Noch nicht am Spielen, aber ...
... da ich Skyrim - Special Edition storniert habe (buchstäblich), habe ich stattdessen drei andere Spiele gekauft. Allesamt Indie-Titel und allesamt physisch für PS4 (hallo Sir Pommes). Das sind:

Among the Sleep
3D-Horror-Action-Adventure. Man muss als 2jähriges Baby irgend welche Aufgaben lösen. Das fand ich so skuril, dass ich das einfach mal mitgenommen habe.

DEX
2D-Jump-n-Run-RPG-öhm-irgendwas im Cyberpunk-Setting ... sieht schick aus. Will ich spielen.

N.E.R.O.
Keine Ahnung, was das sein soll. Es sieht auf jeden Fall zauberhaft aus.


Damit habe ich für den Preis von Skyrim sogar drei Spiele erstanden. Ich hoffe nur, dass die Spiele sind nicht alle Müll sind.

Zitat von »henrikf«

Noch nicht am Spielen, aber ...
... da ich Skyrim - Special Edition storniert habe (buchstäblich), habe ich stattdessen drei andere Spiele gekauft. Allesamt Indie-Titel und allesamt physisch für PS4 (hallo Sir Pommes).

Gestern war ich in der Gaming-Abteilung vom örtliche MediMax und war überrascht, wie viele Indie-Games es mittlerweile als Retail-Fassung für die PS4 gibt. Neben bekannteren Sachen wie bspw. Aragami, waren da auch allerlei unbekannte Sachen (div. Walking Simulatoren u.ä.) für 20,- 25,-€.
Da kann man auch einfach mal so nebenbei zugreifen - in der Hoffnung keine totale Gurke zu erwischen.

Diese Idee »PS4 ist eigentlich ein PC« scheint sich langsam auszuzahlen. Zudem gibt es zum Beispiel mit Unity eine (wohl) sehr gute und sehr günstige Cross-Platform-Entwicklungsumgebung, mit der man eigentlich alles erschlägt, was es an Spiele-Möglichkeiten so gibt (sogar Samsung Smart TV).

Hotline Miami 2: Wrong Number

Habs jetzt endlich durchgespielt und bin mit einem "meh" aus dem Spiel gegangen.
Ich liebte Hotline Miami 1 und Teil 2 war in vielen Bereichen genau auf dem Niveau von Teil 1 - nur größer. Also alles super eigentlich.
Problematisch wird es aber in der Größe der Level. Die sind vor allem später seeeeeeeehr groß und von vielen freien Flächen/Fenstern gekennzeichnet. Das Level wird so effektiv zu einem riesigen Puzzle, das sich innerhalb von Sekundenbruchteilen verschiebt. Oftmals geht man rein aus Zufall rauf weil auf der aneren Seite des Bildschirms irgendwo ein Gegner den Spieler durch ein Fenster gesehen hat. Das nervt nach ner Weile etwas. Viele der Charaktere engen auch den Spieler ein weil sie nur sehr eingeschränkte Spielweisen zu lassen (nur ohne Waffen, nur mit bestimmten Waffen etc). Das wäre eigentlich OK un abwechslungsreich, ist aber oft wirklich einschränkend und limitiert das Gameplay.

Das größte problem hab ich aber mit den großen offenen Flächen im Spiel komibiniert mit der scieren Größe der Level. Oft hab ich das Spiel frustriert inne Ecke gestellt weil ich grad ne halbe Stunde oder länger an einem BIldschirm hing, nur um dann festzustellen dass da noch ein Bildschirm der gleichen Art kommt und dann noch einer und dann noch einer....

Eine der Stärken von Hotline Miami 1 war die Kurzweiligkeit und Zugänglichkeit. Man ist in Hochgeschwindigkeit da durchgerauscht und zig Mal gestorben, aber insgesamt ließ sich das immer sehr rasch spielen. Das ist bei Teil 2 jetzt anders. Oft sitzt man eine halbe Stunde oder länger an sonem Level und es ist wirklich anstrengend. Anstatt mit rauchenden Colts durchzurennen muss man jetzt häufig taktieren und vor allem stillstehen und warten, die Gegner einzeln anlocken usw um durchzukommen. Es nimmt viel Tempo raus.

Und obwohl die Story und auch das Gameplay an sich komplett toll und spaßig sind.... würd ich im Zweifelsfall lieber Teil 1 spielen. Einfach weil der viel schneller und kurzweiliger ist. Da muss ich mir nicht zuuu viele Gedanken machen. Bei Teil 2 ist vieles ein teilweise frustrierendes Stop and Go. Ich würde Fans von Teil 1 auf jeden Fall aber trotzdem auch Teil 2 empfehlen, weils immer noch urcool ist und über weite Strecken auch immer noch sehr viel Spaß macht. Auch wenn ich insgesamt eher unterwältigt bin :c

Also zu meinem Erstaunen kann ich im Wesentlichen den Leuten von der Gamestar zustimmen.

Finde es nur komisch dass sie nicht beleuchten wie krass anders das mit den Masken und Waffen in Teil 2 war. Das ist auch einer der Faktoren, die (mit dem Leveldesign) dafür sorgen dass sich das so anders spielt als Teil 1

BLADE RUNNER (1997, PC)

Würd ich sehr gerne wieder spielen, aber wegen Windows 7 (64) kann ich et nich installieren. Ich habe einen patch bei replaying.de oer so gefunden, aber den kann ich nicht ausführen weil mein Antivirusprogramm das SOFORT in die Quarantäne verschiebt, selbst wenn ich ihm sage dass er es wiederherstellen soll. Ergo wirds wohl erstmal bei Portal am C64 bleiben, schätz ich)