Conspiratio.Lib
2.3.0
Esse é o status atual da biblioteca de classes C# .NET 4.6.2 com a lógica de jogo de conspiratio, removida do cliente Conspiratio Winforms. O Bibiliothek ainda não está completo, mas já contém as classes e métodos mais importantes e pode servir como um bloco básico de construção para o cliente da Unity.
O projeto foi criado com: Visual Studio 2019
Basta abrir e compilar a pasta do projeto Conspiratio.Lib.sln para construção manual.
O projeto de fãs chamado "Conspiratio" é uma simulação econômica gratuita dos tempos modernos, que é fortemente baseada na peça de culto "Die Fugger 2".
No início, o jogador herda uma instalação de produção em ruínas e a modesta salvamento de um parente. Ele pode usá -lo para demonstrar sua habilidade como comerciante, fabricando e vendendo mercadorias, fazendo investimentos bem pensados -ou se afirmando como um exportador inteligente. O jogador pode usar a riqueza recém -adquirida e a influência associada:
Mas tenha cuidado! Mesmo alguns concorrentes não vão se esquivar dos assuntos ...
O objetivo é a reescrita da superfície e a porção, bem como a refatorização da lógica de jogabilidade e toda a arquitetura da versão atual do Windows Forms para um jogo da Unity, já que temos muito mais multimídia e, acima de tudo, opções gráficas e há uma certa independência da plataforma. Esse novo cliente da Unity será completamente de código aberto, gostaríamos de simplesmente incluir outras pessoas na cooperação e co-desenvolvimento e o projeto de hobby deve se tornar um projeto comunitário, fãs para fãs.
Os problemas do GitHub devem servir para planejar e controlar o desenvolvimento.
Você quer participar deste projeto? Ótimo! Basta entrar em contato conosco via Discord ou Oldschool por e -mail e esclarecemos os detalhes.
Qualquer ajuda é bem -vinda.
IMPORTANTE: Nunca cometemos e empurramos diretamente no ramo principal!
O motivo é simplesmente a falta de transparência e falta de 4 olho ou falta de controle por pelo menos outro desenvolvedor.
Um novo ramo pessoal sempre deve ser criado para todas as alterações em conspiração. O nome da indústria deve sempre começar com um dos seguintes nomes, seguido de uma barra:
Exemplo: Correção/Crash e Overfall
Além disso, umlauts e caracteres especiais devem ser evitados e o espaço também não pode ser usado devido a restrições técnicas no nome do setor, e é por isso que usamos linhas de ligação aqui.
Se sua própria filial for estável e contiver todas as alterações/extensões desejadas, uma solicitação na mesclagem poderá ser criada na ramificação principal. Isso sempre deve ser atribuído a outro desenvolvedor para exame, o que faz uma pequena revisão de código, possivelmente fornece feedback ao código e também mescla a filial após o reparo. Os ramos próprios devem ser compostos apenas em casos excepcionais (por exemplo, urgência temporal).
Como diretrizes de codificação para C#, usamos a seguinte referência em particular para novo código, pois agora prevaleceu como padrão:
https://docs.microsoft.com/de-de/dotnet/csrogramming-guide/inside--a-a-program/coding-conventions
No que diz respeito à nomeação e aos padrões, essa referência também é usada:
https://www.dofactory.com/reference/csharp-coding-tandards
Observe que usamos o alemão como o idioma dos comentários no código e também a maioria dos identificadores, já que toda a base de código existente já está construída em alemão. Obviamente, nem todas as palavras -chave em todos os métodos precisam ser completamente alemãs, por exemplo, GetUmsatzProSpieler seriam completamente legítimos (já que o GET deve ser simplesmente padrão para todos os desenvolvedores), mas algo como GetVolumeOfSalesPerPlayer seria problemático, pois encontramos esses termos em qualquer outro, nem no código da superfície de jogo nem no código existente e, portanto, pode ser rapidamente confundir o que se destina rapidamente.
O código antigo pode e deve ser gradualmente convertido a essas diretrizes, para que não haja confusão mais tarde, mas a princípio não é a maior prioridade. Mas se você alterar ou refatorar o código mais antigo, deve se esforçar e aplicar as novas diretrizes aqui, de acordo com o lema de escoteiros:
Sempre deixe um local (código) em uma condição melhor do que você o encontrou.
A documentação de recursos extensos ou outros métodos interessantes, aulas etc. ocorre no código no wiki do GitHub. O Wiki do Github deve servir apenas a documentação técnica e não a documentação para os jogadores, haverá um wiki.
Primeiro de tudo: usamos muito deste conceito aqui: https://keepachangelog.com/de/1.0.0/
O Changelog é mantido no arquivo changelog.md, aqui na raiz. É importante que todas as mudanças sejam documentadas aqui, sempre na área de "não lançadas". Por outro lado, isso significa que toda solicitação de tração deve sempre conter alterações no arquivo Changelog, caso contrário, não está concluído.
No Changelog, usamos os seguintes grupos para dividir as mudanças:
