Skip to content

Guide to Development

goliath edited this page Mar 1, 2021 · 11 revisions

В этом гайде разбираем первые шаги разработчика билда Space Station 13. Для совместной разработки во всех сообществах Space Station 13 используются git-репозитории, поэтому немалая часть этого руководства посвященна работе с git-ом.

Весь гайд написан с точки зрения использования минимального набора стандартных инструментов разработчика: встроенного редактора BYOND, который называется DreamMaker, а также обычного консольного git-а. Если вы поймете как работать с кодом с помощью этих стандартных инструментов, то вы легко разберетесь и с более навороченными и современными инструментами разработки, такими как графические интерфейсы git. Конечно, пользоваться git-ом в виде графических интерфейсом кажется гораздо удобнее, чем консольной версией, но если вы не разберетесь с консолью, то пользование графической версией будет для вас очень сложной магией, что вызовет очень много сложностей. Обязательно пройдитесь по этому руководству используя консольный git, а в конце вы увидите список рекомендуемых более современных средств разработки, которые используют опытные разработчики.

Скачиваем билд

В виде архива

Если вы не собираетесь ничего разрабатывать, а просто хотите запустить локальный сервер, то тогда вам не нужен git и вы можете просто скачать билд архивом. Это можно сделать нажав по большой зеленой кнопке "Code" сверху-справа главной страницы репозитория.

С помощью git

  1. Скачиваем git с официального сайта и устанавливаем. При установке лучше выбрать опцию использования git из командной строки (вместо использования git только из-под Git Bash). Все остальные опции оставляем по дефолту. После установки в командной консоли (cmd) должна появиться команда git, с которой мы дальше и будем работать.

  2. Открываем консоль в папке, куда мы хотим выкачать репозиторий и пишем следующую команду:

git clone https://github.com/ChaoticOnyx/OnyxBay   // Клонируем удаленный репозиторий в новую папку "OnyxBay"

Поздравляю, у вас в папке "OnyxBay" лежит последняя версия нашего билда, готовая к запуску. Вы также можете проверить статус вашего репозитория:

cd OnyxBay  // заходим в папку "OnyxBay", где создан наш локальный репозиторий
git status  // проверяем статус репозитория

Если все получилось, то вывод будет примерно такой:

On branch dev  // вы находитесь на локальной ветке dev - это копия нашей основной ветки с последними изменениями
Your branch is up to date with 'origin/dev'.  // ваша локальная ветка "dev" отслеживает ветку "origin/dev" удаленного репозитория

nothing to commit, working tree clean  // у вас нет никаких изменений, которые можно было бы зафиксировать и отправить

Если в основном репозитории появились новые изменения, то вы можете затащить их к себе следующей командой:

git pull  // затащить изменения из удаленной отслеживаемой ветки (сейчас это "origin/dev") в нашу текущую локальную ветку ("dev")

После выполнения этой команды ваша текущая ветка обновится и у вас в папке будет лежать свежая версия билда. Если при попытке обновить билд вы получаете ошибки, то, возможно, вы сделали какие-то изменения в билде, которые не дают вам получить обновления. Как избавиться от них и как отправлять свои изменения - расмотрим дальше.

Запускаем билд

Итак, каким-то образом мы получили у себя на компьютере папочку с билдом.

Основной файл билда - файл в формате .dme, который лежит в корне проекта. Этот файл открывается с помощью редактора DreamMaker, который устанавливается вместе с BYOND. Открыв билд в этом редакторе, мы можем его сначала скомпилировать (Build/Compile), после чего запустить (Build/Run). При компилировании билда обязательно смотрите на вывод в нижней части окна DreamMaker, в конце компиляции вы должны увидеть такой вывод:

saving baystation12.dmb (DEBUG mode)
baystation12.dmb - **0 errors, 0 warnings** (10/13/20 8:46 am)

Если есть ошибки (errors), то билд не скомпилировался и запустить его не получится, нужно разбираться с ошибками. Если есть предупреждения (warnings), то билд скомпилировался, но что-то может пойти не так, так что запомните факт их существования на случай, если будут какие-то проблемы при запуске.

Дальше, если билд компилируется и работает, то стоит выключить сервер и настроить конфиги. Пример конфигов лежит в папке configs/examples, их нужно скопировать в папку configs и настроить под себя. Чтобы выдать себе кнопки админа, нужно добавить свой логин бьонда в configs/admins.txt, например, можно прописать себе все права, добавив строчку: Epicus - Host.

После настройки конфигов можно снова запустить сервер и уже тестировать что-то свое на полностью рабочем сервере.

Запуск сервера через DreamDaemon

Хотя сервер можно запускать прямо из DreamMaker, иногда это удобнее делать через DreamDaemon. Так, например, иногда при запуске через DreamMaker возникают странные лаги.

Чтобы запустить сервер просто откройте DreamDaemon, укажите путь до скомпилированного билда (файл в формате .dmb в корне билда), выставьте режим безопасности Trusted, а видимость в Invisible. Теперь нажимаем кнопку старта, чтобы запустить сервер.

Подготовка к отправке своих изменений

Итак, у вас уже стоит рабочий билд. Теперь вы можете поменять в нем все что угодно, скомпилировать билд с вашими изменениями и даже локально запустить сервер, чтобы посмотреть как ваши изменения работают. Теперь разберемся как залить ваши изменения в наш основной репозиторий.

Здесь описана подготовка, которая делается один раз - когда вы только-только создали свой локальный репозиторий. Каждые новые изменения можно будет заливать сразу начиная со следующего раздела.

Для начала важно заметить, что лить все что угодно кто угодно в наш репозиторий не может. Для того чтобы опубликовать свои изменения - вы можете создать на GitHub свой форк, копию нашего репозитория. В этот форк можно залить свои изменения, после чего создать "Запрос на затягивание изменений" (Pull Request). Такой Pull Request уже появится в нашем репозитории, мы сможем его принять и ваши изменения автоматически попадут в нашу основную ветку dev, откуда они через какое-то время попадут и на игровые сервера.

Теперь по шагам:

  1. Создаем свой форк. Это делается специальной кнопкой "Fork" в верхнем-правом углу главной страницы репозитория.
  2. Открываем консоль в папке с вашим локальным репозиторием.
  3. Настраиваем git. Нам нужно указать никнейм и почтовый адрес, которые будут привязываться к коммитам.
git config --global user.name "John Doe"
git config --global user.email [email protected]  // этот почтовый адрес должен совпадать с почтовым адресом аккаунта на GitHub
  1. Добавляем ваш форк как удаленный репозиторий.

Ваш локальный репозиторий ссылается на удаленные репозитории чтобы загружать оттуда обновления или отправлять туда ваши изменения. Наш основной репозиторий уже есть в вашем локальном репозитории, т.к. мы из него изначально клонировались. К нему можно обратиться по ключевому слову "origin". Теперь мы хотим точно также добавить ваш форк, например, с ключевым словом "onyx-epicus".

Делается это так (url-адрес берем от своего форка):

git remote add onyx-epicus https://github.com/Epicus7/OnyxBay  // добавить удаленный репозиторий с идентификатором "onyx-epicus".

На этом мы закончили подготовку. Теперь можем уже зафиксировать какие-то изменения и отправить их в основной репозиторий.

Фиксация и отправка изменений

Теперь опишем действия, которые нужно делать каждый раз, когда вы начинаете работу над новой фичей или новым фиксом.

  1. Для начала проверяем, что у нас в репозитории нет каких-то мусорных изменений, переключаемся на основную ветку dev и обновляем её.
git status  // проверяем что у нас происходит в репозитории
git reset --hard  // если есть какие-то лишние изменения, сносим их. Осторожно, это действие необратимо
git checkout dev  // если мы находимся на другой ветке, то переключаемся на основную ветку dev
git pull  // вытаскиваем последние изменения нашей текущей ветки (dev) из удаленного репозитория
  1. Создаем новую ветку для своих изменений.
git branch my_feature_1  // создали новую ветку с названием "my_feature_1"
git checkout my_feature_1  // переключились на новую ветку
  1. Теперь вносим свои изменения, которые мы хотим отправить. Фиксим какой-то баг или реализуем какую-то фичу. В любой момент работы вы можете проверить свои текущие изменения:
git status  // проверяем список измененных файлов
git diff my/file/path/code.dm  // смотрим изменения конкретного файла
  1. Фиксируем все изменения и создаем новый коммит в текущей ветке.
git add .  // зафиксировать все изменения
git commit  // создать новый коммит в текущей ветке. Эта команда откроет текстовый редактор, в котором можно будет написать название и описание коммита
  1. Отправляем изменения в ваш форк.
git push -u [ваш идентификатор форка]  // отправляем вашу ветку в ваш форк
  1. Создаем Pull Request. Это делается в основном репозитории, в разделе пулл реквестов с помощью большой зеленой кнопки. Выбираем ветку в вашем форке, на основе которой мы создаем PR, пишем описание и отправляем.

Ура! Ваши изменения теперь в Пулл Реквесте, скоро их посмотрят и примут. Если в результете ревью вам понадобиться внести какие-то изменения, это можно сделать следующим образом:

git checkout my_feature_1  // возвращаемся на нашу ветку, если мы уже успели переключиться.
.. вносим какие-то изменения ..
git add .  // фиксируем
git commit  // создаем еще один коммит
git push  // отправляем. Теперь без указания удаленного репозитория, так как ветка уже привязана к конкретной ветке в конкретном удаленном репозитории (вашем форке)

После отправки изменения сразу же появятся в пулл реквесте.

Рекомендуемые инструменты разработки

  • Самая удобная среда разработки для BYOND на данный момент - Visual Studio Code с установленным плагином для поддержки BYOND. По сравнению с DreamMaker VS Code поддерживает автодополнение кода и удобный поиск по коду с помощью ctrl-щелчков по ключевым словам. Также в VS Code есть куча различных общих фич, которыми обладают современные IDE, например встроенный Git-клиент и плагин для GitHub.
  • Для работы с гитом вполне можно обойтись Visual Studio Code + консолью. Впрочем можно еще попробовать очень удобный графический клиент SourceTree, который сочетает в себе простоту использования и богатство функционала. Совсем новички еще могут попробовать Github Desktop, в котором даже есть встроенный туториал, но этот гит-клиент самый бедный по своему функционалу, из-за чего в нем чаще всего приходится открывать консольку.