Guide to Contribution

В разработке…

Данная статья помечена как неоконченная. Это означает, что статья находится на доработке, поэтому является неверной или неактуальной. Вы можете помочь проекту Onyx и сообществу SS13 в целом — зайдите на наш Портал сообщества.

Что может быть интереснее того, чтобы играть в компьютерную игру? Правильно! Менять мир игры и наблюдать, как глупые ньюфаги превозмогают. Хотите знать, как делают игры? Отлично, в этой статье мы и разберем все, что касается разработки билда Space Station 13, помимо самого написания кода.

Зачем все это? Давайте просто писать код!

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

Наверное, ты уже видел один из реальных билдов Space Station 13? При достаточной внимательности, ты даже мог там разглядеть кнопку "Download ZIP". Давай пойдем по наивному пути и попробуем его скачать.

Скачав и разархивировав архив, ты получил папку с полной копией того билда, который, скорее всего, прямо сейчас работает на сервере. Что мы видим в типичной папочке с билдом? Рассмотрим на примере сборки Baystation12:

• название_билда.dme (Dream Maker Environment) - самый главный файл исходных кодов игры. Он хранит в себе список всех файлов с кодом, которые будут скомпилированы в дистрибутив игры. Все просто: добавили новый файл - добавили его путь в .dme; не хотите чтобы какой-то файл компилировался в сборку - удалите его отсюда. Это файл можно открыть бьондовским Dream Maker'ом, в котором можно добавлять/исключать файлы из сборки с помощью дерева файлов в его интерфейсе слева.
• название_билда.dmb (Dream Maker Build) - скомпилированная версия сборки. Dream Maker собирает все исходные файлы с кодом, которые указаны в .dme файле вместе, компилирует их и отдает этот .dmb файл, который можно загрузить в Dream Daemon, чтобы запустить сервер.
• code, icons, interface, fonts, maps, sound - обычные папки, в которых, внезапно, лежат исходные коды, иконки, файлы интерфейса, шрифты, карты и звуки соответственно. Здесь все легко.
• config - важная папка с конфигами сервера. Перед первым запуском локальной сборки, убедись что скопировал файлы из подпапки examples в корень папки config и все правильно настроил.
• html - различные html-формы, которые используются для описания расположения элементов интерфейса во всяких консолях, панельках, а также вспомогательные элементы.
• tools - скрипты и программы, в основном, на нормальных языках программирования, которые могут понадобится при разработке и запуске сервера. Например, здесь может программа, которая переводит музыку в формате midi в ноты для пианино.
• sql - конфигурационные файлы для запуска Базы Данных под сервер.

Хорошо, мы разобрались с тем, что тут лежит. Допустим, ты нашел какой-то файлик с кодом и решил в нем что-то поменять, скажем, урон у дубинки СБ - одно число. Скомпилировал билд, запустил у себя локальную версию - все хорошо. Далее ты хочешь сделать так, чтобы эти изменения попали на сервер - как ты их будешь передавать?

Можно, конечно, взять этот файлик, отправить владельцу сборки на GitHub'e, чтобы он полностью заменил файл. Также, например, можно попросить его заменить все самому в конкретной строчке, но чем больше будет количество изменений и людей, которые их вносят - тем сложнее будет со всем эти справляться. Тут приходит на помощь Git.

Тут важно отличать две вещи - Git и GitHub. Первое - это обычная маленькая программа для сохранения истории изменений кода, а второе - это интернет-портал, который позволяет хранить у себя твои исходные коды.

Что делает Git? По сути, он сравнивает исходную версию всех файлов до изменений с тем, что получилось в итоге и создает список изменений - diff (от слова difference). Далее он помогает зафиксировать эти изменения и сохранить со своим описанием в специальном архиве изменений, в подпапке .git. Зафиксировав изменения, их можно будет откатывать, восстанавливать, сливать и делать с ними прочие непотребства, не беспокоясь о том, что твоя работа куда-то пропадет - вся история изменений останется в архиве и ее всегда можно будет восстановить. Более того, любой другой человек может прийти и посмотреть всю историю работы со сборкой. И это еще не все, git позволяет синхронизировать твой локальный архив изменений с другими архивами, которые расположены у других разработчиков на компьютерах, или, например, на GitHub'e.

То есть, с помощью Git, ты можешь зафиксировать свое изменений кода и создать, так называемый, commit - один набор изменений файлов. Этот коммит сохранится в историю в твоем локальном архиве, как последнее изменение сборки, после чего можно будет синхронизировать свой архив с архивом игрового сервера на GitHub. Как только архив изменений на GitHub обновится - изменения применятся к сборке сервера и, после компиляции и обновления сервера педалями, дубинка станет наносить новый урон.

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