Conspiratio.Lib
2.3.0
Это текущее состояние библиотеки классов C# .NET 4.6.2 с логикой игрового процесса Conspiratio, удаленной из клиента Conspiratio Winforms. Bibiliothek еще не завершен, но уже содержит наиболее важные классы и методы и может служить основным строительным блоком для клиента Unity.
Проект был создан с помощью: Visual Studio 2019
Просто откройте и составьте папку проекта Conspiratio.Lib.sln для ручной сборки.
Фан -проект под названием «Conspiratio» - это свободное экономическое моделирование современного времени, которое сильно основано на культовой игре «Die Fugger 2».
Вначале игрок наследует полуразрушенную производственную установку и скромную экономию относительного. Он может использовать его, чтобы продемонстрировать свое мастерство в качестве торговца, создавая и продавая товары, делая хорошо -размышления инвестиции или утверждая себя как умного экспортера. Игрок может использовать недавно полученное богатство и связанное влияние:
Но будь осторожен! Даже некоторые конкуренты не уклоняются от вопросов ...
Цель - переписать поверхность и портирование, а также рефакторизация логики геймплея и всей архитектуры от текущей версии Windows Forms до игры Unity, поскольку у нас гораздо больше мультимедиа и, прежде всего, графические параметры и существует определенная независимость платформы. Этот новый клиент Unity будет полностью открытым исходным кодом, мы хотели бы просто включить других людей в сотрудничество и совместное развитие, и проект Hobby должен стать общественным проектом, фанатов для фанатов.
Проблемы GitHub должны служить для планирования и контроля за развитием.
Вы хотите участвовать в этом проекте? Большой! Просто свяжитесь с нами через Discord или Oldschool по электронной почте, и мы уточняем детали.
Любая помощь приветствуется.
ВАЖНО: Мы никогда не совершаем и не толкаем прямо в главную ветвь!
Причина-это просто отсутствие прозрачности и отсутствие принципа 4-го глаза или отсутствие контроля, по крайней мере, другого разработчика.
Новая личная ветвь всегда должна быть создана для каждого изменения в заговор. Название отрасли всегда должно начинаться с одного из следующих имен, за которыми следуют черта:
Пример: исправить/сбой и перепад
Кроме того, следует избегать умен и специальных символов, и пространство также не может использоваться из -за технических ограничений в названии отрасли, поэтому мы вместо этого используем здесь привязывающие линии.
Если ваша собственная филиал является стабильной и содержит все желаемые изменения/расширения, то запрос на слияние может быть создан в главной ветви. Это всегда должно быть назначено другому разработчику для экзамена, что делает небольшой обзор кода, возможно, дает обратную связь с кодом, а затем также объединяет филиал после ремонта. Собственные филиалы должны быть составлены только в исключительных случаях (например, временная срочность).
В качестве руководящих принципов кодирования для C#мы используем следующую ссылку, в частности для нового кода, поскольку теперь она преобладает в качестве стандарта:
https://docs.microsoft.com/de-de/dotnet/csrogramming-guide/inside-a-a-program/coding-conentions
Что касается именования и стандартов, также используется эта ссылка:
https://www.dofactory.com/reference/csharp-coding-standards
Обратите внимание, что мы используем немецкий язык в качестве языка комментариев в коде, а также большинство идентификаторов, поскольку вся существующая база кода уже построена на немецком языке. Конечно, не каждое ключевое слово в каждом методе должно быть полностью немецким, например, GetUmsatzProSpieler были бы совершенно законными (поскольку Get должен быть просто стандартным для каждого разработчика), но что -то вроде GetVolumeOfSalesPerPlayer было бы проблематичным, поскольку мы находим такие термины где -либо еще, ни в игровой поверхности, ни в существующем коде, и поэтому не может быть быстро нарушающееся, что теперь предназначено.
Старый код может постепенно преобразовать в эти руководящие принципы, чтобы позже не было путаницы, но сначала это не является самым высоким приоритетом. Но если вы измените или рефакторируете более старый код, вам следует принять усилия и применить здесь новые руководящие принципы, согласно девизу Scout:
Всегда оставляйте место (код) в лучшем состоянии, чем вы его нашли.
Документация об обширных функциях или других интересных методах, классах и т. Д. Имеется в коде в вики GitHub. Wiki GitHub должен служить только технической документации, а не документации для игроков, будет вики.
Прежде всего: мы много используем из этой концепции здесь: https://keepachangelog.com/de/1.0.0/
Чангэглог поддерживается в файле ChangeLog.md, прямо здесь, в корне. Важно, чтобы каждое изменение было задокументировано здесь, всегда в области «неизданного». И наоборот, это означает, что каждый запрос на вытягивание всегда должен содержать изменения в файле Changelog, в противном случае он не завершен.
В измене мы используем следующие группы для разделения изменений:
