Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Grundlegende Browserspielfragen

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • [Erledigt] Grundlegende Browserspielfragen

    Guten Abend (oder auch Morgen)

    Vorweg, ich hatte große schwierigkeiten bei der Einordnung meines Themas und meiner Qualifizierung. Ich selbst würde meine PHP-Kentnisse als zwischen Anfänger und Fortgeschritten einschätzen. Mit der grundlegenden Bedienung komme ich super klar, u.a. weil ich in Java einigermaßen bewandert bin und die Grundsätze dann nicht so schwer zu übernehmen sind.

    Meine Fragen sind grundlegende (wahrscheinlich Verständnisprobleme), bei denen ich nicht sicher bin ob sie in der Kategorie "PHP-Fortgeschrittene" optimal aufgehoben sind.

    EDIT: entschuldigt bitte, die Uhrzeit hat mich den obersten Beitrag in diesem Forum überlesen lassen. Das Thema hat hier nichts zu suchen und falls jemand mit genüfend Rechten daherkommt könnte er das bitte in den Anfängerbereich verschieben?
    Dankesehr

    Ich beschäftige mich schon seit einiger Zeit mit dem Gedanken ein eigenes kleines Browserspiel als Hobby zu schreiben. Ideen sind reichlich vorhanden (in Richtung Strategie vgl. Stämme und co.). Im Zuge meines Studiums (Wirtschaftsinformatik) ist mir nun auch die Lust gekommen, das wirklich mal umzusetzen. Ich habe in den letzten Tagen also ein wenig konkretere Konzepte geschrieben, einige Modelle erstellt (größtenteils ausprobiert wie alltagstauglich die im Studium erlernten Methoden denn so sind ;D).

    Hier gehts los mit meinen wirklichen Fragen:
    Browserspiele haben immer einen Server, welcher unabhängig von eingeloggten Usern Berechnungen durchführt, Werte aktualisiert usw.
    Kann mir jemand einen Anstoß geben wie sowas funtioniert? Ich weiß wie ich mit php auf Usereingaben reagiere und die eingegebenen Daten verarbeiten kann, aber wie funktionieren diese eigenständigen Dinge? Was für Scripte sind das die dort auf dem Server (oder als Server?) arbeiten?

    Eine weitere ebenfalls noch recht hoch priorisierte Frage beschäftigt sich mit der Datenspeicherung.
    Ist es "sinnvoll" wirklich alle Daten in einer Datenbank (in meinem Fall wohl mysql) zu speichern? Um etwas konkreter auf das Strategieelement einzugehen.
    Truppenproduktion, sich bewegende Armeen usw.
    Also in erster Linie äußerst dynamische Werte. Im Falle der Truppenproduktion werden dort eventuell einmal 1000x produziert. Mein Ansatz wäre, diesen Wert mit Startzeitpunkt in einer Datenbank zu speichern und dann entsprechend runterzuzählen. und sobald die 0 erreicht wird den Eintrag zu löschen.
    Gibt es dort "elegantere" / schnellere Methode der Speicherung solcher, sich ändernder Daten?


    Ich bedanke mich bei allen die bis hier gelesen haben und noch mehr freue ich mich auf Antworten aller Art.

    Liebe Grüße
    ChromOxid


  • #2
    Zitat von ChromOxid Beitrag anzeigen
    Kann mir jemand einen Anstoß geben wie sowas funtioniert? Ich weiß wie ich mit php auf Usereingaben reagiere und die eingegebenen Daten verarbeiten kann, aber wie funktionieren diese eigenständigen Dinge? Was für Scripte sind das die dort auf dem Server (oder als Server?) arbeiten?
    Meistens wird das über sogenannte Cron-Jobs erledigt. Es gibt auf jedem Server ein Tool, welches im Endeffekt zeitgesteuert beliebige Aufgaben erledigen kann.

    Dem kann man dann z.B. sagen: "Führe jede Stunde das PHP Skript XYZ aus" - und in diesem Skript machst du dann alle Berechnungen, die quasi immer wieder gemacht werden müssen.

    Man kann diese Taktung quasi als Uhr deines Spiel-universums ansehen. Wenn dann dort steht: "Produktion von X dauert Y Runden", und dein Skript läuft jede Stunde, dann sind Runden = Stunden. So hast du auch den Vorteil, dass du z.b. mal die Zeit anpassen kannst, und eine Runde = eine halbe stunde oder sogar ein ganzer Tag ist, je nachdem wie "schnell" dein Spiel ticken soll.

    Zitat von ChromOxid Beitrag anzeigen
    Eine weitere ebenfalls noch recht hoch priorisierte Frage beschäftigt sich mit der Datenspeicherung.
    Ist es "sinnvoll" wirklich alle Daten in einer Datenbank (in meinem Fall wohl mysql) zu speichern? Um etwas konkreter auf das Strategieelement einzugehen.
    Truppenproduktion, sich bewegende Armeen usw.
    Also in erster Linie äußerst dynamische Werte. Im Falle der Truppenproduktion werden dort eventuell einmal 1000x produziert. Mein Ansatz wäre, diesen Wert mit Startzeitpunkt in einer Datenbank zu speichern und dann entsprechend runterzuzählen. und sobald die 0 erreicht wird den Eintrag zu löschen.
    Gibt es dort "elegantere" / schnellere Methode der Speicherung solcher, sich ändernder Daten?
    Ja. Fang einfach mit MySQL an. Es gibt da natürlich je nachdem, was und wie du speichern möchtest auch andere Möglichkeiten, aber mit MySQL haste zumindest mal die eierlegende Wollmilchsau, die quasi alles ein bisschen kann. Zudem ist es vermutlich das einfachste zu lernen am Anfang.
    Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

    Kommentar


    • #3
      Vielen Lieben Dank für deine rasche Antwort.
      Meine zweite Frage bezüglich der Datenspeicherung wurde zu meiner vollsten Zufriedenheit beantwortet.

      Meine erste Frage muss ich im nachhinein wohl einmal korrigieren.
      Cron-Jobs sind mir einigermaßen bekannt, als Schlüsselwort für solche Anwendungen. Mein Hauptproblem liegt in der "Echtzeitbearbeitung", vermutlich ist das etwas komplexer und ich bin schon über passende Schlüsselwöörter über die ich mich genauer informieren kann sehr erfreut.
      Ein Beispiel aus dem konkreten Anwendungsbereich des Strategiespiels: 2 Armeen können zu einer beliebigen Zeit aufeinander treffen und wenn das geschieht soll ein entsprechendes Script zur Bearbeitung des Kampfes aufgerufen werden.

      Sind Cron-Jobs zu so etwas fähig? Wenn ich mich dazu bisher nicht zu oberflächig informiert habe, sind Cron-Jobs in Zeitintervallen festgelegt und für so eine Echtzeitanwendung untauglich?

      Nichts desto trotz bedanke ich mich natürlich auch für diesen Teil deiner Antwort und entschuldige mich für meine unpräzise Frage.

      Liebe Grüße
      ChromOxid

      Kommentar


      • #4
        Diese "Echtzeit" ist auch nur simuliert.

        Im Endeffekt kannst du z.b. den Cron-Job auf alle 5 Sekunden stellen, und er prüft in jedem Zyklus, ob ein "Event" stattfinden muss oder nicht. Wenn nicht, passiert auch nichts. Wenn der Cron sieht: "Ah, dort stehen zwei Armeen auf den gleichen Feld", dann kann er die Routine für den Kampf abarbeiten, das Ergebnis speichern und ist dann fertig.
        Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

        Kommentar


        • #5
          Ich kann da ApoY2k nicht zustimmen.
          Wenn du Ereignisberechnungen durchführen willst, macht man sowas nicht mit Cronjobs. Dafür eignen sich Event-Dämonen viel besser - vor allem wenn du deine Spielideen mit die Stämme vergleichst.
          In diesen Programmen führst du alle Events, die ausgeführt werden sollen, chronologisch aus. Ein Cronjob ist nur eventuell dann geignet, wenn ein Tick wirklich nur alle zehn Minuten ist. Aber in deinem Fall gehe ich davon aus, dass du sekündliche Eventberechnungen brauchst.

          Ich kann zu MySQL seit den Versionen der letzten paar Monate nicht mehr raten. Bugs werden einfach nicht mehr behoben und ich denke, dass die Übernahme durch Oracle da nicht ganz unschuldig dran ist.

          Daher rate ich dir wirklich an, entweder eine nicht relationale Datenbank wie MongoDB zu benutzen, oder dann eine andere relationale wie Oracle oder PGSQL (und wenn du PG benutzt, wirst du bestimmt 'nen neuen Freund in diesem Forum finden).
          Crashkurs zum Thema Rechtschreibung: normalerweise (normaler weise oder normaler weiße), Standard (Standart), eben (ebend)

          Kommentar


          • #6
            Ich rate zu gar keinen Cronjobs: Rechne aus was ausgerechnet werden muss, dann wenn du es brauchst!

            Wenn die Bauzeit eines Hauses 30 Minuten dauert, dann speichere Start-Zeitpunkt des Baues und das wars. Wenn der User das nächste mal nachschaut wie weit das Haus ist, berechnest du aus Start-Zeitpunkt und aktueller Zeit den Fortschritt.

            Es kann nicht sein, das ein Cronjob Werte auf deiner DB herunterrechnen muss. 1. Kannst du nicht sagen wie langer der CJ läuft und 2. speicherst du redundante Daten.

            Wenn ein Benutzer ein Geburtsdatum bei seiner Registrierung angibt dann lasse ich auch nicht jeden Tag einen CJ laufen um sein Alter eventuell um 1 Jahr hochzurechnen. Ich errechne mir einfach das Alter anhand Geburtsdatum.

            Kommentar


            • #7
              Das ist Unsinn. Die meisten Events haben einen Einfluss auf andere, die wiederrum einen Einfluss auf noch andere haben. Je komplexer das Spiel, desto mehr rekursive Eventresolution muss man machen, was aber auch wieder total ineffizient ist. Alles sequentiell ausführen ist die einzige Lösung, die Sinn ergibt.
              Crashkurs zum Thema Rechtschreibung: normalerweise (normaler weise oder normaler weiße), Standard (Standart), eben (ebend)

              Kommentar


              • #8
                Zitat von Asterixus Beitrag anzeigen
                Daher rate ich dir wirklich an, entweder eine nicht relationale Datenbank wie MongoDB zu benutzen, oder dann eine andere relationale wie Oracle oder PGSQL (und wenn du PG benutzt, wirst du bestimmt 'nen neuen Freund in diesem Forum finden).
                Diesen Rat finde ich enorm gefährlich. Dokument-Datenbanken sind nur in einem sehr kleinen Rahmen wirklich effizient und sinnvoll einsetzbar.

                Spätestens, well du Referenzen auf andere Objekte hast, sind die Redundanzen in so einer Datenbank kaum noch handhabbar. Da kriegst du so wahsinnig schnell inkonsistente Daten, was dir mit einer InnoDB garnicht erst passieren kann.

                Davon rate ich wiederrum entschieden ab.

                Mit deinen Ausführungen über Cron-Jobs bin ich einverstanden. Ich verwende selbst Cron-Jobs in meinem Spiel, allerdings stündlich, da das gesamte Spiel auf diese Dauern ausgelegt/getaktet ist, da funktioniert das also wunderbar.
                Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

                Kommentar


                • #9
                  Zitat von Asterixus Beitrag anzeigen
                  Das ist Unsinn. Die meisten Events haben einen Einfluss auf andere, die wiederrum einen Einfluss auf noch andere haben. Je komplexer das Spiel, desto mehr rekursive Eventresolution muss man machen, was aber auch wieder total ineffizient ist. Alles sequentiell ausführen ist die einzige Lösung, die Sinn ergibt.
                  Nutz einen Eventdispatcher und lass Cronjobs laufen wenn du merkst, du hast zuviel Last auf dem Client-Request. Lass den Cronjob aber nicht Dinge herunterzählen. Was aber ok ist: Bemerken, dass das Haus fertig ist, den Status auf "done" setzen und von mir aus irgendwo die Fabrik freischalten. Aber genau das sollte auch Client-Seitig passieren, wenn es denn nötig sein sollte! Ansonsten muss der Client auf Cronjobs warten...

                  Kommentar


                  • #10
                    Gar keine Cronjobs heisst: Berechnungen werden im "Userkontext" berechnet (dh. die Zeit für Systemberechnungen geht auf die Antwortzeit des Benutzers). Das kann u.U. sehr unangenehm sein und zu Supportanfragen führen (wenn z.B. ein Request plötzlich viele Sekunden braucht anstatt nur wenige, um beantwortet zu werden)

                    Cronjobs in zu kurzen Abständen: Kann bei steigender Datenmenge zur Kaskadierung führen. Während der alte Job noch läuft, startet der nächste. Ohne Gegenmaßnahmen führt das unweigerlich zu Chaos und Problemen bei der Datenbankperformance.
                    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                    Kommentar


                    • #11
                      Wie wäre es mit einem Daemon? Der löst gleich alle Probleme:
                      - Kaskadierung ist nicht möglich
                      - Unnötige Last wenn keine Aufgaben vorhanden gibt es praktisch nicht
                      - Startet automatisch wieder falls er mal abstürzen würde
                      GitHub.com - ChrisAndChris - RowMapper und QueryBuilder für MySQL-Datenbanken

                      Kommentar


                      • #12
                        Ich habe bereits gesagt, dass ein Dämon die einzige Lösung dafür ist, die effizient ist.
                        Crashkurs zum Thema Rechtschreibung: normalerweise (normaler weise oder normaler weiße), Standard (Standart), eben (ebend)

                        Kommentar


                        • #13
                          Mir gehts nicht darum wer wie wo wann warum die Berechnungen anstellt. Wichtig scheint mir erstmal, dass dem TE klar wird, dass keine Werte runter gezählt.

                          Kommentar


                          • #14
                            Nimm MariaDB statt MySQL

                            Kommentar


                            • #15
                              Zitat von SirSnyder Beitrag anzeigen
                              Nimm MariaDB statt MySQL
                              Hauptsache mal was in die Runde geworfen. Begründe doch bitte deine Aussagen, vor dem Hintergrund, dass das hier ein totaler Anfänger ist, dem die feinen Unterschiede vermutlich völlig egal sind.
                              Lerne Grundlagen | Schreibe gute Beispiele | PDO > mysqli > mysql | Versuch nicht, das Rad neu zu erfinden | Warum $foo[bar] böse ist | SQL Injections | Hashes sind keine Verschlüsselungen! | Dein E-Mail Regex ist falsch

                              Kommentar

                              Lädt...
                              X