Timestamp-cronjob-....

ich stelle mit die ganze zeit schon die frage wie ich meine "zeit" in das script einbaue....
im mom denke ich an einen timestamp jedoch find ich diese version sehr unsicher!
den ich meine wenn der timestamp so einfach eingebaut ist und jeder user "direkten" zugriff auf ihn hat dan wird es doch recht unsicher und schnell "hackbar" sein mein game...?!

cronjobs find ich schlecht da sie 1. nicht direkt zu mir und ich mein game gehören und 2. den server unnötig mit treffik belasten...

habt ihr noch andere ideen? oda möglichkeiten?

(mein game ist komplett in php geschrieben!)

wie welche methode nutzen andere BG?


ist es sinvoll java o-ä. einzubinden?
naja schreibt mal eure meinung....

Ich nutze timestamps und es funktioniert soweit auch gut. Für den globalen gamestate gibt es einen Eintrag 'nextupdate' in der Datenbank. Jeder page refresh überprüft diesen, wenn er <= now() ist wird ein lock gesetzt und der Spielstatus aktualisiert. Entities, die nur einzelnen Spielern gehören haben ähnliche Einträge und werden nach Bedarf (und ohne globales lock) aktualisiert. Ein Beispiel für letzteres wäre die Lebensenergie, die alle x ticks regeneriert. Vor Angriffen oder Anzeigen wird diese auf den neusten Stand gebracht (note: wichtig die Daten dann als float oder in einer anderen Einheit abzuspeichern, die es dir erlaubt bruchteile eines ganzen abzuspeichern. Dies ist für den Fall, dass ein update 2 sec hintereinanderkommt und in dieser Zeit dann auch nur ein Bruchteil eines Lebenspunktes regeneriert wurde.)

Das Spiel ist noch nicht öffentlich und ich habe nur eine kleine Gruppe Tester, also kann ich noch nichts über die Skalierbarkeit sagen. Hier im Forum und anderswo habe ich aber gehört, dass viele erfolgreiche Spiele ihre updates genauso lösen.

mfG,
Sören

Ich benutze auch keine Cronjobs. Wenn z.B. das Rohstofflager aktualisiert werden muss, passiert das immer nur für den Spieler, der gerade eingeloggt ist und wenn der Tick da ist. Außerdem werden die Daten vor einem Angriff aktualisiert oder sonst immer nur dann, wenn es für den jeweiligen Spieler wichtig ist.

Das klappt ganz wunderbar und es gab nie Probleme mit dem System. Ich halte es auch nicht für Sinnvoll, alle Spielerdaten zu aktualisiern, wenn die meisten ihre Daten zu jedem Tick gar nicht aufrufen (Wenn sie z. B. offline sind)

Original von Progralixx
Ich benutze auch keine Cronjobs. Wenn z.B. das Rohstofflager aktualisiert werden muss, passiert das immer nur für den Spieler, der gerade eingeloggt ist und wenn der Tick da ist. Außerdem werden die Daten vor einem Angriff aktualisiert oder sonst immer nur dann, wenn es für den jeweiligen Spieler wichtig ist.

Das klappt ganz wunderbar und es gab nie Probleme mit dem System. Ich halte es auch nicht für Sinnvoll, alle Spielerdaten zu aktualisiern, wenn die meisten ihre Daten zu jedem Tick gar nicht aufrufen (Wenn sie z. B. offline sind)

Dieses System hat 2 grosse Nachteile:
1. Zu Peakzeiten, wo der Server sowieso die groesste Last bearbeiten muss, wird diese noch einmal um ein vielfaches erhoeht, so dass du keine dauerhafte, niedrige Last hast, sondern enorm hohe Last zu bestimmten Momenten. Das ist wohl eher ineffektiv.

2. Du musst an jeder Stelle darauf achten.. je nach Spielkonzept koennen das zig Dinge sein, die da Probleme bereiten und leicht vergessen werden.. diverse Aktualisierungen bei Angriffen, Spionage uswusw...

Dieses System hat 2 grosse Nachteile:
1. Zu Peakzeiten, wo der Server sowieso die groesste Last bearbeiten muss, wird diese noch einmal um ein vielfaches erhoeht, so dass du keine dauerhafte, niedrige Last hast, sondern enorm hohe Last zu bestimmten Momenten. Das ist wohl eher ineffektiv.

2. Du musst an jeder Stelle darauf achten.. je nach Spielkonzept koennen das zig Dinge sein, die da Probleme bereiten und leicht vergessen werden.. diverse Aktualisierungen bei Angriffen, Spionage uswusw...

Zu 1) Naja fast. Wenn du eine feste Tick-Intervallzeit hast wird selbst zu Peakzeiten maximal 1 mal pro tick aktualisiert - nur eben häufiger überprüft ob es nun gerade nötig ist oder nicht.

Zu 2) das ist ein Nachteil, ja. Kapselung der Abfragen in einer entsprechende Klasse kann jedoch abhilfe schaffen. Diese würde dann intelligent als cache fungieren und die Daten bei Bedarf neu holen, bzw einfach direkt zurückgeben.

mfG,
Sören

Wie ist es denn wenn man real Echtzeit braucht. Gibt es noch andere Möglichkeiten als einen Hintergrundthread der alles abarbeitet was anfällt? Ich hab gehört das solle nur it C einigermaßen realisierbar sein, leider kann ich nur PHP, Delphi und Assembler. :lol:

Original von BuschnicK


Zu 1) Naja fast. Wenn du eine feste Tick-Intervallzeit hast wird selbst zu Peakzeiten maximal 1 mal pro tick aktualisiert - nur eben häufiger überprüft ob es nun gerade nötig ist oder nicht.

40 Angriffe sind auch bei einem Tick 40 Angriffe und nicht einer.. es geht ja nicht nur um Ressourcenverteilung. Und gerade komplexe (moeglichst reale - ala jedes Schiff schiesst, mit Schadensmodell, abwechselnd und nicht zahl ist groeser als zahl) Angriffsscripts ziehen Performance...

Zu 2) das ist ein Nachteil, ja. Kapselung der Abfragen in einer entsprechende Klasse kann jedoch abhilfe schaffen. Diese würde dann intelligent als cache fungieren und die Daten bei Bedarf neu holen, bzw einfach direkt zurückgeben.

Klar hilft es, dennoch muss es an jeder entsprechenden Stelle beruecksichtigt werden und ist eine kein kleines Fehlerrisiko

Zu 1) Naja gut, aber irgendwie kann ich dir nicht mehr ganz folgen. Wenn viel los ist im Spiel dann ist halt viel los ;-) Das frisst Performance so oder so. Oder versteh ich dich falsch? Ob jetzt ein cron job deine Scripts für die Angriffe triggert oder der Spieler selbst ist in dem Falle doch irrelevant? (Es sei denn der cron Job läuft auf einem anderen Rechner...)

Zu 2) Völlig richtig.

Da ich momentan aber ohne direkten Serverzugang (insbesondere keine cron jobs o.ä.) experimentiere und nur mit PHP und mySQL auskommen muss ist eine andere Lösung für mich eh nicht drin.

mfG,
Sören

ich habs ganz einfach gelöst.. ein programm ruft meine tick.php zu jeder vollen stunde auf dieses schaut obs schon ticken kann, und wenn ja, tickts. (überprüfung da dass programm auch bei den meisten meiner mods lauft, damit ein internetausfall von mir nicht das spiel stoppt..)
das erledigt alles in einem, auch kämpfe. viele kämpfe auf einmal werden erst ab 2 mia+ schiffen problematisch, da geht die berechnungszeit mal auf ca.20 sec. ich hab nur einen webspace bei inode, keinen eigenen server..

im havok fehlt halt die überprüfung..

@Nuky: Wenn deine tick.php dann aber auch direkt auf dem Spielserver läuft besteht doch kaum ein Unterschied mehr zu meiner Lösung? Nochmal im Vergleich:
- jeder Seitenaufruf prüft ob tick laufen sollte (also ob z.B. eine volle Stunde und kein lock vorliegt)
- tick.php wird ausgeführt.

Bei dir startet tick.php per cron, bzw selbstgemachtem cron jede Stunde.

Unterschiede, die ich jetzt noch sehe:
- meine Überprüfung bei jedem Seitenaufruf. Die ist performance technisch kaum der Rede wert.
- in meinem Falle muss der user theoretisch mal länger auf die Seite warten, wenn er das "Pech" hatte die tick.php zu starten. Dies liesse sich im Zweifelsfall aber durch einen fork, also neuen thread lösen.

war kein "besser/schlechter" post, war nur tatsache wies bei mir is - wir haben eig. eh die gleiche lösung..

Ich habe festgestellt, dass es für mein Spiel mehr Performance gibt, wenn ich die Aktualisierungen verteile, als dass ich jede Stunde für alle Spieler - egal, ob die Aktualisierung bei jedem Spieler nötig ist, oder nicht - ein Script ablaufen lasse.

Aber ich denke, dass es auch sehr auf die Art des Spiels ankommt, welche Variante am effektivsten ist. In meinem Fall ist es eben die ohne CronJobs.

Original von BuschnicK
Zu 1) Naja gut, aber irgendwie kann ich dir nicht mehr ganz folgen. Wenn viel los ist im Spiel dann ist halt viel los ;-) Das frisst Performance so oder so. Oder versteh ich dich falsch? Ob jetzt ein cron job deine Scripts für die Angriffe triggert oder der Spieler selbst ist in dem Falle doch irrelevant? (Es sei denn der cron Job läuft auf einem anderen Rechner...)

Nein. :-) Sagen wir ich greife jemanden an. Starte den Angriff um 20:00 Uhr. Er erfolgt um 23:00.

Wir loggen uns beide nicht mehr ein bis zum Angriff.

Allerdings am naechsten Abend um 20:00.

So.

Nun sind zig Dinge passiert, zum Beispiel vor meinem Angriff 10 andere Angriffe, Ressourcenverteilung (und zwar jeweils passend zu den Angriffen!!! etc..).

Du musst also immer genau achten welche Ereignisse in welcher Reihenfolge geschehen.

Das Problem ist aber eben, dass sich jede Menge Leute um 20:00 Uhr einloggen und im Spiel sind. Mehr als in der Nacht, obwohl jedoch die meisten Angriffe (oder jede Menge) eben in der Nacht stattfinden.

Der Vorteil von Daemon Programmen oder Cron ist dann eben, dass die Berechnungen sich auf den gesamten Tag verteilen.

Das mag teilweise ein wenig Overhead sein (z.B. Ressourcenverteilung regelmaessig, geht aber ja auch mit einem SQL query), aber es reduziert die Hochzeiten um einiges.