Topic: Diverse Fragen
Siegfried![]() |
Posted at:
2011-11-11, 09:25 UTC+1.0
Das dürfte gut hinkommen mit Deiner Analyse.
Was die Spielkomplexität angeht, da stimme ich eher nicht zu. Ich mag es, wenn solche Art Spiele etwas komplexer werden. Also, das Hinzufügen einer weiteren strategischen Komponente finde ich eher gut. Auf der anderen seite hast Du natürlich insofern Recht, als dass das die Spielbalance nicht gefährden darf.
Stimmt! Nur meine ich nicht, dass die Tiere Fleisch und/oder Getreide massiv wegfressen. Bei Getreidefeld dachte ich z.B. etwa an Folgende: Wenn ein Getreidefeld reif wird, und sich zufällig ein passendes Tier im näheren Umkreis befindet (radius=3?), dann kommt das Tier und frisst das Feld leer. Die Wahrscheinlichkeit, dass genau dies zutrifft, wenn das Feld reif wird, ist nicht sehr groß. Die Wahrscheinlichkeit steigt natürlich, wenn geeignete Tiere massenhaft auftreten. Aber um mehr als 10% der Ernte wegzufressen, müsste man es schon mit einem sehr massiven Befall zu tun haben.
Dass meine Ideen natürlich ausgiebig getestet werden müssen, ist klar. Und dass ich vermutlich eine ganze Menge daran herumschrauben muss, bis es wirklich zufrieden stellt, ist auch klar. Aber momentan geht es erst mal um die prinzipiellen Ideen, und ob resp. wie die zu verwirklichen sind. Und zwar vorläufig ohne Änderungen am c+ Code. Mal sehen, was da machbar ist. Was die Produktionsrate von z.B. Farmen angeht: Das Problem tritt so nur bei den Barbaren auf. Denn nur die Barbaren brauchen die Wildtiere als Nahrungsquelle. Aber genau hier macht das auch Sinn. Es passt einfach besser zu den Barbaren. Im Endeffekt hieße das vermutlich, dass die Barbaren im späten Spiel eine Farm mehr bauen müssen. Also wird eine Barbaren-typische Besonderheit eben noch etwas prägnanter. Nicht viel, aber ein klein Wenig. Bei den Anderen tritt das Problem so gut wie nicht auf. Eine Jagdhütte hingestellt, und Ruhe ist. Was das Wegfressen von transportierbaren Waren angeht: Das tritt ja nur dann ein, wenn die Waren längere Zeit wegen Verstopfung an einer Fahne liegen bleiben. Und da schadet es Nichts, wenn ein paar Waren entfernt werden. Allerdings muss ich mir hier erst mal ansehen, wie das überhaupt funktioniert. Hier habe ich noch keine Idee, wie angehen Momentan habe ich erst mal den Gamekeeper so umgerüstet, dass er keine Schafe mehr aussetzt, sondern stattdessen Wisente und Elche. Passt besser in die Landschaft. Und das ändert an der Spielmechanik Nichts. Nachtrag:
Ich musste grade feststellen, dass das einzige Kommando, das ein critter_bob versteht, das remove Kommando ist. Also kann ich zwar beliebige Programme hinzufügen, die beliebig von extern ausgelöst werden können, aber das einzig mögliche Kommando in jedem dieser Programme ist remove
Edited:
2011-11-11, 10:19 UTC+1.0
![]() ![]() |
SirVer |
Posted at:
2011-11-11, 10:24 UTC+1.0
Im weitesten gebe ich Horatio recht. Außerdem möchte ich hier noch mein Steckenpferd loswerden: Zufall macht ein multiplayer spiel nur frustriender und subjektiv unfairer. Sowas wie "hin und zu mal ein feld fressen" oder "ochsen, die wild werden" werde ich mit einem Veto belegen - aus genau diesem Grund. Gleichzeitig ist realismus kein argument für mich - Widelands ist genau so (un)realistisch wie monopoly, starcraft oder schach. Dennoch finde ich das experiment spannend und sehe Anwendung für diese Ereignisse in scenarien (die per definition nicht fair sein müssen). ![]() ![]() |
Siegfried![]() |
Posted at:
2011-11-11, 13:38 UTC+1.0
Nix dagegen. Für mich sind das Alles erst mal Experimente. Und wenn man die gesondert in Scenarien einbringen kann, warum nicht? Zur Zeit suche ich noch nach Dokumentationen über die möglichen Befehle in den conf Dateien. Für die worker gibt's da was. Aber nicht für die immovables und nicht für die critter. Wobei critter anscheinend wirklich nur remove versteht. Aber die anderen bobs (immovables) verstehen mehr. So funktioniert ein transform, aber nur in einen anderen immovable. Man kann einen immovable animieren (so man denn hat), und man kann ihn entfernen. Desweiteren scheint es noch die Kommandos "seed" und "grow" zu geben. Seed funktioniert auch nur mit immovables. Und was der Unterschied zwischen grow und transform ist, habe ich noch nicht rausgefunden. Ich hab mal zu debugging Zwecken einen immovable kreiert und integriert. Einfach ein rotes Rechteck, das kurze Zeit existiert und dann verschwindet. Damit kann ich ganz gut experimentieren. Gibt's sonst noch was, was man mit einem immovable machen kann? Insbesondere wäre das Finden anderer Objekte und das Ausführen von dort definierten Programmen wünschenswert. Andererseits, so lange für die critter nicht wenigstens findobject, findspace, walk und object definiert und implementiert sind, komme ich da wohl nicht viel weiter. ![]() ![]() |
Siegfried![]() |
Posted at:
2011-11-11, 23:23 UTC+1.0
Ich habe da gerade was Interessantes entdeckt, und habe eine Frage dazu. Also:
Der Hintergrund: Ich habe in der Barbarencampagne, dritte Karte, die Erfahrung gemacht, dass die battlearena dafür sorgt, dass massenweise Soldaten produziert werden. Genug Bier und Worscht ist ja da. Also wird ständig ein Soldat erstellt, wird hier ein bisschen gelevelt, und er kehrt zurück. Aber dann fehlt im Warenhaus eine Axt, die natürlich sofort wieder produziert wird. Dadurch fehlt Eisen für die fortgeschritteneren Äxte. Wenn ich nun dafür sorgen könnte, dass die battlearena nur Soldaten mit z.B. attack=1 mindestens aufnimmt, dann werden frisch gebackene Soldaten zuerst in das trainingcamp geschickt und dort bis zum Maximum ausgebildet. Erst, wenn sie das Camp verlassen, werden sie dann auch in die battlearena geschickt. Wenn das so, wie gedacht, funktioniert, hätte man damit eine Automatik, um die Soldaten maximal auszubilden. Übrigens denke ich, dass das trainingcamp ein bisschen zu viel auf einmal ist. Das wäre in 2 Stufen besser. Also zuerst ein kleines trainingcamp errichten, ohne Gold Kosten. Trainiert nur attack+1, mit der Axt, die vom einfachen Waffenschmied erstellt wird. Dann upgraden (mit Gold) auf volles training camp, das mis zum Maximum levelt. So kann man bei Eisenknappheit automatisch nur bis attack 1 leveln. Das wäre so eine Art Billigvariante für einen einstellbaren max-level. das könnte man komplett ohne Änderungen am Sourcecode machen, einfach nur eine neue production site einrichten, und das trainingcamp als upgrade davon ändern. ![]() ![]() |
Horatio |
Posted at:
2011-11-12, 05:06 UTC+1.0
Dein Vorschlag führt nicht zu einer eleganten Automatik sondern zu einer katastrophalen Einschränkung. Aus welchen Gründen sollten nur Soldaten mit gewissen attack Werten evade Training erhalten? Was wenn jemand Rohstoffprobleme aber keine Nahrungsmittelprobleme hat und gerne nur evade Training laufen lassen will? Wenn Du keine neuen Soldaten willst machst Du einfach die battlearena dicht. Vielleicht solltest Du erstmal versuchen das Spiel zu verstehen bevor Du tausend neue Vorschläge einbringst?
Edited:
2011-11-12, 05:06 UTC+1.0
![]() ![]() |
SirVer |
Posted at:
2011-11-12, 12:15 UTC+1.0
Das Empire hat so ein Trainingscamp. Der Unterschied ist gewollt und ein Balance feature. ![]() ![]() |
Horatio |
Posted at:
2011-11-12, 15:32 UTC+1.0
Arena/Koloseum ist aber für evade Training. Der Wunsch den Siegfried ausspricht, Soldaten nur bis einem gewissen Verteidgungs- oder Angriffslevel zu trainiern, wird durch das neue Feature in der Entwicklungsversion welches einem ermöglicht die maximale Anzahl an Waren, die in einem Gebäude eingelagert werden, zu kontrollieren erfüllt. Finde ich übrigens zusammen mit Deinem dismantlement feature eine sehr gelungene Idee. Waren, ob zum bauen oder produzieren benutzt, sind jetzt nicht mehr notwendigerweise "verloren" und für Barbarenspieler war es ja immer sehr unschön mit anzusehen dass Brot in einfachen Tavernen "draufgeht". Und Siegfried's Bedarf nach mehr Micromanagement beim Soldatentraining wird damit auch noch bedient. Solche universellen Features die viele Dinge auf einmal ermöglichen sind in meinen Augen besser als Partialansätze. ![]() ![]() |
Siegfried![]() |
Posted at:
2011-11-12, 20:51 UTC+1.0
Ja und nein. Die Möglichkeit, Waren nur bis zu einem Maximallevel einzulagern, hilft hier nicht weiter. Wenn im Trainingscamp ein Soldat nicht bis zum Maximum trainiert ist, wird er da drin bleiben, bis sein Maximum erreicht ist. Und wenn das ewig dauert. Man muss ihn da manuell herausholen. Und genau das finde ich weniger prickelnd. Am besten wäre hier ein einstellbarer maximal Level. Und aus den Gründen, die ich oben aufgeführt habe, auch ein einstellbarer minimal-level. Das einstellen der maximal einzulagernden Waren wird dann besonders sinnvoll, wenn die zur Zeit mehr eingelagerten Waren dann auch entfernt werden. Damit könnte man wichtige Resourcen vor dem Abriss retten. Und unter Umständen könnte man damit die Produktion etwas drosseln. Das Gleiche wäre übrigens auch interessant mit den Workern. Ich habe jetzt noch mal die Karte 3 der Barbarencampagne angespielt. Speziell zum Testen. Und ich habe festgestellt, dass, wenn ich eine Axe Factory upgrade, die resultierende War Mill nicht funktionsfähig ist. Der ausgebildete Schmied (weiss grad nicht, wie der heisst) kommt rein, und anschliessend heisst es: Worker missing. Und das war's. Da kommt niemals ein Schmied rein. Ein Metalworks shop existiert. Ausserdem sind 8 Hämmer vorhanden. Habe ich mal auf Vorrat produziert. Nichts hilft. Die freie Position bleibt definitiv unbesetzt. Ich werde diese Karte noch mal starten, aber vorher mal die Reihenfolge der Worker in der conf Datei austauschen. Vermutung: Da ist ein Bug in der Engine. Denn der vorhandene Master Dingsbums erscheint in der Liste an zweiter Position. In der conf Datei ist er an erster Position. Könnte sein, dass es daran liegt. Aber mit einem gezielten Aussenden der Worker könnte man solche Upgrades resp. deren Funktionieren besser steuern.
Grundsätzlich auf jeden Fall. Ich gehe nur zuerst mal das an, was direkt zugreifbar ist: Die conf Dateien. Dass die nur einstufige Umsetzung des trainingscamps so explizit gewollt ist, nehme ich mal zur Kenntnis und werde das daher nicht ändern. Allenfalls möchte ich anregen, darüber noch mal nachzudenken. Es könnte sehr sinnvoll sein, zunächst ein abgespecktes Trainingscamp zu errichten, das an den Output der axe factory angepasst ist, ohne Helmschmied. BTW: Vielleicht experimentiere ich auch noch mit anderen Rüstungsteilen, die diese komischen Masken ersetzen. Zwei Rüstungsteile, die den gleichen Effekt haben wie die bisherigen, ohne also die Barbaren-typische attack und defense resp. HP Konfiguration zu ändern. Das aber einfach nur, weil ich es schöner finde. Mir schwebt da etwa folgendes vor: Als HP upgrade materials denke ich mir: 1. eine Lederharnisch (für Level 1). Gewonnen vom Jäger als Beiprodukt der Jagd. Dazu müsste die Jagdhütte umgerüstet werden. Dazu muss allerdings ein neues Item kreiert werden: Die Jagdbeute. Die wird dann in der Hütte selber zu a) Fleisch und b) zu Leder verarbeitet. selbiges kann vom Helmschmied zu einem Lederharnisch verarbeitet werden. Für den zweiten HP Upgrade den vorhandenen Helm. Für den dritten Upgrade ein Plattenharnisch. Ebenfalls output des Helmschmieds. Die gleichen Kosten wie die Kriegsmaske. Also de facto nur eine neue Grafik. Es gibt auch noch andere Punkte, die ich jetzt nicht ganz so prickelnd finde. Dass z.B. die "ration" nur eine schlichte Umsetzung irgend eines Nahrungsmittels ist, ist suboptimal. Für etwas sinnvoller würde ich etwa folgende Variante halten:
Desweiteren könnte es interessant sein, für das Upgrade nicht auf die rohen Nahrungsmittel, sondern auf eben diese hier zurückzugreifen. Allerdings müsste dann wohl der output und die Effektivität der Brunnen erhöht werden. Aber das ist nur so eine Idee. Darüber denke ich noch nach. Nachtrag: Ich bin auch mal das Problem angegangen, dass bei einem Abriss eines Gebäudes alle eingesetzten Materialien futsch sind. Ohne Änderungen am Sourcecode kann man da natürlich nicht viel machen. Aber immerhin ein Bisschen. Also, ich habe zunächst mal den "pebbles" das Attribut "stone" gegeben. Das bedeutet dann natürlich auch, dass sie ein [shrink] Programm bekommen müssen. Dieses löscht das Objekt einfach. Also, aus 1 pebbles lässt sich genau 1 raw stone gewinnen. Dann habe ich einen dieser pebbles nach tribes/barbarians kopiert. Dann die Ruine (asches) so geändert, dass, am Ende des idle Zyklus das Ding nicht verschwindet, sondern in eben dieses pebbles transformiert wird. Damit liegt nach Abriss eines Hauses nach einiger Zeit genau 1 Portion Stein rum. Kann von einem Steinmetz abgebaut werden. Ist jetzt nicht grade besonders selektiv (Eine Zitadelle bringt genauso 1 Stein wie eine Fischerhütte), aber es ist mehr als Nichts. Und ein pebbles behindert nicht den Neubau von Gebäuden. Man kann dieses bob also auch, bei Bedarf, einfach überbauen. Funktioniert recht gut. Aber eine selektive Rohstoff Rückgewinnung wäre natürlich besser. Am flexibelsten wäre es wahrscheinlich, für jedes dieser Objekte in der conf Datei angeben zu können, in was es bei "Abriss" transformiert wird. Das Experimentieren mit Spielparametern finde ich mindestens so interessant wie das Spiel selbst.
Edited:
2011-11-12, 21:18 UTC+1.0
![]() ![]() |
Sadchant |
Posted at:
2011-11-12, 21:27 UTC+1.0
Es ist wirklich beeindruckend, wie viele Gedanken du dir über das Spiel machst um im Code herumsuchst. Aber du bist meiner Meinung nach leider eindeutig zu übereifrig.
P.S.: Ich bin auch nur ein normaler Wl-Spieler und verstehe leider noch nicht so viel vom programmieren, aber ich habe schon so manches Spiel seit Build 13 gespielt.
Edited:
2011-11-12, 21:30 UTC+1.0
![]() ![]() |
SirVer |
Posted at:
2011-11-12, 22:14 UTC+1.0
definiere mal bitte "optimal", also deine metrik. Meine Metrik ist die spielbalance. Dort macht es sinn, dass man fleisch nicht sofort in minen liefern kann, sondern es etwas zeit kostet bis es verarbeitbar wird. Die kleinen minen der barbaren gehen dann auch sehr schnell leer, ab dann braucht man komplexeres essen. Ich denke du solltest noch einige spiele mehr machen bevor du so grundlegende sachen veränderst. Auch deine metrik solltest du überdenken, realismus macht kein gutes spiel. ![]() ![]() |