Неделя 12 (декабрь 3): Действия с предметами и инвентарь персонажа.

Оглавление

Надо учиться правильно называть задачи. А то вот так ляпнешь “пришло время одеть персонажей”, а потом смотришь почти через месяц, а персонажи все еще не одеты. Хотя за это время все-таки было проделано довольно много в том числе нужной работы. Меню инвентаря, механизм складов… но вернемся немного назад. Предыдущая неделя у меня закончилась на попытках сдружить массивы действий с системой загрузки конфига.

Этум имеет довольно интересное свойство. Грубо говоря это список константных значений, которые одновременно строка и число. Для удобства чтения используется строка, но логически это число (int). А числа можно складывать, перемножать и прочее.

Когда в коде создаешь энум его можно завести без упоминания того, какое числовое значение имеет та или иная строка. А можно указать. И можно указать не подряд, а с перерывами. Например одеть = 2 (010 в битовом виде, поэтому этот механизм еще называют битовыми флагами), а снять = 4 (100). И грубо говоря сравнение такого энума с числом 6 (110) не приведет к ошибке (все чуточку сложнее, конечно) потому что 6 вмещает в себя и 2, и 4. А вот число 5 (101) вмещает только 4 (из имеющихся у меня значений). И тогда это будет флаговый энум.

И вот, мне совершенно все равно будут ли действия загружаться как флаговый энум (сумма значений) или как массив энумов (список значений). Как загрузит так и сойдет. Просто очень не хотелось возвращаться к нечитаемой цифре, кодирующей набор действий – строковое отображение энумов очень удобно. Я бы скорее согласился даже на массив стрингов, чем на цифру…

Но при загрузке из гуглодоков возникала ошибка в отображении scriptable object‘а, хранящего конфиг, в интерфейсе Юнити. И не просто ошибка, а целая лавина ошибок. Работать игре это не мешало, но было признаком явного непорядка. Сначала я решил, что проблема в том, что я как-то неправильно оформил массив в конфигах.

***

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

И вот я даю юните значение 6 (которое является суммой 4 и 2) и она теряется. При этом, если использовать не кастомный интерфейс, а базовый, то никаких вопросов не возникает. Но использовать базовый интерфейс поздно (scriptable object содержит кастомные механизмы обновления контента и в интерфейсе есть и должна быть соответствующая кнопка), он должен быть кастомным… я написал затычку, чтобы программа не мучилась пытаясь отобразить непонятное ей значение энума.

А потом и вовсе заменил идущий вместе с библиотекой механизм отображения на механизм из Odin. Впервые в жизни вижу внешнюю библиотеку, которая решает возникающие проблемы, а не создает их. Как, например, QuickSheet.

Я кстати зарегался на GitHub чтобы написать автору плагина о моей проблеме. И даже получил от него ответ. Типа, “чувак, нафига тебе это вообще нужно?” Ну как нафига… в общем походу автор не знал о существовании флаговых энумов и мое объяснение того как их можно использовать ему понравилось. То странное чувство когда оказываешься умнее чем привык думать.

***

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

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

Интерфейс предметов – штука довольно простая. Это общий для всех предметов интерфейс отображения информации о них в зависимости от их предназначения, возможностей и расположения. Дело осталось за малым: связать воедино склады, предметы и действия – заставить шмотки одеваться и сниматься. Учитывая мои сложности работы механизма разделения шмоток по складам. А потом еще заставить это все нормально отображаться.

На видео работа механизма меню предметов и действий одевания/снимания шмоток. И бага со списанием шмотки из инвентаря если в слоте уже есть шмотка. Должно менять местами, конечно.

Игра начинает обрастать слишком сложной для меня логикой. В голове все уже не умещается, я начал документировать код, приехали. Класс описывающий работу предметов, их хранение и перемещение по складам, занимает больше 800 строк. Дальше будет только хуже. У меня полное ощущение того, что игра начинает состоять из соплей. С одной стороны в этом даже нет ничего плохого: я ведь не знаю какой функционал мне понадобиться, а оптимизировать то, что еще не сделано – вообще пустая трата времени. Но и вцелом я хочу чтобы игра была многопользовательской, а значит вся логика уедет из приложения на сервер, где ее скорей всего придется переписывать.

Оглавление