+- Город Джунов (https://www.gipat.ru/forum)
+-- Форум Аддон для Проклятых Земель (https://www.gipat.ru/forum/forum-20.html)
+--- Форум Программирование (https://www.gipat.ru/forum/forum-6.html)
+--- Темы: Рассуждения: О скриптовых командах (/thread-661.html)
Рассуждения: О скриптовых командах - sun - 30.01.2002
ЧЕРНОВИК
Некоторые выдержки из классификации терминов и понятий команд, процедур и функций для скрипитов.
Как бы рассуждения вслух, себе поднос….
В ПЗ существует более 200 команд для скриптов, четвертая часть которых вообще игрой не используются. Далеко не все команды могут работать правильно на предельных значениях, а некоторые из них представляют собой только заготовки процедур из нереализованных задумок. Также есть процедуры написанные, практически, только для одного квеста, как, например: SetWaterLevel. Эта команда может динамически, во время игры, изменять ландшафт на карте, влияя на координату Z отдельной группы областей текстур воды.
В именах процедур предназначенных для скрипта, заложены смысловые понятия их принадлежности к классам, группам, свойствам или типам возвращаемых данных, относящихся к задуманной разработчиками ПЗ структуре самой игры. С одной стороны - это удобно, а с другой - может ввести в некоторые заблуждение, так как разработчики игры не особо трепетно побеспокоились о точности классификации имен процедур к полному завершению работ по созданию игры. Хотя, есть и иное мнение, что в данном случае добиваться строгого соответствия терминов к понятиям, нет необходимости, так как мы разбираем откомпилированную игру, а не конструктор уровней. К тому же, на сегодня уже существует сложившийся стереотип представления этих процедур, функций (и т.п.) от сторонних деятелей. Однозначно классифицировать все скриптовые команды только по их имени нельзя. Возможно, что причина кроется в истории создания самой игры. Многим, наверное, известно, что однажды игра переделывалась полностью, то есть проект и работы по созданию игры были полностью остановлены, а сам движок Нивал переписали по-новому.
В настоящем виде в ПЗ существует как бы два глобальных уровня дипломатии, это так называемые: Party и PlayerGroupDiplomacy (Group или Player или Diplomacy). Похоже, что из-за того, что игра не писалась с самого начала по единому начальному проекту то, и имеет место некоторая путаница в терминах и понятиях, некоторых названий скриптовых процедур.
Начну монолог с набора «Party» (Партия) - это особая объединение персонажей, принадлежащих Игроку. Понятие «Игрок», следует ассоциировать непосредственно с человеком, играющим в игру. Так будет проще понять смысл этой статьи. Процедуры, работающие с группой Party написаны, как это выразится помягче,… - странновато. В некоторых процедурах, в одном параметре типа String находится как бы два параметра разделенные нетипичным сочетанием делителя – «::». В принципе такое построение, на мой взгляд, нелогично.
Я предполагаю, что второй уровень дипломатии: набор Дипломатических групп PlayerGroupDiplomacy возник несколько позже и унаследовал терминологию и понятия Player, от структуры группы Party. Вот именно поэтому, по моему мнению, и происходит главная путаница в терминологии, понятиях и классификации скриптовых команд в ПЗ.
Предлагаю вашему вниманию рассмотреть несколько функций:
063 GetPlayerUnits(nPlayerGroupDiplomacy : float) : group;
064 GetUnitOfPlayer(idPlayer* : float, nUnitOfParty: float) : object;
083 GroupSee(PlayerGroupDiplomacy : group) : group;
129 PlayerSee(nPlayerGroupDiplomacy : float) : group.
ОПИСАНИЕ ПАРАМЕТРОВ:
Object – в данном случае, возвращаемый объект функцией ¹064 - это объект персонаж - лидер или помощник которыми управляет Игрок владеющий группой Party. Игрок может иметь несколько партий одновременно, но управлять только одной. Партию можно сменить в любой момент командой:
165 SetCurrentParty(idPlayer : float, strParty : String).
Объект Player не является набором для подмножества групп Party.
Group – это группировка юнитов, объединенная в единую дипломатическую группу на игровой зоне, и только на игровой зоне и принадлежащая логическим (виртуальным) игрокам – владельцам каждой из группировок. Персонажи из всех групп Party, а не только из CurrentParty, по умолчанию, при попадании на игровую зону получают номер в наборе дипломатических групп PlayerGroupDiplomacy - 0. Группировкой под номер 0 на игровых зонах всегда управляет настоящий Игрок. Каждого из Персонажей группы Party, на игровой зоне можно переподчинить к любой другой дипломатической группировке логического игрока из набора: PlayerGroupDiplomacy. Но даже после установления различных дипломатических отношений для персонажей-помощников, от этого все равно дипломатия Party в игре будет действовать по-прежнему - персонажи-помощники не станут врагами, но поведение изменится.
Например: если установить помощнику Зака (или самому Заку) принадлежность к дипломатической группировке Врагов-монстров, то Враг-монстр, состоя в одной группировке набора «PlayerGroupDiplomacy» с Помощником, по-прежнему будет враг для Зака и будет атаковать Зака как только его увидит. И в этом случае Помощник, имея общую дипломатическую группу в наборе PlayerGroupDiplomacy с Врагом-мостром, станет атаковать нападающего на Зака Врага-монстра только в том случае, если Зак ответит атакой этому Врагу-монстру. Повторю: хотя Враг-монстр и Помощник находятся в одной дипломатической группировке! Соответственно, при соблюдении старшинства в глобальном понятии Дипломатии в ПЗ, приоритет всегда отдаётся: «Party».
Продолжение примера: в случае коллективного нападения на Зака несколькими Врагами-монстрами, Помощник самостоятельно не будет нападать на всех врагов, которые атакуют Зака, а лишь на того, которого в текущий момент атакует Зак. Так же и другие Враги-монстры атакующие одновременно Зака не будут врагами для Помощника, пока Зак не начнет атаковать очередного врага.
Дипломатия в ПЗ очень тонкая штука, поэтому следует быть очень внимательным. Можно создать весьма хитрый союз.
idPlayer*: Всегда – 0. На самом деле сюда напрашивается одиозное название параметра: «nPlayer». Параметр представляет собой объект настоящего Игрока из набора Игроки. Это параметр всегда будет равен 0, так как больше игроков в ПЗ, на этом уровне иерархии игры, нет. Нет и логических игроков, таких как в Группировке набора Дипломатических групп логических игроков: PlayerGroupDiplomacy. Возможно, что этот запрашиваемый параметр может принадлежать и к набору Партий, в этом случае параметр следует назвать: «nParty». Но в пользу idPlayer говорит то, что существование набора типа GroupParty нет и Party, добавляется прямо к объекту Player как новое свойство объекта. Операции по добавлению и удалению персонажей в Party происходит не по номеру, а в довольно странном виде, только в текстовой строке и только по имени, и в дальнейшем указатель на группу при операциях изменения группы, всегда указывает Имя группы и имя Персонажа-Лидера. Если имя Персонажа отсутствует в базе данных ресурсов игры, то персонаж появляется на игровой зоне без имени. Например, процедура:
008 AddUnitToParty(idPlaeyr, “strParty:
trPers” : String, strNameUnitRes : String) или008 AddUnitToParty(idPlaeyr, strPers : String, strNameUnitRes : String) - вторая процедура добавляет Персонажа к текущей группе. Не путать! Если нужно работать не с текущей группой или с вновь созданной, то всегда нужно указывать второй параметр как два параметра через делитель“strParty:
trPers”. Имена пресонажей: «strPers» можно найти в базе данных: «texts.res» в именах файлов после слова: «pers*».Более подробно я не буду расписывать эту процедуру, так как эта статья и так слишком перегружена вложениями. На этот момент я разобрался с переменными и и способами создания групп Party. Ещё скажу, что я думаю: что эта процедура первоначально-задуманная разработчиками игры для уровня группы дипломатии из первых ПЗ.
В заключении к описанию параметра idPlayer выскажу свое сомнение: И всё-таки, вполне может оказаться, что первый параметр в 064 функции: «nParty», настаивать на любом из вариантов не буду, досконально не проверил.
nUnitOfParty: номер персонажа в текущей Партии - Лидер (всегда = 0) или номер помощника по очередности добавления в группу Party. Функция Party не относится к классу Наборы, но обладает стандартным свойством Items и Count определяющим количество объектов в текущей группе Party.
nPlayerGroupDiplomacy: можно также назвать эту переменную как: «nPlayer», «nGroup», «nDiplomacy» - по вашему вкусу, но лучше вообще удалить из имени этой переменной слово: Player. Все Эти названия вполне приемлемы. Видимо у разработчиков бытовало понятие: «Логический Игрок», владелец дипломатической группировки воинов, включающий в себя объекты: Units, Pers, - на игровой зоне. Этот параметр: «nPlayerGroupDiplomacy» - номер группировки в наборе Дипломатических групп логических игроков: «PlayerGroupDiplomacy».
СУТЬ:
В первых именах двух функций много общего, но эти функции предназначены для работы со значениями из различных глобальных групп дипломатии. Их путать нельзя, так как внешне схожие названия с корнем Player не имеют ничего общего между собой.
Две следующих функции «GroupSee» и «PlayerSee» напротив не имеют в названиях практически ничего общего, но представляют единую сущность и принадлежат к функциям Дипломатических групп Логических Игроков.
КОНФИДЕНЦИПЛЬНОСТЬ:
Меня вынудили обстоятельства написать некоторые вещи, которые я пока не хочу разглашать до выпуска нашего аддона. Пожалуйста, не перепечатывайте и не распространяйте эту статью из этого форума!
ПОСЛЕСЛОВИЕ:
Я не претендую на 100% точность в классификации, но именно эти понятия мне помогают разбираться с ПЗ и предсказывать поведение игры. Информация предоставляется, «как есть» и как теоретическая.
[ 22 апреля 2002: Изменил: Holy Warrior ]</p>
Рассуждения: О скриптовых командах - sun - 03.02.2002
Вот посмотрите, как описывает внутренние процедуры в скриптах сам разработчик ПЗ.
DeclareScript #OnBriefingComplete ( nPlayer : float, szComplete : string )
И вызов команд:
GSSetVarMax( 0, "b.witch.z13_1", 1 )
GSSetVarMax( nPlayer, "b.witch.z13_2", 1 )
Сами разработчики не всегда пользовались переменой nPlayer в функциях, а прописывали непосредственно число – номер игрока. Интересно то, что вызов команд с параметром nPlayer встречается 66 раз только на первой диалоговой зоне. Файл первой зоны не гармонизирован в игре по имени как остальные зоны – это «basecam» (этот брифинг должен был называться: «bz1g») и 6 раз встречается переменная nPlayer на зоне «bz2g». Далее видимо разработчики отказались от поддержки прохождение одной игры сразу несколькими игроками. Далее параметр nPlayer не встречается в игре, а команда: GSSetVarMax на других зонах всегда использует значение 0.
Чтобы понять, что планировали разработчики сделать в ПЗ, делая класс: «Игроки» с использованием уровня дипломатии: Party – наверное нужно поиграть в Диабло2 в сети несколькими игроками, и задуматься над тем как реализован учет и выполнение совместных квестов в Диабле. Схожесть между двумя играми в этом случае была бы в том, что если было бы реализовано задуманное в ПЗ, то задания из одиночной игры можно было бы выполнять по сети совместно несколькими НАСТОЯЩИМИ игроками. Но видимо из-за линейности сюжета это невозможно было реализовать.