From c14c7bbdba4fdc58e04f37775003943f5416c1ec Mon Sep 17 00:00:00 2001 From: Dis_Bro Date: Wed, 28 Jan 2026 12:43:20 +0300 Subject: [PATCH] =?UTF-8?q?Commit=20as=20of=202026-01-28=2012:43:20=20by?= =?UTF-8?q?=20Dis=5FBro=20(=D0=94=D0=B0=D0=BD=D0=B8=D0=BB)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- GreatGamedevVault/CHANGELOG.md | 7 +- GreatGamedevVault/README.md | 14 +- GreatGamedevVault/TEMP.md | 4 + .../Организация/Организационная структура.md | 79 ++-- GreatGamedevVault/Организация/Стандарты.md | 406 +++++++++++++++--- 5 files changed, 414 insertions(+), 96 deletions(-) create mode 100644 GreatGamedevVault/TEMP.md 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