Original von nerdfactor
im optimalfall wird das ereignis berechnet wenn es auftritt. und das geht nur wenn die software auf dem server eine warteschleife hat und die ereignisse dann berechnet wenn sie fällig sind (oder so ähnlich), oder wenn eine dritte kraft von außen in regelmäßigen abständen, die berechnung aller ereignisse anstößt. diese dritte kraft (cronjobs z.b.) müssten aber jede sekunde ausgelöst werden, um so exakt zu berechnen, wie es die stetig laufende software könnte.
Im Optimalfall werden die Ereignisse dann nicht dann berechnet, wenn sie auftreten, sondern dann, wenn ungenutzte Leistung vorhanden ist, bzw die Serverlast es zulässt. Das ist jedoch grade bei Browserspielen nicht immer möglich. Dort hat man per se sehr viele kleine Anfragen und Datenmengen von außen, das das Berechnen beim Auftreten u.U. zu ekelhaft langen Ladezeiten führt.
2 Beispiele:
Eine Useraktion löst bei vielen Spielen eine Wartezeit aus, z.B. bei der "Arbeit" oder beim aussenden einer "Armee" zum Gegner. Es wäre doch doof nun zu warten bis die Armee beim Gegner eintrifft und erst dann die Berechnung des Kampfes zu starten, oder abzuwarten bis die 8 Std Arbeit des Spielers abgelaufen sind.
-Im Fall der Arbeit wird sich das Ergebnis wohl zumeist eh nicht mehr verändern, eine Gehaltserhöhung wärend der Arbeit wird in den meisten Fällen nicht eintreten, bringt keinen besonderen Mehrwert und wird ergo bei der Entwicklung gar nicht ermöglicht.
Die Engine hat also 8 Std Zeit, für das berechnen des Arbeitsergebnisses. Entweder erledigt man es sofort (ist ja eh nichts aufwendiges) - oder aber lässt es irgendwann während dieser 8 Std in einem Teillast oder Leerlaufzustand berechnen. Der User wird davon eh nichts merken.
- Bei der Armee wirds difficiler - möglicherweise hat der Gegner seine Basis verändert oder Verteidigungstruppen aufgestellt während meine Armee 10 min. durch die Wüste gezogen ist. In dem Fall habe ich 2 mögliche Optionen:
1. Berechnen während die Armee sich "eigentlich" noch bewegt und danach nur noch überprüfen ob sich beim Gegner zwischenzeitlich was verändert hatte. Wenn nein ausliefern, wenn ja MIST - dann muss die Enine eben gleich nochmal mit den nun aktuellen Daten rechnen.
2. Berechnen wenn die Armee angekommen ist, dann aber unabhängig von Serverauslastung und der Zeit die der User genervt vor dem Rechner sitzt und wartet. (Kann durchaus geschehen - in einer frühen Version unseres momentanen Projektes dauerte eine Kampfberechnung bis zur Auslieferung an den User bis zu 10 Sekunden)
Gut ist z.B., wenn eine Highscoreliste nicht jedesmal dann berechnet wird, wenn der Spieler sie aufruft (bei 100k Spielern auf einem Server kann das schon problemathisch werden). Allerdings ist das aus Sicht des Spielers wiederum nicht so toll, deshalb steckt man bspw. feste Zeitgrenzen innerhalb derer berechnet werden muss, sagen wir eine Std - sorgt aber dafür, dass das Programm auch mal 5 oder 10 Minuten durch diese Grenzen bricht wenn die Last gerade zu hoch ist. Wenn nach oder innerhalb dieser Zeit immer noch kein geigneter Lastzustand entstanden ist, dann muss man eben in den sauren Apfel eines Laggs beissen und die Berechnung dennoch starten. Man sieht also: Optimal aus unserer Sicht ist nicht = Optimal aus Usersicht.
In groben Zügen arbeitet unsere Engine ähnlich. Wir warten nicht auf spezifische Anfragen, sondern bereiten vieles vor um es dann bei Anfrage auszuliefern. Geht natürlich nicht überall - z.B. bei Kämpfen oder Einkäufen. Wir sparen uns zwar den Overhead jedesmal eine Auslage bei einem NPC-Händler zu generieren wenn ein User sie anfordert - innerhalb eines bestimmten Zeitabstandes wird dynamisch eine neue Auslage erstellt die gecacht und bei Anfrage nur noch ausgeliefert wird, aber der Prozess des Einkaufens selbst ist nicht vorbereitbar.
Mit tieferen und vor allem technikbezogeneren Darstellungen kann ich nicht dienen. Mein Job ist nicht das Prorammieren, ich habe nur das Konzept unseres Spiels in großen Teilen mitentworfen und dadurch viel mit unseren Codern zu tun gehabt.
PS: Bei Cronjobs fehlt dazu die Dynamik - außerdem sind sie denkbar ungeeignet für sekündliche Jobs und würden dabei in den meisten Fällen massiven Overhead vom Damm brechen wenn ich mich nicht arg täusche.
