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

  • Quu
    hat ein Thema erstellt [Erledigt] Reihenfolge und (Un)Abhängigkeit von Events.

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

    Hallo,

    ich habe auf einer Website Events die sekundengenau berechnet werden. Soweit kein Problem. Dies geschieht indem vor jedem Seitenaufruf in der Datenbank geschaut wird ob Events anstehen und diese dann ggf. rückwirkend berechnet werden. Dass Events nicht 2x berechnet werden stelle ich sicher, indem ich in der Zeile des Events einen Status update und nur wenn mir PHP gesagt hat dass der Status sich geändert hat die Berechnung / das Event ausführe.
    Jetzt das Problem: wie kann ich sicherstellen, bzw kann ich sicherstellen dass die Events halbwegs in der richtigen Reihenfolge ausgeführt werden. Weil ich frage mich was passieren würde wenn Event Nr 23 von Browser A angestossen wird und kurze zeit später von Browser B Event Nr 24 angestossen wird, welches vor NR 23 fertig wäre. Dann hätte ich das Problem, dass Event Nr 24 noch nichts von den Änderungen des Events 23 gehört hat und es so zu inkonsistenzen kommen könnte.

    Mir fällt dafür keine sinvolle Lösung ein, ausser Abhängigkeiten für Events zu definieren, was jedoch bei sehr vielen Events performancetechnisch vermutlich nicht tragbar wäre.

    Andere Ideen? Eine Frage an alle die sich durch den Text gequält haben

  • Asterixus
    antwortet
    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

    Einen Kommentar schreiben:


  • lstegelitz
    antwortet
    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.

    Einen Kommentar schreiben:


  • ChrisB
    antwortet
    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.

    Einen Kommentar schreiben:


  • Quu
    antwortet
    Habt ihr meinen Beitrag auf der letzten Seite überhaupt bemerkt?

    Einen Kommentar schreiben:


  • ChrisB
    antwortet
    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.

    Einen Kommentar schreiben:


  • lstegelitz
    antwortet
    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).

    Einen Kommentar schreiben:


  • lstegelitz
    antwortet
    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)...

    Einen Kommentar schreiben:


  • Quu
    antwortet
    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.

    Einen Kommentar schreiben:


  • ChrisB
    antwortet
    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.

    Einen Kommentar schreiben:


  • lstegelitz
    antwortet
    "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.

    Einen Kommentar schreiben:


  • ChrisB
    antwortet
    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.

    Einen Kommentar schreiben:


  • Quu
    antwortet
    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.

    Einen Kommentar schreiben:


  • lstegelitz
    antwortet
    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.

    Einen Kommentar schreiben:


  • mepeisen
    antwortet
    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".

    Einen Kommentar schreiben:

Lädt...
X