 |
| Zufallskarten - Die Lösung?! |
ultimate |
2012-04-09 13:34:15 |
Vorwort
Ich glaube wir sind uns alle einig, dass Zufallskarten eine feine Sache wären, wären da nicht die Bedenken und Probleme die sie mit sich bringen. Ich habe mir daher (schon seit längerem) eine mögliche Lösung überlegt Zufallskarten zu realisieren, die ich nun endlich einmal beschreiben und zur Diskussion freigeben möchte.  (Die Lösungsidee habe ich schon lange, ich hatte nur immer wenn ich mal dran gedacht habe nicht genug Zeit hier einen anständen Post zu verfassen...)
Ausgangsituation
Hauptbedenken seitens Didi ist das dynamische Ablegen neuer Karten in der Datenbank.  Zur Erinnerung zitiere ich noch einmal:
also momentan isses so, dass die Karten als Datei vorliegen und über ein script in die DB geladen werden, wenn's neue gibt. Ganz einfach, weil an jedem Spiele eine Karten-ID hängt.
Für jede Einmal-Karte IDs zu vergeben ist auf dauer nicht haltbar.
Von daher wird es im neuen Design auch möglich sein, pro Spiele eine Kartenstruktur zu hinterlgen.
Das kann z. B. entweder eine leicht abgewandelete form einer existierenden Karte oder eben etwas von Zufi sein.
Aber: Tut eben noch nicht.
Wie sich das ganze mit einer evtl. geplanten bzw. als Beta schon existierenden Kartenbewertung vertragen könnte, ist mir bis heute noch schleierhaft....
Wenn einer ne Patent-Idee für diese komplexe Kartenverwaltung hat, bin ich sehr dankbar.
Will sagen: Zufi wirft ne neue Karte aus, jemand findet die toll und will sie speichern. Wo wird diese "gelagert"? Bewertet? Wie verhindert man einen Wildwuchs von vielen Karten, die unübersichtlich werden?
Die Idee
Ich habe mir gedacht, man könnte Zufallskarten quasi-statisch machen...
Ich denkt jetzt sicher: "statisch? Hat der sie nicht mehr alle? Wie soll denn etwas zufälliges statisch sein?" ... und das natürlich zu Recht, daher auch quasi-statisch!
Gingen wir davon aus, man in Karten veränderliche Bereiche (Straße <-> Gras) definieren könnte, so wäre man in der Lage trotz statischen Quellcodes Varianten einer Karte zu erstellen. Diese Varianten wären aber dennoch einfach zu verwalten und programmatisch zu behandeln, wie das funktioniert beschreibe ich im Anschluss...
Hintergrund
Schauen wir uns einmal die Art und Weise an, in der die Karten gespeichert werden. Das berühmteste Beispiel (wenn auch als Karte relativ unspektakulär  ) ist wohl XOSOFOX
Momentan sind folgende Zeichen belegt:
X,Y,Z - Gras,Sand,Matsch
O - Fahrbahn
S - Startpunkt
F - Finish, Zieldurchfahrt
P - Parc ferme, in die linke obere Ecke kommen die Felder, um die Sieger abzustellen
1-9 - Checkpoints 1...9
Was also bleibt sind:
a-z (Kleinbuchstaben)
A-E,G-N,Q,R,T-W (Großbuchstaben)
0 (Null)
!"§$%&/()=?*+'#_-;,:. (Sonderzeichen)
Die Realisierung
Wenn wir nun eine definierte Zeichenmenge (z.B. die 8 Kleinbuchstaben a-h) im Karten-Quellcode wie Schalter betrachten, dann können wir diese durch einfache Parameter ein und ausschalten. Für jedes der 8 Zeichen gibt es die 2 Möglichkeiten "X" (unbefahrbar) und "O" (befahrbar), woraus sich 2^8 = 256 Varianten für die Karte ergeben. (Die muss man erst mal alle fahren )
Bei der Spielerstellung kann dann der Spielersteller entweder eine Zahl (in diesem Fall von 0 bis 255) eingeben oder diese zufällig vergeben lassen, woraus sich dann die Streckenvariante ergibt.
Anmerkung:
Es ist zu überlegen, ob man die Variante 0 (alle Schalter aus = nicht befahrbar) unterbindet, da diese sehr leicht zu nicht fahrbaren Karten führen kann...
Beispiel
Ich habe mal ein kleines Beispiel angelehnt an Jodys Irrkartengenerator gebastelt (der Einfachheit ohne CPs...)
Das Beispiel ist im Wiki zu finden
Ein bisschhen Technik
Ich habe weiter oben erwähnt, dass das einfach programmiertechnisch umsetzbar ist. Ich möchte daher hier kurz eine Idee äußern, wie Didi oder die Botschreiber die Sache behandeln könnten:
Betrachten wir die für definierte Zeichenmenge (hier die 8 Kleinbuchstaben a-h) eine Bitfolge mit genau so viel Bits, wie Zeichen definiert wurden, so kann man damit einfach die Schalterstellungen aller Zeichen definieren.
Bei der Spielerstellung wird nun einfach ein Zahlenwert von 0 bis 2^(Anzahl Zeichen) übergeben, woraus sich eindeutig die Variante der Karte ermitteln lässt. (Hier gilt auch wieder: evtl. Variante 0 unterbinden).
Die Überprüfung von Feldern auf Ihre Befahrbarkeit kann dann ganz einfach durchgeführt werden (ein bisschen Pseudo-Code):
variante; // Kartenvariante 0 bis 255
feld; // der Textwert des Kartenfeldes als Zeichen (X,Y,Z,O,S,F,P,1-9,a-h)
if(feld >= 97 && feld <= 104) // 97 = ASCII von 'a', 104 = ASCII von 'h'
feld = variante & 2^(feld-97) ? 'O' : 'X';
// feld-97 liefert einen Wert von 0 bis 8
// 2^(feld-97) liefert dann die Zweierpotenz
// die Potenz wir bitweise mit variante verrechnet
// wenn das Ergebnis != 0 ist, so ist es befahrbahr (Schalter ein), wenn nicht unbefahrbar (Schalter aus)
endif
// weiter wie bisher
Vorteile
- Es wird nicht jedesmal eine neue Karte in der DB abgelegt
- alle Varianten einer Karte haben den gleichen Quellcode und die gleiche ID
- Didi muss nur die Variante bei der Spielerstellung mit abspeichern (und bei Abruf des Spiels für die Bot-Schreiber bekannt machen, damit die sich ihre Variante errechnen können)
- Für die Bot-Schreiber ändert sich nicht viel
- Variierende Nachtkarten sind kein Problem mehr (hier sollte man die Variante natürlich nicht bekannt geben, sonst könne man sich ja gleich die Karte nachbasteln)
Ein bisschen weitergesponnen
Natürlich kann man das ganze beliebig mehr Varianten (z.B. weitere Buchstaben i-z) erweitern (dann wäre theoretisch bis zu 2^26 Varianten möglich)... 
Außerdem könnte man das gleiche Prinzip auch für die Checkpoints anwenden. Dann gäbe es nicht mehr nur CPs an oder aus, sondern auch Abstufungen, welche aktiviert sind und welche nicht... 
Schlusswort
Wie ich schon sagte, die Idee habe ich schon lange, jetzt bin ich endlich (in 3 Etappen) dazu gekommen das hier zusammenzuschreiben und nun sehr gespannt auf euer Feedback.
 ultimate |
|
|
