Неделя 8 (ноябрь 3): Учебная комната.

Оглавление

Это была вторая неделя игры в Civ VI… я ложился в 3 часа ночи, у меня началась бессонница… в общем я начал работать над учебной комнатой.

Суть идеи такая. В Нastle Сastle каждая шмотка имеет некое значение, которое означает какой минимальный уровень определенного скила должен быть у персонажа, чтобы эту шмотку надеть. Уровень скила качается в специальной учебной комнате. По сути очень похоже на рецепт апгрейда постройки только апгрейда персонажа. Скила персонажа.

Но все оказалось не так просто. Система рецептов и так плохо пережила встраивание третьего типа рецептов, а четвертого она просто не пережила. Пришлось немного переписать алгоритм рецептов… ну как немножко, механизм запуска нового рецепта пришлось переписать целиком.

***

Дело в том, что рецепты, на уровне конфигов, прикрепляются к постройкам. И до сего момента в инстанс рецепта так же был прикреплен к соответственно инстансу постройки. Железо добывается в шахте и соответственно рецепт железа привязан к шахте. Увеличение уровня шахты так же производится в шахте и привязано к ней. Но при обучении персонажа нужно было как-то связать рецепт с персонажем. При том, что увеличение уровня навыка добычи железа все равно происходит в школе шахтеров и привязано к школе шахтеров. То есть так же как и с простыми рецептами, школ может и должно быть несколько. То есть отвязывать рецепты от постройки нельзя.

Так конфиг рецепта остался связан с постройкой, а инстанс рецепта стал прикрепляться к “объекту”. Благо этот объект всегда определялся по айдишнику, а не напрямую, так что обошлось переименовыванием поля и определением типа объекта по типу рецепта: если рецепт “улучшение персонажа”, то объект – персонаж.

Вот так выглядит таблица рецептов сегодня. Не обращайте внимания что скилу работы с золотом я учу в школе боевых искусств. Издержки временных конфигов.

Таблица бонусов рецептов, улучшающих скилы персонажей. Как видим поле objectId у меня пока пустое. Тип скила, который будет улучшаться определяется постройкой: если помните, у построек есть свой ролевой параметр – вот его постройка и будет улучшать в персонаже.

В остальном система вроде бы не изменилась, но подрихтовать ее пришлось значительно.

***

Так же проблемы возникли и с рестрикшенами.

Рестрикшены, сами по себе, довольно простая штука, выполняющая простые логические операции занесенные в конфиг: проверить больше, меньше или равно какой-то параметр, указанному в конфиге значению. Но одно дело когда тебе нужно сравнить некое значение с параметром уровня текущей постройки (ведь мы не можем апгрейдить не текущую постройку). И совсем другое дело, когда тебе нужно сравнить значение со значением уровня ролевого параметра, соответствующего не то рецепту, не то постройки…

Буквально в предыдущем посте я рассказывал про поле conditionValueType, необходимое чтобы сравнить ограничение со значением скила персонажа. Так же тут видно, что апгрейд скила персонажа может зависеть и от уровня постройки.

В общем у меня теперь есть трехстраничный документ описывающий механизм работы рестрикшенов и доказывающий что даже если ничего не проверять наверняка, то все равно все будет само работать, ведь было проверено еще до вызова фукнции.

Проблема заключается в том, что в игре все происходит как бы в двух параллельных мирах: на экране и в данных. Когда у нас игра простая мы с экрана посылаем какую-то команду об изменении данных, а данные посылают на экран команду о том, что нужно изменить отображение. Когда игра становится чуточку сложнее появляются такие интересные моменты: на экране отображается какое-то состояние, но мы не можем просто отправить команду, мы должны отобразить может ли команда вообще быть отправлена. Ладно, мы проверили и убедились в том, что может, должны ли мы перед началом выполнения команды проверить возможность ее выполнения еще раз? По идее должны, ведь состояние игры за это время могло измениться.

В результате при проектировании таких сложных систем надо выделять не только выполнение команд, но и проверку возможности их выполнения в отдельные функции. Даже если логика вроде как отделена от отображения, думать о таких вещах все равно очень сложно.

Зато теперь я смогу применять рецепты к, например, шмоткам и теперь-то механизм рецептов к этому готов.

Оглавление