Code Monkey home page Code Monkey logo

conspiratio.lib's Introduction

Conspiratio.Lib

Dies ist der aktuelle Stand der C# .NET Framework 4.6.2 Klassenbibliothek mit der Gameplay Logik von Conspiratio, entnommen aus dem Conspiratio WinForms Client. Die Bibiliothek ist noch nicht vollständig, enthält aber bereits die wichtigsten Klassen und Methoden und kann als Grundbaustein für den Unity Client dienen.

Package

Nuget GitHub release (latest SemVer)

Build

Push - Build and publish Lib
Pull-request - Build Lib
CodeQL

Das Projekt wurde erstellt mit: Visual Studio 2019

Für den manuellen Build einfach die Projektmappe Conspiratio.Lib.sln öffnen und kompilieren.

Systemvoraussetzungen / Abhängigkeiten

  • .NET Framework 4.6.2

Über das Spiel Conspiratio

Das Fanprojekt namens "Conspiratio" ist eine freie Wirtschaftssimulation der Neuzeit, die sich stark am Kultspielt "Die Fugger 2" orientiert.

Zu Beginn erbt der Spieler eine heruntergekommene Produktionsstätte und das bescheidene Ersparte eines Verwandten. Damit kann er sein Geschick als Kaufmann unter Beweis stellen, indem er Waren herstellt und verkauft, wohl durchdachte Investionen tätigt oder sich als gewiefter Exporteur durchsetzt. Der Spieler kann den neu gewonnenen Reichtum und den damit verbundenen Einfluss nutzen um:

  • Noch weitere Produktionsstätten zu erwerben,
  • Titel und Privilegien zu erlangen,
  • Spione und Saboteure auszusenden
  • Angesehene Amtsinhaber zu manipulieren,
  • oder sogar selbst ein mächtiger Amtsträger zu werden.

Doch Vorsicht! Auch manche Konkurrenten werden von niederträchtigen Maßnahmen nicht zurückschrecken ...

Über dieses Repository

Ziel ist ein Rewrite der Oberfläche und eine Portierung sowie Refaktorisierung der Gameplaylogiken und der gesamten Architektur von der aktuellen Windows Forms Version zu einem Unity Spiel, da wir hier viel mehr multimediale und vor allem grafische Möglichkeiten haben und es eine gewisse Plattformunabhängigkeit gibt. Dieser neue Unity Client wird vollständig Open-Source sein, wir möchten andere Menschen möglich einfach in die Mitarbeit und Mitentwicklung einbeziehen und aus dem Hobbyprojekt soll ein Communityprojekt, von Fans für Fans, werden.

Zur Planung und Steuerung der Entwicklung sollen Github Issues dienen.

Mitmachen

Ihr wollt Euch an diesem Projekt beteiligen? Großartig! Tretet einfach mit uns über Discord oder oldschool per E-Mail in Kontakt und wir klären die Details.
Jegliche Hilfe ist willkommen.

Git Workflow

Wichtig: Wir committen und pushen nie direkt in den master Branch!
Der Grund ist einfach mangelnde Transparenz und fehlendes 4-Augen-Prinzip bzw. fehlende Kontrolle durch mind. einen anderen Entwickler.

Für jede Änderung an Conspiratio muss daher immer ein neuer, persönlicher Branch erstellt werden. Der Name des Branches sollte immer mit einem der folgenden Namen beginnen, gefolgt von einem Schrägstrich:

  • improvement (= Verbesserung des Code oder einer Funktion im Spiel, auch Refaktorisierungen)
  • fix (= Korrektur)
  • feature (= neue Funktion des Spiels)

Beispiel: fix/absturz-bei-ueberfall

Es sollten außerdem Umlaute und Sonderzeichen vermieden werden und es können außerdem aufgrund von technischen Restriktionen im Branchnamen Leerzeichen nicht verwendet werden, weshalb wir hier stattdessen Bindestriche verwenden.

Ist der eigene Branch dann soweit stabil und enthält alle gewünschten Änderungen/Erweiterungen, dann kann mittels Pull Request eine Anfrage auf den Merge in den master Branch erstellt werden. Diese sollte immer einem anderen Entwickler zur Prüfung zugewiesen werden, welche einen kleinen Code Review macht, ggf. Feedback zum Code gibt und nach Ausbesserung den Branch dann auch mergt. Eigene Branches sollten nur in Ausnahmefällen selbst gemergt werden (z.B. zeitliche Dringlichkeit).

Code Guidelines

Als Coding-Richtlinien für C# nutzen wir insbesondere für neuen Code folgende Referenz, da sich diese mittlerweile als Standard durchgesetzt hat:
https://docs.microsoft.com/de-de/dotnet/csharp/programming-guide/inside-a-program/coding-conventions

Bezüglich der Benennung und der Standards wird zusätzlich noch diese Referenz herangezogen:
https://www.dofactory.com/reference/csharp-coding-standards

Dabei ist bitte zu beachten, dass wir hier als Sprache der Kommentare im Code und auch der meisten Bezeichner deutsch verwenden, da die gesamte bestehende Codebase schon deutsch aufgebaut ist. Natürlich muss jetzt nicht jedes Keyword in jeder Methode komplett deutsch sein, z.B. wäre GetUmsatzProSpieler vollkommen legitim (da Get einfach für jeden Entwickler Standard sein sollte), problematisch wäre allerdings etwas wie GetVolumeOfSalesPerPlayer, da wir solche Begriffe sonst nirgendwo finden, weder in der Spieloberfläche noch im bestehenden Code und es daher schnell Verwirrungen geben kann, was nun gemeint ist.

Alter Code kann und sollte gerne nach und nach auf diese Richtlinien umgestellt werden, damit es später kein Durcheinander gibt, das hat aber zunächst mal nicht die höchste Priorität. Sollte man aber älteren Code verändern oder refaktorisieren, dann sollte man sich die Mühe machen, und hier auch die neuen Guidelines anwenden, frei nach dem Pfadfindermotto:
Hinterlasse einen Ort (Code) immer in einem besseren Zustand als du ihn vorgefunden hast.

Dokumentation

Die Dokumentation von umfangreichen Features oder sonstigen interessanten Methoden, Klassen etc. im Code erfolgt im Github Wiki. Das Github Wiki soll ausschließlich der technischen Dokuementation und nicht der Dokumentation für die Spieler dienen, dafür wird es ein eigenes Wiki geben.

Changelog

Vorab: Wir nutzen einiges aus diesem Konzept hier: https://keepachangelog.com/de/1.0.0/

Der Changelog wird in der Datei CHANGELOG.md gepflegt, direkt hier im Root. Wichtig ist, dass jede Änderung hier dokumentiert wird, und zwar immer im Bereich "Unreleased". Das bedeutet im Umkehrschluss, dass jeder Pull Request also auch immer eine Änderungen an der Changelog-Datei enthalten muss, sonst ist er nicht vollständig.

Im Changelog nutzen wir folgende Gruppen zur Unterteilung der Änderungen:

  • Erweiterungen
  • Änderungen
  • Korrekturen
  • Balancing

conspiratio.lib's People

Contributors

sirtobyb avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar

conspiratio.lib's Issues

Räuber/Söldner System Teil 2

In Anlehnung an die erste Version des Räuber & Söldner Systems möchte ich hier Features festhalten, die noch in dem System fehlen, weil sie es nicht in die erste Version geschafft haben, die aber noch rein sollten, um ein gutes Spielgefühl zu liefern und dem "Fugger 2 Anspruch" gerecht zu werden:

  • - Es sollte möglich sein, mit einer bestimmten Menge an Werbungsgeld eine gewisse Anzahl an Rekruten anzuwerben, allerdings erst bei Rundenende und dann auch nur einmal pro Runde. Bisher werden die Truppen direkt hinzugefügt.
  • - Möglichkeit schaffen, dass ein menschlicher Spieler einem anderen Spieler ein Kaufangebot für eine Zollburg/ein Räuberlager (im folgenden nur noch "Stützpunkt") machen kann, welches durch den anderen Spieler bearbeitet werden kann, sobald er seine Runde beginnt
  • - Möglichkeit für menschliche Spieler schaffen, einen Stützpunkt zum Verkauf anzubieten, welches zur Folge hat, dass pro Runde eine Chance besteht, dass ein zufälliger KI-Käufer ein Angebot macht
  • - Es muss bei den Aktionen in einem Stützpunkt möglich sein, einen anderen anzugreifen. Der Kampf sollte bei Rundenende ausgetragen werden und es sollte über diesen Weg möglich sein, den gegnerischen Stützpunkt entweder zu beschädigen oder sogar einzunehmen (unter gewissen Regelungen)
  • - Möglichkeit für menschliche Spieler schaffen, vor der Kampfausführung am Ende der Runde einen Bonus an die Truppen zu zahlen, um die Moral zu stärken. Im Falle eines Sieges wird dem Spieler dieser Bonus abgezogen.
  • - Neue Spieloptionen einbauen für:
    • #26
    • #27
    • - Regler: Aktivitätsfaktor der KI-Spieler von 1 bis 100% (Standard: 50%)
  • - Anzeige der angefallenen, bezahlten Zölle als Einnahmen für die menschlichen Besitzer von Zollburgen bei Rundenanfang
  • - Kampfsound als Loop abspielen, solange auf den Rechtsklick gewartet wird

Folgende Platzhalter-Grafiken und Übergangslösungen sollten ersetzt werden (dazu wird Hilfe eines Grafikers benötigt):

  • - Symbole der einzelnen Stützpunkte im Fenster, in dem das Kaufangebot gemacht werden kann (frmStuetzpunktKaufen)
  • - Ersetzung der Platzhaltersymbole für die 5 Stützpunkte (4 Räuberlager und 1 Zollburg) und ggf. Anpassung der Position, ich habe mir einfach welche ausgedacht, sind nicht fix. Können in SVW angepasst werden.
  • - Symbole im Fenster frmStuetzpunktVerwalten sollten ersetzt werden. Vor allem die Truppensymbole sind alles nur Platzhalter von mir und passen vermutlich nicht zum bisherigen Grafikstil. Auch die Buttons darunter für Ausbau etc. sollten überprüft werden. Evtl. auch das Hintergrundbild in diesem Fenster, da es dem einer Stadt entspricht.

Unpassende KI-Bewerber auf Ämter

Gemeldet von Qumas:

Bei manchen Bewerbungen tauchen noch immer Bewerber auf, deren Stand ihnen eigentlich diese Postion nicht möglich macht.
zB. Bewerber ohne Amt kandidiert für den Posten des Regenten

Frustfaktor durch unvermeidliches Spielende reduzieren

Feedback von berfroid: http://conspiratio.net/forum/viewtopic.php?f=12&t=54

  • Generell am Balancing und der Chance der Geburten (ggf. anheben) und Kindersterblichkeit (ggf. senken) arbeiten.
  • Ich überlege mir mal, ob man das Vermögen dann immer durch alle Kinder geteilt werden soll (das würde das Testatement ein Stück weit überflüssig machen)
  • Zusätzlich werde ich eine neue Spieloption einbauen, mit der man die Adoption eines Mündel aktivieren kann. Diese Funktion stelle ich mir so vor, dass man nach einer gewissen Anzahl von Jahren ohne eigenes Kind bei der Kirche ein Waisenkind gegen einen entsprechenden Talerbetrag adoptieren kann, quasi als letzten Ausweg vor dem Ende der Dynastie. Da man dadurch die ganze Heirat usw. umgehen kann und diese damit ebenfalls fast überflüssig werden, würde ich das gerne an eine Einstellung knüpfen, die standardmäßig ausgeschaltet ist. So kann der Spieler selber entscheiden, ob ihm dieser letzten Ausweg im Falle des Falles zur Verfügung stehen soll oder nicht.

Gerichtsverhandlung erweitern

Die Gerichtsverhandlung benötigt noch ein paar Erweiterungen, um die gleichen Möglichkeiten wie Fugger 2 zu bieten. Zunächst sollte im Falle der Anklage eines KI-Spielers durch den menschlichen Spieler auch evtl. gesammelte Beweise bei der Entscheidung der Richter eine Rolle spielen. Aktuell werden die/das Vergehen auch noch per Zufall ermittelt, das könnte bei den KI-Spielern auch so geändert werden, dass diese eine "echte" Verwaltung der Straftaten besitzen, die per Zufall bei Rundenende begangen werden und von den Spionen erkannt werden können.

Bei der Gerichtsverhandlung mit Spielerbeteiligung sollte es grundsätzlich folgende Erweiterungen geben:

  • Zu Beginn dem angeklagten Spieler die Möglichkeit geben, die Richter und die Zeugen mit einer beliebigen Summe zu bestechen. Das sollte Auswirkung auf den Prozessausgang haben.
  • Dem angeklagten Spieler die Möglichkeit geben, eine Aussage zu den Anschuldigungen zu geben ("Ich bin unschuldig!", "Alles Lügen", "Ich bekenne mich schuldig" usw.). Diese sollte auf jeden Fall Auswirkungen haben. Häufig werden einem Verbrechen vorgeworfen (die man nicht gemacht hat) und dann sollte man diese leugnen können. Falls man allerdings alles gemacht hat und alles zugibt, so sollten die Strafen geringer ausfallen.
  • Das Plädoyer der Anklage und der Verteidung sollte variabel sein und sich ein wenig an der Schwere der Anschuldigungen und der Beweise sowie des Ansehens des Angeklagten richten
  • Es sollten verschiedene Zeugen gehört werden, die jeweils eine überzeugende oder weniger überzeugende Aussage tätigen. Dies orientiert sich an dem Verhältniss zu Angeklagten und auch zum Kläger (Bestechung kann helfen)
  • Es sollte vor der Entscheidung durch das Gericht angezeigt werden, ob Bestechungen durchgeführt worden sind

Spiel-Aufträge

Es sollte bei der Erstellung eines neuen Spiels die Möglichkeit geben, einen Auftrag anzugeben. Diese sollten sich in leicht, mittel und schwer unterteilen. Im Prinzip so, wie die Auftragskärtchen damals bei Fugger 2. Die Auswahl eines Auftrags sollte aber optional sein, damit auch freie bzw. endlose Spiele möglich bleiben. Es könnte zusätzlich auch eine lokale Highscore Liste geben, in die sich der Spieler eintragen kann, wenn er einen Auftrag geschafft hat. Es wird dann das Jahr im Spiel dazu gespeichert sowie die Anzahl der Mitspieler. Je schneller ein Auftrag erledigt wurde, umso besser.

Beispiele:
Talerrennen
Der Spieler, der zuerst 1.000.000 Taler besitzt, gewinnt das Spiel.

Herr des Doms
Domherr werden und 7 Jahre lang bleiben.

Mäzen
Dem Reich Bauwerke im Gesamtwert von 160.000 Talern stiften.

Conspiratio.Lib aufbauen: Code refaktorisieren und veröffentlichen

Vorbereitungen treffen, um möglichst viel Code auf GitHub veröffentlichen zu können. Dafür muss noch einiges refactorisiert und optimiert werden. Gleichzeitig möchte ich erreichen, dass dabei eine Basis für die Gameplay Logik entsteht, welche von beiden Clients (WinForms und der neue in Unity) verwendet werden können, da ich den WinForms Client noch nicht direkt sterben lassen möchte (da es vermutlich relativ lange bis zur ersten stabilen Unity Version dauern wird).

Dafür wird die neue Bibliothek Conpiratio.Lib aufgebaut und stetig erweitert. Ich übernehme dafür Logik vom alten Conspiratio WinForms Projekt.

Dieses Projekt ist abgeschlossen, wenn die gesamte Gameplay Logik, die heute bereits vorhanden ist, in diese Lib gewandert ist und vom Unity Projekt verwendet werden kann.

Lib als nuget Paket deployen und im WinForms Client einbinden

Um die Lib möglichst einfach nutzen so können, sowohl im alten WinForms wie auch im neuen Unity Client, sollte diese als nuget Paket erstellt und deployed werden. Dies am besten vollautomatisch bei einem Merge in den master Branch.

Die Versionierung soll per semantic versioning erfolgen. Es wird mit der Version 1.0.0 gestartet.

Neues Wirtschaftssystem

Ursprünglich von @DerEinzehnte verfasst, habe es aus dem alten Repo kopiert:

Das neue Wirtschaftssystem wird sich an einfachen volkswirtschaftlichen Theorien orientieren. Es soll einem Angebot/Nachfrage-Konzept folgen und dadurch deutlich realistischer werden. Das neue System soll in etwa wie folgt aufgebaut werden:

  1. Prokopfbedarf: Jede Stadt hat pro Jahr einen Bedarf an Gütern pro Einwohner (Prokopfbedarf). z.B. Stadt Kingsguard benötigt pro Einwohner und pro Jahr 0,1 Einheiten Holz, 0,2 Einheiten Wein,... . Gemeinsam mit der Einwohnerzahl soll sich daraus der Gesamtbedarf der Stadt pro Jahr ergeben (z.B. eine Stadt mit 0,1 Holz Prokopfbedarf und 100 Einwohner benötigt also 0,1 *100 = 10 Holz pro Jahr). Dieser Prokopfbedarf soll natürlich von der Stadt selbst ebenfalls abhängen. Beispielsweise sollen Städte in den Bergen einen erhöhten Bedarf an Fellen haben, während Städte an den Grenzen mehr Waffen benötigen. Der Bedarf der Stadt kann eine beliebige positive oder negative Zahl annehmen. An diesen Bedarf soll dann der Preis jedes einzelnen Rohstoff gebunden sein. Bei einem Bedarf von ~0 soll der Rohstoff für den Standardpreis verkauft werden können. Bei einem hohen Bedarf soll auch der Preis des Rohstoffes steigen. Und bei negativem Bedarf soll der Preis sinken. Allerdings muss es eine Preisober- und -untergrenze für jeden Rohstoff geben.
  2. Prokopfproduktion: Jede Stadt produziert von jedem Rohstoff eine gewisse Menge abhängig von der Einwohnerzahl (Prokopfproduktion). z.B. eine Stadt mit 0,2 Wein Prokopfproduktion und 100 Einwohnern produziert dann also 0,2 * 100 = 20 Wein pro Jahr. Städte, die diesen Rohstoff nicht herstellen können sollen einfach eine Prokopfproduktion von 0 auf diesen erhalten.
  3. Gleichgewicht als Basis: Dadurch, dass die Summe der Prokopfbedärfe über alle Städte eines Rohstoffes gleich der Summe der Prokopfproduktionen aller Städte definiert wird, herrscht also ohne menschlichen Spieler immer ein Gleichgewicht an Bedarf und Produktion. Wenn jetzt die Summe des Prokopfbedarfs der Prokopfproduktion in jeder Stadt entspricht, dann wird immer gleich viel erzeugt wie verbraucht wird. Für jeden menschlichen (und vl auch später KI-Spieler) der am Spiel teilnimmt (d.h. Waren herstellt und exportiert) soll der Prokopfbedarf erhöht und/oder die Prokopfproduktion um einen prozentuellen Anteil gesenkt werden. Dadurch entsteht dann ein Ungleichgewicht, welches durch den Spieler wieder ausgeglichen werden kann.
  4. Schwankungen von Prokopfbedarf und Prokopfproduktion: Zufällige Ereignisse wie Katastrophen sollen den Prokopfbedarf und die Prokopfproduktion beeinflussen.
  5. Selbstregulierend: KI-Spieler starten automatisch Exporte, falls der Bedarf in manchen Städten zu negativ ist (d.h. zu viel von diesem Rohstoff vorhanden ist) und zwar in Städte welche hohen Bedarf haben. Dadurch ist das Wirtschaftssystem ohne menschliche Spieler komplett ausgelichen bzw. selbstausgleichend.

Durch diese Punkte soll insgesamt eine kleine, stadtinterne, geschlossene Volkswirtschaft entstehen, welche nicht immer ausgeglichen ist. Dadurch können hohe Preise und Rohstoffbedarfe entstehen, welche durch den/die Spieler mittels Im- und Export ausgeglichen werden können.

Weitere Ideen:

  • Punkt 5 könnte über Eisbergtransportkosten programmiert werden.
  • Marktgleichgewicht über "Bestimmung des Gleichgewichtspreises" berechnen.
  • Transportkosten sollen abhängig von der Distanz sein

Hilfreiche Links:
https://de.wikipedia.org/wiki/Marktgleichgewicht

Feste benötigen zu viele unterschiedliche Waren

Auf die Frage von PommBaer im Forum (https://conspiratio.net/forum/viewtopic.php?p=171#p171) ergab sich folgendes Problem:

Alle Waren, die für ein Fest benötigt werden, werden vor Ort (dort wo das Fest stattfindet) benötigt. Hier ist mir beim Testspielen bereits das Problem aufgefallen, dass bei großen Festen für optimalen Erfolg mehr unterschiedliche Waren (Bier, Wein, Nahrung, ...) erwartet werden, als man überhaupt einlagern kann. Das muss verhindert werden.

Duelle (Beleidigung) und Fechtunterricht

Wir sollten das schöne Feature der Beleidigungen und der Duelle aus Fugger 2 implementieren. Über Fechtunterricht lässt sich die Fähigkeit, ein Duell zu gewinnen steigern. Der Preis pro Fechtstunde steigt an. Über die Beleidigung eines Amtsträger wird dieser zu einem Duell herausgefordert, die Gesundheit des Verlierers sinkt. Ab einer bestimmten Gesundheit ist der Verlierer nicht mehr in der Lage, sein Amt auszuführen.

Titelvergabe rebalancen

Feedback von DerEinzehnte: https://conspiratio.net/forum/viewtopic.php?p=181#p181

Von Landherr kommt man wirklich wirklich schwer zum nächsten Titel. Möglicherweise kann man hier den Unterschied überprüfen und ggf. etwas nachbalancen ;)

Meine Ideen:

  • - Ab Landherr die benötigten Taler etwas herabsetzen
  • - Weitere Kriterien zusätzlich zu den Talern einfügen wie z.B. Freiherr erst mit Söldnerburg oder Räuberlager, Baron erst ab Wohnsitz Burg, Graf erst ab Wohnsitz Schloss usw.
  • - Am Schluss die Kriterien im Wiki dokumentieren

Strafe "Kerker" prüfen

Laut Muffinz: Ich wurde 2 oder 3 mal schuldig gesprochen, --> 1 Monat Kerker was genau gar nichts bewirkt hat (ja ich weiß Gesundheit leidet darunter - hat man nicht gemerkt)

Muss ich mir mal anschauen und eventuell rebalancen.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.