Ankündigung

Einklappen
Keine Ankündigung bisher.

[Erledigt] Reihenfolge und (Un)Abhängigkeit von Events

Einklappen

Neue Werbung 2019

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

  • #16
    Um was für Ereignisse handelt es sich denn? Vlt. kann man das System ja etwas umstrukturieren das es anders berechnet wird, nach außen hin aber den selben Effekt hat.

    Kommentar


    • #17
      Es sind Ereignisse für ein Spiel, z.B ein Gebäude gebaut oder eine Forschung fertig
      "Das Unendliche ist weit, vor allem gegen Ende" - Alphonse Allais

      Kommentar


      • #18
        Das kann schnell zu einer sehr großen Berechnung kommen. Solange es sich nur um die Events eines Spielers handelt, ist das noch überschaubar, aber sobald du damit auch Interaktionen zwischen 2 Spielern handhabst, wird es schon schwieriger (ausser du betrachtest immer alle Events und nicht nur die vom Spieler, allerdings kann das auch sehr schnell zu langen Wartezeiten führen)

        Kommentar


        • #19
          Ich betrachte die Events aller Spieler, ich gehe aber davon aus, dass ich mit nem Cronjob der alle ~ 2 min ausgeführt wird dafür sorgen kann dass sich nicht zuviel Arbeit anhäuft.

          Ich danke allen, die mir geholfen haben herauszufinden, dass es keine sinvolle Lösung für mich gibt.
          "Das Unendliche ist weit, vor allem gegen Ende" - Alphonse Allais

          Kommentar


          • #20
            Es gibt eine Lösung für dich. Vorausberechnung. Wenn du beispielsweise weisst dass in 5 Minuten ein Gebäude fertig ist, dann überlege die Abhängigkeiten dazu. Du weisst beispielsweise dass dieses Gebäude bewirkt, dass deine Produktion erhöht wird. Dann stell dir die Frage: Wann ist diese Info relevant?
            Hintergrund: Wenn die Info erst beim nächsten Besuch des Users relevant ist, dann muss das Event nicht in 5 Minuten verarbeitet werden, sondern erst dann wenn der User das nächste mal die Seite betritt. Heisst: Du musst nur gucken, ob für den eingeloggten User ein nicht verarbeitetes Event vorliegt.
            Alternativ: Berechne die neuen Produktionszahlen bereits mit dem Bau des Gebäudes und nicht dann, wenns Gebäude fertig ist. Pflege zwei Datensätze: (a) Aktuelle Produktion und (b) Produktion in 5 Minuten. Selektiere dann beim Anzeigen der Produktion immer mit Zeitstempel. Damit sind die Daten bereits fertig und sobald die 5 Minuten um sind wird (b) selektiert, davor wird immer (a) selektiert. Natürlich bedeutet dies, dass es schwierig wird, wenn der Bau abgebrochen wird.
            [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
            Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

            Kommentar


            • #21
              Hintergrund: Wenn die Info erst beim nächsten Besuch des Users relevant ist, dann muss das Event nicht in 5 Minuten verarbeitet werden, sondern erst dann wenn der User das nächste mal die Seite betritt. Heisst: Du musst nur gucken, ob für den eingeloggten User ein nicht verarbeitetes Event vorliegt.
              Da muss man nur aufpassen, wenn man Interaktionen zwischen verschiedenen Usern hat. Wenn zum Beispiel ein User bei einem anderen User produzierte Dinge klauen kann, dann wäre es blöd, wenn die Produktion erst erhöht wird, wenn der User sich wieder einloggt. Da muss man auch immer die Abhängigkeiten betrachten.

              Die zweite Lösung mit den 2 Datenfeldern ist da denke ich mal wesentlich flexibler

              Kommentar


              • #22
                Deswegen habe ich auf die Abhängigkeiten hingewiesen
                [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

                Kommentar


                • #23
                  Das Problem dürfte, wei schon weiter oben erwähnt, genau darin liegen dass Abhängigkeiten zwischen den Benutzern stark sind. Wenn Rohstoffe geklaut werden können sollten sie möglichsst aktuell sein, wenn ein Angriff des Weges kommt sollte die Verteidgung zu dem Zeitpunkt möglichst stehen, sonst beschwert sich der Benutzer.

                  Wenn ich das ganze mit mehreren Datensätzen mache bekomme ich aber insofern Probleme als dass ich wenn ich eine Einheitenliste habe, dann angegriffen werde bei der alten Liste das Zeug update, ich bei der Neuen dasaber nicht getan habe dann aufeinmal alle Einheiten wieder da sind. Außerdem, wie soll ich z.B Ángriffe vorausberechnen? Ich weiss bei längergehenden Angriffen nicht ob vorher noch jemand anders den Angegriffenen unterstützt.
                  Außerdem bräuchte ich dafür dann fast für jede Sache eine unabhängige Tabelle in der DB, damit ich das möglichst unabhängig erhöhen kann. Ich würde zb. ungern die Ressourchen in der Usertabelle speichern(wo sie aktuell liegen) da ich dann viele identische Sachen habe (Mir fällt gerad das Wort dafür nicht ein)

                  Ich werde es vermutlich so machen, dass ich davon ausgehe, dass bei Ereignissen die nahe zeitlich beieinander liegen die Ausführungsreihenfolge egal ist, es ist egal ob eine Einheit vor oder nach einem Kampf fertig ist, für die Spieler zwar nicht direkt, aber im großen und ganzen schon. Aber auch da sehe ich Probleme auf mich zukommen, wenn zwei Kämpfe paralell gerechnet werden...
                  "Das Unendliche ist weit, vor allem gegen Ende" - Alphonse Allais

                  Kommentar


                  • #24
                    Nein, das weisst du nicht, ob andere doch noch was tun, was das Ergebnis beeinflusst. Dann musst du neu berehnen. Im übrigen arbeiten Prozessoren seit einiger Zeit auch so, sie berechnen viele Befehle im Voraus in der Hoffnung, dass sie die Ergebnisse nicht wegwerfen müssen aufgrund geänderter Bedingungen. Wenn doch haben die Prozessoren Pech gehabt.

                    Du kannst das natürlich auch etwas verschleiern. Also die Sachen nicht sekundengenau angeben. Sondern beispielsweise "Angriff in den nächsten 15 Minuten".
                    [url]www.php-maven.org[/url] PHP und Maven vereint: Build/Deploy/Produktion/Konfiguration, Projekt Management, CI, PHPUnit, zahlreiche Frameworks
                    Twitter @ [url]https://twitter.com/#!/mepeisen[/url] und Facebook @ [url]http://t.co/DZnKSUih[/url]

                    Kommentar


                    • #25
                      Was soll denn das überhaupt für ein Spiel werden?
                      Strategie, das hab ich schon raushören können. Echtzeit, Rundenbasiert, Hot-seat oder feste Rundenzeiten?

                      Die Verarbeitung von Ereignissen bezieht sich immer auf eine Spiel-Runde. Jedes Spiel arbeitet irgendwo rundenbasiert, bei Echtzeitspielen ist die Rundenzeit nur wesentlich kürzer.

                      Ausgangsbasis ist der Spiel-Zustand zu Beginn einer Runde (Stand der Rohstoffe, Entwicklung, Position von sich bewegenden Einheiten usw.). Alle Aktionen können nur auf den Zustand dieser Runde ausgeführt werden, Client und Server haben zu Beginn der Runde den gleichen Stand. Das ist sehr wichtig, da anderenfalls Client und Server nicht mehr synchronisiert sind, entbindet die Serverseite aber nicht von der Pflicht, die eingehenden Daten & Aktionen auf Gültigkeit zu untersuchen (z.B. dein Angriffsbeispiel, damit nicht plötzlich Einheiten auftauchen können, die in der Runde zuvor bereits vernichtet wurden - da kam dann wohl ein Event zu spät herein, hatte noch alte Daten und wird einfach in die aktuelle Runde eingefügt... klar, das dann die Daten völlig aus dem Ruder laufen. Oder der User versucht zu cheaten, solls ja auch geben).

                      Eingehende Aktionen werden vom Server gesammelt (es gelten nur Ereignisse der aktuellen Runde - hast du ein Ereignis dabei, das aus einer alten Runde kommt, war der Spieler halt zu langsam, s.o.) und für die Berechnung des Zustands der nächsten Runde verwendet.

                      Für die Annahme von Ereignissen (Aktionen) gibt der Server also eine gewisse Zeit, dann schliesst er die Annahme und startet die Berechnung der nächsten Runde anhand der Daten, die bis dahin eingegangen sind.
                      Nach Abschluss der Berechnung sendet der Server allen Clients den neuen Zustand und das Spielchen beginnt von vorne.
                      Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                      Kommentar


                      • #26
                        Das Spiel soll dann in Echtzeit stattfinden, aber das Rundenkonzept krieg ich da irgendwie nicht eingepasst. Denn die Angriffe dauern zB ne halbe Stunde, dann kann ich net als Rundendauer ne halbe Stunde nehmen.
                        Aktuell funktionier es so: Wenn ein Gebäude gebaut wird, wird die Stufe nicht sofort erhöht sondern in der DB eingetragen: zum Zeitpunk 14223966 wird die Stufe um eins erhöht. Vor jedem Seitenaufruf wird halt geschaut ob es passieren muss oder ob es zu früh ist. Ich werde aber dass Gefühl nicht los dass wir aneinander vorbeireden, oder zumindes ich an dir.
                        "Das Unendliche ist weit, vor allem gegen Ende" - Alphonse Allais

                        Kommentar


                        • #27
                          Zitat von Quu Beitrag anzeigen
                          Das Spiel soll dann in Echtzeit stattfinden, aber das Rundenkonzept krieg ich da irgendwie nicht eingepasst. Denn die Angriffe dauern zB ne halbe Stunde, dann kann ich net als Rundendauer ne halbe Stunde nehmen.
                          Natürlich nicht - wenn zwischenzeitlich weitere Aktionen möglich sind, dann beträgt die Dauer einer „Runde“ ja auch keine halbe Stunde.

                          In „Runden“ zu denken, bietet sich bei einem „Echtzeit“-Spiel, wo quasi zu jedem beliebigen Zeitpunkt ein Zugriff erfolgen kann, vielleicht auch nicht so wirklich an.
                          Aktuell funktionier es so: Wenn ein Gebäude gebaut wird, wird die Stufe nicht sofort erhöht sondern in der DB eingetragen: zum Zeitpunk 14223966 wird die Stufe um eins erhöht.
                          Wenn in mehreren Stufen erhöht wird, und das linear erfolgt - dann reicht es aber auch, den kompletten Bauzeitraum und den gesamten Anstieg der Stufen durch die Bau-Aktion zu speichern. Wie viel vom Bau schon erledigt ist, und welche Stufe damit bereits erreicht wurde, lässt sich damit zu jedem Zeitpunkt zwischendrin errechnen.
                          [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                          Kommentar


                          • #28
                            "Echtzeit" sind auch nur Runden... zumindest muss man es darauf reduzieren im Computerbereich. Du kannst (musst!) die "Echtzeit" in "Abständen von Millisekunden/Sekunden/Stunden/Tagen" einteilen. Wie lang eine Runde ist, bestimmst du als Programmierer. Je mehr Runden pro bestimmter Zeit (z.B. Sekunde) abgearbeitet werden, desto näher kommst du an die "Echtzeit" heran.

                            Dein Halbstündiger Kampf mal als Beispiel: Bei einer Rundenzeit von einer Sekunde dauert der Kampf 1800 Runden. Wie sich die beteiligten Einheiten verhalten bzw. was sie "schaffen", muss natürlich festgelegt werden. Wie weit kommt ein Fußsoldat in 1 Sekunde, wie weit ein Berittener? Wie lange ist das dann in Runden umgerechnet? Stehen sich die Parteien z.B. in 500m Entfernung zueinander auf, brauchen sie erstmal x Sekunden, um sich anzunähern. Bei einer Rundenzeit von 1 Sekunde passiert 120 Runden lang nix anderes, als das die Truppen sich bewegen. Definiert man nun eine Runde als 2 min, träfen die Einheiten bereits nach 1 Runde aufeinander.

                            Glaub mir, wenn ich dir sage, das die Einteilung in Runden etwas absolut wesentliches für Spiele dieser Art ist... auch für "Echtzeit" Spiele*

                            *edit: In "Echtzeit" dauern Runden nur Bruchteile von Sekunden. Beispiel Ego-Shooter, jeder kennt das Phänomen: A schiesst auf B (in Bewegung), auf seinem Bildschirm hat er B getroffen, beim Server ist der Schuss aber vorbeigegangen, weil B sich schon weiterbewegt hat. Dieses Problem lässt sich nicht in Realzeit lösen, ist physisch unmöglich wegen des sog. "Lag", Latenz zwischen Server und Client... Client-zu-Client heisst das, das die Gesamtlatenz die Summe der beiden Einzellatenzen ist (Info von Client A muss zum Server muss zu Client B und umgekehrt.
                            Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

                            Kommentar


                            • #29
                              Zitat von lstegelitz Beitrag anzeigen
                              Dein Halbstündiger Kampf mal als Beispiel: Bei einer Rundenzeit von einer Sekunde dauert der Kampf 1800 Runden.
                              Der Hausbau als Gegen-Beispiel - dauert eine halbe Stunde, alle fünf Minuten wächst Eigenschaft X um einen Punkt.

                              Wozu um alles in der Welt würde ich das jetzt in 1800 „Runden“ zerkrümeln wollen, ergibt doch kaum einen Sinn.

                              Wenn ein Nutzer zum Zeitpunkt Start+4:59 zugreift, dann ist die erste Baustufe noch nicht abgeschlossen, ab Start+5:00 ist sie es.
                              Und für alle anderen, zwischen den „Bauabschnitten“ liegenden Zugriffspunkte sieht es genauso aus.
                              Das kann zum Zugriffszeitpunkt ermittelt/berechnet werden - dazu muss aber ganz sicher nicht die eigentliche Aktion Hausbau explizit in 1800 einzelne „Schritte“ zerbröselt werden.


                              Damit, dass die zeitliche „Auflösung“ selber festgelegt werden kann, hast du Recht.
                              Das bedeutet aber nicht, dass man diese für alle länger dauernden und schrittweise ablaufenden Aktionen auf genau das gleiche winzige Intervall herunterbrechen muss.
                              [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

                              Kommentar


                              • #30
                                Das heisst, wenn ich das auf dem Rundenkonzept aufbauen würde, hätte ich bei einem Angriff anstatt einer Bewegungsrechnung & Kampfrechnung am Ende auch noch 1800 Zwischenschritte. Das will mir jetzt von dem Rechenaufwand her nicht wirklich gefallen.
                                Abgesehen davon hab ich jetzt verstanden, dass es rundenbasiert ist, aber wie bringt mich das weiter?

                                Zum Thema Spieltyp noch ein bisschen mehr: es geht in die Richtung eines klassischen Browsergames, allerdings mit neuem, hochintelligenten, absolout innovativen Elementen Aber zumindest in Dingen wie Angriffen ähnelt es doch den klassischen, bekannten Marktführern.
                                Das wollte ich nur am Anfang nicht direkt schreiben, weil es doch eine gewisse Ablehung gibt gegen Leute die einfach mal allein aus purer Langeweile ein Browergame programmieren wollen. Ich kann die sogar nachvollziehen. Die Anzahl der Forenthread im Internet die sich mit der Implementierung eines BG's beschäftigen und sinnvoll sind kann man an einer Hand abzählen.
                                "Das Unendliche ist weit, vor allem gegen Ende" - Alphonse Allais

                                Kommentar

                                Lädt...
                                X