Pull to refresh

Comments 22

Спасибо!
А есть идеи по оптимизации взвешенного рандома «в бою»?
«ВБР» многих достал. Как в такой ситуации быть разработчику?
ВБР работает, по сути, по тому же принципу.
Непонятно зачем изобретать всякие «мешки» (с тремя синими и одним красным шарами), если можно сделать просто так:
if (random(1, 100) <= 25) {
    getRareItem();
} else {
    getNormalItem();
}
И уже этот подход можно обернуть в красивые функции-генераторы и т.п.

А насчёт последнего подхода, «с подкладыванием» хорошего результата, — довольно сомнительное решение.
а где гарантия что на 100 бросков random вернет результат в пределах 1-25? Самый простейший способ это создать массив с числами в соотношении вероятности и перемешать чем угодно.

Зря минусуете камрада, я вот лично столкнулся с очень странным поведением C#-го стандартного Random.Range(): из 100 сферическо-вакуумных бросков костей как-то подозрительно часто одни и те же значения выпадают… условно 33 шестерки и 25 единиц...


За подсказку с изменением веса спасибо, не догадался, это всякие [ММО]РПГ большими командами пилят, а в инди все грабли на себя собирать приходится)


Кстати, в Бельгии намедни лутбоксы законодательно запретили, особенно в детских играх…

Плюсую, у меня на боевом игровом сервере тоже была странность — числа из диапазона 50-100 выпадали гораздо чаще при редких выборках, а в диапазоне 0-30 — очень редко
Ваш код реализует как раз-таки стандартный генератор обычных и редких вещей. При шансе выпадения редкой в среднем в 1 из 4 случаев невезучие люди получат 0 из 4, а везучие — 2, 3 или даже 4. Это-то всем геймерам и не нравится. А если есть мешок с тремя обычными и одной редкой, из которого эти вещи достают, то самое большое различие — невезучие люди вытащат редкую вещь последней, а везучие — первой. Намного лучше, правда же?

Остается вопрос лишь о размере этого мешка. Можно сделать его минимальным, 4 вещи. Тогда игра станет слишком предсказуемой, ведь вы всегда знаете, что редкая вам выпадет не позднее чем через 6 вещей (1ый мешок — редкая, 3 обычных, 2ой мешок — 3 обычных, редкая). Можно сделать чуть побольше. 8 вещей, 6 обычных и 2 редкие. Чуть менее предсказуемо. Таким образом, вы берете власть над рандомизацией в свои руки. Больше размер мешка — больше рандомность. И конечно же, не стоит делать размер мешка в 4 миллиона вещей. Невезучим игрокам их миллион редких вещей будет доставаться в самом конце мешка. Когда они уже бросят эту невезучую для них игру.
Если допустить что есть классы вещей(от более частых к более редким):
серые, зеленые, синие, фиолетовые, красные.
Каждый класс имеет также свои подклассы — различный мусор, зелья, шмотки.
Итого имеем 15 категорий в которых разные шансы выпадения, причем они могут иметь привязку к определенным модам, событиям, учитывать уровень игрока, а также количество уже существующих таких шмоток в игре(что бы не приводить к утрате ценности вещей).

А еще понадобится подкрутить рейты(может так получиться что рейты завышены или занижены)

Из за этого ваш подход становится неудобным, и вы прийдете к «мешкам» которые по сути будут тем же самым что вы написали, с тем отличием что условия могут меняться на лету, тем более проще видь в БД писать вещи и вероятности их выпадения, нежели хардкодить, или даже выносить в конфиг.
Не знаю как в других играх, но ВБР в Мире Танков, Кораблей только в самом начале был веселым и задорным, невидимым. Сейчас в это сложно играть. Надеюсь другие игры не пойдут по этому пути.
Вначале, это когда краевые значения флипались к краю и огромное количество снарядов летело в круг? Ничего веселого там не было. Просто вам надоела игра.
Немного вне темы. Турбосливы и турбопобеды появились далеко не сразу и сейчас их очень много. Понятно, что количество игроков выросло в разы по сравнению в 2011 годом, но балансило явно иначе.
Это вы о том балансе, когда в одной команде максимум 8-й уровень, а в другой даже пару десяток? Да, никаких турбосливов. Ещё раз — вам просто надоела игра, по рандому там все стало намного лучше

Неясно откуда в способе "Слоты редкости" взялись цифры 1, 3, 5 и что именно они означают.
В такой контейнер можно сунуть 10 предметов средней редкости, 1 обычной и 5 редких. Вероятность выпадения любого обычного предмета при этом будет 15 / (15+103+51) = 0.125 и любого "редкого" тоже 0.125.
По-хорошему в этом способе нужно учитывать количество предметов каждой редкости, чтобы не было подобных аномалий.

Формула немного исказилась: 1*5 / (1*5+10*3+5*1)

11% / 33% / 55% вероятность достать редкий / необычный / обычный предметы и эта вероятность контролируется количеством экземпляров конкретной редкости. Вы же добавили к этой системе «второй раунд» оценки и получилось черте знает что. Для ваших данных коэффициенты 1,3,5 надо забыть, а вместо них прописать 5,1,10, тогда вероятности распределятся как 31,25 % / 6,25 % / 62,5%.
Вы же добавили к этой системе «второй раунд» оценки и получилось черте знает что.

Какой еще раунд? Я работаю исключительно с контрактом класса. Метод addItem принимает на вход любой предмет. Значит им можно воспользоваться как то так


Bag bag = new Bag();
bag.addItem({name='item1', rarity='uncommon'});
bag.addItem({name='item2', rarity='uncommon'});
bag.addItem({name='item3', rarity='uncommon'});
bag.addItem({name='item4', rarity='uncommon'});
bag.addItem({name='item5', rarity='uncommon'});

bag.addItem({name='item6', rarity='uncommon'});
bag.addItem({name='item7', rarity='uncommon'});
bag.addItem({name='item8', rarity='uncommon'});
bag.addItem({name='item9', rarity='uncommon'});
bag.addItem({name='item10', rarity='uncommon'});

bag.addItem({name='item11', rarity='common'});

bag.addItem({name='item12', rarity='rare'});
bag.addItem({name='item13', rarity='rare'});
bag.addItem({name='item14', rarity='rare'});
bag.addItem({name='item15', rarity='rare'});
bag.addItem({name='item16', rarity='rare'});

При этом получится описанная мной ситуация с аномалиями в распределении.
Такая же ситуация, только чуть менее явная, может получиться когда предметы добавляются в пул мешка каким-нибудь инструментом. А потом игроки ловят интересные проблемы, когда обычный предмет встречается сильно реже, чем "редкий".


Если захардкоженные в классе коэффициенты ломаются при использовании, значит нужно как-то иначе их сохранять.

Ок, я понял. Там действительно отсутствует балансировка вероятностей. Либо метод addItem предполагался приватным. В любом случае это лишь пример, интерфейс класса явно не доделан.
UFO just landed and posted this here
Sign up to leave a comment.

Articles

Change theme settings