| Autor |
Mitteilung |
|
 verfasst am: 21.10.2005, 20:26 |
Admin, Spielsatz GalWar
Registrierdatum: 31.08.2005, 21:51
Beiträge: 5596
 |
Eines der Ziele für Version 1.0 lautet, dass die Bodeneinsätze stärker mit dem Script und den Spielsätzen zu verbinden (siehe Roadmap).
Meines Erachtens (soweit ich den Code nachlesen konnte) nach ist dies schon fast fertig, wenn man die bereits bestehenden Variablen richtig nutzt und nur ein paar zusätzliche Skriptfunktionen schreibt.
Dazu ist es aber notwendig, die Namen der Bodenkarten etwas zu normieren. Deshalb als erstes nun mein Vorschlag zu so einer Normierung:
Alle Dateien erhalten einen Dateinamen nach dem Fileformat
kMMM_###.m3d
wobei folgende Bedeutungen existieren:
k Einsatzzuordnung
x: allgemeiner Bodeneinsatz
s: Spielsatzbezogener Bodeneinsatz
Andere Bedeutungen könnten vielleicht auch definiert werden, aber ich sehe zur Zeit keine notwendige weitere Variante
MMM Einsatztyp oder Spielsatzbezeichnung
Bei einem spielsatzbezogenen Einsatz ist dies eine vom Team festgelegte Abkürzung für den Namen des Spielsatzes. Auf diese Art können alle Spielsatzkarten im selben Verzeichnis zusammenkommen, ohne das ein Spielsatz die falsche Karte aufruft (die aktuelle Zufallssuche nach vorhandenen Karten wird nachher noch modifiziert).
Bei einem allgemeinen Einsatz könnte es folgende Varianten geben:
abs: regulärer Ufo-Absturz wie bisher
inf: Infiltrations-Einsatz
lan: Ufo ist gelandet (Karte mit einem UFO drauf, Sieg bringt UFO-Komponenten)
aus: Irdisches Gebäude befreien, dort befindet sich Ausrüstung (wie das eine Beispielscript, nur das die Ausrüstung mit entsprechenden Kartenscripts schon im Bodeneinsatz herumliegt und auch zerstört werden kann)
oder ähnliches
Die genaue Definition dieser Varianten wird wohl einer Version nach 1.0 vorbehalten sein, wenn der Bodeneinsatz auch Rückmeldungen zum Spielsatz geben kann. Da weiß ich nicht in wie weit das jetzt schon vorbereitet ist und für 1.0 realisierbar ist.
###: fortlaufende Dateinummer
Offizielle Karten dieser Art werden vom Team eine fortlaufende Dateinummer zugeteilt kriegen (dann können auch externe ohne Gefahr eigene Karten entwerfen.
Inoffizielle private Karten sollten an dieser Stelle mit Buchstaben arbeiten - dadurch kann nichts ducheinander kommen, aber die Buchstaben verschiedener privater Karten werden natürlich nicht gegengeprüft, da ist jeder selber verantwortlich.
Jetzt anschließend werden folgende Skriptänderungen benötigt:
alle GenerateEinsatz-Funktionen müssen einen String/Namen zur Definition der Einsatzkarte übergeben.
Außerdem wird eine zusätzliche Skriptfunktion definiert, die den vorhandenen TEinsatz.MapName austauschen kann. Diese Funktion wird dann auch von den GenerateEinsatz-Funktionen aufgerufen, da sie gleichzeitig die Dateinamenprüfung enthält.
Ein direkter Zugriff auf MapName aus dem Skript muss gesperrt werden (aktuell wohl noch möglich wenn ich das richtig sehe).
Diese Funktion SetMapName(Mapwahl: String) muss dann folgender Logik folgen (ich benutze Umschreibungen, da ich nicht jeden Pascal-Befehl kenne):
Mapwahl ist ein vom Script oder dem GenerateEinsatz gesetzter Steuerstring
filelist[] ist ein Array mit allen im Verzeichnis mapdata gefundenen m3d-Dateien
Ist Mapwahl identisch mit einem Dateinamen aus filelist, dann setze TEinsatz.MapName:=Mapwahl
Endet Mapwahl auf einen Stern, dann suche alle Karten die denselben Anfang haben wie Mapwahl und wähle zufällig eine davon aus.
Gibt es keine auf den Schlüssel passende Datei, dann ersetze Mapwahl durch xabs_* und wähle erneut aus.
Ergebnisbeispiele:
SetMapName("slst_001") würde (wenn lst die Abkürzung für "Lenstar's Spielsatz" wäre) die Karte 001 aus diesem Spielsatz wählen.
SetMapName("xabs_*") würde eine zufällige Standart-Absturzkarte auswählen
SetMapName("xlan_12*") würde zufällig eine Ufo-Landemission mit einer Nummer zwischen 120 und 129 auswählen (z.B. wenn man die Landemissionen nach Ufogröße sortiert nummeriert)
SetMapName("x*") würde eine beliebige Standartmission zufällig auswählen
Wenn man nach diesem Konzept vorgehen würde, dann könnte jeder Karten beisteuern ohne dass irgendein Spielsatz durcheinander kommen könnte.
Allerdings noch zwei weitere Änderungsvorschläge:
1.)
Addiert in TEinsatz eine zusätzliche Variable und die Funktionen, um sie sowohl vom Geoscape-Skript aus zu setzen alsauch im Kartenscript abzufragen:
TEinsatz.UserData: Integer
Hintergrund ist einfach das man manchmal für die Spielsatzkarten Laufzeitwerte übergeben will, z.B. der wievielte Einsatz das war oder aus dem Geoscape zur Laufzeit festlegen, wieviele Aliens/Gegenstände eines bestimmten Typs vorhanden sind oder ähnliches. Je nach Karte ist das natürlich anders definiert und bringt nur bei den Spielsatzkarten etwas, aber es wird den Spielsatzerstellern einige Möglichkeiten geben ohne etwas zu kosten.
2.)
Gebt bei jedem UFO-Modell die Möglichkeit vor, die Mapwahl zu setzen. Voreinstellung wäre dann wohl "x*" oder "xabs*", aber ein Spielsatzersteller soll bei einem Mutterschiff auch spezielle Karten "xlan_*" oder "slst_100" zuordnen können, selbst wenn das Mutterschiff zufällig und nicht gescriptet auftaucht. Dasselbe gilt natürlich auch für die Übergabe der userdata, die per default dann natürlich 0 ist. |
|
verfasst am: 21.10.2005, 20:42
|
Programmierer, allgemeines
Registrierdatum: 06.06.2004, 17:19
Beiträge: 3186
|
Zitat: DirkF Dazu ist es aber notwendig, die Namen der Bodenkarten etwas zu normieren Wäre eine Variante. Ich persönlich fände es aber besser, wenn Karten direkt im Spielsatz gespeichert werden könnten (ähnlich den Skripten). Das Einhalten von Normen für die Namensvergabe kann man nur schwer erzwingen... |
|
verfasst am: 21.10.2005, 21:25
|
Admin, Spielsatz GalWar
Registrierdatum: 31.08.2005, 21:51
Beiträge: 5596
|
Das Speichern der Karten im Spielsatz bringt nur etwas für Spielsatzbezogene Karten, für allgemeine Karten ist es eher nachteilig. Dann kann ein Spieler nämlich nicht die von einem dritten erstellte allgemeine Karte in seinem Lieblings-Spielsatz spielen.
Eine Normung der Namen würde in so einem Zusammenhang nur Vorteile bringen und es müsste niemand dazu gezwungen werden - derjenige der sich nicht an die Normung hält würde nämlich nur Nachteile (oder besser keinen der Vorteile) haben.
1. Vorteil: Spielsatzersteller könnten unterschiedliche Missionstypen gezielt nutzen. Ohne eine Namensnormung wirst Du große Probleme mit unterschiedlichen Bodenmissionen kriegen, weil Du sie nie eindeutig aufrufen oder sperren könntest. Alle Spezialmissionen außer UFO-Absturz wären dann Spielsatzgebunden und man könnte sie nicht unabhängig nutzen
2. Vorteil: Kartenersteller können ihre Phantasie besser spielen lassen. Sobald ein Kartenersteller weiß das eine Verwendung eines bestimmten Namens dazu führt das seine Karte auch nur in den passenden Momenten auftaucht, werden die Alienbasen (Kennung bas, im Beispiel oben vergessen) oder Ufo-Landekarten nur so aus dem Boden sprießen. Zur Zeit macht nämlich keiner der Kartenersteller was anderes als Zufallskarten in menschlicher umgebung, und das wird auf Dauer langweilig...
Glaub mir, so eine Namensnormung muss niemand erzwingen. Hätte nur Vorteile und vor allen Dingen gäbe es andere m3d-Dateien als village.m3d, village2.m3d usw.... |
|
verfasst am: 21.10.2005, 21:52
|
Admin, Spielsatz GalWar
Registrierdatum: 31.08.2005, 21:51
Beiträge: 5596
|
Noch ein paar Gedanken:
Wenn man die Spielsatzabhängigen Karten tatsächlich im Spielsatz speichert und die allgemeinen im jetztigen Verzeichnis, dann kann man die Kennung s/x weglassen und die Normung so etwas öffnen - allerdings darf man dann nicht den zusätzlichen Betatest vergessen, ob die dann internen spielsatzbezogenen Karten korrekt abgespeichert und aufgerufen werden können.
MMM_####.m3d
Die Aufruflogik würde sich dann verändern in
1.) Ist der aufgerufene Name im Spielsatz vorhanden? Dabei dasselbe Zufallsprinzip mit dem * benutzen wie oben beschrieben für diejenigen, die diese Technik für mehrere Kartendateien im Spielsatz nutzen wollen.
Z.B. mehrere Dateien ssss_9* anstelle einer Datei mit aufwendigem Zufallskartenaufbau.
2.) gibt es eine auf die Mapwahl treffende Datei im allgemeinen Verzeichnis?
Hier wäre die Nutzung der Normung abs*, bas*, lan*, aus* usw. durch den Spielsatzersteller freiwillig - aber viele werden das tun, weil es eine bessere logische Steuerung ermöglicht.
3.) findet man keine passende Kennung, dann wird zufällig aus allen Karten gewählt (s/x gibt es ja nicht mehr, man muss keine Spielsatzspezifischen Karten abfangen).
Wenn sich dann ein Kartenersteller nicht an die Norm hält dann kann seine Karte halt erst in Schritt 3 (und damit auch nicht mehr in einem Spielsatz ohne absolute Zufallsmissionen) geladen werden. |
|
verfasst am: 22.10.2005, 23:38
|
Admin, Spielsatz GalWar
Registrierdatum: 31.08.2005, 21:51
Beiträge: 5596
|
Man sollte sich nicht mit Programmierung beschäftigen, wenn man schon im Halbschlaf ist.
Streicht die Logik in den Posts oben, es geht deutlich einfacher und eleganter (und erledigt dann auch Natter's Einwände)
Im folgenden ist
Mapwahl: Der Filterstring aus den verschiedenen GenerateEinsatz-funktionen bzw aus dem Script.
filelist[]: Array mit den Namen aller Kartendateien aus dem Verzeichnis Mapdata sowie aller Spielsatzinternen Karten (sobald letzteres vorhanden ist)
maplist[]: temporäre Liste der gefilterten Karten, unter denen eine zufällig ausgewählt wird.
cutstr(String, Length) diejenige Pascal-Funktion, die den ersten Teil von Length Zeichen eines Strings liefert.
Der Code ist kein echter Pascal-Code weil ich nicht mit Pascal arbeite, aber das sollte leicht zu korrigieren sein.
procedure SetMapName(Mapwahl: String)
{
if Mapwahl="" then Maplist = Filelist;
for i=0 to length(filelist[]) do
{
if Mapwahl=cutstr(Filelist[i],length(Mapwahl)
Maplist.add(Filelist[i]);
};
if length(Maplist)=0
Maplist=Filelist;
TEinsatz.Mapname=Maplist[random(length(Maplist))];
};
Wenn dann der Einsatz aufgerufen wird dann wird als erstes geprüft ob der MapName spielsatzintern vorhanden ist - falls ja gilt die Spielsatzinterne Karte, falls nein wird die Karte extern aus Mapdata geladen.
Lässt der Spielsatzersteller die Mapwahl leer (oder wird kein passender Spielsatz gefunden), dann wird automatisch auf eine absolute Zufallskarte gewechselt.
Ist die Mapwahl ein kompletter Dateiname, dann wird nur eine Karte gefunden und gezielt ausgewählt.
Ist die Mapwahl dagegen nur der Beginn eines Dateinamens, dann wird zufällig aus allen passenden Dateien gewählt.
Wenn jetzt die im ersten Post beschriebenen Funktionen und Zusatzwerte im Editor verfügbar sind, dann kann der Spielsatzersteller bestimmen wie er vorgeht.
Setzt er eine eigene Namensdefinition und gibt alle notwendigen Karten Spielsatzintern, dann kann er (mit Spielsatz-Passwort und geheimen Namensschlüssel) sicher stellen das kein Community-erstellter Einsatz in seinem Spielsatz verwendet wird.
Benutzt er eine allgemein gültige Namenskonvention wie meine vorgeschlagene, dann kann der jeweilige Spieler alle nach dieser Namenskonvention erstellten Karten dem Spielsatz hinzufügen und die Missionen werden trotzdem nur dort aufgerufen, wo es Sinn macht.
Denkt sich ein Teil der Community eine eigene Namenskonvention aus, dann können sie auf diese Art sicher stellen das nur ihre eigenen Karten in dem Spielsatz zum einsatz kommen - z.B. wenn man in jeder Karte eine bestimmte Nutzung von Userdata oder einfach ein durchgehendes eigenes Tileset haben möchte.
Lässt der Spielsatzersteller die Mapwahl weg, dann hat er automatisch eine Zufallskarte - auch wenn dann mal aus einem abgeschossenen Ufo ein Sturm auf eine Alienbasis werden kann.
Da die Mapwahl auch unterschiedlich gescriptet werden kann, können alle Methoden gemischt werden.
Theoretisch gibt es ein Problem wenn gescriptete Spielsatzinterne Missionskarten existieren und einige Ufo-Abschüsse trotzdem den absoluten Zufall nutzen - dann können die auch die Missionskarten aufrufen.
Das muss aber nicht extra abgefangen werden, denn erstens ist dies die Entscheidung des Spielsatzerstellers und zweitens kann man bei Bedarf auch UserData=0 zur Identifikation der Zufallseinsätze nutzen und dann in den Missionsskripten eine Standartkarte erstellen (und bei gescripteten Missionen dann UserData auf einen anderen Wert setzen.
Auf diese Art ist der Code einfacher, funktioniert auch schon ohne Spielsatzinterne Kartenspeicherungen und es liegt im Ermessen des Spielsatzerstellers, ob er einem Vorschlag zur Kartennormung folgt oder nicht... |
|
verfasst am: 23.11.2023, 14:25
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 03.12.2023, 05:31
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 02.05.2024, 22:35
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 02.06.2024, 18:58
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 02.08.2024, 18:30
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 03.11.2024, 00:51
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 10.12.2024, 23:49
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 18.03.2025, 04:52
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
|
verfasst am: 03.05.2025, 18:40
|
Registrierdatum: 22.11.2023, 07:10
Beiträge: 275939
|
|
