"CronJobs" umgehen und nachträglich berechnen?

d3mueller · 28.12.2013

Hi,
ich plane, ein Browsergame zu erstellen (just for fun

)

Und gehe jetzt so die wichtigsten Voraussetzungen durch, die ich brauchen werde. Unter anderem gibt es diese CronJobs.

Also das manche Skripte immer automatisch ausgeführt werden.

Jetzt habe ich überlegt, ob man nicht (einiges) nachträglich berechnen lässt, sobald ein Spieler die Seite aufruft.

Also bspw. die Ressourcenberechnung. Da braucht man ja nur in der Datenbank die Zeit eintragen, zu der das letzte mal aktualisiert worden ist. Dann kann man mit der aktuellen Zeit eine Differenz bilden und Rohstoffe dazuaddieren. Oder?

Genauso kann man es mit vielem anderen machen.

Nur kritisch wird's, wenn es um Interaktionen zwischen mehreren Spielern geht.
Also wenn Spieler A 2 Tage offline ist und Spieler B ihn nach 1,5 Tagen angreift. Die Rohstoffe von diesen 1,5 Tagen sind ja noch nicht einberechnet.

Jetzt könnte man ja einfach in dieses Angriffsskript diese Ressourcenberechnung einfach nochmal einbauen (oder per Klassenmethode aufrufen, dann hat man es nur einmal). Also wenn was passiert, dann hat man immer die richtige Menge an Rohstoffen berechnet. Ginge sowas?

Was glaube ich noch schwieriger sein wird, ist folgendes:

Wenn man z.B. eine Truppe 5h lang in eine andere Stadt schickt, dann kann man ja wie oben geschrieben einfach mit der Zeitdifferenz arbeiten und ggf. die Truppen wieder zurückholen lassen.

Aber auch hier wieder das Interaktionsproblem mit anderen Spielern. Kann man es auch wie oben machen, indem man in der Datenbank z.B. bei der Tabelle dieser eingenommenen Stadt eine Spalte "stationierte Truppen" machen, in denen alles steht (u.a. Ankunftszeit und Dauer). Und bei einem Angriff von Spieler B wird dann wieder berechnet, ob die Truppen noch da sind, oder nicht.

Geht das so?

Ich hoffe, ihr versteht, was ich meine

LG

PS: https://www.cronjob.de/features.php
Ist die Seite gut? Falls man CronJobs benutzen muss?

Duddle · 28.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Was genau ist deine Frage?
Wenn du einen Algorithmus formulieren kannst, "geht das" automatisch. Die Schwierigkeit liegt eher darin, ob damit alle Fälle abgedeckt werden, was wiederum mit jedem Feature unwahrscheinlicher wird.

Fang daher so klein wie möglich an und versuche, abgeschlossene Systeme/Module zu entwickeln und zu testen.

Beispielsweise klingt

bei der Tabelle dieser eingenommenen Stadt eine Spalte "stationierte Truppen" machen, in denen alles steht (u.a. Ankunftszeit und Dauer)

schon auf den ersten Blick nach einem falschen Entwurf. Wenn du mehrere Städte hast, sollte es eine Tabelle für die Städte geben. Auch ist "Dauer" (wenn ich dich recht verstehe) eine berechenbare Größe, also hat sie nichts in der Datenbank zu suchen.

PS: https://www.cronjob.de/features.php
Ist die Seite gut? Falls man CronJobs benutzen muss?

Wie definierst du "gut"? Die Seite macht nichts weiter als max. jede Minute eine Seite von dir aufzurufen. Wenn dir das reicht, ist sie "gut".
Eigene Cronjobs sind aber bei jedem etwas größeren Hostingpaket dabei. Alternativ nutzt du jeden Hit auf der Website um zu prüfen ob etwas geupdatet werden muss und führst es dann durch.

Duddle

d3mueller · 28.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Hi, danke für die Antwort

Okay, also meinst du damit, ich soll einzelne Funktionen in einem Modul zusammenfassen und das dann nach und nach integrieren? Also beispielsweise ein Modul für die Rohstoffberechnung und eins für Kämpfe o.ä.?

Und meinst du mit Modul dann eine Klasse und Methoden? (Ich merk mir nie so die ganzen "Fachbegriffe"^^)
Man könnte es ja so machen, dass man eine Klasse "Berechnungen" hat und dort Methoden sind, um alles zu berechnen, was bei Interaktionen zwischen Spielern notwendig ist. Und dann kann man eben per Skript einfach alle Methoden ausführen lassen (per get_class_methods () und dann per Schleife).

So kann man die Klasse problemlos um Berechnungen erweitern, wenn neue Funktionen eingebaut sind.

Oder hab ich das falsch verstanden?

Zu den Städten:
Da hab ich mich etwas undeutlich ausgedrückt, tut mir Leid. Ich meinte, dass eine eine Tabelle "Städte" gibt und dort dann einzelne Städte drin sind.
Aber wie kann man die Dauer berechnen? Die kann doch unterschiedlich sein, oder?

Auch ist "Dauer" (wenn ich dich recht verstehe) eine berechenbare Größe, also hat sie nichts in der Datenbank zu suchen.

Das ist interessant

So habe ich das noch nicht gesehen, dass man alles berechenbare im Skript hat und nicht in der Datenbank. Ist es denn schneller, aus Rohdaten (von der DB) das Ergebnis im Skript zu berechnen, als einfach das Ergebnis in der DB zu speichern?

---

Es hätte ja sein können, dass die Seite irgendwas anderes macht, was ich übersehen habe^^

LG
Akeno

Duddle · 28.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Okay, also meinst du damit, ich soll einzelne Funktionen in einem Modul zusammenfassen und das dann nach und nach integrieren? Also beispielsweise ein Modul für die Rohstoffberechnung und eins für Kämpfe o.ä.?

Grob gesagt, ja.
Hast du bspw. einen Prototyp und willst einen Kampf simulieren, hast aber noch nicht über Truppenstärken, Moral, das Schere-Stein-Papier-Prinzip oder ähnliches nachgedacht, könnte ein einfaches Modul schlichtweg "größere Zahl besiegt kleinere Zahl" berechnen. Im Idealfall kannst du später exakt die gleichen Schnittstellen nutzen um ein komplexeres Kampfsystem zu implementieren, ohne in deinem Hauptprogramm etwas ändern zu müssen.

Und meinst du mit Modul dann eine Klasse und Methoden? (Ich merk mir nie so die ganzen "Fachbegriffe"^^)
Man könnte es ja so machen, dass man eine Klasse "Berechnungen" hat und dort Methoden sind, um alles zu berechnen, was bei Interaktionen zwischen Spielern notwendig ist. Und dann kann man eben per Skript einfach alle Methoden ausführen lassen (per get_class_methods () und dann per Schleife).

Denk noch nicht über die Implementierung nach, das ist der einfache Schritt. Dein Fokus muss auf dem Entwurf liegen und ein guter Entwurf ist (theoretisch) unabhängig von eingesetzter Sprache und Technologie.

Denk abstrakt über dein Problem nach und modellier dein System Schritt für Schritt. Erst danach übersetzt du es in die gewünschte Programmiersprache.

Ist es denn schneller, aus Rohdaten (von der DB) das Ergebnis im Skript zu berechnen, als einfach das Ergebnis in der DB zu speichern?

Nein, das nicht, aber es ist eine Faustregel für Datenbanken, keine berechnbaren Daten zu speichern. Zum Beispiel ist eine "Dauer" der Zeitraum zwischen zwei Zeitpunkten, ist also automatisch verfügbar wenn letztere sowieso gespeichert werden (ja, du kannst argumentieren "Start+Dauer=Ende", d.h. Ende als berechneter Wert, aber dann hast du schon zwei statt einem Datentyp).

Duddle

d3mueller · 28.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Okay, danke. Dann versuche ich das mal.

wird nur schwer, das abstrakt zu planen. Vor allem Schnittstellen zu planen wird schwer.
Ich kann mir das halt immer nur vorstellen, indem ich das in PHP durchgehe.

Beispiel Rohstoffsystem:
Im Prinzip braucht man doch nur ein Modul, welches die Rohstoffe der Stadt berechnet. außerdem muss dieses Modul eine Möglichkeit bieten, die Rohstoffe zu steuern, also beim Gebäudekauf zu sinken und bei z.B. Geschenken von anderen Spielern zu steigen.
Mehr müsste dieses Modul ja nicht können, oder? Man könnte die diversen Methoden in dem Modul einfach zu einem bestimmten Zeitpunkt aufrufen.

Sind bei diesem Modul die Schnittstellen dann die Methoden zur Rohstoffregulierung(Steigen, sinken)?

Und ist so eine Planung abstrakt genug? Oder schon zu abstrakt?

Und mal eine etwas andere Frage. Wenn man das jetzt alles abstrakt geplant hat, wie baut man dann die Klassen auf? Macht man ne Klasse "Rohstoffe" und "Gebäude" und "Schiffe" und belädt die mit den passenden Methoden (z.B. Bei Klasse "Schiffe" eine/mehrere Methoden zum Kampf). Oder ist das anders vielleicht sinnvoller?

Sry, wenn ich so viel Frage

Ich möchte das jetzt mal lernen und richtig machen

LG

EDIT:

Noch eine Frage:

Die einzelnen Module sollen ja unabhängig voneinander sein und praktisch alleine lauffähig (wenn man den richtigen Input simuliert), oder?

Ist es sinnvoll, so "untermodule" zu verwenden? Module in Modulen also? Wenn man zum Beispiel zufallsgesteuerte Ereignisse haben will, könnte man doch ein Untermodul für solche Ereignisse erstellen, oder? Oder wenn es ein bestimmter Einsatz gegen einen bestimmten Gegner ist, dann kann ein Untermodul den Kampf anders simulieren etc.

Oder sollte das in einem einzigen Modul sein?

Duddle · 28.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

wird nur schwer, das abstrakt zu planen. Vor allem Schnittstellen zu planen wird schwer.

Wie gesagt ist das der schwierigere Teil, plus ein Fehler im Entwurf zieht sich durch den ganzen Prozess, deshalb werden die Designer auch besser als die Programmierer bezahlt.

Deshalb rate ich auch dazu, klein anzufangen. Wenn du nur über die Wechselwirkungen von zwei Teilsystemen nachdenken musst, erkennst du schneller die Schwachstellen und mögliche Verbesserungen als bei 42 Teilsystemen.

Im Prinzip braucht man doch nur ein Modul, welches die Rohstoffe der Stadt berechnet

Aber ist "Stadt" wirklich die abstrakteste Entität? Könnte nicht auch ein Dorf Rohstoffe einbringen? Oder eine Mine? Minen sind aber keine Städte.
Sinnvoller wäre da vielleicht, ein allgemeineres "Gebiet" als Rohstoffquelle zu haben. Aber was wenn ein Handelsschiff umkippt, könnte das nicht auch eine Rohstoffquelle sein? Ein gekentertes Schiff ist aber kein "Gebiet". Vielleicht wäre "Rohstoffquelle" als Attribut besser und jede "Rohstoffquelle" kann ihre Erträge melden.
Wenn Schiffe aber keine Rohstoffquellen sein können, brauchst du diese Abstraktion mglw. garnicht, also wäre "Gebiet" die bessere Wahl.

Was ich damit sagen will: je allgemeiner du etwas formulierst, umso mehr Fälle kannst du abdecken. Je allgemeiner das Modul und deine Schnittstellen sind, desto besser kannst du es später austauschen oder erweitern oder sogar in einem neuen Projekt wiederverwenden. Gleichzeitig ist das aber natürlich schwieriger zu entwerfen.

Wenn man das jetzt alles abstrakt geplant hat, wie baut man dann die Klassen auf?

Darüber (bzw. den ganzen Softwareentwicklungsprozess) werden ganze Bücher verfasst.
Allgemein: OOP ist gut, Entwurfsmuster sind hilfreich, Unit-Tests sind immer gern gesehen.

Wenn du verstehst, dass die Klasse für "Einheit" (also Figur auf dem Spielfeld) wichtiger als die für "Schiff" oder "Panzer" oder "Bauer" ist und sie entsprechend gut modellierst, dann kommt der Rest automatisch.

Ich kann wirklich nur so allgemein darüber sprechen, weil alles andere von deinem System und von deinem Ziel abhängt.

Ich möchte das jetzt mal lernen und richtig machen

Fang klein an und lern aus den Fehlern und Sackgassen, die du unvermeidbar finden wirst. Kauf dir ein Buch oder zwei und leg dich rein (Stichwort "Softwaretechnik").

Die einzelnen Module sollen ja unabhängig voneinander sein und praktisch alleine lauffähig (wenn man den richtigen Input simuliert), oder?

Ja. Es gibt bspw. die sehr bekannte OpenSSL-Bibliothek, mit der , wenn nicht sogar hunderte, von Projekten Verschlüsselung umsetzen. Das wäre nicht möglich, wenn die Bibliothek spezifisch auf ein bestimmtes Programm hin geschrieben wäre.

Ist es sinnvoll, so "untermodule" zu verwenden?

Klar, warum nicht. Je stärker die Module jedoch gekoppelt sind, desto schwieriger wird der Austausch.

Oder wenn es ein bestimmter Einsatz gegen einen bestimmten Gegner ist, dann kann ein Untermodul den Kampf anders simulieren etc.

Einen ähnlichen Fall habe ich als Beispiel in benutzt, ja.

Duddle

Curanai · 30.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Duddle, ich bin ja umgefallen! Sehr schön, sehr schön ...

Aber doch, es funktioniert! So, wie man eine "Map" mit wenigen Zeilen hochindividuell entwerfen kann (= Universum in der Nussschale), kannst Du auch Folgegeschehnisse abbilden.

Mein Tipp: Hierarchie der eingesetzten Klassen in der Verwendung (gem. Erfahrung: Produktion, Handel, Kampf, Sonstiges). Bedeutet: Produktion vor Handel, vor Kampf, vor Sonstiges ... und gerade etwas wie Kampf, was bspw. "Plünderung" zur Folge hätte, würde nachfolgende Scripte aufheben.

"Ohne Cronjob" ist auf kleinen Webpaketen durchaus angebracht - Du findest unter "pseudo crons" ganz viele Erklärungen (u. a. bei O'Reilly; ISBN kann ich Dir noch raussuchen) und Beispiele. Wenn Du aber Dampf hast (= Server), würde ich eher die Automation (also einen echten Cronjob) nehmen. Kleines (super einfaches) Beispiel dazu, um Dich auf die eine oder andere Schwäche hinzuschubsen ...

Dorf A von Spieler 1 produziert Holz - bspw. 10 Raummeter pro Tag rund um selbiges.

Spieler 1 ist verhindert und kehrt erstmal zwei Wochen nicht zurück.

Dorf A hingegen produziert eigentlich weiter und räumt das "biologische Umfeld", wodurch das Dorf sichtbarer und leichter einnehmbar (= schweres Gerät) wird.

Spieler 2 attackiert das Dorf - was findet der?!

Du hast zwei Möglichkeiten: Der "pseudo" wird ausgeführt und rechnet "ähnlich regulärem Spieler-1-Login" oder es ist das, was da ist ... denn sind wir ehrlich: Holz bei einer Schlacht benötigt der Feind auch und ein belagertes Dorf schickte niemanden zum Pilzesammeln. ^^

In meinen Augen ist die Automation für Mehrspieler, die auch miteinander interagieren sollen, schöner, da flexibler und mit Eigendynamik versehbar (Wechselwirkungen mit Umwelt, Änderungen bei Belagerung whatever). Wenn Du aber gar nicht so umfangreich werden willst (man stelle sich verschiedene Dörfer/Städte mit geografischen Vor- und Nachteilen vor, wodurch es eben nicht nur immer "rein mathematisch" ist bzw. ein Dorf mit Aufbringen von x Einheiten als erobert gilt) ... naja, Deine Entscheidung eben.

Eines noch: Es ist egal wie viel Mühe Du Dir mit dem Grundstein gibst - sobald "User" hinzu kommen, entsteht eine Eigendynamik, welche "Reaktion" und "Ausbauten" (= Wünsche) beinhalten muss.

Je größer es wird, umso mehr musst um die Ecke denken! Abhängigkeiten gehören verewigt (dokumentiert) und vermeide "God"-Methoden/-Funktionen. ^^

Ich wünsch Dir gutes Gelingen.

d3mueller · 30.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Danke für die Antworten

CronJobs sind also vermutlich doch besser ^^
Diese pseudo Crons, wären auch eine Überlegung wert. Verstehe ich das richtig, dass die dann im Nachhinein (bei einem Seitenaufruf) diese Skripte laufen lassen? Also wenn man ein Skript jede Stunde laufen lassen will und dann 10 Stunden offline ist, dass der dann das Skript 10 mal laufen lässt (im Nachhinein)?

Das wäre durchaus praktisch

Im Prinzip hatte ich ja geplant, etwas ähnliches zu machen. Also bei deinem Beispiel: Wenn Spieler 2 das Dorf angreift, dann wird (im Kampfmodul/skript) erst das Dorf des anderen auf den aktuellen Stand gebracht (mittels einiger Funktionen, die das auch berechnen, wenn Spieler 1 on ist) und dann kann normal weiter gemacht werden

Duddle · 30.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

Also wenn man ein Skript jede Stunde laufen lassen will und dann 10 Stunden offline ist, dass der dann das Skript 10 mal laufen lässt (im Nachhinein)?

Das wäre eine Möglichkeit, aber cebito meint wohl das Prinzip, bei dem jeder Hit die geplante Aufgabe auslöst, solange der letzte Start länger als bspw. 10 Minuten her ist.
Sehr viel einfacher zu implementieren sind aber normale Cronjobs, entweder lokal oder eben durch einen externen Dienst.

Alternativ machst du die Updates on-demand, so wie du es selbst in vor einem Jahr beschrieben hattest.

Duddle

Curanai · 30.12.2013

AW: "CronJobs" umgehen und nachträglich berechnen?

"Curanai" glaubt, dass Du es richtig beschrieben hast in puncto "pseudo". Sprich: Wenn sich da irgendwas "externes" tut, erst das "interne" (wie bei Login etc.) von "last login" bis "jetzt" (nach-)regeln (= höhere Ausbeute) und dann "zur Kasse", da Plünderung.

Aber das liegt eben nur dann vor, wenn Du eine derartige Interaktion mit anderen hast.

Truppenbewegungen finde ich da schlimmer - gerade, wenn diese derart genau "anschwappen", dass Timing richtig wichtig (und dann isses Spaß pur, da "Angriffswellen"!) ist und wird und dann auch wirklich aus verschiedenen Richtungen angegriffen werden kann (die einen über den Hang, die anderen aus dem Sumpf (und bleiben lange unentdeckt) u. v. m.). Das "wer-ist-zum-Zeitpunkt-wo" ist schwieriger - auch und gerade dann, wenn man sich "unterwegs" zufällig trifft ... aber vielleicht hat Duddle da noch eine Idee?!