Всем прива и все такое!

Тут вкратце изложу основные правила создания шардов.

ЧАСТЬ № 1.

ОСНОВНОЕ  ПРАВИЛО:
альфа: ТЕГ И РЕСРЕФ КАСТОМНЫХ РЕСУРСОВ ДОЛЖНЫ БЫТЬ УНИКАЛЬНЫ И ИМЕТЬ ОДИНАКОВОЕ ЗНАЧЕНИЕ (НАПРИМЕР: ТЕГ "IT_KKS_ELC" ИМЕЕТ РЕСРЕФ "it_kks_elc").
бетта: КАЖДЫЙ РАЗРАБ ДОЛЖЕН ВЫБРАТЬ ДЛЯ СЕБЯ ИДЕНТИФИКАТОР ИЗ 3-Х СИМВОЛОВ (Например у меня ник Keks, И МОЙ ИДЕНТИФИКАТОР "KKS" ИЛИ "kks", В ЗАВИСИМОСТИ ОТ ТОГО, ГДЕ ОН ИСПОЛЬЗУЕТСЯ)
гамма: КАЖДЫЙ ЧЛЕН КОМАНДЫ ДОЛЖЕН ДОВОДИТЬ ДО СВЕДЕНИЯ ОСТАЛЬНЫХ ЧЛЕНОВ О ПЛАНЕ СВОЕЙ РАБОТЫ, С ЦЕЛЬЮ ИЗБЕЖАНИЯ ДВОЙНОЙ РАБОТЫ В ХОДЕ КОРРЕКТИРОВКИ ГОТОВЫХ СИСТЕМ.
дельта: ЗА СВОД ВСЕХ ХАКОВ, 2ДА, ТЛК (т.е. за свод всех кастомных ресурсов) ДОЛЖЕН ОТВЕЧАТЬ 1 ЧЕЛОВЕК, С ЦЕЛЬЮ ИЗБЕЖАНИЯ ДУБЛИРОВАНИЯ ДАННЫХ.

1) ПРАВИЛО ХАКА.
1.1. Прежде чем добавлять хак-пак в модуль, разработчик должен убедиться в работоспособности ВСЕХ компонентов входящих в хак-пак. Если какая-либо часть хака (контента, системы, скрипта и т.п.) не работает как должно, то эта часть должна быть удалена из хака или заменена рабочей версией.
1.2. Каждый хак-пак подключенный к модулю должен иметь описание входящих в него систем и ресурсов, например, расшифровка изменений 2да, название файлов и их содержание (актуально для плейсов и итемов).
1.3. Хак НЕ должен содержать неиспользуемые ресурсы. Прикрепить неиспользуемые ресурсы не сложно, а вот разобрать в "мусорке" хака достаточно гемморно и сложно.
1.4. Длина названий файлов в хак-паке, как и самого хак-пака не должно превышать 16 символов без учета точки и расширения.

2) ПРАВИЛО ТЛК.
2.1. Кастомный ТЛК ДОЛЖЕН быть описан в отдельном файле (не важно в таблице екселя, как у меня или в тхт файле). Я разношу тлк в ексель таблицу, т.к. я могу в любой момент получить значение строки, проставляемую в нужные места (2да или скрипты), а также вижу к чему относится данная запись (например название спела или описание спела).
2.2. Кастомный ТЛК и его описание должны быть доступны всем разработчикам, если вам необходимо внести изменения/дополнения в кастомный тлк, то необходимо, В ОБЯЗАТЕЛЬНОМ ПОРЯДКЕ ИЗВЕСТИТЬ ВСЕХ РАЗРАБОТЧИКОВ О ЗАРЕЗЕРВИРОВАННЫХ СТРОКАХ.

3) ПРАВИЛО МАПЕРА.
3.1. При создании арены необходимо помнить, что название и тег арены желательно делать уникальными.
3.2. Тег НЕ системной и НЕ тестовых арен рекомендуется делать по формату:
NNNХХХУУУZZZ0000, где:
NNN - уникальный идентификатор разработчика.
ХХХ - код арены относительно уровня земли, OVE (Over The Earth) - надземье, UNG (UNderGround) - под землей. Должен совпадать с настройками в свойствах арены.
УУУ - код арены относительно помещения OUT (OUTside) - снаружи, INS (INSide) - в помещении. Должен совпадать с настройками в свойствах арены.
ZZZ - код условного региона к которому относится арена, например город с названием "SITy" (SIT), восточный лес "EAst Wood" (EAW);
0000 - номер арены в данном регионе с заданными NNNXXXYYYZZZ параметрами.
3.3. Тег системной или тестовой должен быть уникальным, в название формируется по формату _Sys_ или _Test_, желательно совпадение тега и названия системной или тестовой локи.
3.4. Мапер должен иметь блок схему регионов, т.е. где относительно друг друга находятся региона и в какие регионы есть пути из соседних.
3.5. Мапер должен иметь блок схему региона, который он делает, удобнее всего формировать его в екселе с указанием всех возможных переходов, название локи и ее тег.
3.6. Размер арены не должен превышать 32*32, для стабильной работы не рекомендуется делать арены, размером более 24*24.
3.7. Не рекомендуется размещать на арене более 1000 объектов или более 400 активных объектов (плейсы, нпс, мобы, эффекты, звук и т.п.).
3.8. Арена не должна содержать "битых плейсов" или "мертвых зон" в которых может застрять движущийся объект.
3.9. Все тригеры должны быть видны в тулсете и доступны для активации игроком, нпс или мобом (т.е. если у вас тригер не правильной формы, убедитесь, что на него реально попасть без проблем, это особенно актуально для тригеров переходов).
3.10. Все монстры и НПС не должны иметь возможность (точки маршрута) переходить через локации, если иное не предусмотрено по системе или скрипту.
3.11. Вид арены и ее содержание должны соответствовать концепции шарда.