diff --git a/GreatGamedevVault/CHANGELOG.md b/GreatGamedevVault/CHANGELOG.md
index c28aed0..0fca29b 100644
--- a/GreatGamedevVault/CHANGELOG.md
+++ b/GreatGamedevVault/CHANGELOG.md
@@ -43,7 +43,12 @@
## Январь 2026
- 26.01.2026 Dis_Bro
- Добавил информацию о системе команд для новой платы, структурировал, расписал подробнее
-
+- 28.01.2026 Dis_Bro
+ - Обновил [[Стандарты]]:
+ - Немного переписал [[Стандарты#C /Unity|C#/Unity]], добавил примеров
+ - Добавил [[Стандарты#Git|Git]] с примерами и правилами для коммитов
+ - Обновил [[Организационная структура]] под текущее положение дел
+
diff --git a/GreatGamedevVault/README.md b/GreatGamedevVault/README.md
index 266ba38..e4af5c9 100644
--- a/GreatGamedevVault/README.md
+++ b/GreatGamedevVault/README.md
@@ -28,10 +28,16 @@
Это не обязательный список, но максимально желательный
## Ссылки хранилища
-### Билды
-[Ссылка на билды фишки](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Conect4_builds)
-[Ссылка на билды промика](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Promo_builds)
-[Ссылка на билды морского боя](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Sea_battle_Cviat)
+### Проекты
+- Фишка:
+ - [Ссылка на билды фишки](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Conect4_builds)
+ - [Ссылка на исходники фишки](http://172.11.0.14:3000/Robotail/chip-game)
+- Данро:
+ - [Ссылка на билды Данро](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Danro_builds)
+ - [Ссылка на исходники Данро](http://172.11.0.14:3000/Robotail/Danro)
+- Морской бой:
+ - [Ссылка на билды морского боя](file:///B:/!ФайлОбменник!/Юнити_Разработка/Builds/Sea_battle_Cviat)
+ - [Ссылка на исходники морского боя](http://172.11.0.14:3000/Robotail/sea-battle)
## Организация
Сведения об организационной деятельностьи [[Организационная структура|в общем]] и в частности.
```dataview
diff --git a/GreatGamedevVault/TEMP.md b/GreatGamedevVault/TEMP.md
new file mode 100644
index 0000000..9f2407e
--- /dev/null
+++ b/GreatGamedevVault/TEMP.md
@@ -0,0 +1,4 @@
+Файл для временного содержания
+
+# Список установленных плагинов
+
diff --git a/GreatGamedevVault/Организация/Организационная структура.md b/GreatGamedevVault/Организация/Организационная структура.md
index 3299db1..4019ea3 100644
--- a/GreatGamedevVault/Организация/Организационная структура.md
+++ b/GreatGamedevVault/Организация/Организационная структура.md
@@ -1,42 +1,53 @@
-# Ораганизация
-- Наличие тимлида
- - Распределение приоритетов
- - Отслеживание сроков
- - Код-ревью понеобходимости
- - Связь с начальством
-- Гит
- - Заливать и хранить на гите объемные ассеты долго и неудобно.
- - Пока разработка у каждого индивидуальная вопрос не слишком актуален
-- Папка на пандоре
- - Хороший переиспользуемый код. Обязательно README.
- - Билды по своим папкам
- - Закупленные или стыренные ассеты + README.
-- Запланированные на неделю мероприятия
-- Использование Obsidian для отслеживания выполненных задач (упрощает вспоминание "что делали" когда приходит время отчитываться)
+# Организация
+
+## Текущие вопросы
+
+> [!faq]- Наличие тимлида
+> - Распределение приоритетов
+> - Отслеживание сроков
+> - Код-ревью понеобходимости
+> - Связь с начальством
+
+> [!answer]- Решение
+> - Пока оставить все как есть, делать все общими усилиями
+> - В перспективе выбрать одного из нас на роль, никаких Барбоскиных
+> - Улучшать оргструктуру
+
+## Текущие решения
+
+> [!done]- Гит
+> - Для объемных ассетов проекта использовать Git LFS под необходимые форматы
+> - Один проект - один репозиторий
+> - Писать содержание коммитов желательно в соответствии с [[Стандарты#Git]], для простого формирования отчетности
+> - Делать коммиты регулярно, желательно ежедневно или по таскам
+> - В дальнейшем прийти к более структурированным репозиториям
+> - Ссылки: [[README#Ссылки хранилища]]
+
+> [!done]- Общая библиотека
+> - Хороший переиспользуемый код. Обязательно README в этом хранилище
+> - Закупленные или стыренные ассеты + README
+
+> [!done]- Папка на пандоре
+> - Билды по своим папкам
+> - README для запуска проекта другими сотрудниками
+
+> [!done]- Obsidian
+> - Запланированные на неделю мероприятия
+> - Использование Obsidian для отслеживания выполненных задач (упрощает вспоминание "что делали" когда приходит время отчитываться)
-___
# Стандарты и правила
-- Общий [[Стандарты]]
-- Общая [[Добавление файла в библиотеку|библиотека]] для складирования полезного переиспользуемого кода (менеджеры, паттерны, префабы, реюзабл механики)
+- Общие [[Стандарты]]
+- Общая [[Добавление файла в библиотеку|библиотека]] для складирования полезного переиспользуемого кода (менеджеры, паттерны, префабы, реюзабл механики)
- Архитектура программы
- Для индивидуальной разработки полагаемся на мнение чата, делаем как удобно
- Коллективная разработка: Сначала проектируем на схемах, вместе мозгуем, потом следуем плану.
-___
-# Недельный цикл работы
+# Недельный цикл работы
-==Понедельник==
-- Планерка
- - Разбираем задачи с пятницы
- - Расставляем приоритеты
+==Пока под вопросом, в процессе разработки==
-==Вторник-Четверг==
-- Фокус на разработку
-- При завершении задачи добавляем отработанную задачу в пул "на проверку"
-- Внеплановые собрания для помощи по необходимости
-
-==Пятница==
-- Собираем билды
-- Проводим плейтесты
-- Собрать информацию о текущем состоянии проектов
-- Составляем обратную связь -> генерируем задачи на следующую неделю
+| День/дни недели | План работы |
+| --------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| Понедельник | Планерка
- Разбираем задачи с пятницы
- Расставляем приоритеты |
+| Вторник-Четверг | Фокус на разработку
При завершении задачи добавляем отработанную задачу в пул "на проверку"
Внеплановые собрания для помощи по необходимости |
+| Пятница | Собираем билды
Проводим плейтесты
Собрать информацию о текущем состоянии проектов
Составляем обратную связь -> генерируем задачи на следующую неделю |
diff --git a/GreatGamedevVault/Организация/Стандарты.md b/GreatGamedevVault/Организация/Стандарты.md
index 6059fe0..3d54d9c 100644
--- a/GreatGamedevVault/Организация/Стандарты.md
+++ b/GreatGamedevVault/Организация/Стандарты.md
@@ -1,66 +1,244 @@
-# 1. Именование и стиль C-sharp
+# C#/Unity
+## 1. Именование и стиль C#
-- **PascalCase**: классы, интерфейсы, методы, свойства, события.
-- **camelCase**: локальные переменные и параметры (spawnPoint, speed).
-- **\_camelCase**: приватные поля.
-- **UPPER_SNAKE_CASE**: const и static readonly.
-- **Namespaces**: Company.Product.Module → BobotailX.Gameplay.Combat.
-- **Один класс = один файл**. Публичные типы в отдельных файлах.
-- **var** — для очевидных типов, иначе явный тип.
+1. Именование:
+ - **PascalCase**: классы, структуры, record’ы, enum’ы, методы, свойства, события.
+ - **IInterfaceName**: интерфейсы (`IDamageable`, `IInputSource`).
+ - **camelCase**: локальные переменные и параметры (`spawnPoint`, `moveSpeed`).
+ - **_camelCase**: приватные поля (`_rigidbody`, `_cachedTransform`).
+ - **UPPER_SNAKE_CASE**: только `const` (без `static readonly`).
+ - **static readonly**: как обычное поле в **PascalCase** (`static readonly Vector3 DefaultOffset = ...`).
+ - **Namespaces**: `Company.Product.Module` → `BobotailX.Gameplay.Combat`.
+ - Суффиксы по смыслу: `*Service`, `*System`, `*Factory`, `*Controller`, `*Presenter`, `*View`, `*Settings`.
+2. Структура исходников:
+ - **Один публичный тип = один файл** (файл называется как тип).
+ - Допускаются несколько приватных типов в одном файле, если они служебные и не используются снаружи.
+ - Предпочтительно использовать **file-scoped namespace** (если версия языка позволяет):
+```cs
+namespace BobotailX.Gameplay.Combat;
-- Для автоформатирования периодически юзаем Ctrl+KD в VS
+public sealed class DamageSystem { }
+```
+3. Использование типов:
+ - Явное указание типов **приветствуется всегда** и является предпочтительным по умолчанию.
+ - **var** — допускается только при очевидном типе и при улучшении читаемости, без потери понимания (тип однозначен из правой части).
+ - Для чисел и Unity API предпочтительнее явные типы (чтобы не путать `int/float`, `Vector2/Vector3`, `Transform/GameObject`).
+ - Примеры:
+```cs
+// предпочтительно (ясный тип)
+float moveSpeed = 6.5f;
-# 2. Unity-специфичные штуки
+Vector3 targetPosition = transform.position;
-- Поля в инспекторе: \[SerializeField] private + public get (инкапсуляция лучше, чем public).
-- Компоненты кешируем в Awake/OnEnable (не дергать `GetComponent` каждый кадр).
-- Минимизируем работу в `Update()`; используем события, корутины.
-- В Input/Physics использовать `Time.[fixed]deltaTime`, не «магические» коэффициенты.
-- Не использовать `FindObjectOfType`/`Find` в рантайме
- - Использовать DI, ссылки через инспектор, фабрики, бутстрапы.
-- Конфиги — **ScriptableObject** (баланс, таблицы параметров).
-- Сцены:
- - **MainBootstrap** сцена с уникальным Bootstrap скриптом для загрузки менеджеров-синглтонов, существующих всю игру (GameManager, ContextManager, AudioManager)
- - Локальные Bootstrap'ы для сцен по необходимости
+// допустимо (тип очевиден и не снижает читаемость)
+var enemies = new List();
+var token = cancellationTokenSource.Token;
+```
+4. Современный C# (рекомендуется):
+ - Включать **nullable reference types** (NRT) и избегать `null`-контрактов без необходимости.
+ - Использовать **pattern matching**, `switch`-выражения, `readonly`/`init` при уместности.
+ - Использовать `sealed` по умолчанию для классов без наследования (в Unity — осторожно, см. ниже).
+ - Примеры:
+```cs
+#nullable enable
+public bool TryGetTarget(out Transform target)
+{
+ target = _target;
+ return target is not null;
+}
->Bootstrap'ы - реализация паттерна Entry Point. Удобно управлять порядком загрузки, чтобы не долбаться с настройкой Execution Order'а когда менеджеров >1 и зависимости усложняются
+public static int ClampToByte(int value) => value switch
+{
+ < 0 => 0,
+ > 255 => 255,
+ _ => value
+};
+```
+5. Unity-ограничения для C#:
+ - `MonoBehaviour`/`ScriptableObject` **не делать `new`**, создаются Unity.
+ - `MonoBehaviour` обычно **не `sealed`**, если планируется наследование/моки; если наследование не нужно — `sealed` допустим.
+ - Использовать `[SerializeField] private` вместо `public` полей.
-# 3. Структура скрипта (порядок элементов)
+5. Форматирование:
+ - Форматирование кода выполняется средствами IDE.
+ - Для Visual Studio: **Format Document** (`Ctrl+K, Ctrl+D`) / **Format Selection** (`Ctrl+K, Ctrl+F`).
+ - Для Rider: **Code Cleanup / Reformat Code** (настройки проекта фиксируются в `.editorconfig`).
+ - Рекомендуется добавить `.editorconfig` и включить анализаторы (Roslyn/IDE).
+
+## 2. Unity-специфичные штуки
+
+1. Сериализация и Inspector:
+ - Поля в инспекторе: `[SerializeField] private` + `public` свойства/геттеры (инкапсуляция лучше, чем `public`).
+ - Для ссылок на компоненты/объекты сцены использовать **SerializeField** и префабы/инстансы, не поиск по имени.
+ - Пример:
+```cs
+public sealed class PlayerMover : MonoBehaviour
+{
+ [SerializeField] private Rigidbody _rigidbody = null!;
+ [SerializeField] private float _speed = 6.5f;
+
+ public float Speed => _speed;
+
+ private void Awake()
+ {
+ // null! допускается, но лучше валидировать в OnValidate (см. ниже)
+ }
+}
+```
+2. Валидация ссылок и настроек:
+ - Для проверки сериализованных ссылок использовать `OnValidate()` (в редакторе) и/или рантайм-assert.
+ - Пример:
+```cs
+private void OnValidate()
+{
+ if (_rigidbody == null) TryGetComponent(out _rigidbody);
+}
+```
+3. Производительность:
+ - Компоненты кешируются в `Awake`/`OnEnable` (не дергать `GetComponent` каждый кадр).
+ - Работа в `Update()` минимизируется; предпочтение событиям, `Coroutine`, `Invoke`, таймерам.
+ - Для частых операций — `FixedUpdate` (физика) или `LateUpdate` (камера), по назначению.
+ - Пример (кэш + ранний выход):
+```cs
+private Transform _cachedTransform = null!;
+
+private void Awake()
+{
+ _cachedTransform = transform;
+}
+
+private void Update()
+{
+ if (!enabled) return;
+ // минимальная логика, без тяжёлых аллокаций
+}
+```
+4. Время, ввод и физика:
+ - Для движения/анимации использовать `Time.deltaTime`.
+ - Для физики — `Time.fixedDeltaTime` и `FixedUpdate`.
+ - Магические коэффициенты вместо времени кадра не допускаются.
+ - Ввод рекомендуется через **Input System** (Unity package), а не старый `Input.*`.
+ - Пример (Input System):
+```cs
+using UnityEngine.InputSystem;
+
+public void OnMove(InputAction.CallbackContext ctx)
+{
+ Vector2 input = ctx.ReadValue();
+ _moveInput = input;
+}
+```
+5. Поиск объектов и зависимости:
+ - Не использовать `FindObjectOfType`/`Find` в рантайме (особенно на мобильных/консолях).
+ - Использовать DI (Zenject/VContainer), ссылки через инспектор, фабрики, bootstrap-инициализацию.
+ - Исключение: редакторские утилиты и одноразовая диагностика в dev-сборках.
+6. Конфиги и данные:
+ - Конфиги — **ScriptableObject** (баланс, таблицы параметров, ссылки на префабы).
+ - Для адресуемого контента и крупных проектов — **Addressables**.
+ - Пример `ScriptableObject`:
+```cs
+[CreateAssetMenu(menuName = "Gameplay/Player Settings")]
+public sealed class PlayerSettings : ScriptableObject
+{
+ [field: SerializeField] public float MoveSpeed { get; private set; } = 6.5f;
+ [field: SerializeField] public float JumpForce { get; private set; } = 7.0f;
+}
+```
+7. Ассембли и пакеты:
+ - Рекомендуются **Assembly Definition Files (asmdef)** для разделения модулей, ускорения компиляции и чистых зависимостей.
+ - Внешние зависимости — через `Packages/` (UPM), минимизировать «всё в Assets/ThirdParty».
+8. Сцены и Bootstrap[^1]:
+ - **MainBootstrap** сцена с уникальным Bootstrap скриптом для загрузки сервисов/менеджеров на всю сессию (например: `GameManager`, `ContextManager`, `AudioManager`).
+ - Локальные Bootstrap'ы[^1] для сцен по необходимости (UI, уровень, режим).
+ - Рекомендуется грузить основную сцену **additive** и управлять жизненным циклом через SceneManager.
+ - Пример (additive):
+```cs
+using UnityEngine.SceneManagement;
+
+private IEnumerator Start()
+{
+ yield return SceneManager.LoadSceneAsync("MainMenu", LoadSceneMode.Additive);
+}
+```
+
+[^1]: Bootstrap'ы — реализация паттерна Entry Point. Удобно управлять порядком загрузки, чтобы не настраивать `Execution Order`, когда менеджеров больше одного и зависимости усложняются.
+
+## 3. Структура скрипта (порядок элементов)
1. const/static readonly
-2. serialized поля
+2. serialized поля (`[SerializeField]`)
3. приватные поля (неконфигурируемые)
4. свойства/события
-5. **Unity Messages** (Awake, OnEnable, Start, Update, …)
+5. **Unity Messages** (Awake, OnEnable, OnDisable, Start, Update, FixedUpdate, LateUpdate, OnDestroy, …)
6. публичные методы API
7. приватные методы/вспомогательные
8. вложенные типы
-# 4. Организация папок проекта
-Assets/
- Scripts/
- Art/
- Models/
- Textures/
- Materials/
- Sprites/
- Animations/
- object1/
- animator
- clips
- object2/
- ...
- Audio/
- Music/
- SFX/
- Prefabs/
- Scenes/
- UI/
- ThirdParty/
- Все что накачали/
+Пример минимального шаблона:
+```cs
+public sealed class Example : MonoBehaviour
+{
+ private const int MaxCount = 10;
-# 5. Аннотации инспектора
-Да, лишний прописывать их тратит время, но инспектор становитсяя красивым, удобным и читаемым.
+ [SerializeField] private float _speed = 6.5f;
+
+ private int _count;
+
+ public float Speed => _speed;
+
+ private void Awake()
+ {
+ _count = 0;
+ }
+
+ public void ResetCount()
+ {
+ _count = 0;
+ }
+
+ private void Tick()
+ {
+ _count++;
+ }
+}
+```
+
+## 4. Организация папок проекта
+
+```shell
+Assets/
+ Scripts/
+ Runtime/
+ Editor/
+ Tests/
+ Art/
+ Models/
+ Textures/
+ Materials/
+ Sprites/
+ Animations/
+ object1/
+ animator
+ clips
+ object2/
+ ...
+ Audio/
+ Music/
+ SFX/
+ Prefabs/
+ Scenes/
+ UI/
+ ThirdParty/
+ Все что накачали/
+ Settings/
+ ScriptableObjects/
+ Resources/ (использовать по необходимости)
+ Addressables/ (если используется Addressables)
+```
+
+## 5. Аннотации инспектора
+
+Да, лишний раз прописывать их тратит время, но инспектор становится красивым, удобным и читаемым.
- Header
- Tooltip
- Range
@@ -68,14 +246,128 @@ Assets/
- Max
- Delayed
- RequireComponent
+- ContextMenu (для отладочных кнопок в инспекторе)
+- FormerlySerializedAs (при переименовании полей, чтобы не ломать сериализацию)
+
+Пример:
+```cs
+using UnityEngine;
+using UnityEngine.Serialization;
+
+public sealed class Health : MonoBehaviour
+{
+ [Header("Config")]
+ [SerializeField, Range(1, 500)] private int _maxHp = 100;
+
+ [FormerlySerializedAs("_regenPerSec")]
+ [SerializeField, Min(0f)] private float _regenPerSecond = 0f;
+
+ [ContextMenu("Print HP")]
+ private void PrintHp()
+ {
+ Debug.Log($"HP: {_maxHp}");
+ }
+}
+```
+
+## 6. Документация и комментарии
-# 6. Документация и комментарии
- XML-комментарии для публичного API.
- ```cs
- ///
- /// Воспроизводит звуковой эффект.
- ///
- /// Аудио-клип для воспроизведения.
- /// Мировая позиция источника звука.
- ```
-- Комментарии «зачем», а не «что».
\ No newline at end of file
+ ```cs
+ ///
+ /// Воспроизводит звуковой эффект.
+ ///
+ /// Аудио-клип для воспроизведения.
+ /// Мировая позиция источника звука.
+ public void PlayOneShot(AudioClip clip, Vector3 position)
+ {
+ // ...
+ }
+ ```
+- Комментарии «зачем», а не «что».
+- Для сложных участков: короткие примеры использования (в README или рядом в комментариях), плюс ссылки на задачи/решения, если применимо.
+
+# Git
+
+## 1. База
+
+1. Ветка `main`/`master` является основной веткой разработки. Прямые коммиты в `main`/`master` допускаются.
+2. История изменений должна обеспечивать однозначную интерпретацию причин и состава изменений, а также возможность оперативного отката.
+3. В `main`/`master` не допускается длительное нахождение состояния, при котором проект не собирается/не запускается. При фиксации некорректного состояния следующий коммит должен устранять выявленную неисправность.
+4. Один коммит должен соответствовать одной логической причине изменения. Смешивание независимых типов работ в одном коммите не допускается (например, рефакторинг совместно с добавлением функциональности).
+
+## 2. Ограничения на состав репозитория
+
+1. Нежелательно включение в репозиторий:
+ - сборочных артефактов, кэшей, временных файлов, каталогов IDE/CI, иных генерируемых данных;
+ - секретов (ключей, токенов, паролей), конфиденциальных данных, а также иных материалов, не предназначенных для публикации в истории Git.
+2. Для проектов с крупными бинарными ресурсами (в т.ч. геймдев) допускается и рекомендуется использование Git LFS для хранения соответствующих файлов.
+
+## 3. Релизы и теги
+
+1. Релизы подлежат фиксации тегами в формате `vX.Y.Z`
+2. Тег релиза должен ссылаться на коммит типа `RELEASE` либо на коммит, явно соответствующий релизному состоянию.
+
+## 4. Требования к сообщениям коммитов
+
+1. Сообщение коммита является обязательным документированием изменения и должно содержать:
+ - тип коммита (далее — `TYPE`);
+ - краткое описание на английском языке;
+ - подробное описание на русском языке.
+2. Допускаются следующие значения `TYPE`:
+ - `FEAT` — новая функциональность;
+ - `RELEASE` — релиз/подготовка релиза;
+ - `FIX` — исправление дефектов;
+ - `UPDATE` — обновления зависимостей/конфигураций/версий без введения новой функциональности;
+ - `TEST — тестовые/временные изменения для проверки/сборки;
+ - `REFACTOR` — рефакторинг без изменения внешнего поведения;
+ - `DOCS` — документация.
+3. Формат сообщения коммита устанавливается следующим образом:
+```diff
+:
+
+<Подробно по-русски>
+1. Что сделано
+2. Зачем / контекст
+3. Как проверить (при необходимости)
+4. Заметки (если есть)
+```
+## 5. Правила применения типов
+1. Коммиты `TEST` допускаются в `main`/`master`, при этом такие изменения подлежат удалению либо отключению до формирования релиза, если они не предназначены для выпуска.
+2. Коммиты `REFACTOR` должны не изменять пользовательское/внешнее поведение. Изменения поведения должны оформляться отдельными коммитами `FEAT`/`FIX`.
+## 6. Примеры сообщений коммитов
+
+### FEAT
+
+```diff
+FEAT: Add daily rewards system
+
+Добавил ежедневные награды.
+- Логика расчёта награды по времени
+- Экран получения награды
+Проверка:
+1) Запустить игру
+2) Промотать время/симулировать новый день
+3) Убедиться, что награда выдаётся 1 раз в сутки
+```
+### TEST
+
+```diff
+TESTBUILD: Add verbose logs for input issues
+
+Временно добавил подробные логи для отладки ввода.
+- Логи на старте сцены и при событиях
+Заметка:
+- Удалить/выключить перед релизом.
+```
+
+### RELEASE (+ тег vX.Y.Z)
+
+```diff
+RELEASE: Release v1.3.2
+Релиз 1.3.2.
+- Исправлены вылеты на перезагрузке сцены
+- Обновлены зависимости
+Проверка:
+- Сборка проходит, тесты ок.
+```
\ No newline at end of file