Peter Molyneux vs. F2P & Dungeon Keeper

[Baumstumpf]

auch n punkt warum es als "mobile" titel nervt, wie alle clash of clans titel: sitzt man in der bahn, kann man davon ausgehen garantiert seine armee für nichts zu verlieren. da steckt einfach zu viel kommunikation mit dem server drin. könnte man auch geiler machen. zb mit berechnung auf plausibilität des ergebnisses am ende und warteschlange/lock des ergebnisse bis zur übermittlung, inkl speicherung der ausgangsdaten am anfang. jede einzelne aktion zu übermitteln ist etwas extrem.

[Itchy]

Korrekt, so würde ich das auch implementieren. Und was noch schlimmer ist, die Verbindungsprobleme hatte ich nicht in der Bahn, sondern im heimischen WLAN.

[Itchy]

Es wird noch besser: die DK Server sind seit ca. 5 Stunden offline und bislang noch keine Reaktion seitens EA/Mythic, weder im Forum noch auf Twitter. So vergrätzt man wohl auch noch die übrig gebliebenen Kunden.

[Neranja]

da steckt einfach zu viel kommunikation mit dem server drin.

Das Problem ist hieran der Zufallszahlengenerator. In einer "echten" Client/Server-Umgebung vertraut der Server dem Client so wenig wie möglich, also lässt er ihn auch keine Zufallszahlen generieren. Manipuliert ein Spieler den Zufallszahlengenerator auf seinem Client so das immer die für ihn optimalen Zahlen rauskommen, dann ist das Ergebnis für den Server in einer abschließenden Plausibilitätsprüfung ja trotzdem ok.

Solche Clients findet man nur indem man die Ergebnisse mitprotokolliert, und das macht eine Untersuchung auf Zeit notwendig. Und das bedeutet immer Daten sammeln und auswerten.

Eine Lösung wäre Seeds oder Zufallszahlenpakete zum Client zu schicken bei denen man nachrechnen könnte ob der Client diese auch verwendet hat. Ist aber auch problematisch weil ein manipulierter Client dann hellseherische Fähigkeiten bekommen könnte.

Aber tröstet euch, wie ich aus Geschichten von Kollegen erfahren habe gibt es auch bei "normalen" Programmen geistig einfacher strukturierte Java-Entwickler die sich lieber ihre eigene Middleware zusammenschrauben und dabei sowohl Performance als auch Transaktionssicherheit ignorieren. "Was passiert denn wenn da eine Transaktion flöten geht?" - "Das passiert nicht, das läuft auf einer redundanten ESX-Farm". Hauptsache selbst gemacht. *seufz*

[Baumstumpf]

solange der client nur einen extrem eingeschränkten bereich an daten vorgeben kann, sollte das ganze nicht so schlimm sein und eine überprüfung einfach gestalten. es geht ja nur darum ob der client die verfügbaren (also an sich schon beschränkten) rohstoffe des gegner lootet und wie viele einheiten er dabei verliert. wenn man da ansetzt und es zb als unplausibel einstuft, wenn ein holzschwerkämpfer einen feuerspeienden drachen solo legt, dann hat man im prinzip alles nötige, um extremes cheaten zu unterbinden. sicher kann man dann noch die maximale effizienz erreichen, aber bei extremer häufigkeit läßt sich das sicherlich auch filtern.

lustig fand ich ja mal zynga, die sich nie irgendwelche gedanken um sowas machen mussten, da ihre spiele ja allein auf den singleplayer content ausgerichtet war. die hatten in ihrem facebookclone von clash of clans dem client gestattet das komplette ergebnis vorzugeben.... kurze zeit nach start der internen beta mussten sie das game erstmal für mehrere wochen abschalten, um den schaden wieder zu richten und vernünftige sicherungen zum implementieren 

[Itchy]

Nera, Deine Ausführungen sind ja gut und richtig, lassen sich auf DK aber trotzdem nicht anwenden, denn die ganze Kampfberechnung läuft sowieso bei DK komplett auf dem Client ab. Die gesamten Dungeondaten inkl. den versteckten Teil werden komplett übertragen, Sicherheit ist da eh nicht da. Ein gehackter Client könnte ohne Probleme jetzt schon alle versteckten Fallen sichtbar machen.

Woher ich das weiß? Dazu reicht es sich nur den Datenstrom zwischen Client und Server anzusehen. Ich hab noch nicht MitM-SSL gespielt, deswegen weiß ich nicht, was für Daten hin- und herfließen, aber ich weiß, dass Daten nur ca. alle 30 Sekunden ausgetauscht werden.

[Neranja]

sollte das ganze nicht so schlimm sein

Das ist übrigens die Denke bei der man echte Informatiker von pickligen Hauptschülern die Programmieren (PHP) unterscheiden kann. "What could possibly go wrong" war schon immer eine gefährliche Einstellung, und manchmal kann man die Folgen gar nicht absehen.  Wenn alles so einfach wäre dann hätten wir derzeit nicht wieder eine Triple Handshake Attacke auf TLS am Hals.

Und wie ich schon schrieb: Das bannen "bei extremer Häufigkeit" erfordert hintenrum Datenhaltung und statistische Analyse der erhobenen Daten. Wir reden hier von Klitschen bei denen man ja schon froh ist das der Client oder Server nicht abraucht, da kommst Du mit OLAP um die Ecke für das man extra Server-Infrastruktur braucht.

Nera, Deine Ausführungen sind ja gut und richtig, lassen sich auf DK aber trotzdem nicht anwenden, denn die ganze Kampfberechnung läuft sowieso bei DK komplett auf dem Client ab.

Ich kenne das Spiel eigentlich überhaupt nicht, und CoC sagt mir auch nix. Aber sowas hatte ich befürchtet. Vielleicht sollte ich mal wieder meine Lowlevel-Debugging-Kenntnisse auffrischen. Aber die JVM ist Stack-orientiert, davon kriegt man immer gleich Kopfschmerzen.

[Baumstumpf]

prinzipiell hast du recht, aber überabsicherung führt zu einer scheiss user experience, was auch ein merkmal vieler programmierer ist 

[Avion Lore]

Glorious C++ Master Race & PHP Peasants

[Itchy]

Es wird noch besser: die DK Server sind seit ca. 5 Stunden offline und bislang noch keine Reaktion seitens EA/Mythic, weder im Forum noch auf Twitter.

Nach 12 Stunden Downtime das erste Statement von Mythic:
http://forums.dungeonkeeper.com/viewtopic.php?f=9&t=2089

Die habens echt drauf