
Неделя 8 (ноябрь 3): Учебная комната.
Это была вторая неделя игры в Civ VI… я ложился в 3 часа ночи, у меня началась бессонница… в общем я начал работать над учебной комнатой.
Суть идеи такая. В Нastle Сastle каждая шмотка имеет некое значение, которое означает какой минимальный уровень определенного скила должен быть у персонажа, чтобы эту шмотку надеть. Уровень скила качается в специальной учебной комнате. По сути очень похоже на рецепт апгрейда постройки только апгрейда персонажа. Скила персонажа.
Но все оказалось не так просто. Система рецептов и так плохо пережила встраивание третьего типа рецептов, а четвертого она просто не пережила. Пришлось немного переписать алгоритм рецептов… ну как немножко, механизм запуска нового рецепта пришлось переписать целиком.
***
Дело в том, что рецепты, на уровне конфигов, прикрепляются к постройкам. И до сего момента в инстанс рецепта так же был прикреплен к соответственно инстансу постройки. Железо добывается в шахте и соответственно рецепт железа привязан к шахте. Увеличение уровня шахты так же производится в шахте и привязано к ней. Но при обучении персонажа нужно было как-то связать рецепт с персонажем. При том, что увеличение уровня навыка добычи железа все равно происходит в школе шахтеров и привязано к школе шахтеров. То есть так же как и с простыми рецептами, школ может и должно быть несколько. То есть отвязывать рецепты от постройки нельзя.
Так конфиг рецепта остался связан с постройкой, а инстанс рецепта стал прикрепляться к «объекту». Благо этот объект всегда определялся по айдишнику, а не напрямую, так что обошлось переименовыванием поля и определением типа объекта по типу рецепта: если рецепт «улучшение персонажа», то объект — персонаж.
В остальном система вроде бы не изменилась, но подрихтовать ее пришлось значительно.
***
Так же проблемы возникли и с рестрикшенами.
Рестрикшены, сами по себе, довольно простая штука, выполняющая простые логические операции занесенные в конфиг: проверить больше, меньше или равно какой-то параметр, указанному в конфиге значению. Но одно дело когда тебе нужно сравнить некое значение с параметром уровня текущей постройки (ведь мы не можем апгрейдить не текущую постройку). И совсем другое дело, когда тебе нужно сравнить значение со значением уровня ролевого параметра, соответствующего не то рецепту, не то постройки…
В общем у меня теперь есть трехстраничный документ описывающий механизм работы рестрикшенов и доказывающий что даже если ничего не проверять наверняка, то все равно все будет само работать, ведь было проверено еще до вызова фукнции.
Проблема заключается в том, что в игре все происходит как бы в двух параллельных мирах: на экране и в данных. Когда у нас игра простая мы с экрана посылаем какую-то команду об изменении данных, а данные посылают на экран команду о том, что нужно изменить отображение. Когда игра становится чуточку сложнее появляются такие интересные моменты: на экране отображается какое-то состояние, но мы не можем просто отправить команду, мы должны отобразить может ли команда вообще быть отправлена. Ладно, мы проверили и убедились в том, что может, должны ли мы перед началом выполнения команды проверить возможность ее выполнения еще раз? По идее должны, ведь состояние игры за это время могло измениться.
В результате при проектировании таких сложных систем надо выделять не только выполнение команд, но и проверку возможности их выполнения в отдельные функции. Даже если логика вроде как отделена от отображения, думать о таких вещах все равно очень сложно.
Зато теперь я смогу применять рецепты к, например, шмоткам и теперь-то механизм рецептов к этому готов.