Disinterpreter
02.08.2014, 16:26
Предисловие: Это мой второй урок на данном портале, первый был конкретно про самп, однако в этом я отбросил все свои принципы и решил написать уникальный, в своем роде, урок.
Итак, Вы решили сделать игровой мод для паблика, но думаете, как не упасть в грязь лицом, и вот, выкладывая его на первый попавшийся форум в архиве через rghost, вы надеетесь, что все пошло прекрасно?
Но нет, Вы уже упали в грязь лицом! В этой статье я хочу до вас донести, как лучше всего сделать гейммод для паблика.
Научитесь работать с Git/SVN!
Работать с системами контроля версий очень важно и полезно.
Лично мне, для этого дела нравится https://github.com, но можно использовать https://bitbucket.org/.
Там Вам нужно создать репозиторий с Вашим модом и определиться с лицензией (об этом чуть ниже), а так же научиться делать коммиты (изменения в репозитории), пулы (забирать данные в свой репозиторий), мержи (объединять данные ветвей) и прочее.
Подробнее можно почитать здесь: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/
Или здесь: http://xakep.ru/articles/61200/ (эта статья мне понравилась).
Для разных версий гейммода, лучше создавать разные ветви.
Важное замечание: На подобные сайты вместе с Вашим кодом крайне
нежелательно заливать бинарные файлы, будь то ".exe", ".dll" или ".amx".
Их можно залить отдельно в соответствующий раздел "tags" или "Release".
Вы спросите, какой же для Вас плюс от svn или git?
На самом деле Вы можете помочь себе откатом коммитов или чем-нибудь ещё, да и так проще показать свой код и уровень навыков :)
Кроме того, люди могут присылать Вам патчи (про это почитать здесь (http://habrahabr.ru/post/125999/)).
Структура игрового режима.
Если Вы делаете мод для паблика, то крайне нежелательно писать всё в одном файле, ибо только вам известно, что и где находится.
А другие пользователи просто увидят кашу из 60-80к строк. Поэтому лучше разделить всё на папки и файлы.
Причем, касаемо деления папок, лучше отделить ядро игрового режима от его оболочки.
Стиль кода.
Делая мод для паблика, разработчик показывает его всему сообществу данного мультиплеера, поэтому код должен быть слажен и иметь чётко определенный стиль.
Лично я люблю использовать стиль отступов Олмана (BSD) (http://ru.wikipedia.org/wiki/%D0%9E%D1%82%D1%81%D1%82%D1%83%D0%BF_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29#.D0.A1.D1.82.D0.B8.D0.BB.D1.8C_.D0.9E.D0.BB.D0.BC.D0.B0.D0.BD.D0.B0), верблюжий стиль кода (UpperCamelCase) (http://ru.wikipedia.org/wiki/CamelCase) у функций/методов и венгерскую нотацию (http://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BD%D0%B3%D0%B5%D1%80%D1%81%D0%BA%D0%B0%D1%8F_%D0%BD%D0%BE%D1%82%D0%B0%D1%86%D0%B8%D1%8F) для префиксов переменных.
Кроме того, несколько правил оформления приведены здесь (http://pro-pawn.ru/showthread.php?8347).
Имена переменных желательно давать только на английском, без транслита.
Комментарии.
Этот пункт довольно очевиден, пишите больше комментариев (желательно на английском языке) особенно у своих, самописных функций.
Лицензия.
Для своего проекта нужно выбрать лицензию и подписать свое авторство.
Тут я ничего советовать не буду, за исключением этого: http://choosealicense.com/ и этого http://choosealicense.com/licenses/.
Документация.
В документации нужно написать всё о вашем коде, ВООБЩЕ ВСЁ, т.е нужно написать принципы работы, что где лежит, как это установить, как пользоваться.
На сайте GitHub документацию можно заполнить в разделе "Wiki" вашего репозитория (на Bitbucket аналогично).
Багтрекер.
Багтрекер - место куда люди пишут предложения и сообщают о недочетах/багах.
Желательно туда записать ваши планы (вдруг кто захочет продолжить ваше дело) ну и прислушиваться к пользователям.
На сайтах GitHub и Bitbucket эту роль выполняет раздел "Issues".
Учитесь у других!
Желательно смотреть другие проекты, даже те, которые вообще не подходят к вашей тематике.
Там всегда есть чему поучиться. Например в репо CyanogenMod (https://github.com/CyanogenMod/) мы найдем кучу ветвей (Branches), которые отражают все версии Android.
С наилучшими пожеланиями, Disinterpreter (http://pro-pawn.ru/member.php?2417).
Редактировал Daniel_Cortez (http://pro-pawn.ru/member.php?100).
https://i.creativecommons.org/l/by/3.0/88x31.png (http://creativecommons.org/licenses/by/3.0/)
Это произведение доступно по лицензии Creative Commons «Attribution» 3.0 (http://creativecommons.org/licenses/by/3.0/).
Итак, Вы решили сделать игровой мод для паблика, но думаете, как не упасть в грязь лицом, и вот, выкладывая его на первый попавшийся форум в архиве через rghost, вы надеетесь, что все пошло прекрасно?
Но нет, Вы уже упали в грязь лицом! В этой статье я хочу до вас донести, как лучше всего сделать гейммод для паблика.
Научитесь работать с Git/SVN!
Работать с системами контроля версий очень важно и полезно.
Лично мне, для этого дела нравится https://github.com, но можно использовать https://bitbucket.org/.
Там Вам нужно создать репозиторий с Вашим модом и определиться с лицензией (об этом чуть ниже), а так же научиться делать коммиты (изменения в репозитории), пулы (забирать данные в свой репозиторий), мержи (объединять данные ветвей) и прочее.
Подробнее можно почитать здесь: http://www-cs-students.stanford.edu/~blynn/gitmagic/intl/ru/
Или здесь: http://xakep.ru/articles/61200/ (эта статья мне понравилась).
Для разных версий гейммода, лучше создавать разные ветви.
Важное замечание: На подобные сайты вместе с Вашим кодом крайне
нежелательно заливать бинарные файлы, будь то ".exe", ".dll" или ".amx".
Их можно залить отдельно в соответствующий раздел "tags" или "Release".
Вы спросите, какой же для Вас плюс от svn или git?
На самом деле Вы можете помочь себе откатом коммитов или чем-нибудь ещё, да и так проще показать свой код и уровень навыков :)
Кроме того, люди могут присылать Вам патчи (про это почитать здесь (http://habrahabr.ru/post/125999/)).
Структура игрового режима.
Если Вы делаете мод для паблика, то крайне нежелательно писать всё в одном файле, ибо только вам известно, что и где находится.
А другие пользователи просто увидят кашу из 60-80к строк. Поэтому лучше разделить всё на папки и файлы.
Причем, касаемо деления папок, лучше отделить ядро игрового режима от его оболочки.
Стиль кода.
Делая мод для паблика, разработчик показывает его всему сообществу данного мультиплеера, поэтому код должен быть слажен и иметь чётко определенный стиль.
Лично я люблю использовать стиль отступов Олмана (BSD) (http://ru.wikipedia.org/wiki/%D0%9E%D1%82%D1%81%D1%82%D1%83%D0%BF_%28%D0%BF%D1%80%D0%BE%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5%29#.D0.A1.D1.82.D0.B8.D0.BB.D1.8C_.D0.9E.D0.BB.D0.BC.D0.B0.D0.BD.D0.B0), верблюжий стиль кода (UpperCamelCase) (http://ru.wikipedia.org/wiki/CamelCase) у функций/методов и венгерскую нотацию (http://ru.wikipedia.org/wiki/%D0%92%D0%B5%D0%BD%D0%B3%D0%B5%D1%80%D1%81%D0%BA%D0%B0%D1%8F_%D0%BD%D0%BE%D1%82%D0%B0%D1%86%D0%B8%D1%8F) для префиксов переменных.
Кроме того, несколько правил оформления приведены здесь (http://pro-pawn.ru/showthread.php?8347).
Имена переменных желательно давать только на английском, без транслита.
Комментарии.
Этот пункт довольно очевиден, пишите больше комментариев (желательно на английском языке) особенно у своих, самописных функций.
Лицензия.
Для своего проекта нужно выбрать лицензию и подписать свое авторство.
Тут я ничего советовать не буду, за исключением этого: http://choosealicense.com/ и этого http://choosealicense.com/licenses/.
Документация.
В документации нужно написать всё о вашем коде, ВООБЩЕ ВСЁ, т.е нужно написать принципы работы, что где лежит, как это установить, как пользоваться.
На сайте GitHub документацию можно заполнить в разделе "Wiki" вашего репозитория (на Bitbucket аналогично).
Багтрекер.
Багтрекер - место куда люди пишут предложения и сообщают о недочетах/багах.
Желательно туда записать ваши планы (вдруг кто захочет продолжить ваше дело) ну и прислушиваться к пользователям.
На сайтах GitHub и Bitbucket эту роль выполняет раздел "Issues".
Учитесь у других!
Желательно смотреть другие проекты, даже те, которые вообще не подходят к вашей тематике.
Там всегда есть чему поучиться. Например в репо CyanogenMod (https://github.com/CyanogenMod/) мы найдем кучу ветвей (Branches), которые отражают все версии Android.
С наилучшими пожеланиями, Disinterpreter (http://pro-pawn.ru/member.php?2417).
Редактировал Daniel_Cortez (http://pro-pawn.ru/member.php?100).
https://i.creativecommons.org/l/by/3.0/88x31.png (http://creativecommons.org/licenses/by/3.0/)
Это произведение доступно по лицензии Creative Commons «Attribution» 3.0 (http://creativecommons.org/licenses/by/3.0/).