Tach zusammen,
also ich bin gerade dabei ein Ticksystem zu erstellen und stehe vor einem Problem:
das Programmieren ist das Kleinste dabei (inzwischen hab ich 5 Jahre PHP, C & Java Erfahrung). Wie zum Teufel soll ich die Ticks errechnen?
Möglichkeiten die mir durch den Kopf gehen:
1. dynamische Ticks. Jeder User bekommt einen Tick alle, sagen wir, 10 Minuten ab seiner Registrierung.
2. globale Ticks. Die Ticks werden vom Server vorgegeben und danach richten sich dann logischerweise alle User.
Wie ich die erste Möglichkeit hinbekomme ist mir klar und ehrlich gesagt hat diese Methode auch einen gewissen Reiz. Dadurch wird es unheimlich schwer vorauszusagen wieviele Ressourcen der User hat zu einem gewissen Zeitpunkt (Angriff oder so).
Wie auch immer...
Ich brauche eine Idee zu Punkt 2. Ich könnte einen Timestamp nehmen und daraus ausrechnen wie viele Ticks vergangen sind. Danach rechne ich aus dem Registrationsdatum des Users wieviele Ticks er haben müsste, schaue in der Database nach wie viele Ticks er schon hatte und kann so errechnen wie viele er bekommen müsste.
Aber das ist sehr umständlich und das geht sicher auch mit weniger Aufwand.
Hat jemand da ne nette Idee?
Tick System
gepostet vor 19 Jahre, 9 Monate von None
gepostet vor 19 Jahre, 9 Monate von Kampfhoernchen
Wie wärs damit:
Du speicherst im Datensatz des Users mit ab, wann du zuletzt ein Update gemacht hast - z.B. Bei Tick 1120.
Jetzt haben wir Tick 1150 (aus timestamp berechnen), der User hat sich jetzt neu einloggt. Also musst du ein Update über 30 Ticks durchführen, und dann den Datensatz des Users auf Tick 1150 updaten.
Hoffe das war das was du meinst.
Du speicherst im Datensatz des Users mit ab, wann du zuletzt ein Update gemacht hast - z.B. Bei Tick 1120.
Jetzt haben wir Tick 1150 (aus timestamp berechnen), der User hat sich jetzt neu einloggt. Also musst du ein Update über 30 Ticks durchführen, und dann den Datensatz des Users auf Tick 1150 updaten.
Hoffe das war das was du meinst.
gepostet vor 19 Jahre, 9 Monate von None
Jup, war genau das was ich wollte. Dadurch spar ich mir schonmal ne Menge Daten in der Datenbank.
Eine 10-stellige Zahl is immerhin um einiges kleiner als ein Timestamp.
Eine 10-stellige Zahl is immerhin um einiges kleiner als ein Timestamp.
gepostet vor 19 Jahre, 9 Monate von Gambler
Ticks pro User sind doch schwachsinnig. Da wirste spätestens Probleme bekommen wenn 2 User interagiern, sprich nen Fight haben oder so. Die einfachste Methode isn Cron Job alle X Minuten laufen zu lassen.
gepostet vor 19 Jahre, 9 Monate von Mudder
Es kommt aufs Gesamtkonzept an doch mit dem Cronjob stehst bei Echtzeitberechnung dumm da, genauswo wie wenn du alle 10 Minuten mehr als 1000 Useraccounts aufrechnen musst.
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
Original von Mudder
Es kommt aufs Gesamtkonzept an doch mit dem Cronjob stehst bei Echtzeitberechnung dumm da
Er will ja keine Echtzeit sondern Ticks und da würde ich auch einen Cronjob empfehlen.
gepostet vor 19 Jahre, 9 Monate von Kampfhoernchen
Original von Samson
Eine 10-stellige Zahl is immerhin um einiges kleiner als ein Timestamp.
Äh, Timestamp = Sekunden seit dem 1.1.1970 um 0:00:00, oder? Aktuell stehen wir bei etwas mehr als 1.000.000.000 (1 Milliarde), das sind auch 10 Stellen. Speicherplatz sparst du da nicht wirklich. Denn ein TS ist nix anderes als eine 10-stellige Zahl.
gepostet vor 19 Jahre, 9 Monate von None
Ich muss gestehn, ich hab die Ziffern noch nie gezählt *gg*
Jedenfalls habe ich auch nicht vor eine 10 stellige Tickzeit (nennt man das so? *gg*) zu erreichen.
Nein, werde ich nicht. Nicht solange ich meiner Klasse nur eine Userid übergeben muss und die dann alles rechnet.
Es gibt dann 3 "Events" (um in Programmiersprachen zu sprechen) die eine Berechnung auslösen:
Login, Angriff & Spionage, Aktuallierung der Bauseiten
Ich finde ein CronJob hat eher Nachteile gegenüber der "Bei Bedarf ausführen"-Variante.
Jedenfalls habe ich auch nicht vor eine 10 stellige Tickzeit (nennt man das so? *gg*) zu erreichen.
Ticks pro User sind doch schwachsinnig. Da wirste spätestens Probleme bekommen wenn 2 User interagiern, sprich nen Fight haben oder so. Die einfachste Methode isn Cron Job alle X Minuten laufen zu lassen.
Nein, werde ich nicht. Nicht solange ich meiner Klasse nur eine Userid übergeben muss und die dann alles rechnet.
Es gibt dann 3 "Events" (um in Programmiersprachen zu sprechen) die eine Berechnung auslösen:
Login, Angriff & Spionage, Aktuallierung der Bauseiten
Ich finde ein CronJob hat eher Nachteile gegenüber der "Bei Bedarf ausführen"-Variante.
gepostet vor 19 Jahre, 9 Monate von Sogil
...und ich dachte immer ein timestamp waere eine 32bit integer Variable
gepostet vor 19 Jahre, 9 Monate von HSINC
sogil es gibt unterschiede zwischen einem unixtimestamp (das ist nen int mit sec seit 1970) und einem mysqltimestamp (YYYY[MM[DD[HH[II[SS]]]]])
gepostet vor 19 Jahre, 9 Monate von Gambler
Naja es gibt unter der Bezeichnung versch. Dinge. Wer schonmal probiert hat nen PHP Timestamp in ein MySQL Timestamp Feld zu schreiben weiss wovon ich rede. Genau genommen heisst es bei PHP Unix Timestamp.
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Ich persönlich tendiere zu der 'Bei Bedarfs-Variante'. Jedes Objekt besitzt eine Methode 'Refresh()', diese aktualisiert die gesamten internen Rohstoffe des Objektes und ihre direkt abhängigen Kinder.
Aktionen wie Gebäudebau und ähnliches werden über einen andauernd laufenden Eventhandler, der auch gleichzeitig als Webserver dient, abgearbeitet. Dieser Eventhandler besitzt eine Tabelle mit den Objekte, die eine Aktion zu einem bestimmten Zeitpunkt auslösen.
Die Web-Oberfläche und dieser Eventhandler kann also ein Objekt bei Bedarf aktualisieren. Loggt sich ein User nicht mehr ein und führt keine Aktionen mehr durch, so verbraucht dieser User bei absoluter Inaktivität ohne Angriffen keinerlei Rechenzeit. Dies war eines meiner Ziele der Engine, da in der früheren Engine die inaktiven genausoviel Rechenzeit wie die aktiven gefressen haben.
Aktionen wie Gebäudebau und ähnliches werden über einen andauernd laufenden Eventhandler, der auch gleichzeitig als Webserver dient, abgearbeitet. Dieser Eventhandler besitzt eine Tabelle mit den Objekte, die eine Aktion zu einem bestimmten Zeitpunkt auslösen.
Die Web-Oberfläche und dieser Eventhandler kann also ein Objekt bei Bedarf aktualisieren. Loggt sich ein User nicht mehr ein und führt keine Aktionen mehr durch, so verbraucht dieser User bei absoluter Inaktivität ohne Angriffen keinerlei Rechenzeit. Dies war eines meiner Ziele der Engine, da in der früheren Engine die inaktiven genausoviel Rechenzeit wie die aktiven gefressen haben.
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
Original von Samson
Ich finde ein CronJob hat eher Nachteile gegenüber der "Bei Bedarf ausführen"-Variante.
Und welche?
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Meiner Meinung nach folgende:
- Inaktive belasten den Cronjob, da sie auch abgefragt werden müssen
- Cronjobs sind zwar regelmäßig, aber die Abstände sind meist groß (1 - 10 Minuten)
Das Problem tritt auf, wenn Spieler A zum Zeitpunkt 0 nen Gebäude erweitern möchte. Zum Zeitpunkt 5 wird es fertig, der Cronjob kommt erst zum Zeitpunkt 10.
Was passiert mit den 5 'Sekunden', in denen das Gebäude schon mehr produziert hätte müssen? Wird das wieder rückwärts verrechnet (mehr Aufwand) oder wird es ignoriert (Ungenauigkeit)
- Cronjobs erzeugen Stoßlasten
- Inaktive belasten den Cronjob, da sie auch abgefragt werden müssen
- Cronjobs sind zwar regelmäßig, aber die Abstände sind meist groß (1 - 10 Minuten)
Das Problem tritt auf, wenn Spieler A zum Zeitpunkt 0 nen Gebäude erweitern möchte. Zum Zeitpunkt 5 wird es fertig, der Cronjob kommt erst zum Zeitpunkt 10.
Was passiert mit den 5 'Sekunden', in denen das Gebäude schon mehr produziert hätte müssen? Wird das wieder rückwärts verrechnet (mehr Aufwand) oder wird es ignoriert (Ungenauigkeit)
- Cronjobs erzeugen Stoßlasten
gepostet vor 19 Jahre, 9 Monate von Gambler
Müssen sie nicht. Man kann z.B. eine Tabelle erstellen wo alles reinkommt was noch läuft. Der Cronjob holt sich was gerade fertig wurde und tut irgendwas damit.
Ich halte eine gemischte Lösung für am besten. Ganz ohne Cron muss man stark aufpassen dass alles live abläuft und sehr viel mit Timestamps versehen.
Was passiert wenn ein Kampf stattfand wenn beide Spieler grad nen Tag lang off waren? In der Zwischenzeit kann sehr viel passieren und dann stimmt der Kampf nicht mehr. Natürlich kann man das abfangen aber es ist doch nicht gerade wenig was man dann machen muss.
Als Alternative so wie ich es vorhab zu machen gibts auch noch statts nem Cron ein C Programm. Die sind sehr schnell und können wirklich sekündlich Aktualisierungen durchführen.
Ich halte eine gemischte Lösung für am besten. Ganz ohne Cron muss man stark aufpassen dass alles live abläuft und sehr viel mit Timestamps versehen.
Was passiert wenn ein Kampf stattfand wenn beide Spieler grad nen Tag lang off waren? In der Zwischenzeit kann sehr viel passieren und dann stimmt der Kampf nicht mehr. Natürlich kann man das abfangen aber es ist doch nicht gerade wenig was man dann machen muss.
Als Alternative so wie ich es vorhab zu machen gibts auch noch statts nem Cron ein C Programm. Die sind sehr schnell und können wirklich sekündlich Aktualisierungen durchführen.
gepostet vor 19 Jahre, 9 Monate von None
Das sind auch die Punkte an die ich gedacht hatte. ConJobs machen das Spiel ein wenig statischer und es ist nicht mehr möglich auf die Sekunde genau zu rechnen. Was ja aber auch gewollt sein kann.
Ich denke da sollte sich jedes Spiel selbst eine Meinung bilden und dann eine Methode wählen die am geschicktesten ist.
Oh ja...ich mag einige Sachen an mysql nicht so. Dazu gehört das DATE-Feld und SET. Ich hasse es wenn ich diese Werte immer in Strings bekomme, die Verarbeitung mit Bits wäre um einiges einfacher...
Weiß da zufällig jemand ob man irgendwie die Bits aus mySQL herausbekommt? Ich hab bisher noch keine Möglichkeit gefunden.
Ich denke da sollte sich jedes Spiel selbst eine Meinung bilden und dann eine Methode wählen die am geschicktesten ist.
Naja es gibt unter der Bezeichnung versch. Dinge. Wer schonmal probiert hat nen PHP Timestamp in ein MySQL Timestamp Feld zu schreiben weiss wovon ich rede. Genau genommen heisst es bei PHP Unix Timestamp.
Oh ja...ich mag einige Sachen an mysql nicht so. Dazu gehört das DATE-Feld und SET. Ich hasse es wenn ich diese Werte immer in Strings bekomme, die Verarbeitung mit Bits wäre um einiges einfacher...
Weiß da zufällig jemand ob man irgendwie die Bits aus mySQL herausbekommt? Ich hab bisher noch keine Möglichkeit gefunden.
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Gambler: Du meinst also es folgendermaßen:
Refresh, wenn Webseite es anfordert.
und sagen wir mal alle 5 Minuten nen Cronjob, der die verbleibenden Objekte aufräumt?
Dieses hätte ich gemacht, wenn ich keinen andauernden Event-Handler hätte, der im Hintergrund läuft, ansonsten habe ich lieber einen Dienst, der rund um die Uhr läuft.
Refresh, wenn Webseite es anfordert.
und sagen wir mal alle 5 Minuten nen Cronjob, der die verbleibenden Objekte aufräumt?
Dieses hätte ich gemacht, wenn ich keinen andauernden Event-Handler hätte, der im Hintergrund läuft, ansonsten habe ich lieber einen Dienst, der rund um die Uhr läuft.
gepostet vor 19 Jahre, 9 Monate von None
Wozu einen EventHandler der im Hintergrudn läuft?
Is doch alles mit PHP selbst möglich. In PHP5 mit den neuen OOP Features klappt das super auch so. Sogar in PHP 4 wäre es mit der Pseudo-OOP kein Problem, aber etwas langsamer.
Is doch alles mit PHP selbst möglich. In PHP5 mit den neuen OOP Features klappt das super auch so. Sogar in PHP 4 wäre es mit der Pseudo-OOP kein Problem, aber etwas langsamer.
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Der Grund ist, dass ich meine Objekte gerne live aktualisiert haben möchte und so keine Verzerrungen oder aufwendige Rückberechnungen.
Zum Beispiel: Wie möchtest du folgendes Szenario abdecken:
09:00 Uhr: Spieler macht ne Bauliste: 3x Metallmine und geht offline
09:15 Uhr: Metallmine 2 würde fertig werden ( 300 Metall die halbe Stunde )
09:30 Uhr: Metallmine 3 würde fertig werden ( 600 Metall die halbe Stunde )
10:00 Uhr: Metallmine 4 würde fertig werden ( 1200 Metall die halbe Stunde )
12:00 Uhr: Der Spieler kommt online [kein Angriff dazwischen]
Er müsste jetzt 3150 Metall aus den Metallminen geschöpft haben. Ohne Eventhandler müsstest du Rückberechnungen machen, da zum Beispiel der Cronjob erst um 09:20 Uhr anspringt. Er hat dann drei Möglichkeiten:
1) Aktualisierung der Rohstoffe mit Mine 1 und Erhöhung der Stufe(Zuwenig Rohstoffe)
2) Erhöhung der Stufe unt Aktualisierung der Rohstoffe mit Mine 2 (Zuviel Rohstoffe)
3) Nachspielen der vergangenen 10 Minuten (bei 10 Minuten Cronjob) [Aufwand]
Würdest du sogar nur den Bau um 12:00 registrieren, müsstest du bei korrekter Behandlung 2 Stunden durchsimulieren.
Zum Beispiel: Wie möchtest du folgendes Szenario abdecken:
09:00 Uhr: Spieler macht ne Bauliste: 3x Metallmine und geht offline
09:15 Uhr: Metallmine 2 würde fertig werden ( 300 Metall die halbe Stunde )
09:30 Uhr: Metallmine 3 würde fertig werden ( 600 Metall die halbe Stunde )
10:00 Uhr: Metallmine 4 würde fertig werden ( 1200 Metall die halbe Stunde )
12:00 Uhr: Der Spieler kommt online [kein Angriff dazwischen]
Er müsste jetzt 3150 Metall aus den Metallminen geschöpft haben. Ohne Eventhandler müsstest du Rückberechnungen machen, da zum Beispiel der Cronjob erst um 09:20 Uhr anspringt. Er hat dann drei Möglichkeiten:
1) Aktualisierung der Rohstoffe mit Mine 1 und Erhöhung der Stufe(Zuwenig Rohstoffe)
2) Erhöhung der Stufe unt Aktualisierung der Rohstoffe mit Mine 2 (Zuviel Rohstoffe)
3) Nachspielen der vergangenen 10 Minuten (bei 10 Minuten Cronjob) [Aufwand]
Würdest du sogar nur den Bau um 12:00 registrieren, müsstest du bei korrekter Behandlung 2 Stunden durchsimulieren.
gepostet vor 19 Jahre, 9 Monate von HSINC
eigentlich müsste man ja nur die zeiten bis 09:15 Uhr, von 9:15 bis 9:30, von 9:30 bis 10:00, von 10:00 bis 12:00 kalkulieren. wären 4 kalkulationsschritte die an einem zeitpunkt ausgeführt werden müssen. kommt wohl auf den umfang der berechnung drauf an und was das maximum der kalkschritte ist ob man es so macht.
gepostet vor 19 Jahre, 9 Monate von Gambler
Ich bin auch der Meinung dass es teilweise etwas zu aufwendig ist Rückberechnungen durchzuführen. Bei Kämpfen ist sowas auch nicht einfach, da müsste man wirklich jeden Kack mit nem Timestamp versehen.
gepostet vor 19 Jahre, 9 Monate von None
Original von TheUndeadable
Der Grund ist, dass ich meine Objekte gerne live aktualisiert haben möchte und so keine Verzerrungen oder aufwendige Rückberechnungen.
Zum Beispiel: Wie möchtest du folgendes Szenario abdecken:
09:00 Uhr: Spieler macht ne Bauliste: 3x Metallmine und geht offline
09:15 Uhr: Metallmine 2 würde fertig werden ( 300 Metall die halbe Stunde )
09:30 Uhr: Metallmine 3 würde fertig werden ( 600 Metall die halbe Stunde )
10:00 Uhr: Metallmine 4 würde fertig werden ( 1200 Metall die halbe Stunde )
12:00 Uhr: Der Spieler kommt online [kein Angriff dazwischen]
Er müsste jetzt 3150 Metall aus den Metallminen geschöpft haben. Ohne Eventhandler müsstest du Rückberechnungen machen, da zum Beispiel der Cronjob erst um 09:20 Uhr anspringt. Er hat dann drei Möglichkeiten:
Hopla, das stimmt...darüber hab ich mir bisher noch keine Gedanken gemacht. Eine Frage:
Wie läuft so ein EventHandler im Hintergrund?
Ich sehe zwei Möglichkeiten:
für jedes Event (in dem Fall Bauen) einen Thread einrichten und laufen lassen. Ist der Timer im Thread abgelaufen, SQL Befehl abschicken und Thread beenden.
Wenig Programmierarbeit, allerdings verbrät das ne Menge Leistung...
Die CronJob Methode: Eventdaten in ne Datenbank schreiben und der EventHandler schaut alle 5 Minuten nach was er erledigen kann.
Hast du eine andre Lösung gefunden?
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Meine Lösung:
"Die CronJob Methode: Eventdaten in ne Datenbank schreiben und der EventHandler schaut alle 5 Minuten nach was er erledigen kann. "
Er schaut nur jede Sekunde in die Datenbank, bzw hat eine temporäre Tabelle, die diese Abfrage überflüssig macht. Er läuft als eigenständiger Dienst, bzw als Kommandozeilenprogramm, welches rund um die Uhr läuft.
Erstere Möglichkeit würde ich meiden, da Threads zuviel Speicher und Geschwindigkeit des Betriebssystems fressen.
"Die CronJob Methode: Eventdaten in ne Datenbank schreiben und der EventHandler schaut alle 5 Minuten nach was er erledigen kann. "
Er schaut nur jede Sekunde in die Datenbank, bzw hat eine temporäre Tabelle, die diese Abfrage überflüssig macht. Er läuft als eigenständiger Dienst, bzw als Kommandozeilenprogramm, welches rund um die Uhr läuft.
Erstere Möglichkeit würde ich meiden, da Threads zuviel Speicher und Geschwindigkeit des Betriebssystems fressen.
gepostet vor 19 Jahre, 9 Monate von None
Ist die tempörere Tabelle ne Datei?
Hab noch nie probiert mehrere Programme / Scripte auf ne Datei zugreifen zu lassen. Wenn dein Handler ein Event erfolgreich ausgeführt hat sollte er dies aus der datei löschen, denke ich. Jetzt kann es aber durchaus sein das genau in diesem Zeitpunkt PHP/Perl/Java usw. versucht auf genau diese Datei zuzugreifen und neue Daten reinzuschreiben.
Beides geht nicht gleichzeitig. Wie umgehst du das?
Sorry wenn ich etwas neugierig bin, aber deine Idee is wirklich gut. Wie du gesagt hast Threads sind nahezu unmöglich, außer der Papa hat n schön dickes Konto und man kann sich n Highend-Server leisten *gg*
Hab noch nie probiert mehrere Programme / Scripte auf ne Datei zugreifen zu lassen. Wenn dein Handler ein Event erfolgreich ausgeführt hat sollte er dies aus der datei löschen, denke ich. Jetzt kann es aber durchaus sein das genau in diesem Zeitpunkt PHP/Perl/Java usw. versucht auf genau diese Datei zuzugreifen und neue Daten reinzuschreiben.
Beides geht nicht gleichzeitig. Wie umgehst du das?
Sorry wenn ich etwas neugierig bin, aber deine Idee is wirklich gut. Wie du gesagt hast Threads sind nahezu unmöglich, außer der Papa hat n schön dickes Konto und man kann sich n Highend-Server leisten *gg*
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Die temporäre Tabelle befindet sich im Speicher des Eventhandlers.
Beim Anlegen werden die Ereignisse in die Datenbank und in den Speicher geschrieben, ausgelesen wird nur aus dem Speicher und sollte der Eventhandler abschmieren, so kann er die noch abzuarbeitenden Ereignisse aus der Datenbank laden.
Da sich der Webserver und der Eventhandler in einem Prozess befinden, gibt es bei ordentlicher Synchronisierung keinerlei Probleme mit gleichzeitigem Zugriff, da Thread B erst warten muss, bis Thread A seine Arbeiten am Objekt erledigt hat.
Der Nachteil meiner Methode ist halt, dass du einen rund um die Uhr laufenden Eventhandler brauchst, den es bei vielen Providern, bzw Webspaces gar nicht erst gibt.
Für PHP würde ich filelocking nutzen. Irgendwo hier in dem Forum liegt ne Klasse von mir, die garantiert, dass nur ein Request gleichzeitig auf ein Objekt zugreift.
Beim Anlegen werden die Ereignisse in die Datenbank und in den Speicher geschrieben, ausgelesen wird nur aus dem Speicher und sollte der Eventhandler abschmieren, so kann er die noch abzuarbeitenden Ereignisse aus der Datenbank laden.
Da sich der Webserver und der Eventhandler in einem Prozess befinden, gibt es bei ordentlicher Synchronisierung keinerlei Probleme mit gleichzeitigem Zugriff, da Thread B erst warten muss, bis Thread A seine Arbeiten am Objekt erledigt hat.
Der Nachteil meiner Methode ist halt, dass du einen rund um die Uhr laufenden Eventhandler brauchst, den es bei vielen Providern, bzw Webspaces gar nicht erst gibt.
Für PHP würde ich filelocking nutzen. Irgendwo hier in dem Forum liegt ne Klasse von mir, die garantiert, dass nur ein Request gleichzeitig auf ein Objekt zugreift.
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
Vorweg: Ihr kommt irgendwie alle vom Thema ab und redet von Echteit-BGs und nicht mehr von Tick-basierenden BGs
- Inaktive belasten den Cronjob, da sie auch abgefragt werden müssen
Jo, das ist klar, aber Inaktive sollten eben nach einiger Zeit eh gelöscht werden, dann ist die Überlast kaum messbar.
- Cronjobs sind zwar regelmäßig, aber die Abstände sind meist groß (1 - 10 Minuten)
Das Problem tritt auf, wenn Spieler A zum Zeitpunkt 0 nen Gebäude erweitern möchte. Zum Zeitpunkt 5 wird es fertig, der Cronjob kommt erst zum Zeitpunkt 10.
Was passiert mit den 5 'Sekunden', in denen das Gebäude schon mehr produziert hätte müssen? Wird das wieder rückwärts verrechnet (mehr Aufwand) oder wird es ignoriert (Ungenauigkeit)
Genau das meine ich... du redest von Echtzeit aber es geht hier um Ticks und die sind meist wesentlich länger als 1 Minute.
Und sobald man Ticks hat kann etwas nicht zu einem halben Tick fertig werden (betrifft dein Beispiel, dass ein Gebäude zum Zeitpunkt 5 fertig sein soll, also mitten im Tick, wenn dieser von 0 bis 10 geht...).
- Cronjobs erzeugen Stoßlasten
Dagegen ist nichts zu sagen, aber bei Tick-Systemen für jeden User einzeln zu rechnen erzeugt im Endeffekt mehr Last.
Das sind auch die Punkte an die ich gedacht hatte. ConJobs machen das Spiel ein wenig statischer und es ist nicht mehr möglich auf die Sekunde genau zu rechnen.
Wieder: Bei Tick-Systemen rechnet man in Ticks und nicht in Sekunden.
Oh ja...ich mag einige Sachen an mysql nicht so. Dazu gehört das DATE-Feld und SET. Ich hasse es wenn ich diese Werte immer in Strings bekomme, die Verarbeitung mit Bits wäre um einiges einfacher...
Weiß da zufällig jemand ob man irgendwie die Bits aus mySQL herausbekommt? Ich hab bisher noch keine Möglichkeit gefunden.
Dazu habe ich mal was geschrieben: http://www.galaxy-news.de/forum/viewtopic.php?p=1122#1122
Stichwort: Bitweise Operatoren
Wozu einen EventHandler der im Hintergrudn läuft?
Is doch alles mit PHP selbst möglich. In PHP5 mit den neuen OOP Features klappt das super auch so. Sogar in PHP 4 wäre es mit der Pseudo-OOP kein Problem, aber etwas langsamer.
Der im Hintergrund laufende Event-Handler kann doch in PHP geschrieben sein...
Original von TheUndeadable
- Inaktive belasten den Cronjob, da sie auch abgefragt werden müssen
Jo, das ist klar, aber Inaktive sollten eben nach einiger Zeit eh gelöscht werden, dann ist die Überlast kaum messbar.
Original von TheUndeadable
- Cronjobs sind zwar regelmäßig, aber die Abstände sind meist groß (1 - 10 Minuten)
Das Problem tritt auf, wenn Spieler A zum Zeitpunkt 0 nen Gebäude erweitern möchte. Zum Zeitpunkt 5 wird es fertig, der Cronjob kommt erst zum Zeitpunkt 10.
Was passiert mit den 5 'Sekunden', in denen das Gebäude schon mehr produziert hätte müssen? Wird das wieder rückwärts verrechnet (mehr Aufwand) oder wird es ignoriert (Ungenauigkeit)
Genau das meine ich... du redest von Echtzeit aber es geht hier um Ticks und die sind meist wesentlich länger als 1 Minute.
Und sobald man Ticks hat kann etwas nicht zu einem halben Tick fertig werden (betrifft dein Beispiel, dass ein Gebäude zum Zeitpunkt 5 fertig sein soll, also mitten im Tick, wenn dieser von 0 bis 10 geht...).
Original von TheUndeadable
- Cronjobs erzeugen Stoßlasten
Dagegen ist nichts zu sagen, aber bei Tick-Systemen für jeden User einzeln zu rechnen erzeugt im Endeffekt mehr Last.
Original von Samson
Das sind auch die Punkte an die ich gedacht hatte. ConJobs machen das Spiel ein wenig statischer und es ist nicht mehr möglich auf die Sekunde genau zu rechnen.
Wieder: Bei Tick-Systemen rechnet man in Ticks und nicht in Sekunden.
Original von Samson
Oh ja...ich mag einige Sachen an mysql nicht so. Dazu gehört das DATE-Feld und SET. Ich hasse es wenn ich diese Werte immer in Strings bekomme, die Verarbeitung mit Bits wäre um einiges einfacher...
Weiß da zufällig jemand ob man irgendwie die Bits aus mySQL herausbekommt? Ich hab bisher noch keine Möglichkeit gefunden.
Dazu habe ich mal was geschrieben: http://www.galaxy-news.de/forum/viewtopic.php?p=1122#1122
Stichwort: Bitweise Operatoren
Original von Samson
Wozu einen EventHandler der im Hintergrudn läuft?
Is doch alles mit PHP selbst möglich. In PHP5 mit den neuen OOP Features klappt das super auch so. Sogar in PHP 4 wäre es mit der Pseudo-OOP kein Problem, aber etwas langsamer.
Der im Hintergrund laufende Event-Handler kann doch in PHP geschrieben sein...
gepostet vor 19 Jahre, 9 Monate von TheUndeadable
Servus,
irgendwie kam das mit den 'Tickbasierten' Spiel nicht rüber. Da geb ich dir voll und ganz recht. Da wirken auch 2-3 meiner Argumente nicht mehr
Ich hatte auch mal nen Tick-Handler in PHP4 geschrieben, welches rund um die Uhr lief und alle 10 Minuten aktiv wurde. Dieses lief für PHP erstaunlich gut und ohne Speicherlöcher über mehrere Wochen ohne Neustart des Skriptes. Cronjob konnte ich nicht einsetzen, da der Scheduler unter Windows ein merkwürdiges Etwas ist.
Also von der Stabilität her spricht nix gegen PHP, höchstens die Verarbeitungszeit, dieses kann bei entsprechend intelligenter Implementierung unter Kontrolle gebracht werden.
BTW: Ich merke gerade: Ich bin viel zu oft zu jeder Zeit online :roll:
irgendwie kam das mit den 'Tickbasierten' Spiel nicht rüber. Da geb ich dir voll und ganz recht. Da wirken auch 2-3 meiner Argumente nicht mehr
Ich hatte auch mal nen Tick-Handler in PHP4 geschrieben, welches rund um die Uhr lief und alle 10 Minuten aktiv wurde. Dieses lief für PHP erstaunlich gut und ohne Speicherlöcher über mehrere Wochen ohne Neustart des Skriptes. Cronjob konnte ich nicht einsetzen, da der Scheduler unter Windows ein merkwürdiges Etwas ist.
Also von der Stabilität her spricht nix gegen PHP, höchstens die Verarbeitungszeit, dieses kann bei entsprechend intelligenter Implementierung unter Kontrolle gebracht werden.
BTW: Ich merke gerade: Ich bin viel zu oft zu jeder Zeit online :roll:
gepostet vor 19 Jahre, 9 Monate von None
Original von BLUESCREEN
Original von Samson
Oh ja...ich mag einige Sachen an mysql nicht so. Dazu gehört das DATE-Feld und SET. Ich hasse es wenn ich diese Werte immer in Strings bekomme, die Verarbeitung mit Bits wäre um einiges einfacher...
Weiß da zufällig jemand ob man irgendwie die Bits aus mySQL herausbekommt? Ich hab bisher noch keine Möglichkeit gefunden.
Dazu habe ich mal was geschrieben: http://www.galaxy-news.de/forum/viewtopic.php?p=1122#1122
Stichwort: Bitweise Operatoren
Klar, diesen "Workaround" kenne ich schon, aber ich möchte einfach die Bits die mySQL in einem SET Feld stehn hat ausgegeben bekommen. Jedoch gibt die Datenbank immer die Strings aus. Damit wird es sehr schwer und aufwendig diese zu verarbeiten.
Ein varchar Feld ist eine Lösung, allerdings ist die Übersicht bei größeren Daten sehr schlecht wie du gesagt hast. Und genau darum ist das SET Feld eingeführt wurden.
Muss jeder selbst entscheiden, ich kommt mit dem varchar nicht so gut klar, als mit einem SET Feld (wenn es Bits ausspucken würde *gg*).
Original von Samson
Wozu einen EventHandler der im Hintergrudn läuft?
Is doch alles mit PHP selbst möglich. In PHP5 mit den neuen OOP Features klappt das super auch so. Sogar in PHP 4 wäre es mit der Pseudo-OOP kein Problem, aber etwas langsamer.
Der im Hintergrund laufende Event-Handler kann doch in PHP geschrieben sein...
Klar, unmöglich ist nichts. Das wissen wir seit Toyota
Aber meiner Meinung nach ist hier die Grenze von PHP überschritten. Klar läuft es, aber in Java ist mir ein EventHandler tausendmal lieber. Da hab ich dann schöne saubere OOP und die Fehlerbehandlung ist genial. Da hinkt PHP5 noch um Meilen hinterher. Allerdings ist das okay, da PHP auch ein anderes Anwendungsgebiet hat. Natürlich Tomcat ausgenommen *gg*
Auch hier muss jeder selbst entscheiden, was er nehmen will. Für mich hat PHP da einige Nachteile, vorallem in der Stabilität, bei evtl. Fehlern und ganz klar in der OOP.
Zum Tick / Echtzeit Problem:
Da muss ich zugeben habe ich mich undeutlich ausgedrückt, da ich das Bausystem erst ganz am Ende programmieren wollte. Daher hatte ich mir noch keine Gedanken darüber gemacht. Aber es wird nun sicher eine Lösung in Echtzeit bei mir geben.
gepostet vor 19 Jahre, 9 Monate von TimeOut
Dämliche Frage, aber wie implementiert ihr den Event-Handler in PHP ordentlich, dass es zu keinem ungewollten Overhead u.A. an der DB kommt. Extra Script oder per register_tick_function?
Wie würdet ihr mit einem extra Eventhandler-Script am sinnvollsten kommunizieren?
Wie würdet ihr mit einem extra Eventhandler-Script am sinnvollsten kommunizieren?
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
Original von Samson
Original von BLUESCREEN
Original von Samson
Oh ja...ich mag einige Sachen an mysql nicht so. Dazu gehört das DATE-Feld und SET. Ich hasse es wenn ich diese Werte immer in Strings bekomme, die Verarbeitung mit Bits wäre um einiges einfacher...
Weiß da zufällig jemand ob man irgendwie die Bits aus mySQL herausbekommt? Ich hab bisher noch keine Möglichkeit gefunden.
Dazu habe ich mal was geschrieben: http://www.galaxy-news.de/forum/viewtopic.php?p=1122#1122
Stichwort: Bitweise Operatoren
Klar, diesen "Workaround" kenne ich schon, aber ich möchte einfach die Bits die mySQL in einem SET Feld stehn hat ausgegeben bekommen. Jedoch gibt die Datenbank immer die Strings aus. Damit wird es sehr schwer und aufwendig diese zu verarbeiten.
Ich bin auch kein Anhänger des SET-Typs und benutze für sowas immer normale Integer-Spalten verschiedener Größe.
Ich habe eben mal versucht, eine SET-Spalte numerisch auszulesen und kam zu dem Ergebnis, dass das Ergebnis als Zahl ausgegeben wird sobald du Rechenoperationen anwendest.
Also kannst du eine SET-Spalte mit einer sinnlosen Rechenoperation wie "|0" oder "+0" auslesen:
SELECT `spalte_mit_set`|0 FROM `table`;
Original von Samson
Ein varchar Feld ist eine Lösung, allerdings ist die Übersicht bei größeren Daten sehr schlecht wie du gesagt hast. Und genau darum ist das SET Feld eingeführt wurden.
Varchar hab ich für sowas auch noch nie benutzt.
Das mit dem "varchar" bezog sich in dem Thread auf eine andere Frage.
BTW: Das SET-Feld geht auch nur bis 8 Byte.
Original von TimeOut
Wie würdet ihr mit einem extra Eventhandler-Script am sinnvollsten kommunizieren?
Welche Kommunikation? <- Wieder sowas, wo alle eine verschiedene Auffassung von haben ^^
Also ich bezog mich auf ein Script, dass eben im Hintergrund immer mal wieder aktiv wird und sich dann Daten aus der DB holt, diese verarbeitet und die DB aktualisiert.
Meinst du mit Kommunikation wieder was in Echtzeit?
Wenn ja: Mach mal bitte ein Anwendungsbeispiel.
gepostet vor 19 Jahre, 9 Monate von None
Original von BLUESCREEN
Varchar hab ich für sowas auch noch nie benutzt.
Das mit dem "varchar" bezog sich in dem Thread auf eine andere Frage.
BTW: Das SET-Feld geht auch nur bis 8 Byte.
8 Byte entsprechen 64 Elementen, ich denke das bekommt man ganz schwer voll *gg*
mySQL speichert nicht die Strings, sondern genau ein Bit pro Element. Darum finde ich SET ja so interessant. Allerdings wie gesagt, ist die Ausgabe mies
Werd aber mal deinen Tipps ausprobiern, wenn das klappt spar ich mir ne Menge Arbeit.
Edit:
Du hast natürlich Recht, sind natürlich keine 66 Elemente sondern 64 *gg*
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
Original von Samson
Original von BLUESCREEN
Varchar hab ich für sowas auch noch nie benutzt.
Das mit dem "varchar" bezog sich in dem Thread auf eine andere Frage.
BTW: Das SET-Feld geht auch nur bis 8 Byte.
8 Byte entsprechen 66 Elementen, ich denke das bekommt man ganz schwer voll *gg*
Sind nur 64, aber hast Recht ^^