Расширение линейки доступных кораблей и создание нового сценария стартаФормулируем задачуКак минимум - расширить линейку доступных геймеру кораблей.
В идеале - открыть возможность выбора корабля на старте, что стимулирует геймера исследовать альтернативные варианты начала карьеры.
Обязательные требования к пакету:Пакет должен быть интегрирован в существующее пространство решений.
Как минимум - не конфликтовать с существующими решениями.
В идеале - легкий емкий код, максимально использующий существующие решения, но способный работать автономно.
В дефолтном наборе есть корабли, геймеру недоступные. Это, в частности, все системные истребители, а также челноки - Transporter, Shuttle и Worm. Практически у всех недоступных геймеру кораблей дефолтного набора есть общая особенность - они не имеют гипердрайва и стало быть для рейсов между системами непригодны. А так как основная экономическая активность в дефолтном Оониверсуме сосредоточена именно в рейсах между системами, то и для геймера на таком корабле возможности крайне ораниченные (не будем рассматривать пиратство на торговых линиях как серьезную альтернативу - шалости с законом сходят с рук лишь на хорошо оснащенном корабле и лишь при возможности покинуть систему, когда репутация станет слишком обременительной).
Пакеты, создающие внешние порты помимо единственной главной станции, эту ситуацию изменили - в Оониверсуме сложился рынок внутрисистемных перевозок. И теперь старт на корабле, не имеющим гипердрайва, из патовой ситуации превращается в интересный альтернативный сценарий. Не скажу, чтобы такой сценарий стал мейнстримом: геймер-торопыга предпочитает на одном месте долго не засиживаться. Но определенный интерес к нему есть, vasig не даст соврать.
Итак, sanata превратил в игровые два корабля дефолтного набора, по умолчанию геймеру недоступные - Transporter и Worm. Задачу он, правда сформулировал по своему "исследовать игровой мир Stranger's World", так что кораблики у него получились нереально шустрые и вместительные в сравнении с дефолтными прототипами. Но об этом в свое время, а пока разберемся с тем, как реализована задача.
В принципе если не глядеть в код, а воспринимать пакет как черный ящик (что рядовой геймер в общем и делает), то задача решена и как минимум, и в идеале. Два новых корабля доступны на верфи, ими можно управлять, а Worm можно выбрать как стартовый кораблик. Но вот если заглянуть в код, то становится ясно, что пакет нуждается в основательной переделке.
sanata скопировал в свой shipdata.plist словари oolite_template_transporter и oolite_template_worm из дистрибутивного ресурсного файла, дописал в них параметр custom_views, изменил в них же значения ТТХ кораблей (максимальную скорость, тяговооруженность, грузовместимость) и создал игровые варианты transporter-player и worm-player, сославшись на эти перенастроенные прототипы. Технически решение сработало, но в нем есть очень серьезный минус.
Словарь oolite_template_worm, к примеру - это шаблон, на основе которого разработчик может быстро создать модификацию корабля, не изобретая велосипед. Сам шаблон должен оставаться в исходном виде. По двум причинам.
а) шаблон oolite_template_worm, скопированный в пакет и в нем отредактированный, получает приоритет над шаблоном в ресурсной папке Config дистрибутива. В результате перенастройка шаблона затрагивает не только Worm в данном пакете, что хотел сделать разработчик, но и все корабли этого класса - как дистрибутивные, так и модификации, которые были сделаны другими разработчиками на базе шаблона. То есть если sanata объявил в своем пакете скорость корабля 310 и грузоподъемность 10 - все корабли Worm в Оониверсуме получают эти ТТХ, как дефолтные, так и модификации - если разработчики модификаций не объявили явно иные параметры.
б) шаблон гарантирует, что при обновлении версии дистрибутива, к примеру с 1.82 до 1.84, возможные перенастройки исходного словаря будут автоматически захвачены всеми модифицированными на основе шаблона кораблями. В каждой версии Оолита появляются новые интересные возможности и словари с описаниями дефолтных кораблей дорабатываются. Разрыв шаблона гарантирует, что пакет не будет использовать эти новые возможности и застрянет в прошлом.
Так как поступить правильно?
А вот так.
Смотрим внимательно дистрибутивный shipdata.plist. Там уже объявлен корабль, унаследовавший свойства прототипа. Копируем в наш shipdata.plist этот словарь и прописываем в нем нужные настройки - это гарантирует, что базовый шаблон остался без изменений:
Код:
"worm" =
{
like_ship = "oolite_template_worm";
// и сюда вписываем все нужные перенастройки
}
Конкретно в случае с кораблем Worm в новый словарь пришлось добавить описание внешних видов custom_views (так как корабль не проектировался как пилотируемый геймером, разработчики не предусмотрели возможность взгляда на корабль в режиме внешней камеры). Здесь я использовал кусок кода из пакета
Start Choices для транспортера - настройки в пакете sanata не слишком удачны, корабль при обзоре сзади-сбоку частично уходит под обрез экрана (возможно, это особенность широкого монитора с аспектом 16:9). Я удалил из описания корабля все параметры, которые я не планирую как-либо редактировать в обозримом будущем. Зачем, к примеру, еще раз описывать расположение факелов выхлопа exhaust или карты текстур materials, если они ничем не отличимы от прототипа? Словарь полегчал примерно на треть. На производительности системы это никак не скажется - Оолит при запуске все равно собирает все файлы shipdata.plist в единый файл и дубликаты параметров удаляются, но читать короткие словари ленивому кодеру удобней, да и геймеру проще найти тот параметр, которорый ему давно не терпелось перенастроить. Но если вы не очень ориентируетесь в содержании словаря, можете сдублировать в него всё содержимое шаблона и оставить как есть.
Ну и теперь создаем корабль игрока:
Код:
"worm-player" =
{
like_ship = "worm";
roles = "player";
// вот здесь можно прописать параметры, которые будут присущи только кораблю игрока
};
Новый кораблик готов. Осталось прописать его покупку на верфи, что sanata тоже сделал в целом правильно - я в основном перешерстил список комплектного оборудования (к этому моменту вернемся позже).
Ладно, а как предложить этот кораблик на старте вместо дефолтной Кобры Марк Три?
В недрах ресурской папки дистрибутива, куда геймеру лазить нефиг ибо маздай, есть папка Scenarios, в которой находятся три документа с расширением oolite-save. Да, мой юный Джеймсон. Технически сценарии - это сэйвы с сохраненными особыми настройками. Один из них, oolite-standard.oolite-save, как раз запускает всем вам знакомый сценарий - Кобра Марк Три с импульсным лазером и тремя ракетами, 100 кредов на счету, система Лэйв. sanata его скопировал, поместил в папку Scenarios своего пакета и заменил дефолтную Кобру Марк Три на Ворм. Следует ожидать, что этот файл, находясь в папке внешнего пакета, получит приоритет над файлом в дистрибутиве. Так они и происходит. Но такое решение создает новую большую проблему. Геймер не имеет возможности выбора между стартом на Кобре Марк Три и стартом на Ворме - он может получить только Ворм, пока не удалит пакет.
А теперь о самом неприятном моменте.
Есть очень интересный пакет
Start Choices, в котором как раз реализован выбор между несколькими стартовыми сценариями. И кстати говоря, транспортер там уже есть. Причем именно что нормальный транспортер со стандартными ТТХ.
И вот когда установлены оба эти пакета, получается нехорошо. Ворм в стартовом меню не виден, поскольку этот сценарий явно не прописан. Это бы полбеды. Но когда ничего не подозревающий геймер выбирает стандартный старт (экран в этот момент показывает вращающуюся Кобру Марк Три, как положено, текст тоже ясно говорит, что будет выбрана Кобра Марк Три), вместо oolite-standard.oolite-save с Коброй подгружается модифицированный сэйв и - опаньки...
Вы вместо Кобры Марк Три получили Ворм.
Решить этот конфликт можно двумя путями.
Можно перенести модифицированный сэйв в папку с сэйвами, переобозвать его как-нибудь по человечески и загрузить как любой обычный сэйв через меню F2.
А можно явно прописать новый корабль в меню стартовой загрузки. И что приятно, ничего в пакете
Start Choices править не надо.
Создаем в папке Config нашего пакета два новых файла - scenarios.plist и descriptions.plist. В словаре scenarios.plist пишем примерно вот что:
Код:
(
{
"file" = "sc-expeditor.oolite-save";
"name" = "[sc-expeditor-name]";
"description" = "[sc-expeditor-description]";
"model" = "worm-player";
}
)
И в словаре description.plist примерно так:
Код:
{
"sc-expeditor-name" = "Expeditor Start";
"sc-expeditor-description" = "Start with a Worm and 100 credits at Lave station. The ship is equipped with a fuel injector and PLC equipment only, so try to search business on a bottom of atmosphere.";
}
Запускаем игру, выбираем опцию Start New Commander и - yes, baby! Любуемся экраном с крутящейся моделью Ворма и кратким описанием сценария. После чего выбираем сценарий и начинаем игру в новом корабле.
Но погодите!
Нужен ли в Оониверсуме Ворм со скоростью 310 и грузоподъемностью 10 тонн?
Поставлю вопрос немного иначе. Если в Оониверсуме геймеру доступен такой Ворм, в чем тогда смысл существования более тихоходной Кобры Марк Один с аналогичной грузоподъемностью за втрое большую цену? А также крошки Аддера за вдвое большую?
Видите ли, сэр, Кобра Марк Один, имея гипердрайв, занимает свой сегмент рынка межсистемных перевозок. Исследования в фокус-группах подтвержают большой интерес к быстроходному легкому шаттлу для внутрисистемных перевозок, сэр.
Кто пустил маркетолога на техническое совещание? Вывести!
Продолжим.
Так вот. Меня не интересует мнение геймеров, которым нужно как можно больше и подешевле. Даже в том случае, если 97% геймеров попадут в эту категорию. Меня интересует в первую очередь мнение тех 3% геймеров, которые предпочитают вызов сбалансированного Оониверсума.
sanata предложил геймеру корабль для быстрого знакомства с моим игровым миром. Я тронут, но для этого в
Start Choices уже есть Кобра Марк Три, оснащенная топливным инжектором и с горным лазером в кормовом порту. Корабль так и позиционируется как решение для геймера, пылающего нетерпением побыстрее окунуться в гущу событий. И правда, прокачать этот кораблик до "железной задницы" можно шутя. А нам нужен корабль для отыгрыша альтернативного хардкорного сценария.
Я тут прикинул со своей инженерной группой. Увеличить грузоподъемность с изначальных 2 т до 5 т можно - есть опыт Worm Miner. В дефолтном Оониверсуме есть опыт глубокого апгрейда Боа до Боа Круизер с увеличением скорости с 240 до 312 - то есть на 30%. Моя инженерная группа увеличила скорость Фер-де-Ланса с 300 до 375, это опять же на 25%. Если взять эти цифры за основу, можно увеличить скорость Ворма со 110 до 140, Транспортера со 100 до 120 и Орбитального Шаттла с 80 до 100. Эти цифры и возьмем за основу, а маркетологи идут лесом, стуча копытцами.
Вносим соответствующие настройки в словарь (я сделал это в отдельном файле shipdata-overrides.plist).
При создании любого корабля или модификации существующего крайне полезно отчетливо представлять его роль и место в Оониверсуме. sanata оснастил свой корабль PLC, стало быть это легкий орбитальный челнок. Принято, возражений нет. Отличная идея: дать геймеру возможность начать карьеру не с рейсов между системами, а с каботажных рейсов на линии земля-орбита. Определяемся со стартовой конфигурацией корабля по принципу "все нужное и ничего лишнего". Система PLС и нужные для нее компоненты - однозначно да, астрокомпас и сборщик топлива убираем: на орбите они не нужны.
Корректируем файл сценария sc-expeditor.oolite-save - удаляем из него лишнее оборудование. Ту же операцию проводим с файлом shipyard.plist. Вот как выглядит фрагмент кода в shipyard.plist, в котором перечислено комплектное оборудование, которое геймер получит уже установленным при покупке корабля на верфи:
Код:
"standard_equipment" =
{
extras =
(
"EQ_FUEL_INJECTION",
"EQ_DOCK_COMP",
"EQ_PLANETFALL",
"EQ_HEAT_SHIELD"
);
"forward_weapon_type" = "EQ_WEAPON_PULSE_LASER";
missiles = 0;
};
Перечислять это же оборудование как optional_equipment не нужно: optional_equipment - это оборудование, которое может предлагаться дополнительно.
В папке Config моего пакета кроме обязательных shipdata.plist и shipyard.plist есть два необязательных файла - shipdata-overrides.plist и shipyard-overrides.plist. Почему я прописал настройки ТТХ для новых кораблей именно в shipdata-overrides.plist?
Все дело в том, что shipdata-overrides.plist запускается после загрузки всех shipdata.plist независимо от того, где они расположены, и перекрывает их настройки. Такой способ натянуть одеяло на себя гарантирует, что все стандартные Вормы в Оониверсуме будут иметь увеличенную до 140 скорость (модифицированные в посторонних пакетах Вормы, объявленные под другим именем, сохранят скорость, прописанную в шаблоне oolite_template_worm, если автор пакета не объявил другое значение). Аналогичная логика действует в отношении условий приобретения кораблей, прописанных в пакетах shipyard.plist и shipyard-overrides.plist.
Пакет технически готов. Но чтобы довести его до игрового вида, необходимо вложить на его корневой уровень три документа:
requires.plist - содержит информацию о совместимости с версиями Оолита.
info.plist - паспорт пакета
readme.txt или readme.rtf - содержит информацию для геймера: лицензию, краткое описание, инструкцию по установке, возможные проблемы и несовместимости, историю разработки и так далее.
То есть получается примерно такая структура:
Extra Playable Ships 0.1.oxp Config
descriptions.plist
scenarios.plist
shipdata.plist
shipyard.plist
info.plist
readme.txt
requires.plist
Scenarios
И давайте договоримся раз и навсегда.
С того момента, как пакет получил статус игрового, он должен сопровождаться и документироваться как положено. То есть любое изменение кода должно сопровождаться изменением номера версии и отражаться в документации.
Даже если пакет не имеет статус игрового, его нормальная сборка обязательна.