db-updates/selects werden wohl den server kalt legen..

[sagg]

Hi wiedermal,

also ich soll ein Onlinegame coden, das nicht wie die meisten Games tickbasierend ist, sondern in realtime abläuft, sprich es kann jede Sekunde irgendeine Einheit, ein Gebäude oder was auch immer fertig werden.
Wenn der User zu dem Zeitpunkt nicht eingeloggt ist, ist das ja kein Problem, da ich alles beim Login des Users nachberechnen kann.
Aber was ist, wenn der User eingeloggt ist? Ich kann doch nicht bei jedem Seitenaufruf die DB überprüfen lassen, da stehen locker mal paar tausend Einträge drinne.

Hat einer ne Idee wie ich das am besten lösen kann? In anderen Games geht's ja auch..irgendwie..

[pekka]

Also ich kenn kein Browsergame, das auf Sekundenbasis arbeitet. Allerdings kenn ich auch nicht viele Browsergames

Ich kann doch nicht bei jedem Seitenaufruf die DB überprüfen lassen, da stehen locker mal paar tausend Einträge drinne.

Können schon! Mit einer kleinen Serverfarm..... Vielleicht hat Inktomi ja mal Rabattwochen

Im Ernst: Ich kann mir nicht vorstellen, daß sowas vernünftig funktioniert. Die Serverlast wird gigantisch; Du bekommst säuisch Traffic durch sekündliche Statusabfragen; Du mußt ein browserbasiertes Echtzeit-Interface bauen, das via Javascript (Komplette Reloads kannst Du bei dem Rhythmus ja vergessen) laufend das Spielfeld und die Controls aktualisiert.... Ich halte das für utopisch.

[Payne_of_Death]

hmm jede Sekunde ist wohl kaum realistisch, daher gibt es ja auch so lange Wartezeiten bei diesen Games bis zum Fertigstellen des Teils X

Die DB wird eigentlich durch das Javasript entlastet ist man eingeloggt sieht man einen Timer der abläuft.....Kommt man irgendwann wieder wird in der DB der Status des Bauens wiederrum abgefragt ist da der Zeitpunkt noch nicht abgelaufen kommt wieder der Timer ist es fertig wird die Einheit verfügbar.....
Wenn der Timer nicht abgelaufen ist darf kein DB Select erfolgen....

Anders wohl nur mit einer Serverfarm möglich und einem gefüllten Bankkonto......

Echtzeitspiele mit Direct-X, Sockets und C++ wohl das einzig sinnvolle.....

Browsergames sind doch eh öde......

[Mudder]

Ihr dürft das jetzt nicht mit ner Echtzeitgrafik verwechseln welche da ne Einheit quer übern Bildschirm jagt.

Aber dennoch ist die nahezu einzige Möglichkeit zu schauen ob seit dem letzten Seitenaufruf ne Action vollendet wurde. Die Datenbanklast ist bei solchen BGs extrem hoch, doch sie ist die derzeit verbreitete Variante.

Damit ein Spieler nun nicht sekündlich auf den Reloadbutton klickt, haben einige Spiele mit dieser "Echtzeitengine" einen Reloadschutz eingebaut um die Spieler etwas auszubremsen.

Es kommt aber letztendlich auf das Spiel ansich an. Hier ist der Designer gefragt, welcher das Spiel so auslegen sollte das es sich für den Spieler nicht lohnt (bzw. dies nötig ist) ständig zu aktuallisieren. Komplexe Spiele mit Echtzeitbrechnung schön und gut, doch diese müssen aus Belastungssicht her langsam ablaufen. Die Aktionen des Spielers sollten sich in Ruhe über den ganzen Tag verteilen. Man lässt ihn 3-5x am Tag einloggen und er fühlt sich aktiv und gefordert. Wenn er hierbei aber nur mal kurz die Karte unter Augenschein nimmt und schnell was neues in Auftrag gibt, bleibt die Serverlast dennoch relativ gering.

[pekka]

Aber wofür dann sekündliche Ticks? Tut's da nicht jede Minute?

[sagg]

Ihr dürft das jetzt nicht mit ner Echtzeitgrafik verwechseln welche da ne Einheit quer übern Bildschirm jagt.

Richtig.
Es ist eine stinknormale Website mit ein paar Bildchen hier und da.
Und selbst wenn, erstens ist es nicht mein Server auf dem der Spass später laufen soll, und zweitens hat der 1TB Traffic, das sollte ausreichen.

aber pekka sagt's, wenn man sich nur 5 mal am Tag einloggen sollte, dann wäre es ziemlich egal ob das paar Sekunden früher oder später fertig ist. Aber das die DB-Last enorm ist, ist wohl wahr.
Das Game soll gegenüber anderen OG's mit enormer Geschwindigkeit gespielt werden, alles dauert nur paar Minuten bis zur Fertigstellung und wenn man nach einem Krieg mal wirklich nichts mehr haben sollte, dann ist man im warsten Sinne des Wortes: draussen.

ps.: ich wiederhole, ICH hab mir das nicht ausgedacht. *g*

Und dadurch, das es so schnell läuft, muss die DB natürlich ständig überprüft werden.
Aber ich überleg gerade, ob ich die "Endzeiten" Userunabhängig vlt. in ein "Array" packen kann, und nur wenn time()=kleinste_endzeit ist ein DB-Update kommt, fehlt mir jetzt nur der Ansatz, wie ich das Brot backen soll.

Aber ich denk mal das wäre schon eine starke Entlastung.

Und so nebenbei: insel-monarchie.de ist glaub ich auch auf Sekundenbasis aufgebaut.

Achso, bevor ich's vergesse, der Reloadschutz ist eigentlich ne gute Idee, muss nur mal sehen ob das bei dem Game Sinn macht, ist ja wie gesagt Sekundenbasierend..
Timer per JavaScript sind schon drinne, ohne die wäre die DB-Last ja schon fast unerträglich.


soo..ich hoff ich hab nix vergessen *g*