Implementierung (Spielinhalte): Unterschied zwischen den Versionen
Cvk (Diskussion | Beiträge) |
|||
Zeile 5: | Zeile 5: | ||
Es ist möglich, [[Zufallsbegegnungen]] aufgrund folgender [[Heldattribute|Attribute]] einzuschränken, ohne dass die Autoren dazu in [[AOQML]] tätig werden müssten: [[Liste der Reiche|Staatenbund]], [[Vegetation]], [[Wegklasse]], [[Handelsregionen|Handelszone]] und [[Staat]]. | Es ist möglich, [[Zufallsbegegnungen]] aufgrund folgender [[Heldattribute|Attribute]] einzuschränken, ohne dass die Autoren dazu in [[AOQML]] tätig werden müssten: [[Liste der Reiche|Staatenbund]], [[Vegetation]], [[Wegklasse]], [[Handelsregionen|Handelszone]] und [[Staat]]. | ||
− | Weiterhin gibt es die Möglichkeit, das Auftreten an Orte oder Strecken zu binden. Legt man beispielsweise fest, dass eine Begegnung nur rund um [[Eisentrutz]] stattfinden soll, kann bei der Implementierung einfach die interne ID Eisentrutz’ benutzt werden, über die dann automatisch alle Strecken von und nach Eisentrutz abgedeckt sind. Ebenso ist es möglich, das Auftreten auf bestimmte, einzelne Strecken einzugrenzen. Beispielsweise nur von [[Eisenrose]] nach [[Eisenfels]] – was dann tatsächlich nur der Hinweg ist, der Rückweg müsste ebenfalls explizit angegeben werden. Das kann interessant sein, wenn man auf einem Fluss eine Begegnung einführen will, die nur flussab- oder flussaufwärts funktioniert oder eine konkrete Beschreibung des Ziels voraus beinhaltet. | + | Weiterhin gibt es die Möglichkeit, das Auftreten an Orte oder Strecken zu binden. Legt man beispielsweise fest, dass eine Begegnung nur rund um [[Eisentrutz]] stattfinden soll, kann bei der Implementierung einfach die interne ID Eisentrutz’ benutzt werden, über die dann automatisch alle Strecken von und nach Eisentrutz abgedeckt sind. Ebenso ist es möglich, das Auftreten auf bestimmte, einzelne Strecken einzugrenzen. Beispielsweise nur von [[Eisenrose]] nach [[Eisenfels]] – was dann tatsächlich nur der Hinweg ist, der Rückweg müsste ebenfalls explizit angegeben werden. Das kann interessant sein, wenn man auf einem Fluss eine Begegnung einführen will, die nur flussab- oder flussaufwärts funktioniert oder eine konkrete Beschreibung des Ziels voraus beinhaltet. Daran anknüpfend, kann eine Zufallsbegegnung auch einer konkreten [[Sonderstrecke]] zugeordnet werden. |
Alle bisher angegeben Einstellungsmöglichkeiten können miteinander kombiniert werden, man könnte also festlegen, dass eine Zufallsbegegnung im Reich A stattfindet, aber nur in Vegetation B oder auf Wegklasse C. Ebenso ist es möglich, eine Blacklist anzulegen, also Ausnahmen zu definieren, wo etwas auf keinen Fall auftreten soll. Beispielsweise immer in Handelszone X, aber niemals um Ort Y oder auf Wegstrecke Z. | Alle bisher angegeben Einstellungsmöglichkeiten können miteinander kombiniert werden, man könnte also festlegen, dass eine Zufallsbegegnung im Reich A stattfindet, aber nur in Vegetation B oder auf Wegklasse C. Ebenso ist es möglich, eine Blacklist anzulegen, also Ausnahmen zu definieren, wo etwas auf keinen Fall auftreten soll. Beispielsweise immer in Handelszone X, aber niemals um Ort Y oder auf Wegstrecke Z. |
Version vom 10. Oktober 2016, 18:17 Uhr
Implementierung bezeichnet den Prozess des Einbaus neuer Spielinhalte nach erfolgreicher Abnahme. Dazu gehört das Hochladen der Dateien auf den Server und das Einbinden derselben in die Datenbank, was in der Regel vom A-Team oder Mitgliedern der Helferschaft übernommen wird. Bei der Implementierung gibt es diverse Einstellungsmöglichkeiten zum Auftreten der Inhalte, die hier im Einzelnen erläutert werden. Bereits durch die Vorlage ZB, bzw. Vorlage Quest abgedeckte Angaben werden dabei ausgelassen.
Inhaltsverzeichnis
Zufallsbegegnungen
Es ist möglich, Zufallsbegegnungen aufgrund folgender Attribute einzuschränken, ohne dass die Autoren dazu in AOQML tätig werden müssten: Staatenbund, Vegetation, Wegklasse, Handelszone und Staat.
Weiterhin gibt es die Möglichkeit, das Auftreten an Orte oder Strecken zu binden. Legt man beispielsweise fest, dass eine Begegnung nur rund um Eisentrutz stattfinden soll, kann bei der Implementierung einfach die interne ID Eisentrutz’ benutzt werden, über die dann automatisch alle Strecken von und nach Eisentrutz abgedeckt sind. Ebenso ist es möglich, das Auftreten auf bestimmte, einzelne Strecken einzugrenzen. Beispielsweise nur von Eisenrose nach Eisenfels – was dann tatsächlich nur der Hinweg ist, der Rückweg müsste ebenfalls explizit angegeben werden. Das kann interessant sein, wenn man auf einem Fluss eine Begegnung einführen will, die nur flussab- oder flussaufwärts funktioniert oder eine konkrete Beschreibung des Ziels voraus beinhaltet. Daran anknüpfend, kann eine Zufallsbegegnung auch einer konkreten Sonderstrecke zugeordnet werden.
Alle bisher angegeben Einstellungsmöglichkeiten können miteinander kombiniert werden, man könnte also festlegen, dass eine Zufallsbegegnung im Reich A stattfindet, aber nur in Vegetation B oder auf Wegklasse C. Ebenso ist es möglich, eine Blacklist anzulegen, also Ausnahmen zu definieren, wo etwas auf keinen Fall auftreten soll. Beispielsweise immer in Handelszone X, aber niemals um Ort Y oder auf Wegstrecke Z.
Zu guter Letzt gibt es noch die Möglichkeit, die Grundwahrscheinlichkeit zu modifizieren. Häufig angewendet wird dies bei Zufallsbegegnungen in der Vegetation Wald, die ebenfalls am Waldrand stattfinden dürfen, dann aber in der Regel nur mit stark reduzierter Wahrscheinlichkeit.
Questen
Die Einstellungsmöglichkeiten für Questen sind etwas umfangreicher, grundsätzlich muss hier zwischen drei Arten von Questen unterschieden werden: Reisequesten, Zufallsquesten und ortsfesten Questen. Bei allen diesen Questarten kann der Autor eine Variable bestimmen, die am Helden vorhanden sein muss, damit die Queste überhaupt starten kann. Diese wird dann ebenfalls in der Datenbank hinterlegt. Gleiches gilt für den Titel einer Queste, wenn Notizen im Tagebuch eine Überschrift haben sollen.
Reisequesten
Bei Reisequesten gelten dieselben Einstellungsmöglichkeiten wie bei Zufallsbegegnungen, hinzu kommt die Möglichkeit, feste Reisetage zu definieren, an denen die Questen lediglich starten dürfen. Da die Angabe einer Bandbreite von Tagen nicht möglich ist, sondern jeder Reisetag einzeln eingetragen werden muss, ist es hierbei praktisch, eine Blacklist zu benutzen, wenn man beispielsweise möchte, dass eine Quest auf gar keinen Fall direkt nach dem Reisestart beginnt. Gerastete Reisetage werden nicht berücksichtigt.
Zufallsquesten
Bei Zufallsquesten handelt es sich um Abenteuer, die in Städten geschehen können, ohne dass der Spieler sie direkt ansteuern könnte. Die grundsätzlichen Einstellungsmöglichkeiten entsprechen auch hier denen der Zufallsbegegnungen, jedoch können zusätzliche Einschränkungen gemacht werden. Die Quest kann an verschiedenen Stellen starten, die dem Attribut location entsprechen, gerne auch in einer spezifischen Location, beispielsweise Bar X in Ort Y. Weiterhin können Qualitätsstufen von Tavernen berücksichtigt werden oder die Einwohnerzahl der Stadt, beide jeweils in einem Wertebereich.
Ortsfeste Questen
Bei ortsfesten Questen gelten besondere Einstellungsmöglichkeiten, da sie jederzeit über einen Link aufrufbar sind. Dieser findet sich in der Regel unter Anderes, das ist aber nicht zwingend. Der Link könnte ebenso ganz oben in der Ortsübersicht auftauchen, sowie in jeder der Unterkategorien in der Stadtanzeige, sprich: Händler, Taverne, Kampfschule/Lehrmeister, Arena oder Bank. Weiterhin muss der Name der ortsfesten Queste mit eingetragen werden, sprich der Linktext, der den Nutzern angezeigt werden soll. Wer es wirklich schön machen will, kann zusätzlich auch noch ein Icon mitliefern, das vor dem Link angezeigt wird. Ansonsten gelten die bekannten Einstellungsmöglichkeiten, wenngleich ortsfeste Questen zumeist auf einzelne Städte eingegrenzt werden und nur selten auf ganze Regionen.
Andere Einstellungen
Alle anderen Einstellungen zum Auftreten von Questen müssen von den Autoren via AOQML, beziehungsweise durch die Abfrage von Attributen, geregelt werden. Um eine Queste sofort abzubrechen, gibt es beim AOQML-Tag quest den Status rejected, der genau zu diesem Zweck eingeführt wurde.