diff options
Diffstat (limited to 'blog/yuydev.md')
| -rw-r--r-- | blog/yuydev.md | 157 |
1 files changed, 157 insertions, 0 deletions
diff --git a/blog/yuydev.md b/blog/yuydev.md new file mode 100644 index 0000000..c7584fc --- /dev/null +++ b/blog/yuydev.md @@ -0,0 +1,157 @@ +# Вступительное слово + +## Что делать +- - - + +Найти в глобальном поиске groups.google.com нашу группу yuydev@googlegroups.com +и подать в неё заявку на вступление. После этого в гугл диске появится +директория Yuydev в которой можно создавать и сохранять основные +документы/ассеты связанные с игрой. + +## Про архитектуру движка +- - - + +Очень настоятельно рекомендую почитать что-то про +[ECS](https://en.wikipedia.org/wiki/Entity_component_system). +Если вкратце --- основные термины: + +- Entity (Объект): по факту является уникальным идентификатором объекта, а + именно --- целым числом, которое является индексом в списке всех объектов; +- Component (Компонент): структура с некоторыми данными в которых содержится + состояние объекта. Например, в компоненте `Transform` могут содержаться + координаты объекта, а в компоненте `Collider` --- размеры коллайдера; +- System (Система): какая-то функция, которая изменяет состояние объекта с + определёнными компонентами. Например, система `movePlayer` может обновлять + состояние объектов, у которых есть компоненты `Transform` и `Player`, а + система `moveEnemy` --- `Transform` и `Enemy`. + +## Стек технологий +- - - + +Игра и движок будут писаться на C++, а проект собираться с помощью make +(**не cmake!!!**). В качестве IDE для разработки стоит выбрать Jetbrains CLion, +а про Visual Studio забыть. Студенческую лицензию для CLion можно получить на +сайте [Jetbrains](https://www.jetbrains.com/shop/eform/students). Если +активирована почта на домене sgu.ru, то можно использовать её и получить +лицензию за несколько минут. Иначе, можно использовать студак во вкладке +Official Document, но тогда придётся подождать несколько дней. + +Для работы с графикой, со звуком и остальными мультимедийными вещами будет +использоваться библиотека [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(имя)` +и через двоеточие указать чего именно не хватает. + +### Работа с git + +При начале работы над новой фичей следует создать новую ветку. У названия +ветки будет какой-то префикс, соответствующий типу того, что в этой ветке +разрабатывается, а после него указывается *очень короткое* описание самой +фичи (два -- три слова). Название ветки полностью нижним регистром, а слова +разделяются тире (!!!). Примеры: + +- feature/new-interface; +- feature/player-controller-update; +- fix/physics-system-bug. + +Во время разработки фичи можете создавать сколько угодно коммитов, так как +при слиянии с основной веткой будет использоваться squash. Не нужно создавать +огромное количество коммитов на каждый чих, но и не нужно делать один огромный +коммит в котором находятся абсолютно все изменения. Git --- это ваш друг, +который поможет откатиться до предыдущего рабочего коммита, если что-то +непоправимо сломалось (или просто получилось какое-то говно, которое лучше +выкинуть, забыть и начать с начала). + +Не рекомендуется работа в одной ветке сразу двух людей, так как это +**неизбежно** приведёт к бесконечным конфликтам при автоматическом слиянии. + +В тексте squash-коммита следует указывать что именно было изменено. Первая +строка коммита является чем-то вроде заголовка, а весь остальной текст +следует оформлять в виде Markdown с подробным описанием новых фич. + +Текст коммита пишется на русском языке. + +Основные команды и процесс работы с нашим репозиторием можно прочитать +[тут](git.html). + |