Normale Briefings

Beispiel-Map muss umgeschrieben und hier eingebunden werden\\
In diesem Tutorial folgt das Eingangsbriefing.
In den BB-Tutorials wurden Briefings bereits erläutert. Allerdings wurde dort eine sehr umständliche Schreibweise gewählt.
Dieses Eingangsbriefing ist ein Beispiel für ein Eingangsbriefing, mit dem man dem Spieler mitteilen kann, Wie die „Übersicht der Lage“ ist, und/oder man kann dem Spieler mitteilen, welche Aufgaben er hat. Die Möglichkeiten sind unbegrenzt.
Allerdings sollte man drauf achten, den Spieler nicht mit zu viel verschiedenen Fenstern förmlich „zu zu texten“, also sollte man sich genau überlegen, was das Eingangsbriefing aussagen soll.
Und das Eingangsbriefing ist eine hervorragende Möglichkeit, die Kamera zu Spielbeginn auf einen bestimmten Punkt (Gebäude, Held etc.) zu fixieren.

Hier wird eine lokale Definition eines Briefings verwendet, was zu keinen Namenskonflikten führt und die Anzahl der Zeichen verringert.

function FirstMapAction()
    CreatePreludeBriefing();
end

Hier wird die Funktion CreatePreludeBriefing() von der FirstMapAction() aufgerufen. Diese Funktion wird hier, unterbrochen von Kommentaren, erläutert.

function CreatePreludeBriefing()
 
    local briefing = {};
 
    local AP = function(_page) table.insert(briefing, _page); return _page; end;

Es wird in der Funktion CreatePreludeBriefing() zunächst ein lokales Briefing-Table erstellt. Dann wird eine lokale Funktion AP() erstellt, die das Briefing-Table (Bedeutung von Table siehe Tables) mit dem Inhalt füllt. Diese zwei Zeilen am Anfang der Funktion sind für jedes Briefing gleich, können also einfach so übernommen werden.

Was macht die letzte Zeile:

AP = function(_page) 
         table.insert(briefing, _page); 
         return _page; 
     end

Jedes mal wenn AP{irgendwas drin} aufgerufen wird, so ist das Irgendwas die _page. Das wird mit table.insert (siehe auch Tables) an das vorhandene briefing angehängt. Dann wird das irgendwas nochmal mit return zurückgegeben. Also nichts anderes wie in der alten Form, nur viel eleganter.

Nun kann das Briefing-Table gefüllt werden:

	-- Eine normale Briefingseite mit beobachtetem NPC
	local page1 = AP{
		title        = "Willkommen",							-- Überschrift
		text         = "Dies ist der Willkommensbildschirm",	-- Beschreibung
		npc          = {	 									-- Eine Einheit wird während dieser Seite beobachtet
			id = GetEntityId("Dario"),
			isObserved = true
		},
		dialogCamera = true
	};
 
	--[[ Es wird eine Seite mit Aufklärung erstellt. Da diese später (aber noch innerhalb dieser Briefing-Funktion)
        resolved werden muss, um das aufgeklärte Gebiet wieder zu entfernen, wird sie lokal gespeichert.
        Soll diese Seite erst in einer späteren Funktion resolved werden, z.B. wenn eine bestimmte Aufgabe erfüllt ist,
        dann muss diese Seite global gesetzt werden. Also kein "local" davor setzen.]]
	local page2 = AP{
		title        = "Lagebeschreibung",
		text         = "Hier ist noch ein Held",
		position     = GetPosition("Yuki"), 		-- Die Position des Entities "Yuki" wird gespeichert.
		explore      = BRIEFING_EXPLORATION_RANGE 	-- Das Gebiet um Yuki wird aufgedeckt.
	};
 
	-- Diese Seite muss später auch resolved werden, damit das Gebiet nicht sichtbar bleibt.
	local page3 = AP{
		title        = "Missionsziel",
		text         = "Gehe zu der Burg und vernichte sie!",
		position     = GetPosition("Player2"),
		explore      = BRIEFING_EXPLORATION_RANGE,
		marker       = ANIMATED_MARKER  			-- Es wird ein Gebiet mit einem sich ausdehnenden grünen Kreis auf der Minimap markiert
	 };
 
	-- Diese Seite, bzw deren Quest, wird später resolved, sie wird einfach an andere Funktionen "weitergereicht".
 
	local page4 = AP{
		title        = "Dario",
		text         = "Vernichten wir die Burg und denken an die Verteidigung?",
		position     = GetPosition("Dario"),
		dialogCamera = true,
		quest        = {
			title = "1.Auftrag",  		-- Ein neuer Quest wird erstellt
			text  = "Vernichte die Burg",
			type  = MAINQUEST_OPEN,  	-- Hauptquest oder optionaler Quest? Unterschied ist Farbe des Icons
			id    = 1					-- Jeder Quest hat eine eindeutige ID
		}
	};
 
	-- Dies ist eine normale Seite, die nicht resolved werden braucht
	AP{
		title        = "Ende",
		text         = "Dies ist das Ende dieses Briefings"
	};

Ganz wichtig sind die Kommas. Bei einem table wie:

meinTable={a,b,s,d}
-- fehlt nur ein Komma
meinTable={a,b,s d}

Dann meckert der PC.
100: `}' expected (to close `{' at line 90 ) near `s'.
Oben das ist nichts anderes nur mehr drin.

Nun wird die Finished Funktion erstellt. Diese wird automatisch aufgerufen, nachdem das Briefing beendet wurde. Diese Funktion ist optional. Wenn man also nach dem Briefing nichts zu erledigen hat, braucht man sie auch nicht erstellen. In diesem Fall wird die Funktion lokal deklariert, da dies einige Vorteile bietet. Es wäre natürlich auch möglich, den Namen einer normal geschriebenen Funktion (aber ohne „“) anzugeben.

	briefing.finished = function()
							ResolveBriefing(page1);
							ResolveBriefing(page2);
						end;

Wird in Funktion A eine Funktion B lokal definiert, so wie hier, so sind alle lokalen Variablen der Funktion A für die Funktion B global. Praktisch bedeutete das, daß die Finished Funktion noch auf die Variablen page1 und page2 zugreifen kann, die wir uns zuvor mit dem Briefing erstellt haben, um diese zu resolven.
Hinweis: wird jedoch die Finished-Funktion (aus welchen Gründen auch immer; ratsam ist das eh nicht) ausserhalb der Briefing-Funktion platziert, sind die lokalen Variablen der Briefing-Funktion nicht mehr verfügbar! Die Finished-Funktion wird deshalb u.U. eine Fehlermeldung (Was steht in Fehlermeldungen?) verursachen.

Zum Schluss erfolgt noch der Aufruf des Briefings und das Ende der CreatePreludeBriefing Funktion:

    StartBriefing(briefing);
end

Die Funktion CreatePreludeBriefing kann natürlich einen beliebigen Namen haben. Jedoch ist es für die Lesbarbeit besser, bei der Benennung von Funktionen einer festen Namenskonvention zu folgen.

Aufmerksame Leser könnten sich nun fragen, was mit page3 und page4 passiert, die zwar lokal erstellt, aber nicht verwendet wurden. Dieser Teil wird in weiterführenden Tutorials erläutert. Diese Seiten sollen nämlich erst später resolved werden. Dazu müssen sie entweder global deklariert (unschöne Lösung), oder weitergereicht werden. Der Hinweis zum Weiterreichen von Parametern an Jobs wird im Auslöser-Tutorial behandelt.

Siehe auch

Zur Tutorial-Übersicht