So ähnlich hab ich mir das gedacht aber das ist kein "elegant" erweiterbares System. Da sind unbequeme Stufen drin.o1ofco2 wrote:Derzeit ist meine ja recht einfach gestrickt:
- es wird eine lineare, nicht veränderbare reienfolge abgefragt und gebaut
(zerschießt man immer eine bestimmte Pat als Ablenkungsmanöver, kann man in Ruhe die Stationen Zerlegen, weil immer erst die Pat nachgebaut wird bevor die Station an die Reihe kommt)
Wäre technisch (und spielerisch) interessanter wenn das Script erst einen Entscheidungsblock hätte, in dem es feststellt, was es denn jetzt gerne hätte.
Das kann auch ganz primitiv sein, wie
1-6 baut Schiffe
7-8 baut Wirtschaft aus
Das kann dann weiter unterteilt sein wie z.B.
Schiffe:
1-3 baut mobile Patrouille,
6-11 stationäre Pat,
12-13 verstärkt irgendeine Pat im Sektor um 1 Schiff.
Wichtig ist, daß in dieser Untertabelle ein Ergebnis immer gültig ist. Dieses Stückchen Script braucht nur so oft würfeln, bis es etwas baubares trifft. Es muß also niemals wieder zurück auf die nächsthöhere Ebene kommen können. Sowas würde unbequeme Aufhänger geradezu einladen und sollte schon im Design vermieden werden.
Das offensichtliche "Problem" dabei ist, daß es keine Obergrenze gibt. Die Flotte könnte also unendlich anwachsen.
Das würde ich aber gar nicht ändern sondern das Problem zur Lösung machen.
Ich würde es so formulieren, daß die wachsende Flotte "Support" braucht.
Bei jedem Produktionstick wird eine Zeitspanne angehängt oder ein Faktor für die Zeit.
Letzteres ist IMO sinnvoller.
Deren Länge ist dann abhängig von der Arraygröße eines
find ship in sector, type=mobile ship, race= Xenon
Es gibt also kein hard cap mehr sondern nur noch ein soft cap.
"Alte" Sektoren im Hinterland sind schwerer befestigt, schicken aber nicht mehr soviele neue Konvois los, da ihre globale queue langsamer läuft.
Das System reguliert sich selbst.
Sollte die Expansion der Xenon wieder und wieder gestoppt werden, werden sie also "weniger Priorität auf Expansion legen" und stattdessen ihre Position stärken.
Wenn ihre Sektoren intensiv angegriffen werden, dann sinken die Schiffszahlen und sie versuchen aggressiver zu expandieren.
Das steht zwar nirgends im Code aber der Witz dabei ist, daß du mit einer popeligen Zufallsauswahl und etwa 3 Extrazeilen für den globalen queue timer etwas bekommst, das nicht nur die allgemeine Expansion limitiert, sondern auch wie eine strategische KI aussieht. =P
Klar ist das überhaupt keine KI. Es soll nur wie eine aussehen...
Das ist viel leichter zu schreiben als eine komplexe Liste von Dingen, die in jeder denkbaren Situation gebaut werden dürfen.
Es ist auch betriebssicherer, da Entscheidungen immer in einem sehr kleinen Stückchen Script getroffen werden und es gibt nirgends "darf ich nicht" Ergebnisse, bei denen sich die Logik aufhängen könnte.
Interessant ist auch, daß du mit 2 Werten den Schwierigkeitsgrad des gesamten Scripts kontrollierst.
- Grundwert für die Länge des build queue timers (=Baugeschwindigkeit)
- Faktor für den Einfluß der Schiffszahl und damit die zahlenmäßige Stärke der Xenon. (=Flottengröße)
So kannst du nicht nur das script leicht balancen, du kannst auch in einem Menü o.ä. dem Spieler verschiedene Schwierigkeitsgrade anbieten.
Wenn nur 2 Zahlen zu verwalten sind, dann ist das nicht weiter tragisch.
Verbunden mit der globalen build queue läßt sich auch das interessanter stricken....ok, der Rest der Bande wird nicht einfach so Verschimmeln... der muss auch noch weggeputzt werden.
Aber ihr habt erstmal die Gewissheit, das nix nachgebaut wird.
Versuchts mal... ist quasi nen bissl mehr "Think" als "Fight" ;)
Der Core würde zwar nachgebaut aber das dauert dann richtig lange und sämtliche Bauvorhaben brauchen derweil 3x oder 4x so lang.
Das erlaubt es dem Spieler zwar, die Xenon empfindlich zu treffen (Schwachstellen sind nur gutes Design!), stoppt aber nicht dein ganzes Script. =)
MARS arbeitet nach einer ganz ähnlichen Philosophie.
Die Gewichtung berücksichtigt zwar viele Faktoren aber es gibt so gut wie keine Situation, in der das Script durch irgendeine "stop condition" zur völligen Untätigkeit verurteilt würde. Es weicht nur auf andere Ziele aus, auch wenn diese nicht so optimal sind, wie es das gerne hätte.
Dadurch verhindert man schon im Design, daß sich komplexe Prozesse irgendwo aufhängen.
Die feste Unterteilung in stationäre und mobile Patrouillen halte ich auch für "zu steif".
Es genügt doch, denn die Bau-KI "Patrouillen" baut.
Alle x Minuten wird dann entschieden, ob eine davon losgeschickt wird.
Das kann wieder auf einer Zahl für "Expansion 1-10" basieren, die sich gut als Schwierigkeitsgrad einstellen läßt.
Rand 1 to ( $Anzahl_Pat_im_Sektor + $Expansion )
Wenn Rand > $Expansion, dann schicke Patruoille auf die Reise.
So wird auch ein gewisser Grundbestand für die Verteidigung gewährleistet, aber die Wahrscheinlichkeit, Patrouillen auszuschicken, steigt mit wachsender Flottengröße, so daß sich auch dieses System wieder irgendwo einpendelt.
Und das gesamte Verhalten der Xenon würde bestimmt durch die 3 Werte für
Flottengröße, Baugeschwindigkeit und Expansion.
Das sind Werte, mit denen der Spieler etwas anfangen kann - ohne langatmige Erklärung der einzelnen Formeln.
Ja, ich weiß. Ich sollte aufhören, anderer Leute Scripts umzudesignen. =P
.....
![[ external image ]](http://img225.imageshack.us/img225/7195/elitewf0.jpg){kind=link}