Conspiratio.Lib
2.3.0
This is the current status of the C# .NET Framework 4.6.2 class library with the gameplay logic of Conspiratio, removed from the Conspiratio Winforms Client. The Bibiliothek is not yet complete, but already contains the most important classes and methods and can serve as a basic building block for the Unity Client.
The project was created with: Visual Studio 2019
Simply open and compile the project folder Conspiratio.Lib.sln for manual build.
The fan project called "Conspiratio" is a free economic simulation of modern times, which is strongly based on the cult play "Die Fugger 2".
At the beginning, the player inherits a dilapidated production facility and the modest saving of a relative. He can use it to demonstrate his skill as a merchant by making and selling goods, making well -thought -out investments or asserting himself as a clever exporter. The player can use the newly gained wealth and the associated influence:
But be careful! Even some competitors will not shy away from matters ...
The goal is a rewrite of the surface and porting as well as refactorization of the gameplay logic and the entire architecture from the current Windows Forms version to a Unity game, since we have a lot more multimedia and, above all, graphic options and there is a certain platform independence. This new Unity Client will be completely open source, we would like to simply include other people in the cooperation and co-development and the hobby project should become a community project, fans for fans.
Github Issues should serve to plan and control the development.
Do you want to participate in this project? Great! Just get in touch with us via Discord or Oldschool by email and we clarify the details.
Any help is welcome.
Important: We never commit and push directly into the Master Branch!
The reason is simply a lack of transparency and missing 4-eye principle or lack of control by at least another developer.
A new, personal branch must always be created for every change to Conspiratio. The name of the industry should always begin with one of the following names, followed by a slash:
Example: fix/crash and overfall
In addition, umlauts and special characters should be avoided and space can also not be used due to technical restrictions in the industry name, which is why we use binding lines here instead.
If your own branch is then stable and contains all the desired changes/extensions, then a request on the Merge can be created in the Master Branch. This should always be assigned to another developer for examination, which makes a small code review, possibly gives feedback to the code and then also merges the branch after repairing. Own branches should only be composed in exceptional cases (e.g. temporal urgency).
As coding guidelines for C#, we use the following reference in particular for new code, since it has now prevailed as the standard:
https://docs.microsoft.com/de-de/dotnet/cSrogramming-guide/inside-a-a-program/coding-conventions
With regard to the naming and the standards, this reference is also used:
https://www.dofactory.com/reference/csharp-coding-standards
Please note that we use German as the language of the comments in the code and also most identifiers, since the entire existing code base is already built in German. Of course, not every keyword in every method has to be completely German, for example, GetUmsatzProSpieler would be completely legitimate (since Get should simply be standard for every developer), but something like GetVolumeOfSalesPerPlayer would be problematic, since we find such terms anywhere else, neither in the game surface nor in the existing code and therefore there can be quickly confusing, which is now meant.
Old code can and should gradually be converted to these guidelines so that there is no confusion later, but at first that is not the highest priority. But if you change or refactorize older code, then you should take the effort and apply the new guidelines here, according to the scout motto:
Always leave a place (code) in a better condition than you found it.
The documentation of extensive features or other interesting methods, classes etc. takes place in the code in the Github Wiki. The GitHub Wiki should only serve the technical documentation and not documentation for the players, there will be a wiki.
First of all: We use a lot from this concept here: https://keepachangelog.com/de/1.0.0/
The changelog is maintained in the Changelog.md file, right here in the root. It is important that every change is documented here, always in the area of "unreleased". Conversely, this means that every pull request must always contain changes to the changelog file, otherwise it is not complete.
In the changelog we use the following groups to divide the changes:
