spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Richtig. Generelle Daumenregel: Erstmal generell funktional bauen. Optimierung danach, sofern notwendig. Nichts ist schlimmer als ein Projekt, was nicht mal bis zum Prototypen kommt, weil man Luxusprobleme schon versucht auszumerzen, bevor sie überhaupt auftreten konnten.

Ich will ja nicht unhöflich sein, aber der Ansatz von Sylence, BlueCobold und mir ist der gleiche: Lass es den Server machen .

Das, wovon ich im speziellen gesprochen habe, ist eben eine dieser Optimierungen, die BlueCobold anspricht. Also dass der Client nur requests an den Server sendet, wenn er selber schon überprüft hab, ob er theoretisch dürfte. So sparst du beispielsweise bei vollem Inventar, dass der Server sich ständig mit dem Client unterhält und ihm sagt, dass er nichts mehr aufnehmen kann, obwohl der Client sich selber "denken kann", dass das nicht geht.

Das kannst du, wie BlueCobold schon sagt, für den Prototypen erstmal weglassen und wird erst später relevant.

Zitat

Wenn ich das Aufsammeln im Client mache, muss der Client erst an den Server melden und dann der Server wieder an den Client.

Davon rede ich ja gar nicht. Aber davon abgesehen hast du die Kommunikation Client->Server->Client ohnehin.

Folgendes Szenario:
Es gibt eine Funktion "void AddToInventory(Item anyItem)" diese Funktion fügt das "anyItem" deinem Inventar hinzu. Wie du das machst ist egal, wichtig ist hierbei nur, dass sie auf dem Server ausgeführt wird. Nur der Server ruft diese Funktion auf - der Client nicht. Der Client darf lediglich einen Request an den Server senden, diese auszuführen. Der Client reagiert dann letztendlich nur auf die Aufnahme des Items. Also genau so wie du es gesagt hast. Daran ändert sich nichts.

Wovon ich jetzt spreche ist folgendes:
Es gibt zusätzlich eine Funktion "bool CheckAddItemToInventory(Item anyItem)", die deine Bedingungen für das Aufnehmen eines Items überprüft. Diese führt der Server aus, bevor er die Logik von AddToInventory tatsächlich ausführt. Also beispielsweise irgendeine maximale Gewichtsangabe und das Gesamtgewicht des aktuellen Invetars + neuem Item.

Die Optimierung von der ich spreche ist, dass du dir jetzt sparst, dass der Server unnötigerweise alles selber überprüft, ohne dass der Client vorher selber fragt. Diese Check-Funktion kannst du auch auf dem Client aufrufen lassen, bevor er ein Request an den Server stellt. Und so reduzierst du die Serverrequests bei nicht-cheatenden Clients.

Und wenn dann noch beim Client ein true rauskommt und beim Server ein false hast du wie gesagt ein Indiz für einen Cheater.

Zitat

Weiterhin reicht eine einfache Variable "inventarIstVoll" nicht. Wenn ich 2 Inventarslots habe, einen zur Hälfte gefüllt mit Äpfeln und einen voll mit Birnen, ist das Inventar dann voll? Äpfel kann der Spieler noch aufsammeln, Birnen nicht mehr.

Realistisch gesehen hättest du auch keine Variable "InventarIstVoll", sondern eben all deine Inventar-Stats und dann innerhalb der Funktionen eine Logik, die mit diesen Stats arbeitet. Wichtig ist halt nur, dass dem Server diese Variablen gehören. Sonst kann der Client sie ja einfach via CheatEngine ändern und dem Server vorgaukeln, er habe ganz andere Werte und eigentlich unendlich viele Slots/Gewicht/ was auch immer du wählst.

Zitat von »KeksX«

Das, wovon ich im speziellen gesprochen habe, ist eben eine dieser Optimierungen, die BlueCobold anspricht. Also dass der Client nur requests an den Server sendet, wenn er selber schon überprüft hab, ob er theoretisch dürfte. So sparst du beispielsweise bei vollem Inventar, dass der Server sich ständig mit dem Client unterhält und ihm sagt, dass er nichts mehr aufnehmen kann, obwohl der Client sich selber "denken kann", dass das nicht geht.

Nicht gut. Dann baue ich mir meinen eigenen Client, der mehr tragen kann, als ich tragen dürfte. Never trust a client. All incoming data is evil.

Zitat von »KeksX«

Die Optimierung von der ich spreche ist, dass du dir jetzt sparst, dass der Server unnötigerweise alles selber überprüft, ohne dass der Client vorher selber fragt.

Der Client sollte gar nicht fragen nach: "Darf ich das aufnehmen?", sondern sollte dem Server sagen: "Der Spieler will das da aufheben!". Und der Server schickt dann dem Client die Nachricht: "Zeige an, dass der Spieler jetzt was aufnimmt und packe X in das Inventory" oder eben: "Nö, das kann er nicht mehr aufnehmen, daher findet jetzt auch keine Aufheben-Aktion statt, um die du dich als Client kümmern müsstest".

Zitat von »BlueCobold«

Zitat von »KeksX«

Das, wovon ich im speziellen gesprochen habe, ist eben eine dieser Optimierungen, die BlueCobold anspricht. Also dass der Client nur requests an den Server sendet, wenn er selber schon überprüft hab, ob er theoretisch dürfte. So sparst du beispielsweise bei vollem Inventar, dass der Server sich ständig mit dem Client unterhält und ihm sagt, dass er nichts mehr aufnehmen kann, obwohl der Client sich selber "denken kann", dass das nicht geht.

Nicht gut. Dann baue ich mir meinen eigenen Client, der mehr tragen kann, als ich tragen dürfte. Never trust a client. All incoming data is evil.

Da hier nur ein Check ausgeführt wird und keine Logik würde der Server einfach sofort erkennen, dass da was faul ist, und den Client disconnecten.

Hö? Wenn der Client den Server gar nicht fragt und clientseitig entscheiden darf, ob er was aufnehmen kann, wie genau reagiert der Server dann? Und um mal zurück zu kommen: Erstmal überhaupt bauen und erst bei Bedarf First-World-Problems wie Client-Side-Prediction nachträglich einbauen. Oder verstehe ich Deinen Vorschlag falsch?

Edit: Meinst Du eventuell, folgendes? Client sagt immer dem Server: "Spieler will X aufheben", kann sich das aber schenken, wenn das Inventory eh voll ist. Das geht natürlich, klar. Dabei können allerdings Client-seitige Bugs (Inventory scheint voll, ist es aber nicht - habe ich schon in diversen Spielen gesehen) schlimmere Auswirkungen haben als stupide einfach immer den Server zu fragen und solche Business-Logik gar nicht im Client zu implementieren.

Zitat von »BlueCobold«

Hö? Wenn der Client den Server gar nicht fragt und clientseitig entscheiden darf, ob er was aufnehmen kann, wie genau reagiert der Server dann?

Die Schritte, von denen ich spreche, wären folgende:

1. Client erkennt irgendeinen Input, der einen Request an den Server erfordert
2. Client kennt die Bedingung für diesen Request und überprüft ihn selbst
3. Client sagt "Ist ok" und sendet Request an Server
4. Server überprüft diesen Request selbst und sendet eine Antwort an den Client und die eigentliche Logik wird ausgeführt.


Wie gesagt, bei einem nicht-cheatendem Client würde der Request also nur dann an den Server gestellt werden, wenn es sich lohnt. Und ein Cheater würde bei Schritt 4 sofort erkannt werden.

Siehe Edit.