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

  • #31
    Es geht ja nur darum, wieviel Spielzeit in einer bestimmten Spanne Realzeit vergeht... völlig egal, wie hoch oder niedrig man diese Beziehung definiert. "Echtzeit" heisst doch nichts anderes, als die Spielzeit synchron mit der Realtzeit laufen zu lassen... in Strategiespielen vergehen aber in 5 Minuten Realzeit vielleicht 3 Monate Spielzeit.

    Der Hausbau als Gegen-Beispiel - dauert eine halbe Stunde, alle fünf Minuten wächst Eigenschaft X um einen Punkt.
    Du unterteilst auch nur 30 Minuten in 5 Minuten Schritte und legst fest, das in 6 5-Minutenrunden eine Gebäudestufe gebaut wird - nichts anderes habe ich auch getan, nur in einem anderen Verhältnis.

    Wozu um alles in der Welt würde ich das jetzt in 1800 „Runden“ zerkrümeln wollen, ergibt doch kaum einen Sinn.
    Weil man in der Zwischenzeit noch andere Dinge erledigen kann (z.B. quasi-Echtzeit mit seinen Truppen gegeneinander antreten).

    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.
    Und in der Zwischenzeit sagst du ihm 5 Minuten lang "Fortschritt bei 80%"?
    Nein, du nimmst wieder die eingetragene Realzeit und rechnest genau aus, wieviel ganz aktuell zum Zeitpunkt des Zugriffs bereits fertig ist.. und der Benutzer refreshed seine Anzeige auch, um Fortschritt zu sehen.

    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.
    Richtig, aber man muss es wieder auf Spielzeit umrechnen, denn im Spiel heisst es nicht "Forschung abgeschlossen in x Sekunden", sondern in "Forschung abgeschlossen in x Monaten (Spielzeit)", um auch ein bischen beim Realismus zu bleiben, den ein Spiel mitbringen sollte.

    Setz das Wort "Runde" einfach als virtuelle Definition von einer bestimmten Realzeitspanne, und lass das dann die Basiseinheit sein für alle Berechnungen der Spiele Engine... die neue Sekunde sozusagen.

    Sid Meier's Civilisation ist ein das Parade Beispiel für Echtzeitstrategie, dort kann man die virtuelle Zeit entweder rasen lassen (pro Sekunde Realzeit vergeht 1 Jahr Spielzeit), man kann aber auch das Tempo selber drosseln, das Realzeit und Spielzeit 1:1 synchron laufen... dann hat man alle Zeit der Welt, seine Einstellungen vorzunehmen und wieder "vorzuspulen" um zu sehen, was so passiert. Und so durchlebt man einen ganzen Zivilisationszyklus in wenigen Wochen (von der Steinzeit ins Atomzeitalter)...
    Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

    Kommentar


    • #32
      Zusatz: Worum es mir eigentlich geht ist, das man eine Definition zu treffen hat. Das bei Egoshootern wirklich "Runden" abgearbeitet werden ist natürlich Quatsch, dort laufen Realzeit und Spielzeit immer synchron - aber im Detail ist so etwas absolut wichtig, will man z.B. physikalische Gegenheiten im Computer simulieren:
      Ein Schuss wird abgefeuert zum Zeitpunkt X von einer Position A. Richtung und Geschwindigkeit der Kugel sind bedeutend. Ziel B befindet sich aber in Bewegung von Position B, mit einer eigenen Geschwindkeit und Richtung. Man kann ausrechnen, ob die Kugel das Ziel trifft oder nicht, kennt man alle Variablen... und im Computer kennt man diese und kann, entgegen zur Realtiät, diese Variablen beeinflussen. Der Programmierer legt fest, wie schnell die Kugel fliegt, wie schnell sich eine Person in "seiner" Welt bewegen kann. Und sein Programm - seine Welt - folgt seinen programmierten Regeln (Physik).
      Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

      Kommentar


      • #33
        Zitat von lstegelitz Beitrag anzeigen
        Du unterteilst auch nur 30 Minuten in 5 Minuten Schritte und legst fest, das in 6 5-Minutenrunden eine Gebäudestufe gebaut wird - nichts anderes habe ich auch getan, nur in einem anderen Verhältnis.
        Eben - und um dieses Verhältnis geht es mir, und darum, dass nicht für alle Aktionen die Unterteilung gleich sein muss.

        Weil man in der Zwischenzeit noch andere Dinge erledigen kann (z.B. quasi-Echtzeit mit seinen Truppen gegeneinander antreten).
        Wer sich wo und in welchen Zeitintervallen getimed die Köpfe einschlägt, interessiert den Hausbau aber erst mal weniger.

        Und in der Zwischenzeit sagst du ihm 5 Minuten lang "Fortschritt bei 80%"?
        Wenn die Aktion Hausbau so definiert ist, wie ich sie im Beispiel definiert habe - ja, ganz genau, weil alles andere sonst gelogen wäre.

        Richtig, aber man muss es wieder auf Spielzeit umrechnen, denn im Spiel heisst es nicht "Forschung abgeschlossen in x Sekunden", sondern in "Forschung abgeschlossen in x Monaten (Spielzeit)", um auch ein bischen beim Realismus zu bleiben, den ein Spiel mitbringen sollte.
        Wenn für die Aktion Hausbau definiert ist, dass sie in einzelnen Stufen erfolgt, deren Fertigstellung jeweils eine bestimmte Zeitspanne dauert - dann wird das auch so und nicht anders angezeigt.

        Dass du die eine oder andere Definition des Fortschrittes einer Aktion für „realistischer“ halten magst, hat mit der grundsätzlichen Technik überhaupt nichts zu tun.

        In der Realität wird der Bauherr auch nicht für jeden auf der Baustelle eingeschlagenen Nagel den „Fertigstellungs-Status“ des Hauses um 0,0[...]001% erhöhen.
        Nein, im Gegenteil - es werden bestimmte „Milestones“ definiert, und deren Erreichen wird im voraus zeitlich geplant und im Nachhinein mit dieser Planung abgeglichen.

        Setz das Wort "Runde" einfach als virtuelle Definition von einer bestimmten Realzeitspanne, und lass das dann die Basiseinheit sein für alle Berechnungen der Spiele Engine... die neue Sekunde sozusagen.
        Es ergibt trotzdem wenig Sinn, für einen Hausbau einen Fortschritt in Prozent auf Sekundenbasis zu definieren, wenn du so darauf bedacht bist, „realistisch“ zu bleiben, siehe oben.

        Einen Fortschritt in Prozent rein zu Informationszwecken kann man ggf. zusätzlich angeben - aber eine gestaffelte Punktevergabe hat trotzdem ihre Berechtigung.
        Ein komplett fertig gestelltes Hausdach bietet vielleicht einen bestimmten Schutzfaktor bei einem Angriff. Aber zu sagen, ein „zu 73,125% fertiggestelltes Haus“ bietet auch einen Schutzfaktor von 73,125% o.ä. ist kaum „realistisch“, sondern ganz trockene und langweilige Mathematik.


        Aber, noch mal: Das sind eher Überlegungen hinsichtlich der Regeln bzw. Spielphilosophie - für die Implementierung haben die weniger Relevanz, wenn man so vorgeht, dass man Zeitintervalle im System hinterlegen kann, in denen etwas bestimmtes fertiggestellt/abgeschlossen wird.
        Den Umfang dieses Zeitintervalls im Einzelfall für bestimmte Aktionen auf der kleinsten Basiseinheit „Sekunde“ zu setzen, ist möglich und denkbar. Aber es muss nicht pauschal für alle Aktionen so sein.
        Sid Meier's Civilisation ist ein das Parade Beispiel für Echtzeitstrategie, dort kann man die virtuelle Zeit entweder rasen lassen (pro Sekunde Realzeit vergeht 1 Jahr Spielzeit), man kann aber auch das Tempo selber drosseln, das Realzeit und Spielzeit 1:1 synchron laufen... dann hat man alle Zeit der Welt, seine Einstellungen vorzunehmen und wieder "vorzuspulen" um zu sehen, was so passiert.
        Für einen single player mode ist das OK.
        Bei multi player muss der Zeitmaßstab aber für alle der gleiche sein, sonst haut das nicht hin.

        Zusatz: Worum es mir eigentlich geht ist, das man eine Definition zu treffen hat.
        Dann scheinen wir uns ja einig zu sein, trotz Verständigungsschwierigkeiten

        Eine „Basiseinheit“ sollte es geben. Aber die stellt eben auch nur die Basis dar, und muss deshalb nicht für alles die kleinste Unterteilung darstellen.
        [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

        Kommentar


        • #34
          Habt ihr meinen Beitrag auf der letzten Seite überhaupt bemerkt?
          "Das Unendliche ist weit, vor allem gegen Ende" - Alphonse Allais

          Kommentar


          • #35
            Zitat von Quu Beitrag anzeigen
            Habt ihr meinen Beitrag auf der letzten Seite überhaupt bemerkt?
            Du meinst den, in dem du dich darüber beklagst, dass die meisten „ich will ein Browsergame programmieren“-Threads in Foren wenig gehaltvolles bieten, weil den Fragern noch die Grundlagenkenntnisse und darüber hinausgehenden Erfahrungen fehlen, um selber entsprechende Konzepte entwickeln zu können ...?

            Nein, den habe ich nicht übersehen. Nur wo da jetzt der Unterschied zwischen dem, was du kritisierst, und dem, was du selber hier zeigst, liegen soll - das müsstest du mir bitte noch mal erklären.

            Abgesehen davon hab ich jetzt verstanden, dass es rundenbasiert ist, aber wie bringt mich das weiter?
            Keine Ahnung.
            Von so unspezifischen Fragen erwarte ich generell kaum, dass sie jemanden weiter bringen

            Zu deiner ursprünglichen Frage, nach Events und deren Abhängigkeiten, kamen doch schon mehrere direkt darauf bezogene Beiträge.
            Was für ein Fazit du bisher aus diesen ziehen kannst, und welche Fragen ggf. noch offen sind - das musst doch in erster Linie du selber wissen.
            [SIZE="1"]RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?[/SIZE]

            Kommentar


            • #36
              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?
              Insofern, als das du dein ursprüngliches Synchronisationsproblem nur auf diese Weise gelöst bekommst (indem dir bewusst wird, was Realzeit und Spielzeit bedeuten). Alle Aktionen eines Benutzers innerhalb eines bestimmten Zeitfensters können sich nur auf den Status zu diesem Zeitfenster beziehen. Eine Aktion, die zu spät eintrifft (Status hat sich zwischenzeitlich geändert), ist ungültig und wird verworfen.
              Zitat von Quu Beitrag anzeigen
              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.
              Genau darum geht es. Spieler A sieht noch eine Information, die längst veraltet sein könnte. Das darf nicht passieren, daher muss Spieler A im Falle eines Angriffs durch Spieler B benachrichtigt werden und die Chance bekommen zu reagieren. Man kann nicht einfach einen Spieler übergehen und am Anfang des nächsten Zuges sagen "Tut mir leid, deine Truppen wurden beim Angriff von Spieler B zwischenzeitlich vernichtet, ich hab nur vergessen dir zu sagen, das er angegriffen hat"

              Das Spiel als solches muss also einer zeitlichen Synchronisierung folgen (das Leben geht weiter), Ereignisse können ausserplanmässig eintreten, müssen aber in den Zeitrahmen eingefügt werden. Beteiligte des Ereignisses müssen darüber informiert werden (Client-Update), so das jeder sich auf die neue Situation einstellen kann. Aktionen können nur anhand der aktuellen Situation ausgeführt werden, die Übrprüfung der Gültigkeit bleibt aber dem Server überlassen. Er ist "Gott" sozusagen und muss jedem sagen, was Sache ist



              @ChrisB:
              Dann scheinen wir uns ja einig zu sein, trotz Verständigungsschwierigkeiten
              Ja, der Meinung bin ich auch nachdem ich deinen Post gelesen hatte.
              Über 90% aller Gewaltverbrechen passieren innerhalb von 24 Stunden nach dem Konsum von Brot.

              Kommentar


              • #37
                Die Diskussion ob Echtzeit oder nicht ist irrelevant. Wichtig ist nur der Zeitpunkt eines Events.

                Wenn du nicht die Möglichkeit hast ein Programm im Hintergrund laufen zu lassen, dass die Events zum punktgenauen Zeitpunkt auszuführen, wirst du die Events bei jedem User-Seitenaufruf (+ eventuelle Cronjobs) berechnen müssen.

                In der ersten Version meines Browsergame hat es eine Tabelle "events" gegeben.
                In der wurden alle Möglichen "Events" eingefügt.

                Code:
                table events:
                  event_id
                  event_type
                  type_event_id
                  time
                  done
                Bei jedem Aufruf wurden erstmal alle Events, die bis zum aktuellen Zeitpunkt ausgeführt werden mussten und noch nicht ausgeführt wurden, chronologisch geordnet selektiert.

                Neben der `events`-Tabelle gab es noch `troop_movement_events`, `building_events`, `merchant_events` usw.
                Jede dieser Tabellen entsprach einem event_type aus der Haupt-Event-Tabelle und der type_event_id war hier mit der Event-Tabelle verbunden.

                Es wurde nicht analysiert, welche Daten in Verbindung mit welchen anderen Daten standen, es wurden für alle aktuell berechneten Events die nötigen Daten jedes Mal berechnet. Das klingt zwar serverlastig, ist es aber bei < 830 Events pro Minuten überhaupt nicht.

                Worauf auf jeden Fall aufgepasst werden muss sind Transaktionen. Wenn ein Problem auftritt, sofort Exception throwen und Fehlerbehandlung machen + rollback. Ist in 6 Monaten Laufzeit bei 230 aktiven Benutzern nur dreimal (einmal war's meine Schuld) aufgetreten, aber es rettet Leben, bzw. in dem Fall Truppen
                Crashkurs zum Thema Rechtschreibung: [COLOR="Green"]normalerweise[/COLOR] ([COLOR="Red"]normaler weise[/COLOR] oder [COLOR="Red"]normaler weiße[/COLOR]), [COLOR="DarkGreen"]Standard[/COLOR] ([COLOR="Red"]Standart[/COLOR]), [COLOR="DarkGreen"]eben[/COLOR] ([COLOR="Red"]ebend[/COLOR])

                Kommentar

                Lädt...
                X