Ich suche nach einer einfachen und performanten Lösung, eine Karte so aufzubauen, dass jeder Spieler nur die Kartenfelder sieht, die er auch mit einem Kundschafter betreten hat. Die Karte ist ca. 400x400 Felder gross und es gibt ca. 500 Spieler. Wenn ich nun für jeden Spieler und für jedes Feld den unsichtbar / sichtbar Wert abspeichern muss, wird die Tabelle einfach viel zu gross (ca 500MB).
Ich habe noch keine Tests gemacht, aber ich denke das wird sehr langsam! Hat da jemand schon Erfahrungen gesammelt oder andere Lösungsansätze?
Unsichtbare / sichtbare Karte
gepostet vor 19 Jahre, 9 Monate von Fasi
gepostet vor 19 Jahre, 9 Monate von Sogil
Du könntest das gesehen/nicht gesehen bitweise abspeichern und das ganze vielleicht auch noch irgendwie komprimieren.
gepostet vor 19 Jahre, 9 Monate von neit
Mein Vorschlag wäre ein Array mit den Koordinaten der gesehenen Felder das du via serialize mit in ein Feld des jeweiligen Benutzerdatensatzes speicherst.
gepostet vor 19 Jahre, 9 Monate von Gambler
Also normal sind doch nur die Felder sichtbar wo auch grad ne Einheit ist. Die haben vl. nen Sichtradius. Da kann man doch vom angezeigten Abschnitt on the fly berechnen was man sieht. Und wirklich rechenintensiv ist das denke ich auch nicht da es einfache Grundrechenarten sind. Kommt halt auf das eigene System an wie performant das finden der Einheiten ist. Wobei das ja nur bei eigenen zu machen ist die im ausgewählten Bereich sind.
Oder meinst du das anders? Das alles schwarz ist und man wenn man mal dort war sieht dass das z.B. ein Berg ist, aber nicht welche Einheit auf dem Berg hockt wenn man net in der Nähe ist?
Oder meinst du das anders? Das alles schwarz ist und man wenn man mal dort war sieht dass das z.B. ein Berg ist, aber nicht welche Einheit auf dem Berg hockt wenn man net in der Nähe ist?
gepostet vor 19 Jahre, 9 Monate von KEEN
Ich glaub er meint letzeres. Also alles schwarz, bis auf die Felder die man mal betreten hat, oder mal im Sichtradius hatte. Mich würden das auch sehr interessieren.
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
@fasi:
welche db verwendest du überhaupt?
und welche sonstigen sprachen?
ich gehe jetzt erstmal von mysql und php aus...
lösung 1:
anhand deiner Zahlen vermute ich, dass du an folgende Tabellen-Spalten gedacht hast:
user-id | x | y
jeweils 2 byte pro spalte
-> 6 byte pro user und gesehenes feld
-> 6*400*400*500=458 mb FALLS jeder user jedes feld gesehen hat
lösung 2:
da deine koordinaten jeweils nur 9 bit brauchen könntest du eigentlich mit 4 byte pro user und gesehenes feld auskommen (9 bit x + 9 bit y + 14 bit user-id)
um das zu realisieren müsste deine tabelle aber aus einer einzigen spalte bestehen und dann könntest du indices vergessen -> langsame queries auf immernoch große datenmenge:
-> 4*400*400*500=305 mb FALLS jeder user jedes feld gesehen hat
lösung 3:
wenn wirklich der großteil der user nach kurzer zeit alle felder gesehen hat, dann müsste man ja entsprechend viele daten speichern und es wäre optimal, pro user nur ein bit pro feld aufwenden zu müssen:
zwei spalten: user-id | feld-daten
das wären gerade mal 400*400/8=19.5 kb pro user
dummerweise gibt es in deiner db-system wohl keinen 20kb-umfassenden spaltentyp mit statischer länge, so dass du einen dynamischen typ (z.b. "blob") nehmen müsstest, was wiederum nicht so gut für die geschwindigkeit ist, da die db davon ausgeht, dass die zeilen in der tabelle unterschiedlich lang sind, wobei du doch für jeden user gleich viel daten speichern würdest...
-> (2+400*400/*500=10 mb EGAL wie viele felder ein user gesehen hat
lösung 4:
also könnte man das gleiche aus der db rausnehmen und z.b. pro user eine sichtbarkeits-datei von jeweils 19.5 kb machen
das wäre von der datenmenge her perfekt, aber du könntest die feldabfragen nicht mehr in queries einbauen sondern müsstest im nachhinein über den dateiinhalt unsichtbare felder aus query-rückgaben aussortieren
-> 10 mb in dateien EGAL wie viele felder ein user gesehen hat
nun stellt sich die frage, wie viele felder ein user durchschnittlich gesehen hat - davon hängt alles ab!
lösung 5:
falls viele user wirklich jeweils so viele felder sehen könnte man die daten aufteilen und die oberste lösung wählen, jedoch immer mal wieder (cronjob) die daten auswerten und für jeden user rechteckige, komplett sichtbare bereiche in eine zweite tabelle auslagern:
tabelle 1: user-id | x | y (jeweils 2 byte pro spalte)
tabelle 2: user-id | x1 | y1 | x2 | y2 (jeweils 2 byte pro spalte)
dann hättest du pro user ein nicht exakt vorhersagbares speicheraufkommen von 10 byte pro rechteck und 6 byte pro weiteres feld
bereits zwei nebeneinander liegende sichtbare felder könnten zu einem rechteck zusammengefasst werden und würden so speicherplatz sparen
lösung 6 (schwer!):
du schreibst dir in c/c++ ein programm, welches auf deinem server läuft und die sichtbarkeitsdaten für alle user im ram hält (insgesamt 10mb - speicherplatzverbrauch wie in lösung 4), diese hin und wieder auf der festplatte speichert und funktionen bereitstellt, um die sichtbarkeit eines feldes auszulesen und zu speichern.
zusätzlich musst du dein php um zwei funktionen erweitern, die mit diesem programm kommunizieren, damit du aus deinen php-scripts heraus felder auslesen und setzen kannst.
zur komprimierung:
komprimieren würde ich die daten nicht, da du wohl des öfteren darauf zugreifen willst und die dann immer wieder zu dekomprimieren ist auch nicht so toll...
fazit:
wie gesagt hängt alles davon ab, wie viele felder der durchschnitts-user sieht und wie diese wahrscheinlich angeordnet sind - werden die spieler querfeldein über die karte felder sehen oder eher einen (rechteckigen) raum um ihren startpunkt erforschen usw....
ich empfehle dir lösung 5 (hat die meisten vorteile) und wenn dir das zu viel aufwand ist lösung 4.
welche db verwendest du überhaupt?
und welche sonstigen sprachen?
ich gehe jetzt erstmal von mysql und php aus...
lösung 1:
anhand deiner Zahlen vermute ich, dass du an folgende Tabellen-Spalten gedacht hast:
user-id | x | y
jeweils 2 byte pro spalte
-> 6 byte pro user und gesehenes feld
-> 6*400*400*500=458 mb FALLS jeder user jedes feld gesehen hat
lösung 2:
da deine koordinaten jeweils nur 9 bit brauchen könntest du eigentlich mit 4 byte pro user und gesehenes feld auskommen (9 bit x + 9 bit y + 14 bit user-id)
um das zu realisieren müsste deine tabelle aber aus einer einzigen spalte bestehen und dann könntest du indices vergessen -> langsame queries auf immernoch große datenmenge:
-> 4*400*400*500=305 mb FALLS jeder user jedes feld gesehen hat
lösung 3:
wenn wirklich der großteil der user nach kurzer zeit alle felder gesehen hat, dann müsste man ja entsprechend viele daten speichern und es wäre optimal, pro user nur ein bit pro feld aufwenden zu müssen:
zwei spalten: user-id | feld-daten
das wären gerade mal 400*400/8=19.5 kb pro user
dummerweise gibt es in deiner db-system wohl keinen 20kb-umfassenden spaltentyp mit statischer länge, so dass du einen dynamischen typ (z.b. "blob") nehmen müsstest, was wiederum nicht so gut für die geschwindigkeit ist, da die db davon ausgeht, dass die zeilen in der tabelle unterschiedlich lang sind, wobei du doch für jeden user gleich viel daten speichern würdest...
-> (2+400*400/*500=10 mb EGAL wie viele felder ein user gesehen hat
lösung 4:
also könnte man das gleiche aus der db rausnehmen und z.b. pro user eine sichtbarkeits-datei von jeweils 19.5 kb machen
das wäre von der datenmenge her perfekt, aber du könntest die feldabfragen nicht mehr in queries einbauen sondern müsstest im nachhinein über den dateiinhalt unsichtbare felder aus query-rückgaben aussortieren
-> 10 mb in dateien EGAL wie viele felder ein user gesehen hat
nun stellt sich die frage, wie viele felder ein user durchschnittlich gesehen hat - davon hängt alles ab!
lösung 5:
falls viele user wirklich jeweils so viele felder sehen könnte man die daten aufteilen und die oberste lösung wählen, jedoch immer mal wieder (cronjob) die daten auswerten und für jeden user rechteckige, komplett sichtbare bereiche in eine zweite tabelle auslagern:
tabelle 1: user-id | x | y (jeweils 2 byte pro spalte)
tabelle 2: user-id | x1 | y1 | x2 | y2 (jeweils 2 byte pro spalte)
dann hättest du pro user ein nicht exakt vorhersagbares speicheraufkommen von 10 byte pro rechteck und 6 byte pro weiteres feld
bereits zwei nebeneinander liegende sichtbare felder könnten zu einem rechteck zusammengefasst werden und würden so speicherplatz sparen
lösung 6 (schwer!):
du schreibst dir in c/c++ ein programm, welches auf deinem server läuft und die sichtbarkeitsdaten für alle user im ram hält (insgesamt 10mb - speicherplatzverbrauch wie in lösung 4), diese hin und wieder auf der festplatte speichert und funktionen bereitstellt, um die sichtbarkeit eines feldes auszulesen und zu speichern.
zusätzlich musst du dein php um zwei funktionen erweitern, die mit diesem programm kommunizieren, damit du aus deinen php-scripts heraus felder auslesen und setzen kannst.
zur komprimierung:
komprimieren würde ich die daten nicht, da du wohl des öfteren darauf zugreifen willst und die dann immer wieder zu dekomprimieren ist auch nicht so toll...
fazit:
wie gesagt hängt alles davon ab, wie viele felder der durchschnitts-user sieht und wie diese wahrscheinlich angeordnet sind - werden die spieler querfeldein über die karte felder sehen oder eher einen (rechteckigen) raum um ihren startpunkt erforschen usw....
ich empfehle dir lösung 5 (hat die meisten vorteile) und wenn dir das zu viel aufwand ist lösung 4.
gepostet vor 19 Jahre, 9 Monate von schokofreak
bluescreen. Denk einfach daran, dass der Ram Bedarf bei einer C++ lösung bedeutend grösser wäre.
aus meiner sicht gibt es 3 PRINZIPIELLE Möglichkeiten.
Wie die implementiert werden, ist egal (ob DB,oder serealisiert).
Möglichkeit 1: Man speichert sich zu jedem Feld, ob man es gesehen hat. Dies kann man über eine simple Bit- Maske machen.
=> Mit viel würgen, kriegt man es sogar als BitMaske in eine DB, welche schnell durchsuchbar ist.
Problem der Sache: SEHR Viele Daten. Sehr schnelle Suche.
Möglichkeit 2: Man speichert sich "Bereiche". Die Logik dahinter ist. Wer bei seiner Heimat ist, wird in der nähe wohl so ziemlich viele Feldchen gesehen, wer weiter weg ist, wohl so ziemlich gar keine.
=> Man unterteilt die gesamtKarte in X * X Bereiche. Danach wird nur gespeichert: Wurde dieser Bereich überhaupt Belegt?
Wenn ja, wird dort die 0101001 maske gespeichert.
Profit: Wenn die Leute wirklich "Nesthocker" sind, braucht es nur sehr wenig Platz. Man kann davon ausgehen, dass es NIE leute geben wird, welche alles Sehen.
Problem der Sache: Immer noch viele Daten. Je nach Game kann dies auch n schuss nach hinten sein, wenn z.Bl 90 % aller user alles sehen. Denn das ganze braucht weiderum verwaltungsaufwand.
Suchmöglichkeiten Mittelschnell
Möglichkeit 3:
Man geht davon aus, dass der User nicht rein Chaotisch Land entdeckt. sprich, ex bilden sich hier und dort so kleine "Fleckchen".
Man speichert sich eine Map mit "sichtbarkeitsbereichen". Sprich z.B. speichert man sich Vierecke oder Kreise. Alle Felder in diesen Bereichen sind bekannt.
Wird was neues entdeckt; wird ein neuer Bereich angelegt. Wen immer möglich wird versucht; Bereiche zu grossen Bereichen zu verschmelzen.
Ansatz hierbei. Wer ein gebiet sehr gut kennt, und nur noch 1 Feld ned kennt... erfährt dieses mit der Zeit auch; liegt ja so nahe. Auf deutsch: Das ganze ist nicht 100 % präzise.
Kann als KI Verkauft werden, wenn richtig programmiert und verkauft.
Vorteil: Der Datenbedarf ist Minimal.
Die Suche ist schnell. Sehr schnell.
Nun gehen wir mal an die Entwicklung. Aufdrängen würde sich ein System, welches alles vereint.
Wie sieht das aus?
Man bildet intelligente Bereiche laut 3. diese Bereiche werden sehr grob gefasst. (viel Fehler). In diesen Bereichen bildet man einen Raster laut 2.
Und je nachdem macht man 1 auch noch. oder sagt gleich: Der minime Fehler wird tolleriert.
Somit haben wir.
Bei 10'000 x 10'000 Feldern eine Suchanfragezeit von wenige Millisekunden. Speicherbedarf minimalst.
Gruss
aus meiner sicht gibt es 3 PRINZIPIELLE Möglichkeiten.
Wie die implementiert werden, ist egal (ob DB,oder serealisiert).
Möglichkeit 1: Man speichert sich zu jedem Feld, ob man es gesehen hat. Dies kann man über eine simple Bit- Maske machen.
=> Mit viel würgen, kriegt man es sogar als BitMaske in eine DB, welche schnell durchsuchbar ist.
Problem der Sache: SEHR Viele Daten. Sehr schnelle Suche.
Möglichkeit 2: Man speichert sich "Bereiche". Die Logik dahinter ist. Wer bei seiner Heimat ist, wird in der nähe wohl so ziemlich viele Feldchen gesehen, wer weiter weg ist, wohl so ziemlich gar keine.
=> Man unterteilt die gesamtKarte in X * X Bereiche. Danach wird nur gespeichert: Wurde dieser Bereich überhaupt Belegt?
Wenn ja, wird dort die 0101001 maske gespeichert.
Profit: Wenn die Leute wirklich "Nesthocker" sind, braucht es nur sehr wenig Platz. Man kann davon ausgehen, dass es NIE leute geben wird, welche alles Sehen.
Problem der Sache: Immer noch viele Daten. Je nach Game kann dies auch n schuss nach hinten sein, wenn z.Bl 90 % aller user alles sehen. Denn das ganze braucht weiderum verwaltungsaufwand.
Suchmöglichkeiten Mittelschnell
Möglichkeit 3:
Man geht davon aus, dass der User nicht rein Chaotisch Land entdeckt. sprich, ex bilden sich hier und dort so kleine "Fleckchen".
Man speichert sich eine Map mit "sichtbarkeitsbereichen". Sprich z.B. speichert man sich Vierecke oder Kreise. Alle Felder in diesen Bereichen sind bekannt.
Wird was neues entdeckt; wird ein neuer Bereich angelegt. Wen immer möglich wird versucht; Bereiche zu grossen Bereichen zu verschmelzen.
Ansatz hierbei. Wer ein gebiet sehr gut kennt, und nur noch 1 Feld ned kennt... erfährt dieses mit der Zeit auch; liegt ja so nahe. Auf deutsch: Das ganze ist nicht 100 % präzise.
Kann als KI Verkauft werden, wenn richtig programmiert und verkauft.
Vorteil: Der Datenbedarf ist Minimal.
Die Suche ist schnell. Sehr schnell.
Nun gehen wir mal an die Entwicklung. Aufdrängen würde sich ein System, welches alles vereint.
Wie sieht das aus?
Man bildet intelligente Bereiche laut 3. diese Bereiche werden sehr grob gefasst. (viel Fehler). In diesen Bereichen bildet man einen Raster laut 2.
Und je nachdem macht man 1 auch noch. oder sagt gleich: Der minime Fehler wird tolleriert.
Somit haben wir.
Bei 10'000 x 10'000 Feldern eine Suchanfragezeit von wenige Millisekunden. Speicherbedarf minimalst.
Gruss
gepostet vor 19 Jahre, 9 Monate von Spyme
Sofern ich das jetzt richtig verstanden habe gebe ich auch einen Lösungsansatz hinzu.
Wenn Du mit Templates arbeitest kannst Du statt Tabellen Container Objekte benutzen und diese mit der CSS Eigenschaft visibility:hidden; verbergen. Der Code müsste nur das Template anweisen in diesem Falle die nicht erkundeten Gebiete / Felder diesen CSS Wert zuzuweisen.
Wenn ich doch nicht richtig gelesen habe, einfach ignorieren
Wenn Du mit Templates arbeitest kannst Du statt Tabellen Container Objekte benutzen und diese mit der CSS Eigenschaft visibility:hidden; verbergen. Der Code müsste nur das Template anweisen in diesem Falle die nicht erkundeten Gebiete / Felder diesen CSS Wert zuzuweisen.
Wenn ich doch nicht richtig gelesen habe, einfach ignorieren
gepostet vor 19 Jahre, 9 Monate von Moogly
Ich empfehle diese eher unelegante lösung:
Du hast ja die Datenbank in der die map gespeichert ist, die ist ja ca. so aufgebaut:
feld_id|x_achse|y_achse
Nun würde ich noch ein Feld dazufügen:
sichbar und es als Textfeld deklarieren!
Nun speicherst du in einem String, jeweils durch ein gut durchdachtes Trennungszeichen getrennt die user_id der User die das Feld sehen könne, also z.B:
User_id_A(Trennungszeichen, bsp: %@%)User_id_B
Und dann frägst du einfach das FEld mittels:
WHERE sichtbar LIKE '%$user_id%'
MfG Moogly
Du hast ja die Datenbank in der die map gespeichert ist, die ist ja ca. so aufgebaut:
feld_id|x_achse|y_achse
Nun würde ich noch ein Feld dazufügen:
sichbar und es als Textfeld deklarieren!
Nun speicherst du in einem String, jeweils durch ein gut durchdachtes Trennungszeichen getrennt die user_id der User die das Feld sehen könne, also z.B:
User_id_A(Trennungszeichen, bsp: %@%)User_id_B
Und dann frägst du einfach das FEld mittels:
WHERE sichtbar LIKE '%$user_id%'
MfG Moogly
gepostet vor 19 Jahre, 9 Monate von Gambler
Das ist wirklich unelegant
Das würde denke ich sehr langsam werden.
Das würde denke ich sehr langsam werden.
gepostet vor 19 Jahre, 9 Monate von Moogly
Ich benutze das auch bei meiner Forensoftware und muss sagen, dass es überraschend schnell ist!
MfG Moogly
MfG Moogly
gepostet vor 19 Jahre, 9 Monate von KEEN
Bei ein paar huntert Spielern mag es eine gute Lösung sein, aber bei tausenden wird man wohl Performance Probleme bekommen. Schließlich kann man keine Indizes im Textfeld nutzen
gepostet vor 19 Jahre, 9 Monate von Moogly
Ich benutze dieses Prinzip bei einem Forum mit rund 12000 Einträgen! Und da geht das in ner halben Sekunde! Ist relativ simpel aufgebaut:
Abfage->Array->Abfrage der Kats&Foren->Array abfrage->Anzeige!
MfG Moogly
Abfage->Array->Abfrage der Kats&Foren->Array abfrage->Anzeige!
MfG Moogly
gepostet vor 19 Jahre, 9 Monate von schokofreak
Original von Moogly
Ich benutze dieses Prinzip bei einem Forum mit rund 12000 Einträgen! Und da geht das in ner halben Sekunde! Ist relativ simpel aufgebaut:
Abfage->Array->Abfrage der Kats&Foren->Array abfrage->Anzeige!
MfG Moogly
Überleg mal...
Für ein Spiel mit 10'000 Spielern rechne ich mit durchschnittlich ca. 10 bis 20 Anfragen pro Sekunde.
Wenn nun eine einzelne Anfrage 1/2 Sekunde dauert, so braucht man 10 Server? *schiel*
gepostet vor 19 Jahre, 9 Monate von Dr.Evil
Also, ich würde es ungefähr so lösen wie schokofreak schon beschreiben hat.
Du hast eine Tabelle, das speicherst du einfach welcher Spieler welches Feld gesehen hat.
Jetzt erstellst du alle x Stunden in eine zweite Tabelle, diese besteht aus aus Koordinaten von Rechtecken.
Da der Spieler im laufe des Spieles immer mehr Land (und wahrscheinlich auch flächig) erkundet bekommst du immer größere rechtecke und. Da jedes Rechteck nur einmal gespeichert wird veringert sich die Datenmenge also immer mehr. Am Schluss wenn man alles erkundet hat ist es 1 Eintrag.
userid, x1, x2, y1, y2.
Wie du die Rechtecke suchst
Ich würde einfach z.B. erstmal alle strecken waagerecht zur x-Achse durchgehen. Dann hast du rechtecke von der Breite x2-x1 und der Höhe 1.
Nächste Runde suchst du alle parallel zur y-Achse. Und dann müssen die "nur noch" zusammengefügt werden.
Vielleicht gibt es ne bessere Lösung Vielleicht war das alles auch nicht sonderlich hilfreich. Dann sorry
Wenn ich sowas mit ner Karte schonmal gemacht hätte, hätte ich auch bissle Code bringen können
Du hast eine Tabelle, das speicherst du einfach welcher Spieler welches Feld gesehen hat.
Jetzt erstellst du alle x Stunden in eine zweite Tabelle, diese besteht aus aus Koordinaten von Rechtecken.
Da der Spieler im laufe des Spieles immer mehr Land (und wahrscheinlich auch flächig) erkundet bekommst du immer größere rechtecke und. Da jedes Rechteck nur einmal gespeichert wird veringert sich die Datenmenge also immer mehr. Am Schluss wenn man alles erkundet hat ist es 1 Eintrag.
userid, x1, x2, y1, y2.
Wie du die Rechtecke suchst
Ich würde einfach z.B. erstmal alle strecken waagerecht zur x-Achse durchgehen. Dann hast du rechtecke von der Breite x2-x1 und der Höhe 1.
Nächste Runde suchst du alle parallel zur y-Achse. Und dann müssen die "nur noch" zusammengefügt werden.
Vielleicht gibt es ne bessere Lösung Vielleicht war das alles auch nicht sonderlich hilfreich. Dann sorry
Wenn ich sowas mit ner Karte schonmal gemacht hätte, hätte ich auch bissle Code bringen können
gepostet vor 19 Jahre, 9 Monate von BLUESCREEN
Original von Dr.Evil
Also, ich würde es ungefähr so lösen wie schokofreak schon beschreiben hat.
(...) Rechtecke (...)
So hatte ich es beschrieben -.-
gepostet vor 19 Jahre, 9 Monate von Dr.Evil
hab ich glatt übersehen, hab aber eigentlich alles durchgelesen.
Ich hab den lösungsansatz irgendwie überscrollt, 4 und 6 hab ich gelsen, aber 5 net
Ich hab den lösungsansatz irgendwie überscrollt, 4 und 6 hab ich gelsen, aber 5 net
gepostet vor 19 Jahre, 9 Monate von schokofreak
hatte das auch überlesen, da mir dein post zu lang wurde...
gepostet vor 19 Jahre, 9 Monate von Moogly
schokofreak, die Prozentabfage braucht ja nicht die vollen 0,5 sec, sondern weitere 10 Abfragen nutzen diese auch!
MfG Moogly
MfG Moogly
gepostet vor 19 Jahre, 9 Monate von felix
Schokofreaks Lösung ist ganz gut
Es bräuchte nur 1 Tabelle, mit den "aktuell" aufgedekten Feldern speziell gekennzeichnet. Alle 10 Minuten nimmt der Ticker diese Felder(sind dann nur die aktiven User dieser Zeitspanne) und rechnet die Rechtecke zusammen oder so
Es bräuchte nur 1 Tabelle, mit den "aktuell" aufgedekten Feldern speziell gekennzeichnet. Alle 10 Minuten nimmt der Ticker diese Felder(sind dann nur die aktiven User dieser Zeitspanne) und rechnet die Rechtecke zusammen oder so
gepostet vor 19 Jahre, 9 Monate von Fasi
Also die Rechteck-Sache tönt gut! Bei meinem Spiel ist es so, dass die entdecketen (sichtbaren) Felder unter den Spielern ausgetauscht werden können. Man kann also sehr rasch zu vielen sichtbaren Feldern kommen.