KiW

Powered by Perl

Forum

Alle Fragen- Darko antwortet (Seite 99)
Darko
29.09.10 - 11:13
Ja, der "neue WD" ist eine große Queller der Inspiration. Und vielleicht auch eine gute Zielscheibe, wir finden es heraus. :)
Paul
29.09.10 - 12:49
Sag mal Darko, wie war noch der Algorithmus für das Finden der Position für neue Planeten? Ich erinnere mich an "Wähle von allen möglichen Positionen eine zufällig aus und wenn dort kein anderer Planet ist, ist gut, sonst noch einmal zufällig auswählen".

Ich frage nur deshalb, weil sich mir der Verdacht aufdrängt, dass der Algorithmus eher lang gezogene Gebilde erzeugt als Planetenhaufen.
Reiner
29.09.10 - 13:20
Wenn man schon eine Planetenkette hat, dann gibt es an deren langen Enden mehr freie Positionen als in der Mitte. D.h. wenn schon eine Kette existiert, dann ist die Wahrscheinlichkeit höher, dass neue Planeten am Ende landen, als dass sie in der Mitte angelagert werden.

Dummerweise hat man ab dem zweiten Planeten auf jeden Fall eine Kette, es geht ja gar nicht anders.
Darko
29.09.10 - 13:54
Also, es läuft etwa so (nicht ganz so):

1. wähle einen beliebigen Platz auf der Karte
2. wenn das ein legaler Siedlungsplatz ist, ok, sonst wieder zu 1.

Nach meinem Verständnis sind hier alle legalen Plätze gleichwahrscheinlich.

Wo jetzt die meisten legalen Plätze liegen ist eine andere Frage.
Paul
29.09.10 - 17:00
Also mal meine kurze Analyse, o.B.d.A. sollen die Planeten horizontal in einer Linie sein. Weitere Kette heißt, dass der neue Planet direkt oder diagonal an einen der beiden Enden liegt:

2 Planeten -> 60% Chance auf weitere Kette
3 Planeten -> 50% Chance auf weitere Kette
n Planeten -> (2*n/6)*100% Chance

Naja dann deckt sich das Verhalten doch mit dem Algorithmus, wenn ich mir die Karte so ansehe.
Reiner
29.09.10 - 19:06
Moment, da stimmt etwas nicht: 2n/6 ist ziemlich schnell größer als 1, das kann keine sinnvolle Wahrscheinlichkeit sein. Wie kommst du auf die Zahlen?

Es müsste eher 6/(2n+6) sein: Es gibt 6 ungünstige Plätze (weitere Kette) und auf jeder Seite der bisherigen Kette n günstige, macht zusammen 2n+6.

Dies deckt sich aber mit deinen Werten für 2 und 3 Planeten, nur für größere Werte wird die Wahrscheinlichkeit immer kleiner. Aber tatsächlich nicht schnell genug, um eine gewisse Kettenbildung zu verhindern. Wenn wir das wollten, müssten wir also tatsächlich etwas am Algorithmus drehen.

Finde ich aber nicht unbedingt nötig: So wie es jetzt ist, hat man schneller Nachbarn, das gibt mehr Äktschn im Spiel.
Paul
29.09.10 - 21:37
Ja stimmt reiner, hatte nen Denk/Schreibfehler. Die Chance für eine weitere Kette ist demnach bei n Planeten 6/(2n+6). Insgesamt sind also eher Ketten begünstigt als Planetenhaufen.
Simon DePerte
29.09.10 - 23:15
Das muss alles ins Wiki rein!
Darko
30.09.10 - 09:21
ich stimme den zahlen soweit zu, nicht aber den schlussfolgerungen.

Ihr müsst aber auch die verketteten Wahrscheinlichkeiten mitbetrachten. Eure aktuelle Reihe geht immer mit 100% davon aus, dass die Kette weitergebildet wird, statt mit nur 60%*50%*...
Darko
30.09.10 - 09:25
das heißt, die wahre wahrscheinlichkeit für eine 5er-Kette ist:

1.0 * 0.6 * 0.5 * 0.43 = 13%!

mehr nicht.
Toshi
30.09.10 - 10:39
Vielleicht sollte man den Algo so ändern, dass er nicht alle, sondern nur mögliche Felder berücksichtigt?

Wenn man diese dann Minesweeper-artig gewichtet und es wahrscheinlicher macht, dass eine Stelle gewählt wird, die mehrere Nachbarn hat, dann würde es eher zur Haufen-Bildung kommen!

Rein logisch (& logistisch) würde es Sinn machen, dass Expeditionen sich nicht weiter als notwendig von den Kernwelten entfernen, oder?

Über den aktuellen Algorithmus hat man im Grunde gar keinen Einfluss auf das Verhalten bei der Planetenverteilung.
Mit der von mir vorgeschlagenen Version könnte man es anhand der Gewichtung von zusätzlichen Nachbarplaneten quasi beliebig stark beeinflussen!

Das x markiert Minen - err - eigene Planeten:

000000
011100
01x210
023x10
01x210
011100
000000

Man könnte beispielsweise die Summe über alle Felder ermitteln: 20
Die Wahrscheinlichkeit für einen Planeten an einer Stelle könnte sich dann aus dem lokalen Wert dividiert durch die Summe ergeben.
Also 3/20 = 15% für die zentrale freie Stelle,
2/20 = 10% für je eine der Stellen mit zwei Nachbarn
und 1/20 = 5% für jede weitere Stelle.

In der Summe hätte man dann in 45% der Fälle einen Planeten, der zum Haufen beiträgt, oder in 55% der Fälle einen Planeten, der das Reich stärker expandiert...
Darko
30.09.10 - 10:46
hochinteressanter Vorschlag!

Dann muss man sich nur zuerst nochmal gründlich überlegen, ob Haufenbildung das ist, was gut für's Spiel ist (gut für die Nation ist es, ja).

Ab ins Wiki! Den letzten Abschnitt über das Aufsummieren braucht es aber nicht, die Minesweeper-Gewichte allein reichen schon für die Implementierung. Die Felder kommen dann x-fach gewichtet in eine Liste, aus der zufällig gewählt wird.
Toshi
30.09.10 - 10:57
Naja, wenn man an der Gewichtung spielen will (davon ging ich aus), um die Verteiling "haufiger" oder "weniger haufig" zu machen, dann will man vermutlich nicht mit ganzen Zahlen hantieren.
Der Ansatz mit der Liste, aus der zufällig gewählt wird und in der Positionen mehrfach vorkommen wird dann aber nicht mehr einfach so funktionieren...

Dann müßte man eher eine Zahl aus [0,Summe] wählen, die Liste der möglichen Positionen randomisieren und dann anhand der gewählten Zahl und den Gewichten an die richtige Stelle springen...
Das wäre auch mit krummen Zahlen leicht implementierbar.
Darko
30.09.10 - 11:05
richtig, aber die minesweeper-Gewichtung ist doch schon ziemlich genau das, was man da haben wollte.
Reiner
30.09.10 - 14:50
Der einfachste Algorithmus geht doch so:

1. Schreibe jede erlaubte Feld-ID in eine Liste
2. Füge entsprechend der Gewichtung noch Kopien einiger IDs hinzu
3. Wähle gleichverteilt ein Feld aus der Liste

Eine Feld-ID kann dabei einfach ein (x,y)-Vektor sein.

Die Wahrscheinlichkeiten wären genau entsprechend Toshis Überlegung, d.h. Gewicht/Summe, aber die Summe muss dafür nicht berechnet werden.
Darko
30.09.10 - 14:58
Er geht aber auch von ganz anderen Gewichtungen als nur Vielfachen der Minesweeper-Gewichte.
Darko
30.09.10 - 14:59
... aus.
Reiner
30.09.10 - 15:16
Noch etwas Allgemeines:

Echte 5er-Ketten sind tatsächlich noch unwahrscheinlicher, weil unsere obige Überlegung erlaubt, dass Planeten am Ende diagonal angelagert werden. D.h. die 13% beinhalten die Möglichkeit, dass sich über zwei Planeten hinweg eine 90-Grad-Kurve bildet, die ja die Flugzeiten schon signifikant verkürzt.

Ich habe mal die Wahrscheinlichkeit für einen 4er-Haufen ausgerechnet, im Moment liegt sie bei 3%, mit dem gewichteten Verfahren dann bei 10%. Sehr hoch ist sie also immer noch nicht, evtl. sollte mann dann sogar doppelt gewichten, wenn man einen spürbaren Effekt haben will.

Andererseits glaube ich, dass unsere Stichproben im Spiel zu klein sind. D.h. wir werden sowieso immer wieder Ausreißer beobachten und ich habe meine Zweifel, dass eine solche Änderung den Aufwand wert ist. Außerdem wird die Berechnung dadurch verkompliziert, dass in der Praxis auch noch Nachbarn da sind, die einige Positionen besetzen. Einziger Vorteil wäre, dass nebenbei das Absturzrisiko gebannt wäre, falls man gar nicht siedeln kann.

Ob wir Haufenbildung haben wollen, ist eine zweischneidige Sache. Dagegen spricht, wie ich oben schon mal angedeutet habe, dass sich die Entfernungen langsamer verkürzen. Bis man Nachbarn hat, dauert es länger, d.h. die Anfangsphase des Spiels würde verlängert. Ein weiterer Effekt wäre, dass Angriffskriege etwas verändert würden. Wenn man Haufen hat, ist es leichter, zurückzuschlagen, als wenn man eine Kette hat. Andererseits ist es schwerer, sich zu verteidigen, weil der Angreifer mehr Optionen hat. Dazu, ob das für das Spiel gut oder schlcht ist, habe ich im Moment noch keine Meinung.
Reiner
30.09.10 - 15:17
Inwiefern geht mein Algorithmus von anderen Gewichtungen aus? Jedes Feld kommt in der Liste mit der Multiplizität vor, die der Minesweeper-Gewichtung entspricht.
Darko
30.09.10 - 17:25
ja, vielleicht möchte man aber deshalb eine Gewichtung die dem Minesweeper-Gewicht ^ 1.5 entspricht.

Dann braucht man die Summe und so. Ich bin ja aber der gleichen Ansicht wie du soweit. Schön zusammengefasst.

Tendenziell würde es sich lohnen, das minesweepermäßig neu zu implementieren, eben wegen dem aktuell bestehenden Absturzrisiko.
Seiten: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116
zurück zur Themenübersicht