# Вступительное слово ## Что делать - - - Найти в глобальном поиске нашу группу yuydev@googlegroups.com и подать в неё заявку на вступление. После этого в гугл диске появится директория Yuydev в которой можно создавать и сохранять основные документы/ассеты связанные с игрой. ## Про архитектуру движка - - - Очень настоятельно рекомендую почитать что-то про [ECS](https://en.wikipedia.org/wiki/Entity_component_system). Если вкратце --- основные термины: - Entity (Объект): по факту является уникальным идентификатором объекта, а именно --- целым числом, которое является индексом в списке всех объектов; - Component (Компонент): структура с некоторыми данными в которых содержится состояние объекта. Например, в компоненте `Transform` могут содержаться координаты объекта, а в компоненте `Collider` --- размеры коллайдера; - System (Система): какая-то функция, которая изменяет состояние объекта с определёнными компонентами. Например, система `movePlayer` может обновлять состояние объектов, у которых есть компоненты `Transform` и `Player`, а система `moveEnemy` --- `Transform` и `Enemy`. Идейные вдохновители: - Unity 3D - ## Стек технологий - - - Игра и движок будут писаться на C++, а проект собираться с помощью make (**не cmake!!!**). В качестве IDE для разработки стоит выбрать Jetbrains CLion, а про Visual Studio забыть. Студенческую лицензию для CLion можно получить на сайте [Jetbrains](https://www.jetbrains.com/shop/eform/students). Если активирована почта на домене sgu.ru, то можно использовать её и получить лицензию за несколько минут. Иначе, можно использовать студак во вкладке Official Document, но тогда придётся подождать несколько дней. Почитать инфу по C++ можно [тут](cpp.html). Для работы с графикой, со звуком и остальными мультимедийными вещами будет использоваться библиотека [SFML](https://www.sfml-dev.org/). Для её изучения можно почитать [туториалы](https://www.sfml-dev.org/tutorials/2.5/) на официальном сайте. Они на английском языке, но к этому придётся привыкать. В целом, в данном проекте я рассчитываю на то, что мы будем использовать минимальное количество внешних библиотек. В идеале --- ограничиться только SFML. Другие библиотеки стоит добавлять только в самом-самом крайнем случае, если проблема требует действительно очень большого количества кода и каких-то продвинутых знаний. На данный момент, единственный кандидат в качестве дополнительной внешней библиотеки --- это парсер какого-нибудь языка разметки (например, json). Для сборки проекта на винде нужно будет установить [mingw-w64](http://mingw-w64.org/doku.php) и [GNU make](https://www.gnu.org/software/make/). И после этого каким-то образом это настроить так, чтобы проект действительно собирался. Пока что этим никто не занимался, поэтому именно ты --- читатель --- можешь стать первым! ## Оформление в различных частях проекта - - - ### Оформление кода (будет дополняться) ``` void someFunctionName(int param1, int param2) { int someArray = { 1, 2, 3 }; const std::type_index anotherArray = { TYPE(EnemyController) , TYPE(Transform) , TYPE(PlayerController }; if (true || false) { callOtherFunction(12345); } for (int i = 0; i < 20; ++i) { // TODO(andrew): Добавить большее количество обработчиков. switch (param1) { case 1: { std::string name = "World" std::cout << "Hello, " << name << std::endl; } break; case 2: { // NOTE(andrew): Приветствую только себя потому что могу! std::string name = "Andrew" std::cout << "Hi, " << name << std::endl; } break; default: { std::cout << "Greeting is undefined" << std::endl; } break; } } } ``` Моменты, на которые необходимо обратить внимание: - В названиях используется [CamelCase](https://ru.wikipedia.org/wiki/CamelCase); - Все фигурные скобки находятся на отдельной строке; - Тип возвращаемого значения функции находится на отдельной строке; - Блоки кода обозначаются **везде**, даже в ифе с одной командой; - Немного необычное оформление кейсов в свитче; - **Забудьте про using namespace std**; - Длина строки не превышает 80 символов (в некоторых случаях можно позволить 120 символов, но эти случаи рассматриваются отдельно в каждом случае); - Оформление литералов массивов в случае, если элементы умещаются в одну строку и в случае, когда не умещаются (аналогичное оформление применяется к параметрам функций); - Комментарии на русском языке. Также можно заметить, что в комментариях есть конструкции `TODO(имя)` и `NOTE(имя)`. Имя указывает только на автора комментария, а не на того, кто это будет чинить. Нужно это для того, чтобы можно было найти автора этого комментария, если не совсем понятна проблема или что-то ещё. Комментарии такого вида обычно распознаются в IDE и, например, по TODO-комментария можно искать части проекта, в которых следовало бы добавить какие-то вещи, которые могут быть не обязательны для сборки и работы проекта в данный момент, но могут привести к неожиданным ошибкам. Например, обработку ошибок/исключений можно отложить на потом, но чтобы не забыть о том, что такая необходимость существует, надо добавить комментарий `TODO(имя)` и через двоеточие указать чего именно не хватает. ### Особенности работы с C++ в этом проекте Очень желательно везде использовать [Plain Old Data](https://ru.wikipedia.org/wiki/Простая_структура_данных), то есть обычные `struct`. Использование наследования и рефлексии запрещено (до тех пор, пока не найдётся место, где это **действительно** понадобится). Макросы не запрещены, но их количество следует минимизировать. Если какой-то сложный тип данных встречается достаточно часто есть возможность рассмотреть вынесение его в отдельный `typedef`. Глобальных переменных следует избегать, а нужные данные хранить непосредственно в компонентах. ### Работа с git При начале работы над новой фичей следует создать новую ветку. У названия ветки будет какой-то префикс, соответствующий типу того, что в этой ветке разрабатывается, а после него указывается *очень короткое* описание самой фичи (два -- три слова). Название ветки полностью нижним регистром, а слова разделяются тире (!!!). Примеры: - feature/new-interface; - feature/player-controller-update; - fix/physics-system-bug. Во время разработки фичи можете создавать сколько угодно коммитов, так как при слиянии с основной веткой будет использоваться squash. Не нужно создавать огромное количество коммитов на каждый чих, но и не нужно делать один огромный коммит в котором находятся абсолютно все изменения. Git --- это ваш друг, который поможет откатиться до предыдущего рабочего коммита, если что-то непоправимо сломалось (или просто получилось какое-то говно, которое лучше выкинуть, забыть и начать с начала). Не рекомендуется работа в одной ветке сразу двух людей, так как это **неизбежно** приведёт к бесконечным конфликтам при автоматическом слиянии. В тексте squash-коммита следует указывать что именно было изменено. Первая строка коммита является чем-то вроде заголовка, а весь остальной текст следует оформлять в виде Markdown с подробным описанием новых фич. Текст коммита пишется на русском языке. Основные команды и процесс работы с нашим репозиторием можно прочитать [тут](git.html). ## Какие есть задачи - - - - Сборка проекта под разные архитектуры - Debug и Release сборки - Система логгирования - Чтение конфигов в каком-то языке разметки - Выбрать этот язык (кандидаты: toml, yaml, json, ini) - Движок - Система компонентов - Подсистема рендеринга - Подсистема ввода - Подсистема сцен - Подсистема сохранений - Сериализация/десериализация объектов - Работа с незапакованными ассетами (Debug build) - Звуковая подсистема - Подсистема событий - Фреймворк для разработки графического интерфейса (а также работа со шрифтами) - Запаковка ассетов и загрузка этих архивов в собранном проекте (Release build) - Графический интерфейс для создания сцен - Игровые механики (придумывание идей и реализация) - Сюжет - Графика - Музыка