Beiträge von Xanos

Willkommen in der Transport Fever Community

Wir begrüßen euch in der Fan-Community zu den Spielen Transport Fever und Train Fever, den Wirtschaftssimulatoren von Urban Games. Die Community steht euch kostenlos zur Verfügung damit ihr euch über das Spiel austauschen und informieren könnt. Wir pflegen hier einen freundlichen und sachlichen Umgang untereinander und unser Team steht euch in allen Fragen gerne beiseite.

 

Die Registrierung und Nutzung ist selbstverständlich kostenlos.

 

Wir wünschen euch viel Spaß und hoffen auf rege Beteiligung.

Das Team der Transport-Fever Community


    Wenn es auch im pausenmodus ruckelt kann es sehr gut möglich sein, dass die Grafikkarte bzw der Grafikspeicher schuld ist. Testweise mal Texturen auf "niedrig" stellen. :)

    Na ich hoffe ja mal inständig, dass UG nicht alle Möglichkeiten für jeden einzelnen Bewohner, sondern mindestens nur einmal pro Haus ausrechnet. Weil für Bewohner des selben Hauses ergeben sich ja auch die selben Ziele. Pro Haus bat man Damm zwei berechnungen: mit Auto und ohne Auto.
    Und wenn UG Rechenzeit sparen will, sollten mehrere Häuser zusammengefasst werden. Einfachster Ansatz wäre es zb alle Häuser eines zusammenhängenden Straßenstücks zusammen zu fassen, bzw im Pfadgraph dem selben Knoten zuzuweisen.


    Genau das meinte ich mit "effizienter" Berechnung. Wie effizient UG wirklich vor geht, weiß ich nicht ^^

    Die verfügbare Stadtnamen kannst Du selber bearbeiten, einfach die towns.lua anpassen. Die Dichte von Städten, Industrien und Wäldern lässt sich in der /config/base_config.lua anpassen.
    Größe und Hügeligkeit legt man selber vorm Spielstart fest.

    bin aber von euch, Persönlich angegriffen worden!

    Das "euch" bezieht mich offensichtlich mit ein. Daher habe ich auf den Seiten 10, 11 und 12 noch ein mal geschaut, was ich so geschrieben habe.


    In den folgenden zwei Beiträge gehe ich direkt auf Dich ein oder beziehe mich auf Dich: Beitrag 1, Beitrag 2. Ich will mich hier keineswegs "reinwaschen" oder sonstiges, aber ich sehe in beiden keinen "persönlichen Angriff". Gerne lasse ich mich eines besseren Belehren. Auf meine neutrale Ausführung in Beitrag 1 antwortest Du allerdings ziemlich gereizt, Zitat: OMG, was soll ich dazu noch sagen. [...] Wer das nicht ein sieht sorry aber!? [...] Wer hier nicht einsehen möchte [...] der ist einfach Ignorant! und Wer davon keine Ahnung hat, sollte besser mal den Mundhalten bevor er sich Blamiert!
    Ich fühle mich dadurch sicherlich nicht persönlich angegriffen, aber ich finde meine Beiträge in keinster Weise "schlimmer" als Deinen ;) Ich fände es sicherlich auch schöner, wenn alle Spieler TF ruckelfrei genießen können! Aber das sinnlose aufgeregt sein bringt keinem was, und damit meine ich nicht nur @Veruslux, sondern alle ^^
    Als letzten Hinweis an Dich @Veruslux: Wenn Du Dich von einem Beitrag angegriffen fühlen solltest, nutze bitte den Melden-Knopf.


    Allgemein:
    Fakt ist nun ein mal, egal wie viele High-Class Top-Grafik Games hier aufgeführt werden, Wegfindung ist nun ein mal ein komplexes Problem, da kommt keine angenähert simulierte Flugphysik oder eine absolut nicht vergleichbare größere Zahl von Einheiten (was im Endeffekt nur Polygonhaufen mit Animationsschleife sind) ran. Sicherlich kann man es besser machen (siehe C:SL), aber auch hier konnte man bei den Erstlingswerken von Colossal Order (Entwickler von C:SL und CIM) sehen, wie unglaublich aufwändig Transportsimulationen sie können, wenn sie alle Personen einzeln simulieren. mit C:SL wurde es deutlich verbessert, aber beim ersten Spiel (wie damals bei CiM) kann man nun einfach keine Wunder erwarten. Und dafür läuft TF doch bei einigen ziemlich flüssig.
    Hier geht es ja auch nicht nur darum, für jede Figur einen Lebensbalken und eine rudimentäre AI zu programmieren (wenn du sehen Gegner -> schieß und verfolge), sondern komplexe Wegfindungen effizient zu implementieren. Am "effizient" mangelt es sicherlich, aber das ändert nichts daran, das es ein komplexes Problem bleibt, welches mit keinem der aufgeführten Spiele vergleichbar ist.


    Edit:
    Nachtrag zur "Scheiben-Fliegen-These": Erstes: Quelle bitte. Die Grafikkarte ist vollkommen in der Lage, Physikalisches Absplittern zu berechnen, da braucht man die CPU nicht. Es kann natürlich trotzdem sein, dass einige Programme dies von der CPU berechnen lassen, daher bitte Quelle ;)
    Zweitens: Ich kenne kein Spiel, in dem die 100enden Stücke splitterndes Glas wirklich physikalisch korrekt berechnet werden. Warum sollte man das tun? Eine zufällige Absplitterung basierend auf einem Statistischen Modell reicht hier vollkommen aus, da kann man mittels Vektorrechnung die gesamte Scheibe in an der Hand abzählbaren Takten zerbersten lassen.


    Dieses Beispiel ist sehr aussagekräftig für das, was hier oft als Argument angebracht wird. Viele der "ach so aufwändigen" Sachen, die hier als angebliche CPU-Rechenleistung aufgeführt werden, werden entweder in keinem Spiel wirklich berechnet, da es vollkommen unnötig wäre, oder aber sie sind in Wirklichkeit gar nicht so aufwändig.
    Ich wollt Beispiele?
    Fangen wir mit den wirklich einfachen Sachen an:
    Einschusslöcher an Wänden: Nur eine Textur, die bei einem Treffer aufgesetzt wird. Rechenaufwand CPU gleich Null.
    Wir wollen mehr Abwechslung? Nun gut: Textur basierend auf Winkel des Treffers -> Winkel ist wegen Flugbahn eh schon vorhanden, lookup mit eventuellem random -> Ein Takt Rechenleistung.
    Wir wollen es noch komplexer: Zufällig erstellte Texur: Kann jedes Kind in wenigen Minuten malen, schafft die GPU deutlich schneller, CPU langweilt sich.


    Machen wir es komplexer:
    Zerbrechende Scheiben: Es gibt keine Grund, diese physikalisch Korrekt zu berechnen! Lösung: Zufällige Bruchteile oder Sollbruchstellen. Bei etwas mehr Realismus: Heuristik / Statistisches Modell wurde im Voraus aufgestellt, Bruchstücke werden basierend darauf erstellt. Scherben untereinander haben in 99% der Fälle keine Kollision, auch das wäre zwar nett und realistisch, aber wenn ein Spieler so etwas überhaupt wirklich bemerken würde, dann nur sehr selten -> Kein Lohnenswerter Gewinn für das Gameplay auf Kosten von Rechenleistung -> Uninteressant. Lösung über Partikeleffekte oder einfache Polygone, auf die die selbe Physik angewendet wird, die auf alle Objekte im entsprechenden Spiel wirken -> Basierend auf Engine sollte dies auch von der GPU übernommen werden, selbst wenn nicht: Kein nennenswerter zuwachs der Komplexität.


    Passend dau, im Gegensatz zu vorberechneten Bewegungen / Animationen / Sollbruchstellen:
    PhysX: NVidia PhysX ist der Weg, sich von im voraus berechneten Animationen zu verabschieden. Hier wird die Physik so effizient wie nur irgendwie möglich, basierend auf Parametern die von den Entwicklern eingestellt werden, "simuliert". Natürlich ist auch das nur eine Annäherung, die aber natürlich auf der Grafikkarte berechnet wird. Im speziellen sogar auf einem eigenständigen Chip, der auf der Grafikkarte sitzt. Von @Veruslux kam ja der Hinweis auf PhysX, verwirrt mich aber ein wenig, denn genau dieses Tool zeigt, dass wirkliche Echtzeitsimulierung eben nicht auf der CPU ausgeführt wird, weil diese damit überfordert wäre.


    Die Menge macht's aus? Sprich:
    Viele Einheiten in Strategiespielen: Hier muss wirklich mal die CPU ran, da die AI von dieser Kontrolliert wird. Allerdings gibt es einen sehr großen und rudimentären Unterschied zu TF: In Strategiespielen ist die AI in erster Linie auf das "große Ganze" ausgerichtet. Das heißt, der "Gegner", der die einzelnen Einheiten kontrolliert bekommt die Priorität. Und selbst da wissen wir, wie Dumm die AI in den meisten Fällen ist. Die Wegfindung beschränkt sich hier auf "Luftlinie mit Umwegen, falls Hindernis im Weg" und ist nicht der Rede wert. Die einzigen Entscheidungen, die Einheiten Treffen müssen, ist es, los zu schießen, wenn Gegner in Sicht sind. Und das ist nun wirklich nicht komplex, und wir außerdem im besten Fall getriggert, muss also nicht durchgehend geprüft werden.


    Die Simulation der Welt: Sprich:
    In Skyrim und GTA werden alle Personen simuliert und es Ruckelt nicht, obwohl die Grafik doch so viel besser ist: Ganz einfach: Nein ;) Kein Open-World Spiel wird auf die Idee kommen, alles zu simulieren. Auch hier gilt: Warum sollte man das tun? Spieleentwickler wollen natürlich, dass ihr Spiel so flüssig wie nur irgendwie möglich läuft. Welcher Entwickler bei Bethesta würde also ernst haft vorschlagen. Hey, lass uns mal die Monster im Dungeon hinter Markath simulieren während der Spieler in Winterhelm sitzt. Es gibt fast nichts sinnloseres. Um mal wieder etwas ernster zu werden: Es werden nur die Sachen simuliert, die der Spieler überhaupt wahrnehmen kann. Bei Skyrim heißt das: Das, was er sehen kann. Beim Betreten von Gebieten werden Trigger ausgelöst, die die entsprechenden Personen sich bewegen lassen. Im Hintergrund wird basierend auf einfacher Zeitmessung maximal Berchnet, wie lange ein aktiver Quest-NPC bis zum Treffpunkt braucht. Dieser läuft aber keinesfalls dort hin sondern wird einfach teleportiert. Außer, der Spieler läuft nebenher ;) Wegfindung gibt es auch kaum, die Wege der NPC sind sehr kurz. Für bestimmte Uhrzeiten gibt es feste Positionen - das war's. Im Falle von GTA ist es noch einfacher: Dort sind quasi alle Personen anonym. Sie werden einfach basierend auf der Uhrzeit in einer gewissen "Menge" außerhalb des Sichtfelds gespawnt und dann ins Sichtfeld des Spielers laufen gelassen. Auch typisch für GTA auf schlechten PCs: Fahrzeuge verschwinden, sobald man sie nicht mehr sieht. Auf meinem alten PC ist es mir mit GTA IV oft passiert, dass ein schönes Auto an mir vorbei fährt, ich drehe mich um und es ist weg, weil mein PC am Limit war. Und selbst bei den wenigen simulierten Fahrzeugen ist die KI im Sinne der Verkehrsplanung schon überlastet, aber darauf ist GTA ja auch nicht ausgelegt.



    Zusammengefasst: Ein einem Spiel wird immer versucht werden, so wenig wie möglich wirklich zu simulieren, das meiste wird nur statistisch angenähert. Ob es überhaupt eil des Spiels ist, hängt davon ab, ob es inhaltlich für das Spiel wichtig ist. Das Problem bei TF, im Gegensatz zu beinahe allen anderen Genres: Genau der Kern, nämlich die Simulation aller Personen, ist das komplexeste Problem des Spiels.



    Letztes Edit / PS:
    Ich wollte mit diesem Post hier nur Fakten zusammentragen. Wenn jemand bestimmte Punkte anders sieht oder widerlegen möchte: Nur zu, ich lerne gerne dazu ;)
    Falls sich irgendjemand von diesem Post angegriffen fühlt: Sorry, ich habe versucht so neutral wie möglich zu bleiben!
    Für mich ist dieses Thema hier gegessen. Bei Fragen oder Gegenargumenten werde ich gerne Antworten. Aber die Diskussion, die mittlerweile immer mehr offtopic wird, möchte ich nicht mehr weiter führen ;)

    wird du hier Gemobbt

    Wer im Glashaus sitzt... ;) Beide Seiten sind hier gerade angriffslustig eingestellt.
    Deine "Quelle" für angebliche Echtzeit Grafikberechnung sagt eindeutig, dass es so mal aussehen könnte, und hierbei handelt es sich um reine Landschaften, in denen die komplette Rechenleistung einzig und allein für das aufgebracht wird, was man eben dort sieht.



    Ich habe selber im gleichen Zug in dem ich die unsinningen Vergleiche abgetan habe meine Meinung dazu geäußert, aber auch darauf kamen ja nur abwertende Bemerkungen. Die Vergleiche die hier gezogen werden, in Verbindung mit strotzendem Unwissen über die Hintergründe können mich eigentlich nur zum lachen bringen, aber mit der Stimmung die hier herrscht ist es eigentlich nur noch traurig....

    Skyrim mit 4K Texturen und [...] GTA 5


    Beide Spiele sind absolut Grafiklastig. Allein schon die Betonung auf die 4K Texturen - was bitteschön haben die mit der CPU zu tun? ;) Im Gegensatz zu TF wird dort so gut wie nichts simuliert. Und das was simuliert (und von der CPU übernommen) wird, kann auch ruhig "schlecht" programmiert sein, denn es ist uninteressant. Außerdem sind beide Spiele ziemlich unfaire vergleiche, da beide von riesigen Teams entwickelt werden, mit einem Millionenbudget getestet und optimiert werden können und zusätzlich zum großen Team eine unglaubliche Entwicklungsdauer hinter sich haben. Zu guter Letzt sind sie 3 mal so teuer wie TF ;)
    TF hingegen wirbt damit, alle Bewohner einzeln zu simulieren - und genau das wird auch getan. Das da mehr Leistung von der CPU verlangt wird sollte jedem klar sein. Gleiches gilt für Cities Skylines. Dort ist es genau das selbe Spiel. Ruckler werden dort einfach umgangen, indem man die Allgemeine Geschwindigkeit des Spiels reduziert, statt am Monatsende die Berechnungen nachzuholen. Sicherlich ist das Angenehmer für den Spieler, und es stimmt auch, dass Cities Skylines im Ganzen deutlich flüssiger läuft als TF. Aber: CiM1 und CiM2, in denen auch alle Personen simuliert wurden, waren beide deutlich ruckelanfälliger - und ziemlich auf einer ebene mit TF. Im Vergleich zu CIM1 würde ich sogar sagen, dass TF flüssiger läuft.
    Die Algorithmen müssen halt noch verbessert werden, und da bin ich guter Hoffnung, dass kommende Titel von UG weniger CPU hungrig sein werden.



    Ich will nicht sagen TF ist perfekt programmiert, aber ganz sicher auch nicht so mies wie es hier gerade dargestellt wird.
    Und vergleicht bitte nicht Äpfel mit Birnen ;)

    wohl kaum eine bezahlbare CPU

    Zu viele Menschen verwechseln Preis mit Leistung.
    i7 sind nicht immer besser als i5, schon gar nicht für Single-Thread hungrige Spiele wie TF. Ich würde sogar behaupten, der i7-5820K ist evtl sogar schlechter im Bezug auf TF als mein i5-3570, der nur halb so viel kostet.

    Windows 8 Nutzer können getrost auf Antivirusprogramme verzichten, denn es hat bereits einen eingebauten Virenschutz, der auf der gleichen Datenbank wie Windows Essentials basiert :) Das nur so am Rande. Wohingegen weitläufig die Meinung herrscht, dass dieser Virenscanner mehr schlecht als Recht funktioniert....


    Mag ja sein, aber für TF ist Deine CPU offensichtlich zu schwach.


    Im Benchmark ist mein "schnuckeliger" i5-3570 jedenfalls circa doppelt so gut wie der AMD Phenom II x4 940 (Signatur von @Veruslux) - und da es bei mir auf großen Kartne schon ruckelt würde ich da mal zustimmen.

    Es sind eher die Sicherheitsprogramme, die Probleme mit ihnen nicht bekanten Programmen oder Spielen haben ;)


    Urban Games hat in keinen Patchnotes jemals genaue Details über die internen Berechnungen herausgegeben. Durch Analysen, Debugging und Schlussfolgerungen haben wir aber bestimmte Zusammenhänge herausgefunden, zB hier zu finden: http://www.train-fever.net/index.php/Thread/2530
    Wie dort schon am Ende erwähnt, gab es mit dem Patch 5112 eine Änderung an genau diesem Verhalten. Da das Spiel seit dem bei mir einigermaßen flüssig läuft, habe ich dort nicht weiter nachgeforscht. Aber entweder es wurden weitere Berechnungen auf einen weiteren Kern ausgelagert (was durch einige Spieler so beobachtet wurde), oder die Berechnungen müssen nicht mehr alle zum Monatsende abgeschlossen werden. Desweiteren können die Algorithmen natürlich auch generell verbessert worden sein.


    Von 7 Jahren alter Hardware sollte man mMn nicht mehr so viel erwarten, egal wie gut die Werte zu ihrer "Geburtstunde" waren...


    Nur so als letzte kleine Anmerkung, Du sprichst immer von "UB". Ich gehe mal davon aus, dass Du "Urban Games" meinst, wobei ich nicht genau weiß, wie man da gerade das "U" und das "B" als Abkürzung wählt. Im Allgemein wird hier im Forum "UG" genutzt. Aber solange jeder weiß, was gemeint ist, ist es ja egal ;)

    Ich bin ehrlich gesagt überfragt, möchte aber nur noch ein mal @Veruslux fragen, welche Versionsnummer im Hauptmenü unten rechts steht. Weil die beschrieben Ruckler und Wartezeiten kenne ich nur von älteren Versionen von TF...

    Zum Glück gibt es ja Ordner zum ordnen der Dateien ;) Naja jedem das seine. Früher habe ich auch unterschiedliche Partitionen für Spiele, Daten, Programme, etc gehabt. Aber in meinen Augen war das komplett unnötig und vor allem ist es Platzverschwendung. Eventuell braucht man auf einer Partition grade in paar GB mehr die man auf einer anderen über hätte aber dort nicht braucht. Deswegen hab ich am liebsten eine Boot Partition und dann eine große für alles. Im Zweifelsfall auch eine Partition, die sich über mehrere Platten erstreckt (zb ab ich im Moment eine 2x4 TB Partition als Backup).

    I would sugest that the costs should be based in power and capacity, and other values like speed modify those base values in a relative way.


    Simply because capacity and power add up using multiple vehicles, those should be the values that contribute to the cost in an absolute way. (Costs obviously also add up when buying multiple vehicles).


    Not using real values, only as an idea:
    Using Capacity and Power as base values, modifiex by speed:


    costs = (capacity * factorC + power * factorP) * ( ( speed / 625 + 0.52) * factorS)
    With all factors equal to one (for simplicity of showing my idea, of course those have to be adjusted):
    costs = (capacity + power) * ( speed / 625 + 0.52)
    A few examples:

    Code
    Railcar A: capacity = 20, power = 10, speed = 100 kph, costs = (20 + 10) * ( 100 / 625 + 0.52) = 20.4
    Railcar B: capacity = 10, power = 5,  speed = 100 kph, costs = (10 +  5) * ( 100 / 625 + 0.52) = 10.2
    Railcar C: capacity = 10, power = 5,  speed = 200 kph, costs = (10 +  5) * ( 200 / 625 + 0.52) = 12.6
    Loco A:    capacity = 0,  power = 10, speed = 100 kph, costs = ( 0 + 10) * ( 100 / 625 + 0.52) = 6.8
    Loco B:    capacity = 0,  power = 5,  speed = 100 kph, costs = ( 0 +  5) * ( 100 / 625 + 0.52) = 3.4
    Loco C:    capacity = 0,  power = 5,  speed = 200 kph, costs = ( 0 +  5) * ( 200 / 625 + 0.52) = 4.2
    Wagon A:   capacity = 20, power = 0,  speed = 100 kph, costs = (20 +  0) * ( 100 / 625 + 0.52) = 13.6
    Wagon B:   capacity = 10, power = 0,  speed = 100 kph, costs = (10 +  0) * ( 100 / 625 + 0.52) = 6.8
    Wagon C:   capacity = 10, power = 0,  speed = 200 kph, costs = (10 +  0) * ( 200 / 625 + 0.52) = 8.4


    Combinations for capacity = 20, power = 10, 100 kph:

    Code
    1*Railcar A: 20.4
    2*Railcar B: 2*10.2 = 20.4
    Loco A + Wagon A: 6.8 + 13.6 = 20.4
    Loco A + 2*Wagon B: 6.8 + 2*6.8 = 20.4
    2*Loco B + Wagon A: 2*3.4 + 13.6 = 20.4
    etc...

    As you can see, the combinations doesn't matter as long as the resulting train has the same properties.


    200 kph trains with same power and capacity are only slightly more expensive (as seen from the above stats).
    Of course, if possible, other values like the length of a model can also be included into the calculation: The smaller the vehicle, the more expensive a vehicle with the same capacity. Why? Because smaller vehicles result in more capacity per area (can use smaller train stations etc). Also, other metadata can be applied as factor. Either to the overall price (as speed) or only to one of the absolute values (currently speed and power). E.g load speed can be used as factor for capacity, but should not be used as factor for power, as they are not related. Or as loadspeed adds up in the resulting vehicle, it can also be used as another absolute value (power + capacity + loadspeed). This is up to the modder ;) Some modders may want to make e.g. vehicles with high loadspeed much more expensive (absolute or relative with high factor), some only want to adjust the value slightly (relative with small factor). The possibilities of implementing this are nearly endless.



    I established these equations in the last 10 minutes, without looking at the equations you guys currently use. I only want to show that it is definitely possible to create working equations quite easily :) As soon as I have a bit more free time I will also take a look at the equations you guys currently have and/or create my own implementation in a way I would use it.


    The simple rule: All values that add up when using multiple vehicles per train should be absolute (added) in the equation), all values that don't add up in the resulting train must not be absolute in the equation but should only modify those values using multiplication.

    Ich stimme da @AnimeTrek zu :)


    Ich freue mich generell auch auf ein Zukunfts-Setting, vor allem, da mit Anno 1404 (Venedig) immer noch ein Grafisch aktuelles und sehr gutes Anno in einem Vergangenheit-Setting existiert. Erst letzten Monat habe ich noch mal ein Anno 1404 Wochenende eingelegt - und ich habe nicht das Gefühl das ich da ein neues Spiel bräuchte. Der Fluch eines sehr guten Spiels: Man kann es auch Jahre später noch spielen ohne das man ein neues kaufen müsste ;) Das Anno 2070 durch eine noch weiter in der Zukunft liegende Version ersetzt wird finde ich hingegen okay ;) 2070 war mMn sicherlich nicht schlecht, aber trotzdem gefällt mir 1404 besser.

    There are at least 4 variants of multiple units (train) possible:

    Just for my understanding: Does the script modify full train compositions, or will each model file (each separate model) be modified individually. If the second case is true, it is complete irrelevant how emus can be organized

    Eigentlich habe ich schon fast erwartet, dass es nach 2070 wieder zurück in die Vergangenheit geht, aber auch auf ein 2205 freue ich mich wie Bolle :)
    Trailer sieht imposant aus, auch wenn der erste leider qusai gar keine Ingame Grafik zeigt. Ich bin immer sehr spektisch, wenn Rendertrailer ein Spiel promoten sollen. Denn abgesehen von der generellen Grundidee bringt so ein Trailer absolut nichts rüber. Und während bei einem Adventure oder RPG die Story noch überdurchschnittlich wichtig ist, ist bei einer Wirtschafts- /Aufbausimulation wie Anno die Umsetzung und das Balancing das einzig wahre und wichtige für mich. Natürlich muss das Setting stimmen, um mittels der richtigen Stimmung den Spieler zu fesseln, aber im Endeffekt muss so ein Spiel vor allem einfach "funktionieren".


    Im zweiten Trailer sieht man da schon ein bisschen mehr, und vieles deutet auf ein verbessertes Anno 2070 hin. Neue Gebäude, veränderte Grafik, und so langsam weicht man vom Schiff als ewigen und alleinigen Transportdienstleister ab. Was in 1404 der Orient und in 2070 die Unterwasserwelten waren wird nun in 2205 wohl der Mond werden: Das alternative Biom für den erweiterte Rohstoffabbau.


    Ubisoft ist leider nicht gerade einer meiner Lieblingspublisher. Für mich das nicht minder schlimme Europäische Gegenstück zu EA in den USA. Ich könnte jetzt schon wieder brechen wenn ich daran denke, dass 2205 wie schon 2070 sehr wahrscheinlich mit dem (Vorsicht Ironie) super-tollen UPlay Launcher kommt und sicherlich einige Features eine ständige Verbindung zum UPlay Server benötigen. Auch der "Season Pass" (Vorrauszahlung für kommende DLCs) ist schon angekündigt. Mal sehen was für "tolle" Sachen sich Ubisoft noch zusätzlich ausgedacht hat. Schade, dass die beiden deutschen Entwicklerfirmen (Blue Byte / Related Design) sich nicht alleine über Wasser halten konnten und Teil von Ubisoft sind. Meine Meinung ist einfach, dass Spiele ein Werk für sich sein sollten, und nicht eine so starke Vernetzung mit den Diensten des Publisher eingehen sollten. Das dient nämlich in keinster Weise dem Spiel(spaß), sondern nur dem Profit des genannten Publishers, der mit den deutlich höheren Preisen für die Titel und DLCs eh schon zu viel Kohle scheffelt, die dann im Endeffekt eh wieder nur in solche Trailer gesteckt wird^^
    Trotzdem (und das ist das was mich eigentlich traurig macht) werde ich mir das Spiel wohl holen - aber nicht bevor ich selber ein paar Ingame-Videos mit echten Gameplay gesehen habe.