Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!
Werbeanzeige
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.
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.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
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.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.
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".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.
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.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.
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Hö? Wenn der Client den Server gar nicht fragt und clientseitig entscheiden darf, ob er was aufnehmen kann, wie genau reagiert der Server dann?
Community-Fossil
Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer
Werbeanzeige