Conspiratio.Lib
2.3.0
Este es el estado actual de la biblioteca de clases C# .NET Framework 4.6.2 con la lógica del juego de conspiración, eliminada del cliente de conspiración WinForms. El Bibiliothek aún no está completo, pero ya contiene las clases y métodos más importantes y puede servir como un componente básico para el cliente Unity.
El proyecto fue creado con: Visual Studio 2019
Simplemente abra y compile la carpeta del proyecto Conspiratio.Lib.sln para la compilación manual.
El proyecto de fanáticos llamado "Conspiratio" es una simulación económica gratuita de los tiempos modernos, que se basa fuertemente en la obra de culto "Die Fugger 2".
Al principio, el jugador hereda una instalación de producción en ruinas y el modesto ahorro de un pariente. Puede usarla para demostrar su habilidad como comerciante haciendo y vendiendo productos, haciendo bienes bienes, a las inversiones o afirmándose como un exportador inteligente. El jugador puede usar la riqueza recién ganada y la influencia asociada:
¡Pero ten cuidado! Incluso algunos competidores no rehuirán los asuntos ...
El objetivo es una reescritura de la superficie y la portada, así como la refactorización de la lógica del juego y de la arquitectura completa desde la versión actual de Windows Forms a un juego de Unity, ya que tenemos mucho más multimedia y, sobre todo, opciones gráficas y hay una cierta independencia de la plataforma. Este nuevo cliente de Unity será completamente de código abierto, nos gustaría simplemente incluir a otras personas en la cooperación y el desarrollo conjunto y el proyecto de pasatiempo debería convertirse en un proyecto comunitario, los fanáticos para los fanáticos.
Los problemas de GitHub deberían servir para planificar y controlar el desarrollo.
¿Quieres participar en este proyecto? ¡Excelente! Simplemente póngase en contacto con nosotros a través de Discord o OldSchool por correo electrónico y aclaramos los detalles.
Cualquier ayuda es bienvenida.
IMPORTANTE: ¡Nunca nos comprometemos y empujamos directamente a la rama maestra!
La razón es simplemente una falta de transparencia y falta de principio o falta de control por al menos otro desarrollador.
Siempre se debe crear una nueva rama personal para cada cambio a conspiración. El nombre de la industria siempre debe comenzar con uno de los siguientes nombres, seguido de un corte:
Ejemplo: arreglar/bloquear y demasiado caída
Además, se deben evitar Umlauts y caracteres especiales y el espacio tampoco se puede usar debido a restricciones técnicas en el nombre de la industria, por lo que utilizamos líneas vinculantes aquí.
Si su propia rama es estable y contiene todos los cambios/extensiones deseados, entonces se puede crear una solicitud en la fusión en la rama maestra. Esto siempre debe asignarse a otro desarrollador para su examen, lo que realiza una pequeña revisión del código, posiblemente le da retroalimentación al código y luego también fusiona la rama después de la reparación. Las ramas propias solo deben componerse en casos excepcionales (por ejemplo, urgencia temporal).
Como pautas de codificación para C#, utilizamos la siguiente referencia en particular para un nuevo código, ya que ahora ha prevalecido como estándar:
https://docs.microsoft.com/de-de/dotnet/csrogramming-guide/inside-a-a-program/coding-conventions
Con respecto al nombre y los estándares, esta referencia también se usa:
https://www.dofactory.com/reference/csharp-coding-sandards
Tenga en cuenta que usamos alemán como idioma de los comentarios en el código y también la mayoría de los identificadores, ya que toda la base de código existente ya está integrada en alemán. Por supuesto, no todas las palabras clave en cada método tienen que ser completamente alemanes, por ejemplo, GetUmsatzProSpieler serían completamente legítimos (ya que Get simplemente debería ser estándar para cada desarrollador), pero algo como GetVolumeOfSalesPerPlayer sería problemático, ya que encontramos tales términos en cualquier otro lugar, ni en la superficie de juego ni en el código existente y, por lo tanto, puede ser rápidamente lo que se significa.
El código antiguo puede y debe convertirse gradualmente a estas pautas para que no haya confusión más adelante, pero al principio esa no es la prioridad más alta. Pero si cambia o refactoriza el código más antiguo, debe tomar el esfuerzo y aplicar las nuevas pautas aquí, según el lema de Scout:
Siempre deje un lugar (código) en una mejor condición de lo que lo encontró.
La documentación de características extensas u otros métodos, clases, etc. tiene lugar en el código en el wiki GitHub. El Wiki de GitHub solo debe servir a la documentación técnica y no a la documentación para los jugadores, habrá una wiki.
En primer lugar: usamos mucho de este concepto aquí: https://keepachangelog.com/de/1.0.0/
El ChangeLog se mantiene en el archivo ChangeLog.md, aquí mismo en la raíz. Es importante que cada cambio esté documentado aquí, siempre en el área de "inédito". Por el contrario, esto significa que cada solicitud de extracción siempre debe contener cambios en el archivo ChangeLog, de lo contrario no está completo.
En ChangeLog usamos los siguientes grupos para dividir los cambios:
