Mein Spiel besitzt bereits einen rudimentären "Fog-of-War"-Effekt. Beim Aufrufen der Karte wird dem Spieler lediglich das gezeigt, was er im Moment sehen kann. Orte, die er schon irgendwann besucht hatte, werden nicht berücksichtigt. Das ist zwar eine einfache und schnelle Lösung, aber spieltechnisch nicht das, was ich mir vorstelle.
Dem Spieler soll natürlich auch das gezeigt werden, was seine Kampftruppen schon mal irgendwann erkundet haben.
Die neue Karte von mir ist 100x100 = 10.000 Felder groß. Es wird immer die ganze Karte auf einmal angezeigt. Hier ein Link zur Testkarte.
Über die Darstellung selbst mache ich mir im Moment weniger Sorgen. Mein Problem ist die Berechnung einer FOW-Map.
Im Moment arbeite ich mit der GD-Bibliothek und weise jedem Spieler eine 100x100 Pixel große 8-Bit PNG zu. So ein Bild ist ca. 900 Byte groß.
Beim Darstellen der Karte wird die Map Pixel für Pixel durchlaufen und je nach Farbwert entweder ein schwarzes, ein halb transparentes oder ein durchsichtiges DIV auf die Karte gesetzt.
Naja wie schon gesagt macht die Darstellung im Moment keine Probleme, auf die Berechnung der FOW-Map kommt es an:
Da Kampftruppen sich bewegen, müssen die FOW-Maps der Spieler aktualisiert werden, da die sich ja bei einer Bewegung der Kampftruppen ändern.
Nun kann ich die Maps aber nicht immer nur aktualisieren, wenn der Spieler grad seine Karte anguckt, denn er würde die Bereiche der Karte nicht sehen können, die sein Kampftrupp erkundet hat, solage er offline war. Das muss also in einem Cronjob passieren.
Da sich aber die Kampftuppen relativ schnell bewegen (bis zu einem Feld in zwei Minuten) müssen die Karte ziemlich oft berechnet werden.
Jetzt stehe ich noch am Anfang meiner Überlegungen und habe noch nicht getestet, wie schnell man solche Karten generieren kann. Was könnt ihr mir über die Performanz sagen? Verfolge ich den richtigen Ansatz oder gibt es Mittel, die so eine Aufgabe viel besser lösen könnten?
"Fof of War" effizient berechnen
gepostet vor 17 Jahre, 10 Monate von Progralixx
gepostet vor 17 Jahre, 10 Monate von open_dimension
Vielleicht als allererstes die Frage.
Ist eine Datenbank nicht schneller als eine Grafik-Abfrage/Generierung?
Wir hatten das auch so vor, ist dann irgendwann gestrichen worden.
Ich hätte das auf Basis von 2 Tabellen gemacht, am Anfang -> wenig erkundet, speichert sie gesichteten Felder, später, wenn man viel erkundet hat, werden nur noch die nicht gesichteten Felder gespeichert.
Auf jeden Fall eine große Tabelle.
Ist eine Datenbank nicht schneller als eine Grafik-Abfrage/Generierung?
Wir hatten das auch so vor, ist dann irgendwann gestrichen worden.
Ich hätte das auf Basis von 2 Tabellen gemacht, am Anfang -> wenig erkundet, speichert sie gesichteten Felder, später, wenn man viel erkundet hat, werden nur noch die nicht gesichteten Felder gespeichert.
Auf jeden Fall eine große Tabelle.
gepostet vor 17 Jahre, 10 Monate von Progralixx
Naja wie soll man das in der Datenbank speichern? Für jedes Feld einen eigenen Datensatz anlegen? Dann hätte jeder Spieler 10.000 Datensätze in der Datenbank, bei 500 Spielern wären das dann schon 5.000.000 Eintäge...
gepostet vor 17 Jahre, 10 Monate von open_dimension
Ja eben nicht.
Tabellen haben folgenden Aufbau:
x - y - SpielerID
Eine speichert die gesehen Felder, die andere die ungesehenen eines Spielers.
Anfang des Spiels, alle sind in der einen Tabelle, da man weniger kennt, als was man nicht kennt.
Irgendwann ist die Tabelle für einen User auf 5000 Datensätze angewachsen. Dann wird er automatisch aus der einen Tabelle gelöscht, und der User wird auf die andere Tabelle gestellt, da er jetzt mehr kennt, als was er nicht kennt. Ab dann nehmen die Datensätze für den Spieler ab, statt zu.
Ergibt ein Rechnerisches Maximum bei 500 Spielern von 2.500.000 Einträgen. Die Realität wird aber weit darunter liegen.
Tabellen haben folgenden Aufbau:
x - y - SpielerID
Eine speichert die gesehen Felder, die andere die ungesehenen eines Spielers.
Anfang des Spiels, alle sind in der einen Tabelle, da man weniger kennt, als was man nicht kennt.
Irgendwann ist die Tabelle für einen User auf 5000 Datensätze angewachsen. Dann wird er automatisch aus der einen Tabelle gelöscht, und der User wird auf die andere Tabelle gestellt, da er jetzt mehr kennt, als was er nicht kennt. Ab dann nehmen die Datensätze für den Spieler ab, statt zu.
Ergibt ein Rechnerisches Maximum bei 500 Spielern von 2.500.000 Einträgen. Die Realität wird aber weit darunter liegen.
gepostet vor 17 Jahre, 10 Monate von Drezil
Original von Progralixx
Da Kampftruppen sich bewegen, müssen die FOW-Maps der Spieler aktualisiert werden, da die sich ja bei einer Bewegung der Kampftruppen ändern.
Nun kann ich die Maps aber nicht immer nur aktualisieren, wenn der Spieler grad seine Karte anguckt, denn er würde die Bereiche der Karte nicht sehen können, die sein Kampftrupp erkundet hat, solage er offline war. Das muss also in einem Cronjob passieren.
Da sich aber die Kampftuppen relativ schnell bewegen (bis zu einem Feld in zwei Minuten) müssen die Karte ziemlich oft berechnet werden.
wie berechnest du denn deine bewgungen? ich geh mal von einem vektorisierten Verfahren aus.
wenn immer eine Truppe ankommt, wird deren Route (=Linie) mit einem radius von x in die fow-map eingezeichnet.
Ich denke für meine Zwecke werde ich ein leicht anderes system nehmen.
ich werden die karte in Sektoren einteilen und das als bitmal in die db hauen. Ein Sektor (etwa 20*20 felder) wird entweder ganz oder gar nicht gesehen. Dann kommt dazu einen 2./3. Tabelle nach dem verfahren von open_dimension. so kann ich die Menge der Daten noch etwas kleiner halten.
wenn man viele radiale sichtkreise hat, dann kann man die sektoren auch rund & überlappend machen, statt quadratisch. Damit kann man z.b. die erhöhte anzahl der datensätze, die durch das radiale "sehen" in open_dimensions Vorschlag entstehen, effektiver minimieren.
gepostet vor 17 Jahre, 10 Monate von woodworker
ich habe mich auch schon mit dem fog of war beschäftigt und bin für mihc persönlich zum schluss gekommen das ich das wohl aus der DB raushalten werde und lieber mit PNG/Bitmasks mache
ich habs noch nicht gebenchmarkt aber sehe aus meiner sicht in der png+bitmask variante mehr vorteile das dafür ne extra db zu haben
ok sind pro user ne eigene png file aber Speicherplatz ist ja heute nciht mehr mangelware
Siehe Wiki
ich habs noch nicht gebenchmarkt aber sehe aus meiner sicht in der png+bitmask variante mehr vorteile das dafür ne extra db zu haben
ok sind pro user ne eigene png file aber Speicherplatz ist ja heute nciht mehr mangelware
Siehe Wiki
gepostet vor 17 Jahre, 10 Monate von exe
Man kann auch einfach die Bitmaske in der Datenbank speichern Wenn man nicht gerade mit PNGs rumhantiert kann man die Bitmaske einfach als Bitstring in der Datenbank ablegen. Vorrausgesetzt natürlich, die Datenbank kann mit solchen Datentypen vernünftig umgehen (BLOBS gehören da eher nicht dazu).
gepostet vor 17 Jahre, 10 Monate von open_dimension
@woodworker
Ich denke das brauch man nicht benchmarken.
Wenn ich eine Schwarz/Weiss - Grafik nehme 100*100 * 1 Bit. Komme ich genau auf diese 5.000.000 Einträge bei 500 Spieler. Diese Karte wird am Anfang absolut einfarbig sein. Massig überflüssige Information.
Wenn jetzt diese Grafik ausgelesen ist, schmeißt php eine fette Grafikbibliothek an, um dieses Bild zu analysieren. Dabei wird ja auch das komplette Bild analysiert/geladen.
Klar Speicher ist kein Problem, aber es kostet ja auch Zeit, den für diesen aufwendigen Prozess freizumachen.
Im Gegensatz zu dem anderen Verfahren, wo ich direkt abfragen kann, kenn ich diese Koordinate oder nicht. Es also nur einer gezielten Abfrage bedarf.
@Drezil
Ich habe mir auch noch einmal Gedanken gemacht, über die Optimierung des Verfahrens, eine Aufteilung in Sektoren hätte ja wieder den Verlust der Genauigkeit zur Folge. 20 * 20 Felder Sektoren würden die 100 * 100 Karte in 25 Sektoren aufteilen. Das ist ein sehr grobes Raster meiner Meinung nach.
Ich würde das so versuchen, für 50 Spieler gibt es 2 Tabellen nach dem obrigen Verfahren, für die nächsten 50 Spieler wieder 2 Tabellen.
Damit würde man die theoretische Datensatzmenge von 2.5 Mio auf 250.000 senken. Also realistische Werte von 100.000 Datensätze für beide Tabellen, und die sollten in Echtzeit handle-bar sein.
Weiterhin zu überlegen wäre die Streichung der x - y Koordinaten aus der Tabelle, und statt dessen mit einer Feld-ID zu arbeiten (nur noch 2 Spalten statt 3), das würde aber eine weiter DB Abfrage verursachen. Ich habe ja X-Y und muss erst ID erfragen, bevor ich die Sichtbarkeit auslesen kann.
Das müsste man dann wohl benshmarken, was das performatere Verfahren ist.
Ich denke das brauch man nicht benchmarken.
Wenn ich eine Schwarz/Weiss - Grafik nehme 100*100 * 1 Bit. Komme ich genau auf diese 5.000.000 Einträge bei 500 Spieler. Diese Karte wird am Anfang absolut einfarbig sein. Massig überflüssige Information.
Wenn jetzt diese Grafik ausgelesen ist, schmeißt php eine fette Grafikbibliothek an, um dieses Bild zu analysieren. Dabei wird ja auch das komplette Bild analysiert/geladen.
Klar Speicher ist kein Problem, aber es kostet ja auch Zeit, den für diesen aufwendigen Prozess freizumachen.
Im Gegensatz zu dem anderen Verfahren, wo ich direkt abfragen kann, kenn ich diese Koordinate oder nicht. Es also nur einer gezielten Abfrage bedarf.
@Drezil
Ich habe mir auch noch einmal Gedanken gemacht, über die Optimierung des Verfahrens, eine Aufteilung in Sektoren hätte ja wieder den Verlust der Genauigkeit zur Folge. 20 * 20 Felder Sektoren würden die 100 * 100 Karte in 25 Sektoren aufteilen. Das ist ein sehr grobes Raster meiner Meinung nach.
Ich würde das so versuchen, für 50 Spieler gibt es 2 Tabellen nach dem obrigen Verfahren, für die nächsten 50 Spieler wieder 2 Tabellen.
Damit würde man die theoretische Datensatzmenge von 2.5 Mio auf 250.000 senken. Also realistische Werte von 100.000 Datensätze für beide Tabellen, und die sollten in Echtzeit handle-bar sein.
Weiterhin zu überlegen wäre die Streichung der x - y Koordinaten aus der Tabelle, und statt dessen mit einer Feld-ID zu arbeiten (nur noch 2 Spalten statt 3), das würde aber eine weiter DB Abfrage verursachen. Ich habe ja X-Y und muss erst ID erfragen, bevor ich die Sichtbarkeit auslesen kann.
Das müsste man dann wohl benshmarken, was das performatere Verfahren ist.
gepostet vor 17 Jahre, 10 Monate von exe
Erstmal vorneweg: 2.5 Mio sind für ein vernünftiges Datenbanksystem ein Witz. Ich habe MySQL mal mit einer Tabelle mit 54 Millionen Einträgen getestet - läuft einwandfrei und lässt sich in Sekundenbruchteilen abfragen. Tabellen mit 2.5 Millionen Einträgen? Also wirklich ... eure Datenbanksysteme können wesentlich mehr.
Mal eine Überlegung von mir: wenn pro Feld 3 Stati (schwarz, grau, weiss) gespeichert werden sind das maximal 2 Bit pro Feld. Bei einer 100x100 = 10.000 Felder großen Karte also 20.000 Bit (oder rund 2.5kb). Wenn ich das in einzelne Integer a 32 Bit aufteile benötige ich zum Speichern 625 Integer. Wenn ich die nun in eine extra Tabelle lege ist das eine überschaubare Datenmenge. Selbst bei 10.000 Spielern kommt man damit auf 6.250.000 Datensätze - für ein modernes Datenbanksystem ein Klacks. Wenn die Karte vergrößert werden es natürlich mehr Datensätze. Dem kann man zum einen entgegentreten indem man 64-Bit Integer statt 32-Bittige nimmt, oder einfach die Tabelle partitioniert (wenn dein Datenbanksystem das unterstützt). Aber solange die Daten sich im Rahmen von < 100 Millionen Einträgen bewegen würde ich noch keine Panik schieben ...
Ausserdem lassen sich noch Optimierungen fahren. Zum Beispiel könnte man Bereiche die noch nie betreten wurden nicht speichern. Da die meisten User wohl nie die komplette Karte aufdecken würden im Schnitt sowieso nie die vollen 625 Einträge pro Spieler benötigt.
Alternativ würde ich auf eine einfache Bitmap die in einer Datei gespeichert wird zurückgreifen. Wenn du die Daten in eine (komprimierte) PNG speicherst, muss die komplette Grafik eingelesen, dekomprimiert und über eine komplette Grafikbibliothek zugänglich gemacht werden. Wenn jedes Feld aber einen festen Speicherbedarf (2 Bit) hat, kannst du die komplette Bitmaske auch einfach als Binärdatei auf die Festplatte schreiben. Und wenn du es noch ganz geschickt machst, teilst du deine Bitmaske in Blöcke ein die der Blockgröße der Festplatte entsprechen. Dann brauchst du, um einen Teil der Bitmaske zu lesen oder schreiben, genau eine Positionierung des Festplattenkopfs und genau eine Lese-/Schreiboperation. Schneller gehts nicht
Mal eine Überlegung von mir: wenn pro Feld 3 Stati (schwarz, grau, weiss) gespeichert werden sind das maximal 2 Bit pro Feld. Bei einer 100x100 = 10.000 Felder großen Karte also 20.000 Bit (oder rund 2.5kb). Wenn ich das in einzelne Integer a 32 Bit aufteile benötige ich zum Speichern 625 Integer. Wenn ich die nun in eine extra Tabelle lege ist das eine überschaubare Datenmenge. Selbst bei 10.000 Spielern kommt man damit auf 6.250.000 Datensätze - für ein modernes Datenbanksystem ein Klacks. Wenn die Karte vergrößert werden es natürlich mehr Datensätze. Dem kann man zum einen entgegentreten indem man 64-Bit Integer statt 32-Bittige nimmt, oder einfach die Tabelle partitioniert (wenn dein Datenbanksystem das unterstützt). Aber solange die Daten sich im Rahmen von < 100 Millionen Einträgen bewegen würde ich noch keine Panik schieben ...
Ausserdem lassen sich noch Optimierungen fahren. Zum Beispiel könnte man Bereiche die noch nie betreten wurden nicht speichern. Da die meisten User wohl nie die komplette Karte aufdecken würden im Schnitt sowieso nie die vollen 625 Einträge pro Spieler benötigt.
Alternativ würde ich auf eine einfache Bitmap die in einer Datei gespeichert wird zurückgreifen. Wenn du die Daten in eine (komprimierte) PNG speicherst, muss die komplette Grafik eingelesen, dekomprimiert und über eine komplette Grafikbibliothek zugänglich gemacht werden. Wenn jedes Feld aber einen festen Speicherbedarf (2 Bit) hat, kannst du die komplette Bitmaske auch einfach als Binärdatei auf die Festplatte schreiben. Und wenn du es noch ganz geschickt machst, teilst du deine Bitmaske in Blöcke ein die der Blockgröße der Festplatte entsprechen. Dann brauchst du, um einen Teil der Bitmaske zu lesen oder schreiben, genau eine Positionierung des Festplattenkopfs und genau eine Lese-/Schreiboperation. Schneller gehts nicht
gepostet vor 17 Jahre, 10 Monate von Progralixx
Ich denke ich werde doch die Datenbank für die Speicherung benutzen. Dadurch, dass ich nicht erkundete Felder nicht speichere, sondern nur die, die man gerade sieht oder mal gesehen hat spare ich ja ne Menge Datensätze.
Ich habe vielleicht noch vergessen zu erwähnen, dass Mitglieder aus der selben Allianz einen gemeinsamen Sichtbereich haben. D.h. ich kann hier noch einmal viel optimieren, indem ich der Allianz selbst den Sichtbereich zuordne und die Spieler dann eindfach den nehmen.
Ich habe vielleicht noch vergessen zu erwähnen, dass Mitglieder aus der selben Allianz einen gemeinsamen Sichtbereich haben. D.h. ich kann hier noch einmal viel optimieren, indem ich der Allianz selbst den Sichtbereich zuordne und die Spieler dann eindfach den nehmen.
gepostet vor 17 Jahre, 10 Monate von exe
Und was machst du, wenn ein Spieler eine Allianz verlässt? Behält er dann den kompletten Sichtbereich? Rekonstruieren was er selbst aufgedeckt hat kannst du ja nicht mehr, wenn du nur noch für die Allianz die Daten speicherst. Dann muss man nur mehrmals hintereinander die Allianz wechseln und hat die komplette Karte aufgedeckt ^^
gepostet vor 17 Jahre, 10 Monate von Progralixx
Naja prinzipiell müssen die Sichtbereiche für jeden einzelnen Spieler immer wieder aktualisiert werden. Spieler in einer Allianz teilen sich einen Sichtbereich, dadurch fällt einiges an Berechnung weg.
Wenn man nun eine Allianz verlässt, bekommte man eben wieder seinen eigenen Sichtbereich, der immer wieder aktualisiert werden muss. Der eigene Sichtbereich ist dann immer noch das, was man vorher erkundet hat (ob durch die ehemalige Allianz oder nicht) und das was man selbst sehen kann. (Eigene Kampftruppen, Basis, etc...)
Und selbst wenn man mehrmals die Allianz wechselt und die ganze Karte aufgedeckt hat, kann man ja auch nicht mehr als die Stützpunkte der anderen Spieler sehen. Kampftruppen erscheinen weiterhin nur im aktuell sichtbaren Bereich.
Wenn man nun eine Allianz verlässt, bekommte man eben wieder seinen eigenen Sichtbereich, der immer wieder aktualisiert werden muss. Der eigene Sichtbereich ist dann immer noch das, was man vorher erkundet hat (ob durch die ehemalige Allianz oder nicht) und das was man selbst sehen kann. (Eigene Kampftruppen, Basis, etc...)
Und selbst wenn man mehrmals die Allianz wechselt und die ganze Karte aufgedeckt hat, kann man ja auch nicht mehr als die Stützpunkte der anderen Spieler sehen. Kampftruppen erscheinen weiterhin nur im aktuell sichtbaren Bereich.
gepostet vor 17 Jahre, 9 Monate von The-Winner
Bei einem RTS habe ich auche eine FoW Map implementiert. Bei mir funzt das so:
Es gibt je Spieler(bzw in deinem Fall Allianz) ein 2D array of Word (spieler hat sicher <64k Einheiten). Jedes Word bildet eine Referenzzählung. Wenn sich nach einem frame eine Einheit bewegt hat, wird um die alte(auf int gerundtete Position) ein Kreis mit Sichtradius gezeichnet, in dem alle Array-Elemente um 1 veringert werden. Danach wird an der neuen Position ein kreis mit Sichtradius gezeichnet, in dem alle Punkte die 0 sind auf 2 gesetzt werden, alle anderen um 1 erhöht werden.
Anschließend kann man die Map so interpretieren:
0 =>Nie gesehen
1 =>Früher gesehen
>1=>Wird momentan gesehen
allerdings habe ich dabei natürlich deutlich weniger spieler(<16), daher ist der RAM-Verbrauch für mich kin Problem. Außerdem kann ich die Daten im speicher behalten, und muss sie nicht in einer db speichern. Daher weiß ich nicht ob dieses Verfahren für dein Projekt geeignet ist. (In php wohl nur sehr schwer und nicht Racecondition-sicher zu implementieren)
Es gibt je Spieler(bzw in deinem Fall Allianz) ein 2D array of Word (spieler hat sicher <64k Einheiten). Jedes Word bildet eine Referenzzählung. Wenn sich nach einem frame eine Einheit bewegt hat, wird um die alte(auf int gerundtete Position) ein Kreis mit Sichtradius gezeichnet, in dem alle Array-Elemente um 1 veringert werden. Danach wird an der neuen Position ein kreis mit Sichtradius gezeichnet, in dem alle Punkte die 0 sind auf 2 gesetzt werden, alle anderen um 1 erhöht werden.
Anschließend kann man die Map so interpretieren:
0 =>Nie gesehen
1 =>Früher gesehen
>1=>Wird momentan gesehen
allerdings habe ich dabei natürlich deutlich weniger spieler(<16), daher ist der RAM-Verbrauch für mich kin Problem. Außerdem kann ich die Daten im speicher behalten, und muss sie nicht in einer db speichern. Daher weiß ich nicht ob dieses Verfahren für dein Projekt geeignet ist. (In php wohl nur sehr schwer und nicht Racecondition-sicher zu implementieren)
gepostet vor 17 Jahre, 9 Monate von Moogly
Ich will noch einmal die Idee von Drezil für einen Cronjob auffassen. Ich gehe jetzt einfach mal davon aus, dass du eine Bewegung in linearer Gleichungsform hast. Nun gehen wir davon aus, dass der Trupp auf x3 y3 steht und einen Sichtradius von 2 Feldern hat. Darauß ergibt sich folgende Map (0 = nicht sichtbar, 1 = sichtbar, 2 ist der Standort des Trupps)
0 0 0 0 0 0 0
0 1 1 1 1 1 0
0 1 1 1 1 1 0
0 1 1 2 1 1 0
0 1 1 1 1 1 0
0 0 0 0 0 0 0
Nun bewegen wir den Trupp mal um x + 1 und y + 1
0 0 0 0 0 0 0 0
0 1 1 1 1 1 0 0
0 1 1 1 1 1 1 0
0 1 1 1 1 1 1 0
0 1 1 1 2 1 1 0
0 1 1 1 1 1 1 0
0 0 1 1 1 1 1 0
0 0 0 0 0 0 0 0
Aus dieser Bewegung ergibt sich, dass 9 neue Felder erkundet wurden, also insgesamt sind nun 34 Felder aufgedeckt ( + 26 % Neue ). Nun ist meine Idee, dass ein DatenUpdate erst eventuell bei +100% Neue oder eben bei erreichen des Zielortes getätigt wird. Gehen wir davon aus, dass der User sich um x + 5 und y + 5 bewegt hat:
0 0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 1 0 0 0 0 0
0 1 1 1 1 1 1 0 0 0 0
0 1 1 1 1 1 1 1 0 0 0
0 1 1 1 1 1 1 1 1 0 0
0 1 1 1 1 1 1 1 1 1 0
0 0 1 1 1 1 1 1 1 1 0
0 0 0 1 1 1 1 2 1 1 0
0 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 0
Darauß ergibt sich, dass es 0 % Überlappung zum ersten Feld gibt und nun eine neue Berechnung sinnvoll wäre. Dadurch könnte man die Berechnung alle 2 Minuten deutlich minimieren.
Viele werden jetzt anmerken, dass der User aber aktuelle Daten braucht. Wenn er sich nun in dem Zeitraum einloggt, in dem die Truppen sich zwar bewegt haben, aber aufgrund von Überlappung keine Neuberechnung stattgefunden hat, fehlen im eben die durch die letzten paar Felderbewegung neu aufgedeckten Felder und die Daten sind nicht 100% aktuell. Hier würde ich dann einfach eine Berechnung beim User durchführen und im sozusagen eine Datenbankspeicherung vorspielen.
Gruß
Moo
PS: Mir kommt gerade die Idee, einfach alle Truppenbewegungen mittels Vektoren in der Datenbank zu speichern und dann einfach beim User die FogMap zu berechnen. Natürlich würden dann teilweise viele Rechnungen anstehen, denkt ihr so ein Verfahren wäre theoretisch anwendbar?
0 0 0 0 0 0 0
0 1 1 1 1 1 0
0 1 1 1 1 1 0
0 1 1 2 1 1 0
0 1 1 1 1 1 0
0 0 0 0 0 0 0
Nun bewegen wir den Trupp mal um x + 1 und y + 1
0 0 0 0 0 0 0 0
0 1 1 1 1 1 0 0
0 1 1 1 1 1 1 0
0 1 1 1 1 1 1 0
0 1 1 1 2 1 1 0
0 1 1 1 1 1 1 0
0 0 1 1 1 1 1 0
0 0 0 0 0 0 0 0
Aus dieser Bewegung ergibt sich, dass 9 neue Felder erkundet wurden, also insgesamt sind nun 34 Felder aufgedeckt ( + 26 % Neue ). Nun ist meine Idee, dass ein DatenUpdate erst eventuell bei +100% Neue oder eben bei erreichen des Zielortes getätigt wird. Gehen wir davon aus, dass der User sich um x + 5 und y + 5 bewegt hat:
0 0 0 0 0 0 0 0 0 0 0
0 1 1 1 1 1 0 0 0 0 0
0 1 1 1 1 1 1 0 0 0 0
0 1 1 1 1 1 1 1 0 0 0
0 1 1 1 1 1 1 1 1 0 0
0 1 1 1 1 1 1 1 1 1 0
0 0 1 1 1 1 1 1 1 1 0
0 0 0 1 1 1 1 2 1 1 0
0 0 0 0 1 1 1 1 1 1 0
0 0 0 0 0 1 1 1 1 1 0
0 0 0 0 0 0 0 0 0 0 0
Darauß ergibt sich, dass es 0 % Überlappung zum ersten Feld gibt und nun eine neue Berechnung sinnvoll wäre. Dadurch könnte man die Berechnung alle 2 Minuten deutlich minimieren.
Viele werden jetzt anmerken, dass der User aber aktuelle Daten braucht. Wenn er sich nun in dem Zeitraum einloggt, in dem die Truppen sich zwar bewegt haben, aber aufgrund von Überlappung keine Neuberechnung stattgefunden hat, fehlen im eben die durch die letzten paar Felderbewegung neu aufgedeckten Felder und die Daten sind nicht 100% aktuell. Hier würde ich dann einfach eine Berechnung beim User durchführen und im sozusagen eine Datenbankspeicherung vorspielen.
Gruß
Moo
PS: Mir kommt gerade die Idee, einfach alle Truppenbewegungen mittels Vektoren in der Datenbank zu speichern und dann einfach beim User die FogMap zu berechnen. Natürlich würden dann teilweise viele Rechnungen anstehen, denkt ihr so ein Verfahren wäre theoretisch anwendbar?
gepostet vor 17 Jahre, 9 Monate von open_dimension
Das verstehe ich jetzt nicht.
Du hast doch sowieso einen Cronjob, der die Truppenbewegung aktualisiert. Lass den doch gleich die Sichtbarkeit mit updaten ...
Edit:
Ok, noch einmal ausführlcher. Weiss ja nicht, welche Prinzip der Legionsbewegung Du hast, ob du jedes Feld berechnen lässt, wo die Legion gerade steht. Dann ist es am einfachsten.
Du datest mit inserts die Karte up. Dein Vorhandensein der Kooradinate bei dem User, wird der Eintrag verworfen, da Primärschlüssel schon vorhanden.
Läßte du nur am Endpunkt die Legion erscheinen, würde ich, in dem Moment wo die Truppe ankommt, den Weg berechnen und genauso mit inserts die Sichtbarkeitstabelle aktualisieren ...
Oder bin ich am Thema vorbei ???
Du hast doch sowieso einen Cronjob, der die Truppenbewegung aktualisiert. Lass den doch gleich die Sichtbarkeit mit updaten ...
Edit:
Ok, noch einmal ausführlcher. Weiss ja nicht, welche Prinzip der Legionsbewegung Du hast, ob du jedes Feld berechnen lässt, wo die Legion gerade steht. Dann ist es am einfachsten.
Du datest mit inserts die Karte up. Dein Vorhandensein der Kooradinate bei dem User, wird der Eintrag verworfen, da Primärschlüssel schon vorhanden.
Läßte du nur am Endpunkt die Legion erscheinen, würde ich, in dem Moment wo die Truppe ankommt, den Weg berechnen und genauso mit inserts die Sichtbarkeitstabelle aktualisieren ...
Oder bin ich am Thema vorbei ???