Неделя 19 (февраль 2): Рандом.

Оглавление

Неделю я начал с совсем не того чем стоило бы заняться (будто в первый раз со мной такое). Но вопрос этот мне хорошенько засорил мозг и надо было хотя бы палочкой в него ткнуть. В общем спать мне не давала мысль о том, в каком масштабе должен исполняться персонаж, если делать его в воксельном редакторе. И знаете что? Мне как-то немного впадлу разбираться кто именно придумал персонажей для Mincraft, но они выполнены в почти идеальном масштабе.

Единицей измерения у майнрафтовского персонажа является кубик в 4 пикселя. Руки и ноги — это столбики по 3 кубика. Тело — площадка 2х3 кубика, а голова — куб в 2 кубика — 8х8х8 пикселей. Понятно что художники — все-таки художники и собака имеет совсем другие базовые элементы, но все же. Кубик в 4 пикселя — это не просто эстетический минимализм. Плюс один пиксель какого-то навешенного сверху шмотья так же совершенно эстетичен. Этот плюс один пиксель не слишком толстый и не слишком тонкий… именно такой, какой нужен.

Идеально

Ну и отдельное спасибо MagicaVoxel за то, что хранит воксели. Благодаря этому можно выделить какой-то объект на сцене и сдвинуть его, скопировать, отдельно сохранить. Тем смешнее то, что внутри моей заготовки майнкрафтового человечка находится соответствующий объем непокрашенных вокселей — типа скелета — которые обнаруживают себя, если попробовать переместить модель персонажа выделив ее только по внешним цветовым элементам.

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

Но продолжать эксперименты я не стал: для текущей задачи получения работающего игрового цикла вполне достаточно и нарисованных в Пейнте иконок и домиков.

***

И тут майкрософт внезапно решил что пол года бесплатно пользоваться Visual Studio Enterprise 2017 — это слишком жирно, и вырубил мне лицензию. Я не долго думая установил уже точно бесплатную Community версию… и выяснил страшное. В состав Энтерпрайза входит штука, называющаяся CodeLens. А в состав Community она не входит. А я почему-то без нее жить не могу. Штука эта отображает короткую информацию о фукнциях в начале их описаний: сколько и где раз используются и все такое. Все то же самое можно получить в отдельном окошке при нажатии на Shift+F12, но ведь удобнее когда ничего нажимать и смотреть в отдельные окошки не надо.

В общем у меня знатно припекло и я начал искать альтернативы. Альтернатив собственно не много: JetBrains Rider и VS Code. Первый стоит денег поэтому отпадает (а еще там нет CodeLens, нафига вообще так жить?), а второй… был бы идеальным так как в его состав входит аналог CodeLens, даже более удобный чем оригинальный, но почему-то на следующий день он сломался. Ну и там были просто не комфортные отличия… много не комфортных отличий. Больше чем одно отличие в необходимости нажимать на Shift+F12 в Community. В итоге, спустя полтора дня мучений, я как побитая собака вернулся в Community.

***

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

Я наконец отделил механизм бонусов от рецептов. Все-таки бонусы не только рецептам нужны и могут не только определять его ингредиенты и результат. Результатом может быть ролевой параметр, например.

Конфиг бонусов претерпел довольно серьезные изменения. Появился типа владельца бонуса чтобы отделить рецепты от артикулов. Добавился новый тип объекта бонуса: ролевой параметр.

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

Я уже писал что к параметру редкости хотел добавить сид рандома для идентификации шмотки. И вот пришла его очередь.

***

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

Дело вот в чем. Есть у нас например шмотка. Чтобы сгенерировать ее параметры надо последовательно выполнить несколько пар рандомов (определить тип бонуса и значение бонуса). Количество этих пар зависит от редкости шмотки: самая простая шмотка — один бонус и соответственно одна пара рандомов. Если в каждом рандоме по 10 вариантов, то получается что всего вариантов 100… а разных вариантов сида 2 с хреном миллиарда (положительный int).

То есть, во-первых, количество значений из которых может выбираться сид рандома в этом случае не должен превышать сотни. А во-вторых это должны быть не просто случайные цифры… ведь два первых рандома все равно могут оказаться одинаковыми даже при разных сидах… ведь у него 2 с хреном миллиарда значений. То есть значения сидов можно брать только из специально проверенной таблицы, которая гарантирует отсутствие совпадений.

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

Сидом рандома безопасно и полноценно можно пользоваться только если количество генерируемых им значений в итоге даст 2 с хреном миллиарда вариантов. Иначе всегда есть шанс того, что шмотки с одинаковыми параметрами будут иметь разный сид и не соединяться в экстазе одной пачки. Но я вот что-то совершенно не уверен в том, что у меня будет столько предметов. А главное, что это не очень касается предметов первой редкости с всего одним бонусом и двумя рандомами, которые ну хоть ты тресни не выходят за пределы 10 тысяч вариантов: 10 бонусов с разбросом значений бонуса 1000-2000… и это я тут еще значения бонуса измеряю тысячами, а не десятками, как хотел бы.

***

Тут кстати отдельно интересный момент. Желание как-то урегулировать количество вариантов шмоток может привести к необходимости выбрать диапазон значений бонусов. Например 10 бонусов со значениями 10-20 — это 100 шмоток, а 10 бонусов с диапазоном 1000-2000 — это уже 10.000 шмоток. Разница налицо.

С другой стороны это означает, что нужна таблица на 10 тысяч значений сидов с не повторяющимися первыми двумя рандомами. Серьезно? Ну я прям даже не знаю.

Оглавление