Verbesserungsvorschläge zu Transportfever

Zitat von fido

Danke, das ist wirklich mal etwas neues.

So etwas neues ist es nicht, auch ich habe bereits am Ende der Seite 20 bewiesen, das "selbstverständlich" mehr (alle) Kerne genutzt werden.

Zitat von Aloysius

Nur mal so reingeplatzt. Gibt es überhaupt Spiele die "fertig" auf den Markt kommen? Kann mich an keinen Titel erinnern...Nur mal so am Rande erwähnt...

Heutzutage nicht mehr, nein. Alle Welt ist doch sogar froh, sich vor Spielstart bereits einen 8GB Day one Patch zu laden. Früher wäre das Produkt einfach nur komplett gefloppt und die Schmiede in der Versenkung verschwunden.

Allerdings sind Spiele heutzutage auch "ein wenig" komplexer und das benötigte Kapital einen zeitgemäßen Titel zu programmieren ist exorbitant höher. Zwar gibt es dafür auch mehr Geld, durch erheblich größere Zielgruppe, doch die betriebswirtschaftliche "lohnt sich der Aufwand?" Rechnung ist in etwa(!) gleich geblieben.

Jedoch wird die Vorgehensweise diverser Studios durch jede Menge "Stammpersonal" selbst in diesem, gezielt auf nur zwei Spiele abzielenden Forums, mehr als häufig als "richtig" bestätigt.

Es sind zwar nur ein paar Wenige, die einfach zu ... (ja was sind die eigentlich? Fanboys, fanatisch, mit weniger zufrieden, verwandt mit den Entwickler, einfach nur blöd oder etwas von all dem?) ... lasse das ganzen Satz besser einfach einmal weg.

Formuliere ich es so:
Es werden selbst kapitale Fehler - hier durch die Größe des Studios und die persönliche Affinität zum Produkt, woanders durch AAA-Hype - stumpfsinnig verteidigt mit Argumenten, die teils RTL2 auf ein solides Niveau heben.

Solange sich an der Haltung der Kunden nichts ändert wird sich auch auf dem Spiele-Markt nichts ändern.
Und Änderung, zumindest in die richtige Richtung, ist eher nicht zu erwarten.

Ich habe mir jetzt nicht jeden einzelnen Kommentar hier durchgelesen, jedoch ist mir das ein oder andere im Kopf hängen geblieben, was mich doch ziemlich verwundert.

Das ganze geht zwar jetzt etwas ins Offtopic, dennoch denke ich das es so halbwegs hier reinpasst.

Ich habe in der Uni 4 Semester Informatik gehört. Da ging es teilweise um das Lernen zu programmieren oder um Algorithmen. Wie man einen Code effizient gestaltet, etc. Das alles ist aber nicht so leicht, wenn man von 0 auf beginnt (TF, ich kann natürlich nicht sagen, wie die Mitarbeiter von UG vorher schon in diesem Bereich gearbeitet haben). Man kann alles noch so gut versuchen, aber etwas besseres wird man fast immer in so etwas finden, besonders im IT Bereich. Jetzt nehmen wir mal an, dass die Performance von TF auf einer Skala von 1-10 bei 2 liegt. Wenn die nun einen Weg gefunden haben, der die Performance um 100% verbessert, dann ist man bei 4/10, sprich man ist beim potenziellem Maximum noch nicht mal zur Hälfte angekommen. Aber dennoch ist eine 100% Verbesserung immer vorteilhaft. Und wenn man für die Umsetzung 1 Jahr braucht (und man insgesamt 2 Jahre für die Entwicklung und Beta-Tests angepeilt hat), dann ist ja wohl klar, dass das ein oder andere dann auf der Strecke bleibt. Denn bessere Performance ist nicht nur für den Spieler von Vorteil, auch für den Programmierer. Der hat dann bei eventuellen Fehlern gegebenenfalls einen schnelleren Einblick auf die Fehlerquelle, als wenn man noch über 3 Umwege gehen muss. Das heißt dann aber noch lange nicht, dass der Code dann wirklich auch optimal ist.
Falls dann Fehler wieder auftreten, die mit einem Patch von TF eigentlich behoben wurden, wieder auftreten, dann passiert es eben mal. Das heißt aber nicht, dass man es nicht versuchen würde, diesen wieder abzustellen.

Man muss aber auch sagen, dass TpF ziemlich viele Ressourcen verbraucht. Jede einzelne Person wird simuliert (sei sich gerade sichtbar oder nicht). Aber wenn ein Auto von A nach B fährt oder ein Passagier am anderen Ende der Karte zum Bahnhof läuft und dort dann auf den Zug wartet, der seinerseits gerade 200 Personen transportiert und dann dort ablädt. Da kommt schon einiges zusammen. Und wenn man dann insgesamt 50000+ Einwohner auf der Karte hat muss einem auch bewusst sein, dass das irgendwann zu viel wird (Jetzt kann man sagen, dass man nicht den besten PC am Start hat, aber wenn ich hier teilweise lese, dass manche mit Laptops spielen und sich dann im Lategame über die Leistung ärgern, dann kann ich das ganze eben nicht nachvollziehen.).

Das Spiel ist eben eine Simulation, und die brauchen bekanntlich viele Ressourcen, um es so realistisch wie möglich darstellen zu können.

Außerdem ist es doch heutzutage nicht unüblich, ein Spiel "nicht fertig" zu veröffentlichen. Besonders dann, wenn das Geld knapp wird. Wenn ich die Wahl hätte, ob ich ein Spiel etwas früher veröffentliche, damit ich dann die nötigen Gelder habe, um alle zu bezahlen, dann macht das jedes Unternehmen. Später kann man immer noch sagen, dass man es versucht und das Bestmöglich getan hat, um das Spiel so gut wie möglich zu machen.
Denn ich denke, wenn ein Entwicklerstudio von den ein auf den anderen Tag bekannt gibt, dass es den Betrieb einstellen muss, weil es die Mitarbeiter nicht mehr bezahlen kann und das Spiel so lange auf Eis liegt, bis sich ein anderes Studio dafür interessiert, dann ist die Enttäuschung auch sehr groß. Und ich behaupte dann auch mal, dass einige sagen: "Könnt Ihr das Spiel nicht trotzdem veröffentlichen, die bisherigen Bilder sahen gut aus und ich könnte über den ein oder anderen Fehler hinwegsehen. ", oder: "Mir ist es lieber ein nicht fertiges Spiel, was spielbar ist, zu spielen, als es nicht spielen zu können. "
Es sei auch gesagt, dass die potenziellen Käufer dieses Spiels (also Wir), immer mehr drängeln und man einfach keine Lust mehr hat zu warten. Das mag zwar nicht auf alle treffen, doch 70% sind es bestimmt, die von neuen Spielen des Lieblingsgenres einfach keine Geduld aufbringen können (wenn man nach den Kommentaren hier geht). Und ja, ich bin auch fast so einer (anderes Beispiel Kingdom Hearts 3, falls es jemand kennt). Wenn man ein paar Monate nichts von dem Spiel hört, dann fragt man sich automatisch: "Kommt da noch was oder doch nicht?"

Bei gesundem Menschenverstand sollte einem klar sein, dass es sich immer noch um ein Unternehmen handelt, welches im Endeffekt Geld verdienen möchte. Und da nimmt man es gerne in Kauf, ein Spiel früher zu veröffentlichen, weil es in der Gegenwart ja jeder andere auch macht. Lieber noch die paar Euros einstecken, um gegebenenfalls offene Gehälter zu bezahlen, als wenn man sich mit irgendwelchen Anwälten rumzuquälen, die am Ende auch nur Geld kosten.

Der Kern meiner Aussage ist: Haltet mal alle den Ball flach. Wenn 10 Leute an so einem Spiel arbeiten, dann braucht es eben Zeit, bis man es spielen kann. Lieber die Erwartungshaltung etwas runterschrauben, als am Ende enttäuscht zu sein. Lieber ein bisschen weniger nörgeln und und Entwickler anschreiben, wann das Spiel denn kommen soll. Die haben nämlich genug zu tun, um das Spiel überhaupt zu einem Spiel zu machen.

@fido

Zitat von homiesoverhere

Es sei auch gesagt, dass die potenziellen Käufer dieses Spiels (also Wir), immer mehr drängeln und man einfach keine Lust mehr hat zu warten. Das mag zwar nicht auf alle treffen, doch 70% sind es bestimmt, die von neuen Spielen des Lieblingsgenres einfach keine Geduld aufbringen können (wenn man nach den Kommentaren hier geht).

Das kann schon durchaus so hinkommen - allerdings stellt sich dann für den Nachfolger von TPF die Frage, ob die Leute immer noch für ein "nicht ganz so ausgereiftes" Spiel bereit sind, frühzeitig Geld zu investieren oder ob sie dann nicht lieber warten, bis entsprechende Patches diesen Status ändern - was durchaus eine Wartezeit von mehreren Monaten nach sich ziehen kann und damit natürlich auch zunächst zu Einnahmeverlusten bei UG führen könnte - mit welchen Konsequenzen auch immer.

Was man auch nicht aus dem Auge verlieren sollte: TPF ist momentan konkurrenzlos - noch. Sowas kann sich jedoch schnell ändern.

Ich für meinen Teil werde die Entwicklung von TPF für einen potentiellen Nachfolger im Hinterkopf behalten...

Zitat von Jey_Bee

auch ich habe bereits am Ende der Seite 20 bewiesen, das "selbstverständlich" mehr (alle) Kerne genutzt werden.

Das Bild des Taskmanagers beweist leider überhaupt nicht, das TpF alle Kerne nutzt. Es beweist nur, dass der Windows-Kernel
in der Lage ist, alle CPUs/Kerne zu nutzen. Der/die Threads eines Programms verbleiben NICHT während der gesamten Laufzeit
des Programms auf einem Kern. Bei deinem Screenshot muss der Kernel dafür sorgen, dass von den 1201 Threads der 81 laufenden
Prozesse jeder mal auf einen deiner 4 Kerne kommt, der etwas zu tun hat. Viele davon werden nur kurzzeitig ein paar wenige
Befehle ausführen um festzustellen, dass sie sich wieder schlafen legen können. Trotzdem sorgt dies dafür, das ein CPU-lastiger
Thread wie der von TpF von seinem aktuellen Kern runter fliegt und vom CPU-Scheduler nach kurzer Zeit auf einen anderen
Kern fortgeführt wird, weil auf dem ursprünglichen Kern gerade andere, wichtige Arbeit verrichtet wird.

Wenn, dann musst Du dir den Prozess im Detail anschauen, wie hier:

Was sehen wir hier für TpF auf meinem Ubuntu-i7-Klapprechner in der zweiten Zeile?
4 Threads, davon einer arbeitend und drei pennend. Der arbeitende erreicht 97% CPU-Last, was aber nicht bedeutet, dass alle meine 8 Kerne
fast am Limit sind. Nein, er lastet nur einen Kern zu fast 100% aus. Mehr geht ja für einen Thread auch nicht.

Es gibt eine einfache Formel, um aus der Anzeige des Windows Task-Manager auf die gleichzeitige Nutzung der Kerne durch ein Programm
zu schließen:
Wenn ein Programm nur einen Kern nutzt, dann hat man bei einem 4-Kerner eine CPU-Auslastung um 25%, bei einem Acht-Ender um 12,5%.
Wenn es zwei Kerne nutzt sind es dann 50% bzw. 25% usw. Im Task-Manager wird man aber immer alle Kerne mehr oder weniger beschäftigt
sehen.

@Reisi007 und @TrainMatti38, auch eure Screenshots sagen über die von TpF genutzten CPU-Resourcen nichts aus. Ich vermute, ihr habt beide
Windowssysteme, und da können leicht mal eben alle Kerne ins Schwitzen kommen, wenn Windows sich mit sich selbst beschäftigt. Nur schon
der kaputte Update-Klapperatismus von Windows-Update lässt gerne einen Thread unter "svchost" einen Kern auf 100 gehen, der wiederum den
"trusted installer" auf einen anderen Kern schmeißt, der wiederum bei Windows 10 den msiexec im Hintergrund ungefragt Updates installieren
lässt, um euch irgendwann die Kiste zwangsneustarten zu lassen. Dabei kommen, wenn Updates vorhanden, neue Dateien auf eure Platten,
wobei wiederum das Schlangenöl Virenscanner mitreden möchte und die Dateien erst einmal auf Herz und Nieren untersucht. Und schwupps
sind eure CPU-Kerne am schwitzen und die Platte am rödeln.

Wieviel von der Stromrechnung dabei auf TfP entfällt, könnt ihr nur anhand der Auslastung eurer CPU-Kerne nicht erkennen.
Vielleicht ruckelt TfP ja auch gerade nur noch...

Der Vollständigkeit halber mal ein Hinweis auf einen Eintrag von einem User aus dem Steam-Forum: Der führt ziemlich ausführlich aus, warum er glaubt, woher Teile der Performance-Probleme von TpF kommen. Da das Punkte sind, die bisher hier noch nicht zur Sprache kamen, fasse ich das mal kurz zusammen:

• Er meint, dass das LoD-System von TpF sehr ineffizient arbeite, weil es
  
  
  • a) Statisch angelegt ist und nicht dynamisch berechnet, was es anzeigen muss
  • b) Hauptsächlich im LoD-System die Polygone je Objekt reduziert werden und nicht die Anzahl der Draw-Calls, die von der GPU benötigt werden, um das Objekt darzustellen. Dadurch ist wohl z.B. jedes Gebäude mindestens ein eigener Draw-Call, was mit steigender Anzahl an Gebäuden zum Problem wird
• Weiterhin erklärt er, dass viele Animationen von TpF, u.a. die Bewohner, auf einer Technik namens "skeletal animation" basieren, die, wenn sie schlecht implementiert ist, sehr viel CPU-Performance kostet
• Die Leistungseinbrüche beim Bauen von Brücken etc. erklärt er damit, dass das gesamte Modell (also alle Geometrien) gestreckt wird - erst berechnet durch die CPU und dann in die GPU rüberkopiert wird, was für alle modernen Rechner mit diskreter Grafik ein Problem ist.
• Er meint zum Abschluss, dass TpF versuche die "Einfachheit seiner Welt durch absurd hochauflösende Texturen und Modelle zu verbergen, was zwar gut aussehe aber zu Lasten von Ladezeiten, Speicherplatz und Speicherbandbreite gehe.

Das erklärt für ihn, wieso die Frame-Raten so niedrig sind. Die Simulationsberechnungen werden auch kurz angesprochen, das ist aber das Gleiche, wie das, was wir hier schon seit TF besprechen.

Zitat von Tom

Das Bild des Taskmanagers beweist leider überhaupt nicht, das TpF alle Kerne nutzt.

Genau deshalb, habe ich gleich 3 Screenshots des Prozessorauslastung gemacht, um zu zeigen, das die "anderen" 80 Prozesse praktisch keine Leistung bedürfen. (Leerlauf)
Schau Dir meine Dokumentation ruhig nochmal genauer an.

@Jey_Bee, aber trotzdem ist bei deinen drei Screenshots die höchste CPU-Auslastung 40%. Von deinen vier Kernen haben 2 gar nichts zu tun,
einer liegt bei 60% und einer bei 100%. Warum jeder Kern im Graphen aber etwas ab bekommt, habe ich oben erklärt.
Wenn alle Kerne genutzt würden - und das täte Tranport Fever gut, dann hättest Du ein Auslastung von nahezu 100%.

@pdca_cycle, guter Beitrag, der verlinkte...

Zitat von Tom

Wenn alle Kerne genutzt würden - und das täte Tranport Fever gut, dann hättest Du ein Auslastung von nahezu 100%.

... so wie beim Erstellen einer neuen Karte kurz bevor die Karte angezeigt wird - da gehts dann über alle Kerne - und nicht zu knapp...

Ich weiß ja nicht warum Ihr schon wieder streitet.

Meine damalige Analyse zu TF hier zu finden: Was macht TF Intern und warum es ruckelt
Zumindest die GOG Version von TPF hat nun scheinbar noch einen zusätzlichen Thread, wobei es immer noch einen normalen Hauptthread gibt.

Der große Unterschied denn ich beim testen gesehen habe:

Der zweite Thread scheint nicht mehr einen kompletten Stillstand des Spiels verursachen. Er hat bei TF immer zu einem Stillstand der ganzen Welt beim zusammenführen der Daten geführt (Monatsende)

Ich tippe sehr darauf das UG das zusammenführen der Thread Daten stark verbessert hat.
TF machte da quasi ein Stop the World wenn die Daten zu groß waren, bzw. die C++ Runtime, das hat sich nun verbessert.

Für Windows empfehle ich die Nutzung von SysInternals ProcessExplorer.
Schaut euch einfach die Threads in Properties an... Da hat man im Endeffekt ähnliche Angaben wie top unter Linux. Unter Performance CPU Usage kann man auch die Monatswechsel schön sehen...

PS: Wenn UG wieder eine exe, elf Datei mit ein paar Debugdaten veröffentlicht werde ich wieder eine Analyse starten...

Zitat von Tom

der wiederum bei Windows 10 den msiexec im Hintergrund ungefragt Updates installieren
lässt, um euch irgendwann die Kiste zwangsneustarten zu lassen

Ich öle mein Haupt und gebe ganz frech damit an, dass mein Windows 10 sich nicht so verhält.
Ob du es glaubst oder nicht, es gibt noch Stellschrauben.

Zitat von Nordwestexpress

da gehts dann über alle Kerne

Auch für einen kurzen Moment, wenn das Laden einer Map beendet ist. Das nutzt halt nur nichts während des spielens...

Edith an @eis_os: Wir streiten doch nicht, wir klären nur wie die Anzeige des Task-Managers zu interpretieren ist.
Und mit Sysinternals hast Du natürlich recht. Die Suite ist ein sehr gutes, brauchbares Werkzeug, wenn man wissen will,
was sich in Windows tut...

Edith's Tante @Gordon Dry: Ich bezweifle doch gar nicht, dass Du dich auskennst und zu helfen weißt...

Zitat von Tom

dann hättest Du ein Auslastung von nahezu 100%.

Die erreiche ich ja aber nicht einmal bei einem (den 1.) Kern.
Wenn nicht einmal 1 Kern ins "schwitzen" kommt, wie sollen dann alle "voll" ausgelastet werden?

Zugegeben, ich verstehe von Prozessstruktur und Verteilung vielleicht nicht so viel wie Du oder andere.
Aber wenn ich als Nutzer sehe, das während des Spiels alle Kerne etwas zu tun haben, ohne das auch nur ein Kern kontinuierlich "voll" ausgelastet ist, kann ich mich im Grunde nicht beklagen.

Mehr noch, wenn es im Spiel tatsächlich mal etwas langsamer wird, und oder stellenweise Ruckelt, ohne das ich auch nur auf einem Kern eine längere 100% Auslastung registriere, sagt mir mein "logischer" Verstand, das diese Ruckelein nicht auf die CPU zurückzuführen sind.

Auch zeigen die Kern-Lastspitzen je nach dem was im Spiel grad passiert, das die Rechnleistung in dem Moment doch direkt oder auch indirekt auf mehrere Kerne verteilt werden.
Denn warum schlagen ausgerechnet am Monatswechsel auch die anderen Kerne so extrem aus?
Weil die anderen Windows-Prozesse ausgerechnet in dem Moment auch so viel Leistung benötigen, oder nur für die dauer dieser Sekunde umgelagert werden?

Wenn dem so ist/wäre, hätte nicht UG mit TPF die Performance verkackt, sondern Microsoft mit Windows.

Aber es ist natürlich leichter für "jeden" Halbprofi und Möchtegern-Programmierer hier UG Inkompetenz und Lügen zu unterstellen.

Für mich ziehe ich als Fazit:
Die Performance ist um vergleich SEHR deutlich verbessert worden.
Performanceverluste im Spiel (Lategame) sind hier ehr auf meine Graka zurückzuführen. Denn meine CPU kommt auch da nur bedingt ins schwitzen.

Zitat von Jey_Bee

Mehr noch, wenn es im Spiel tatsächlich mal etwas langsamer wird, und oder stellenweise Ruckelt, ohne das ich auch nur auf einem Kern eine längere 100% Auslastung registriere, sagt mir mein "logischer" Verstand, das diese Ruckelein nicht auf die CPU zurückzuführen sind.

Eigentlich würde mir mein logischer Verstand das Gleiche sagen - allerdings stellt sich auch die Frage, ob die Anzeige in der Lage ist, kurzzeitige "Überlastungen" der CPU entsprechend auch darzustellen.

Bei meiner GPU, welche durch viele Assets ziemlich heftig in meiner letzten TF-Karte belastet wurde, zeigte mir ein dazugehöriges Programm zunächst eine immer stärker werdende Auslastung an, um dann - als noch mehr Assets hinzukamen - zwischen 99% und 0 hin und herzuschwanken - so als wenn die GPU sich zwischenzeitlich langweilen würde. Tat sie aber gewiss nicht...

Zitat von Jey_Bee

Auch zeigen die Kern-Lastspitzen je nach dem was im Spiel grad passiert, das die Rechnleistung in dem Moment doch direkt oder auch indirekt auf mehrere Kerne verteilt werden.

Die Fieberkurve des Task-Managers ist viel zu ungenau und kann das, was tatsächlich passiert, nicht darstellen.
Dazu müsste die Zeitachse auf Milli-Sekunden skaliert werden und Du würdest in Echgtzeit nur einen hellen, grünen Balken sehen.

Die Zeit, die ein Prozess max. eine CPU benutzen kann, bevor er vom CPU-Scheduler von der CPU genommen wird und ein anderer auf die CPU kommt, liegt z.Bsp.
beim Linux-Kernel zwischen 0.75 und 6 Millisekunden (Standard-Voreinstellung des CFS-Schedulers und während des Betriebs dynamisch an die aktuellen Anforderung des Systems
angepasst, es gibt auch noch andere CPU-Scheduler). Beim Windows-Kernel bewegt es sich aber bestimmt auch in dieser Größenordnung.

Um mit dem Auge zu sehen, dass zu einem bestimmten Zeitpunkt t ein Thread auf Kern #1 ist, aber bei t+1 auf den anderen Kern #2 verschoben wurde, müsstest Du deinen
Rechner mit einem sehr, sehr niedrigen Takt betreiben - sagen wir mal auf jeden Fall etwas deutlich unter 25 Hz...

Hallo

Zitat von Jey_Bee

Aber es ist natürlich leichter für "jeden" Halbprofi und Möchtegern-Programmierer hier UG Inkompetenz und Lügen zu unterstellen.

Hier jeden Kritiker einen „Halbprofi“ oder „Möchtegern Programmierer“ zu schimpfen und den Kritikern zu unterstellen, diese würden UG selbst „Inkompetenz und Lügen“ unterstellen, halte ich – auch und trotz des Smileys – für schäbig. Dass du hier oft genug ungestraft in einem mindestens grenzwertigen Ton agieren kannst, liegt wohl daran, dass du hier eine ausreichend große Nummer bist. Dennoch würde auch dir etwsa Mäßigung gut zu Gesichte stehen.

Tschö, Auge

Sorry, aber in den vorherigen Beiträgen wurde sowohl wörtlich als auch Sinngemäß UG bzw. deren Entwickler mehrfach als Lügner und Inkompetent hingestellt.
Auch scheint es reichlich Leute hier zu geben, die "glauben" es besser zu wissen oder gar können.
Der Beweiß steht aber "grundsätzlich" aus.
Somit ist diese zitierte Aussage "zynisch" absolut gerechtfertigt.

Dazu sollte man sich dann aber ggf. auch die vorherigen Beiträge durchlesen.

Ich hatte als Titel "Verbesserungsvorschläge für Transportfever" gelesen. Oder hab ich da was falsch gelesen?

Aber das was ich hier zu lesen bekomme, ist unterste Schublade.
Statt Vorschläge zu machen bzw. darüber zu diskutieren, wird den Machern von einen Super Spiel für wirklich kleines Geld, Inkompotenz und Lügen unterstellt.

Sicher ist es OK wenn Kritik geübt wird. Aber bitte sachlich bleiben und niemanden etwas unterstellen, was er nicht wirklich beweisen kann.
Ich kann mir bei allerbesten Willen nicht vorstellen, dass UG Sch... auf den Markt werden wollte um den schnellen Taler zu machen. Die haben sich grösste Mühe gegeben und das sollte respektiert werden.
Wer Fehlerfrei ist, darf sich am Steinbruch Steine abholen und rumschmeisen.
Anständiger wäre es allerdings, die Steine zu Baumaterial zu verarbeiten.

Alle die meinen, UG zu beschimpfen zu müssen, dürfen gerne etwas "Besseres" mit vergleichbarem Budget zaubern. Aber wehe (Steine liegen überall rum) es ist nicht "PERFEKT" und muss irgendwo gepatcht werden.
Wenn sie das geschafft haben, dürfen sie wieder unterstellen, difamieren, der Lüge bezichtigen und "Steine werfen".
Aber bis dahin bitte den Ball so flach halten, dass er am besten von oben nicht mehr zu sehen ist.

Ich hab die 30€ gerne gezahlt und wäre auch bereit gewesen mehr zu bezahlen.
Wenn ich da an die Preise denke, die milliardenschwere Softwarekonzerne für ihre BETA-Produkte von ihren "Beta-Testern" verlangen, wirds mir schwindelig.
Da würde ich eher davon sprechen, dass Sch... auf den Markt geworfen wird. In der Hoffnung das aus Sch... mit jedem Patch ein bisschen mehr Bonbon wird.

Und jetzt würde ich mir wüchschen, dass zum eigentlichen Thema zurück gekehrt wird.

Zitat von kasperle

Inkompotenz und Lügen unterstellt.

Diese "Untersteller" darf man nicht so ernst nehmen.
Es sind wie überall im Internet einige wenige, aber sehr laute.
Davon finden sich immer schnell ein paar zusammen, die sich gegenseitig ihre Meinung bestätigen
und die dadurch in den Irrglauben verfallen, sie würden die Mehrheit repräsentieren.
Besser wissen und können könnten sie es sowieso...