[PHP] Forum für WebGame

[Gruber_Hans_12345]

Tach, hab da ne Frage, möchte gerne mal (so als übung und aus spass) mich mal an einem Online Web Game versuchen (etwas im Strategy Bereich)

Da ich eigentlich ganz gut vorankomme, bis auf ein paar kleine Probleme würde es mich interessieren, ob es irgendwo ein gutes Forum für sowas gibt.

Falls es jemanden interessiert würde ich mich freuen, wenn er ab hier weiterliest, und auch seinen Senf dazugibt :

Mein aktuelles Problem ist, das ich etwas brauche, das jede Sekunde oder bei einer bestimmten aktion gewissen sachen in der mySQL Datenbank berechnet.
Da habe ich einfach eine Krise, wo ich nicht weiss, welcher Weg am besten ist.

Ich habe Ressourcen in dem Game (ist ja klar)
Diese Ressourcen können natürlich von anderen geklaut werden und die kann man auch selber klauen.
Ich kann auch Einheiten bauen, womitich die Ressourcen verteidigen kann.
Ich kann Gebäude bauen, damit ich mehr ressourcen bekomme

Ich habe folgende Möglichkeiten
a.) Ich könnte jede Sekunden alle Sachen in der Datenbank berechnen.
+ Bin immer auf den aktuellen Stand
- Bin mir nicht sicher, wie sich PHP, MySQL und Apache in so ner situation verhält (in punkto Multithreaded)
- Wird oft was berechent, was gar nicht nötig ist
- Zum beispiel, wenn ich 1000 Einheiten produziere, dann kommen die immer stückenweise raus. Und bräuchten vielelicht nur auf einmal berechnet werden
- keine Ahnung wie man in PHP soetwas realisiern kann, das ein Thread im Hintergrund läuft ...
b.) Jedes mal wenn ein user eine Aktion (irgendeine Aktion) macht wird alles Berechnet, was bis jetzt passiert ist
+ Habe eigentlich immer den aktuellen Stand (zumindest wenn ein User was nachschaut)
+ kann dann leicht mit Punkt A gekoppelt werden
- ist evnentuell für den ersten User etwas langwieriger (ODer auch nicht)
c.) Wenn der User eine Aktion macht, wird alles berechent, was für den User wichtig ist
+ Wäre eigentlich ganz gut
- Schwierig, wenn ne Punktetabelle gemacht werden soll, da ja alle sachen der User hir reinspielen können
- Problematisch, da sich die "was für den User wichtig ist" rekursiv vergörßern kann
*) Der User wird angegriffen
*) Zuerst müssen die produzierten Einheitem berechent werden
*) Dann müssen alle Einheiten, die von dem User unterwegs sind auch berechnet werden
*) da es ja sein kann, das einheiten zur verteidigung zurückkommen
*) und auch Ressourcen
*) das kann recursiv werden, da ja den der User angreift jetzt auch berechnet werden muß

[Flare]

An sich klingt dieses System interessant, bloß ich glaube an der Umsetzung wird es scheitern. Denn ich glaube dass die mySql-Verbindung ab einer bestimmen Anzahl an Benutzern einfach nicht mehr hinterherkommt.
Ich weiß auch nicht ob es sinnvoll ist jede Sekunde irgendetwas zu berechnen. Ich programmiere gerade selber an einem ATB-Kampfsystem, dort mache ich es so, wenn einer Aktualisiert/etwas macht, so wird alle sberechnet, was bis dahin passiert sein müsste.


Flare

[Gruber_Hans_12345]

mm, welches system meinste das interessant ist a b oder c ?

Also, du berechnest nach dem System B, also bei JEDER User aktion ALLE Aktionen von ALLEN Usern berechnen.

Wie verhält sich das System, wenn du von 2 Clients (fast) gleichzeitig ne Aktion ausführst ?
Hab da leider noch keine Ahnung mit PHP und mySQL wie es sich in solchen situationen verhält.
*) Transaktionen - gibts ja keine bei mySQL oder ?
*) MutliThread - nicht, das beide Clients gelichzeit versuchen die Aktionen zu lösen

[Phoenix]

PHP ist eine Script / Interpretersprache und kein Programm das ständig läuft.

Das Problem das Du gerade hast stellen sich im Prinzip alle Entwickler eines Webgames früher oder später - und genau aus dem Grund verwenden eigentlich nahezu alle Spiele ein Rundenbasiertes Modell - mal mit mehr oder weniger langen Runden.

Wenn Du Deine Runde nur eine Sekunde lang machen willst geht das sicher recht stark auf die Performance, ich würde - wenn es Richtung 'Echtzeit' gehen soll - vielleicht einen 5-Minuten-Takt machen.

Und nun zur Realisierung: Du schreibst ein Berechnungssript, das eben alle Berechungen die für alle Spieler nötig sind nacheinander abwickelt. Dieses Script wird aber nicht von einem User aufgerufen oder durch ein User-Script gestartet, sondern von einem sogenannten Cron-Job alle 5 Minuten automatisch gestartet auch wenn kein User irgendwas macht. Ein Cron-Job ist bei Linux-Systemen sowas wie ein geplanter Task unter Windows.

Das ist denke ich die einfachste Möglichkeit, sowas zu realisieren.

[Flare]

Das Problem mit MultiThread habe ich nicht wirklich, da ein MySQL-Befehl zum ausführen rund 0.0006 Sekunden dauert. Ich glaube nicht, dass so etwas warscheinlich ist wenn 2 Menschen zur gleichen Zeit etwas machen, genauer gesagt, ist es mir einmal bisher passiert, mit interessantem nebeneffekt (wird aber Offtopic, wenn ich das hier erkläre).


Flare

[Tubos]

Zitat:

Das Problem mit MultiThread habe ich nicht wirklich, da ein MySQL-Befehl zum ausführen rund 0.0006 Sekunden dauert.

Solange das Online-Spiel nur von 2 oder 3 Spielern gespielt wird, geht es vermutlich immer so schnell ;)
Mehr User --> geringere Performance

[Flare]

Ist klar, allerdings rechne mal 0.0006 Sekunden mal 200, da kommt etwas unter ner Sekunde raus, ist doch wohl noch akzeptabel, ich benutze es für ein textbasierendes Rollenspiel, wo normalerweise nicht jede Sekunde ein Klick gemacht wird.


Flare

[yankee]

Ich muss hier in weiten Teilen wiedersprechen:
Ein cronjob der alle 5 min ausgefuehrt wird ist hier bei weitem nicht genug. Bei Echtzeitspielen geht es schliesslich eher um Bruchteile von Sekunden. Andere Entwickler werden sagen, dass es sich ab 20 Millisekunden lohnt wieder zu warten.
Mit den events machst du das einfach so, dass du ein php-script auf endlosschleife laufen leasst (set_timeout(0) oder so aehnlich um zu verhindern dass das Script wegen ausfuerdauer abgebrochen wird.) Dieses Script greift auf eine mysql-Tabelle zu, sieht nach, wann das naechste event stattfindet (angriff usw.), und sleep()-t sich bis zu diesem Zeitpunkt. Dann fuehrt es die noetige aktion aus und schaut nach, was als naechstes an der Reihe ist. Wenn der Abstand zum naechsten Ereignis zu gross ist (mehr als ein paar Sekunden) willst du wahrscheinlich das script nur sehr kurz sleepen um zu verhindern, dass ein neues Element hinzukommt, welches ein kuerzere Zeit hat.
Und dann nimmst du -ja- Methode 3, aber noch eingeschraenkter: Sobald du auf eine infomation zugreifst aktualisiserst du diese. Also zum Beispiel wenn du die momentane menge ressis anzeigst, dann berechnest du wieviele ressis in der zwischenzeit produziert worden sind.
Alles, was das lineare Modell der veraenderung stoert muss natuerlich auch wieder ein event sein. Also wenn Beispielsweise ein Rohstoffproduziernde Mine fertig ist, muss dessen fertigstellung ein event ausloesen, dass die Rohstoffe neu berechnet und dann die sekuendliche neuproduktion hochsetzt.
Und ja, eine mysql-Verbindung reicht aus. Man muss eben nur geschickt programmieren und bei jedem event alles von jedem Benutzer neu zu berechnen ist nicht nur unnoetig, sondern auch viiel zu langsam.

[Gruber_Hans_12345]

Ja, so ungefähr habe ich es mir auch vorgestellt

Das PHP Interpretiert wird, und das ich das Script, das im Hintergrund laufen soll, abgekoppelt von dem PHP ist, was der User aufruft ist mir klar.
Die Ressourcen berechnung habe ich schon von den Events weggekoppelt.
Als Events habe ich
-) Neue Gebäude die Ressourcen produzieren
-) Neue Gebäude die Ressourcen speichern können
-) Angriffe von Units
-) Rückkehr von Units (Verteidigung falls ein Angriff kommt)
-) Produktion von Units (Verteidigung falls ein Angriff kommt)
-) Forschung (Stärke der Units)

Bei all diesen Events MUß in der Datenbank sofort neu berechent werden, da ich ja sonst rekursionen zusammenbekomme

Ich bin gerade mal dabei, ne Funktion zu schreiben, die all das da oben mal berechnet.

Ich bin mir noch nicht sicher, ob ich das nun bei jedem Aufruf eines Spielers machen sollte
(Sollte ja auch nicht um viel anders sein als wenn es im Hintergrund läuft - oder ?
Da ja wenn schnell hintereinander geklickt wird, ja fast nix zu berechnen ist)

oder als Job im Hintergrund