Dieser Artikel beginnt eine unregelmäßige Serie von Gedanken und Ideen rund um die Entwicklung von Spielmechanismen.
Bitte entschuldigt, liebe Leser, wenn Euch die Ideen hier bereits bekannt vorkommen. Ich spiele nicht allzu häufig und so kann es durchaus vorkommen, daß Ihr die hier geschilderten Ideen und Ansätze bereits aus anderen Spielen kennt.
Alles begann mit der Idee, ein eigenes Spielsystem zu erfinden, mit dem sich Spiele in der Tradition von Privateer umsetzen lassen würden. Das bedeutet, daß ein Wirtschaftssimulation ebenso ein Teil der Speilmechanik sein müsste, wie auch Kampf. Ja - es würde etwas werden, was mancher als Kriegsspiel bezeichnet. Aber letztlich ist auch Schach ein Spiel, bei dem es darum geht, den Gegner auszuschalten und wenigstens ist die hier skizzierte Idee kein First Person Shooter. Letztlich geht es aber darum, daß die Mechanik funktioniert - ich habe vor, im Winter zu versuchen, eine Pendeluhr aus Holz zu bauen und das mache ich auch nicht, weil ich wissen will, wie spät es ist.
Hierbei geht es um die Simulation von Märkten: Der Spieler, der mit dem Transport von Waren sein Geld verdient, soll kein statisches Preisgefüge vor sich sehen, das es ihm erlaubt, eine einmal gefundene rentable Route mit beliebig vielen Schiffen zu überschwemmen und so sagenhaft reich zu werden. Es soll vielmehr so sein, daß sich der Preis nach dem Angebot richtet. Weiterhin muß gewährleistet sein, daß ein reichhaltiges Angebot den Markt vergrößert, so daß - in vernünftigen Grenzen - das Angebot die Nachfrage reguliert. Es soll also eine positive Rückkopplung zwischen Angebot und Nachfrage existieren - oder in anderen Worten: Ist das Warenangebot reichhaltig, siedeln sich mehr Konsumenten an - die Nachfrage steigt; sind die Waren knapp, ziehen Konsumenten fort und die Nachfrage sinkt. Ein anderer wichtiger Aspekt ist, daß die Anzahl unterschiedlicher Warenkategorien groß sein soll- also nicht die 5 bis 10 verschiedenen Warenkategorien, auf die manche Spiele unwiederruflich festgelegt sind. Warenkategorien können sich auch überholen: wenn Hyperfunk erfunden wird - wer will dann schon noch Radios kaufen? Beziehungsweise kann natürlich auch der Preis der dann überholten Waren drastisch fallen - wegen fehlender Nachfrage...
Das Kampfsystem gliedert sich in die einander beeinflussenden Bereiche Ressourcenverwaltung und Schadensberechnung: Man benötigt Ressourcen, um Schaden anrichten zu können und angerichteter Schaden beeinflusst die Ressourcenerzeugung. Dazu die folgenden Ideen (ein + oder ein Minus heißt, daß die genannte Ressource erzeugt oder verbraucht wird, ein p bedeutet, daß dies eine Eigenschaft ist):
Schiffe sind frei konstruierbar - für eine bestimmte Größe der Schiffszelle muß ein gewisser Technologielevel erreicht werden. Aber eine verfügbare Schiffszelle kann man völlig frei einrichten. Abheben wird ein Schiff aber nur dann, wenn die Bilanzen der Ressourcen Energie, Personal, Lager und Platz positiv sind.
Treffer richten Schaden an. Wenn eine durch die Art des Schildes definierte minimale Energie im Treffer enthalten ist (kleines bisschen wie der ETW0), dann richtet der Treffer auch Schaden an. Wieviel Schadenswirkung dann durchkommt, wird ebenfalls durch die Art des Schildes und die der angreifenden Waffe bestimmt. Bei Schadensereignis werden folgende Ressourcen verbraucht: Personal (Tote und Verwundete) und Platz (zerstörte Sektionen).
Jeder Ressourcenerzeuger in einem Schiff hat eine gewisse Effizienz. Frisch von der Werft wird dies meist 100% sein (Ausnahmen sind zum Beispiel möglich, wenn man sich bei der Personalstärke für ein 2-Schicht-System entschieden hat). Die Effizienz berechnet sich aus dem Basiswert für das jeweilige Bedienbare Objekt und der Verfügbarkeit von Personal, Energie und Platz (oder was sonst für Ressourcen benötigt werden). JE geringer die Effizienz, desto geringer die Ressourcenerzeugung.
Dieser Bereich ist daher ein Sonderfall, da ohne Sonderbehandlung ein Schiff vor der unweigerlichen Zerstörung steht, sobald es einen Treffer erhalten hat: Treffer: Platz und PErsonal sinken -> Eff LE sinkt -> Personal sinkt -> Eff LE sinkt ... Ein Teufelskreis! Daher: Wegen LE-Effizienz absinkende Personalstärke darf sich nicht auf Ressourcenerzeuger auswirken, von denen die LE abhängig ist. Das lässt sich vielleicht so erklären, daß ein Kapitän bei ungenügender Lebenserhaltung lieber ein Geschütz stillegt und dessen Bedienmannschaft helfen schickt.
Dieser Bereich ist daher ein Sonderfall, da ohne Sonderbehandlung ein Schiff vor der unweigerlichen Zerstörung steht, sobald es einen Treffer erhalten hat: Treffer: Platz und Personal sinken -> Eff Lagerraum sinkt -> Energie sinkt -> Eff Lagerraum sinkt ... Ein Teufelskreis! Daher: Wegen Lagerraum-Effizienz absinkende Energieerzeugung darf sich nicht auf Ressourcenerzeuger auswirken, von denen der Lagerraum abhängig ist. Das lässt sich vielleicht so erklären, daß ein Kapitän bei ungenügendem Lagerraum lieber einen Container Tiefkühlkost verderben läßt, als die Eindämmungsfelder für den Kernbrennstoff zu destabilisieren!
16.01.2014
Dieser Artikel setzt die unregelmäßige Serie von Gedanken und Ideen rund um die Entwicklung von Spielmechanismen fort. Seit dem ersten Artikel ist längere Zeit vergangen, seither haben sich so viele Gedanken aufgestaut, daß sie wieder einmal geordnet werden müssen...
Multi-User-WebDAV, Docker, GitHub
17.11.2019
Nachdem ich mich in letzter Zeit verstärkt mit Docker und dem zugehörigen Ökosystem beschäftige, habe ich begonnen, verschiedenste Dienste in Containern zu testen um zu sehen, ob in manchen Fällen LXC oder KVM nicht doch die bessere Wahl wäre...
Weiterlesen...Android Basteln C und C++ Chaos Datenbanken Docker dWb+ ESP Wifi Garten Geo Go GUI Gui Hardware Java Jupyter Komponenten Links Linux Markdown Markup Music Numerik OpenSource PKI-X.509-CA Python QBrowser Rants Raspi Revisited Security Software-Test sQLshell TeleGrafana Verschiedenes Video Virtualisierung Windows Upcoming...
In eigener Sache...
Weiterlesen...Ich habe eine neue Java Swing Komponente erstellt: Es handelt sich um einen Wrapper für von JToolBar abgeleitete Klassen, die die Werkzeugleiste minimieren und sie nur dann einblenden, wenn der Mauszeiger über ihnen schwebt.
Weiterlesen...Ich habe bereits in einem früheren Artikel über meine ersten Erfolge berichtet, der sQLshell auf Basis des bestehenden Codes aus dem Projekt EBMap4D eine bessere Integration für Geo-Daten zu spendieren und entsprechende Abfragen, bzw. deren Ergebnisse auf einer Kartenansicht zu visualisieren.
Weiterlesen...Manche nennen es Blog, manche Web-Seite - ich schreibe hier hin und wieder über meine Erlebnisse, Rückschläge und Erleuchtungen bei meinen Hobbies.
Wer daran teilhaben und eventuell sogar davon profitieren möchte, muss damit leben, daß ich hin und wieder kleine Ausflüge in Bereiche mache, die nichts mit IT, Administration oder Softwareentwicklung zu tun haben.
Ich wünsche allen Lesern viel Spaß und hin und wieder einen kleinen AHA!-Effekt...
PS: Meine öffentlichen Codeberg-Repositories findet man hier.