Вверху: Упрощенное представление игровых объектов, действующих в среде Trainz.
Требующиеся знания
Этот раздел и другие части справочника, относящиеся к сценариям,
предполагают знание программирования. Для тех, кто желает писать свои
собственные сценарии, как минимум, требуется понимание языков
программирования третьего поколения - логических конструкций, простых
типов данных (целое, вещественное и т.д.), строк, булевой логики,
переменных, области видимости, операторов, циклов, функций (аргументы и
возвращаемые значения) и структур данных.
Компилятор Auran Game Script (GS) использует синтаксис, очень похожий на синтаксис Cи/Cи++ и Явы, так что знание одного из этих языков очень поможет для начала. Те, кто не знаком с Cи/Cи++, но знают другой язык программирования. например, Паскаль, Модулу-2 или Перл, не должны расстраиваться, поскольку это языки с похожими концепциями и перейти от них к GS не должно быть очень трудно.
Окажется полезным, но не требуется в обязательном порядке, понимание основ теории объектного программирования и таких концепций, как инкапсуляция, наследование и полиморфизм. Кроме этого, будет очень полезным понимание базовых основ потоков и функций обратного вызова.
Сценарии прикреплены к отдельным ресурсам, а не выполнены в виде большого куска кода, выполняемого последовательно. Таким образом ресурсы со сценариями могут быть использованы в других сессиях. Повторно используя уже готовые ресурсы, непрограммист может создавать свои собственные сессии. Если бы код хранился в виде одной последовательной программы, он был бы намного менее портируемым.
Определение сценария
Код сценария определяется в исходном файле .gs, который должен быть
расположен в том же каталое, что и ресурс, с которым связан данный сценарий.
Тогда Trainz будет знать, где найти исходный текст сценария. В
файле config.txt ресурса должны быть установлены два
параметра. Например:
script "<имя файла>" class "<имя класса>"
Параметр script определяет имя исходного файла
.gs для ресурса (без расширения
.gs), а class - это имя главного класса сценария.
Этот класс должен быть унаследован от GameObject, а его код должен находиться в
указанном исходном файле. В дополнение к главному классу сценария в
исходном файле могту быть определены и другие классы.
Например, в сценарии для завода может быть использован класс, наследующий от класса Industry. Вообще говоря, сценарий может быть написан для любого ресурса, для которого определен GameObject.
Сценарии правил
Сценарии правил можно считать особым типом сценариев из-за их связи с
сессией. Правила похожи на сценарии других типов за одним исключением -
они не связываются с конкретным ресурсом вроде завода или единицы
подвижного состава,а существуют сами по себе, как несвязанный независимый ресурс.
Как работает сценарий правила, какие данные конфигурации он содержит, как они устанавливаются в Топографе - все это зависит от того, как написан сам сценарий.
Компиляция и отладка сценариев
В TRS2004 нет необходимости компилировать исходные файлы
сценариев вручную, поскольку Trainz обрабатывает их
автоматически при запуске. Но программист может и сам откомилировать свое
файлы, чтобы проверить их на ошибки до запуска самой игрой. Так можно
убедиться, что код не содержит синтаксических ошибок. Если делается
попытка использовать ресурс, содержащий ошибочный сценарий, появляется
сообщение об ошибки, а данный ресурс не будет нормально работать, пока
пользователь не остановит игру и не запустит ее заново, исправив код
сценария.
Для компиляции файла .gs вручную с целью проверки его
на ошибки, убедитесь, что каталог \Trainz\bin
находится в текущем пути и введите gsc -c
<имя-файла> в командной строке, находясь в каталоге
ресурса (то есть там, где расположен исходный текст сценария). Программа
gsc.exe откомпилирует файл
.gs в файл байт-кода .gsl. Если в файле
.gs будут обнаружены ошибки, компилятор напечает их
вместе с соответствующими номерами строк.
\Trainz\JetLog.txt) и точное размещение операторов
вывода вроде Interface::Print() будет удачным началом отладки
неправильно работающего сценария.
.gs, расположенных в каталоге
\Trainz\scripts или файлов
.gsl в
\Trainz\libraries.
Самое большое отличие заключается в самой модели исполнения сценария. У
него нет одной определенной точки входа, подобной главной функции старых
сценариев, которые требовали, чтобы программист определил класс Scenario с функцией
main(), являющейся единственной точкой входа, очень
похожей на функцию main() в C/C++. Это может
вызвать недоумение: откуда же начинать написание кода.
В среде сценариев создаются экземпляры объектов, представляющих такие ресурсы Trainz, как локомотивы, заводы и т.д. Если у ресурса есть сценарий, Trainz создаст экземпляр класса сценария. С этого моменты данный объект будет существовать в мире Trainz и сможет получать/посылать сообщения, а также взаимодействовать с другими объектами игры.
Использование потока для запуска объекта требуется не всегда. Это обычно требуется для предприятия, но для единицы ПС это не очень разумно, поскольку если для каждой единицы данного типа, поставленной на маршруте, будет создан отдельный поток, общий счет потоков может пойти на десятки и даже сотни. Поскольку скриптовые языки вроде GS интерпретируются, нагрузка может оказаться слишком большой. Поскольку для многих ресурсов имеются функции обратного вызова, потоки сценария можно удерживать в разумных пределах.
Вверху: Упрощенное представление игровых объектов,
действующих в среде Trainz.
Как показано на диаграмме вверху, объекты сценариев (равно как и обычные игровые объекты) могут взаимодействовать в среде Trainz. Взаимодействие выполняется с помощью сообщений, вызовов функций, а также с помощью других методов, например, функций обработки сообщений.
В данном упрощенном примере все объекты связываются друг с другом с помощью диспетчера Trainz. Объекты предприятий и правил имеют собственные потоки, а сценарии для отдельных единиц ПС запускаются через функции обратного вызова.
Это сложная тема, и возможно вам не все в ней понятно. Вероятно, тщательное изучение учебников поможет вам разобраться
