test content
Logo
What is the Arc Client?
Install Arc
Не апается камень буйства 6-го ранга
Застрял камень буйства на 6-ом ранге. Было сделано более 20 попыток апнуть камень. Вероятность что алгоритм исправен стремится к нулю. Я учил математику в школе и считается все очень просто. Шанс у камня 30% соответственно для того чтобы промазать 10 раз подряд нам нужна вероятность 0.66 * 0.66 * 0.66 ... и так десять раз = 1,568%. И это при десяти попытках. Я сделал около 20. Мы все прекрасно понимаем для чего это все. Но так вы потеряете и оставшихся в игре игроков. Надеюсь ошибку доступно описал. Спасибо за внимание.
0
Войдите или Зарегистрируйтесь чтобы комментировать.
Комментарии
ты точно из кастрюльки?)
30% шанс на попытку апа.
30% шанс на следующую попытку апа.
30% шанс на каждую попытку апа, а не в общем на ап одного камня.
Да точно, а что не так?
Неправильно считаешь. Я считаю вероятность одного и того же события несколько раз подряд.
Если сомневаешься google в помощь.
Разработчик анализатора логов NCLA
но вероятность в невере зависит от времени
т.е расчет вероятностей уже произведен и добавлен в профиль и срабатывает профиль, а не вероятность
т.е в один момент времени вы можете к примеру истратить 50-60 катализаторов
у некоторых камней заявленные шансы, совсем другие...
на 5камней 12лвл было потрачено 120каталиков...
..событие не должно было начаться, но началось..
Ты мог просто попасть в эти 1,568%
1,568% это на примере 10 попыток, но я сделал значительно больше. Поэтому и написал что там шанс уже стремится к нулю. Просто не стал приводить расчет на 20 попыток, там процент будет смешной и здравый смысл мне подсказывает что дело не в фатальном невезении а в чем-то другом.
Разработчик анализатора логов NCLA
Мой ответ:
Разработчик анализатора логов NCLA
А вообще если так подумать ап камней больше напоминает игру в дарц будучи пьяным в дупель, нежели чем броски кубиков%)
Квест рабочий, но все еще в доработке.
там своя высшая математика со своими зависимостями и вероятностью:), ТС примерно правильно раскинул вероятность, на грубую - сойдет, выводить более точную картинку муторно и долго, а вывод правильный и так - вероятность неправильно отраженна и занижена, хотя если это вероятность не на попытку игрока к этому камню а вероятность всех попыток в данную секунду то тогда да - оно будет стремиться к нулю,где грубо - и какая то миллиардная обезьяна сделает открытие мирового значения.
Или же одновременно с вами кто-то пытался апнуть свой камень. Вот вы пробуете - провал, он пробует - успех, вы пробуете - провал, он пробует - успех и т.д.. И в таком случае опять получаем шанс апгрейда равным 50%.
Смысл поста таков, что пока вы не узнаете у разработчиков какими математическими функциями реализован рандомайзер, один ли рандомайзер на всех или же у каждого игрока свой, вы не сможете доказать, что указанный процент не соответствует реальности.
и пользовательское соглашение, надо читать
http://www.arcgames.com/ru/about/terms
..событие не должно было начаться, но началось..
это объектно ориентированная модель. каждому объекту создается свой экземпляр функции рандома. Реализация доступа множества к одному и выстраивание очереди намного сложнее в реализации. Не думаю что так было сделано да и зачем.
О детальной формуле никто не говорит. Интересует принцип реализации. Например что касается покерных сайтов а эти ребята, уж поверьте на рандоме собаку съели, они сообщают пользователям на каких источниках энтропии основан их механизм. Да и сами функции выкладывают публично и подвергают проверке в независимых аналитиеских центрах. Генерация последовательности одной лишь функцией рандома не может быть случайной и называется псевдослучайной (ГПСЧ) Поэтому в серьезные программы добавляют дополнительные источники энтропии, зачастую физические, например передвижение мыши пользователем и сертифицируют свой комбинированный ГСЧ в Швейцарском Федеральном бюро метрологии. Но это уже разговор о тонких материях и о таких вещах можно говорить лишь когда при анализе сотен тысяч или милионов последовательностей выявляется какая либо обратная закономерность. Мы же говорим о 20 попытках))
Разработчик анализатора логов NCLA
Откуда вы это знаете? Выделять экземпляр каждому игроку отдельно это ресурсоемко, гораздо медленнее и бессмысленно (т.к. операция всего одна и она быстрая), легче посчитать все на одном экземпляре. Смысл параллелить такие мелкие вычисления? Это не гидродинамика. Пусть даже каждую секунду точат 10000 тыс человек, что такое 10000 операций для современных процессоров? Пусть даже и функции рандомизации.
Я бы на месте разработчиков сделал бы как раз вариант "один на всех".
Поясняю:
Предположим на сервере стоит вариант "у каждого свой". Пусть шанс заточки 50%. Пусть сейчас апгрейдят по одной попытке 100 человек. Значит будем иметь в среднем 50 успехов, 50 провалов. Те, кто получил успех идут играть дальше. Те, кто провалил, точат еще раз, т.к. шанс 50%, то второй раз получают успех. Как видно, всего было 150 попыток, 100 успешных, 50 провальных. Значит шанс успеха на весь сервер будет 100/150=2/3=66.7%. Врядли такой шанс устроит разработчиков.
Я не знаю, я предполагаю потому что я программист и сделал бы именно так.
Ошибка. На следующую попытку шанс не меняется и будет иметь также 50% на провал.
Расчет неверен
Разработчик анализатора логов NCLA
Перечитайте шапку темы, где вы так упорно пытаетесь показать, что шанс с каждой попыткой стремиться к нулю.
Шанс возникновения череды провалов! Это вы поняли неверно. Более детально я так же описал выше во втором ответе для технической поддержки. Там даже пример с монетой есть.
Разработчик анализатора логов NCLA
)))) ок, в двух словах. Есть базовый класс например "камень" от него наследуются и плодятся индивидуальные объекты типа "лазурный". У базового класса описан алгоритм улучшения. Наследуясь каждый камень получает свою копию алгоритма и пихая в него свои текущие параметры (шанс, необходимые ос) использует его для улучшения. как-то так)
Разработчик анализатора логов NCLA
Да, мне ответили специалисты ТП что якобы проблема наблюдается не только на камнях.
Разработчик анализатора логов NCLA
Интересно, спасибо!!!
Разработчик анализатора логов NCLA
Алгоритм улучшения на камни/арты/открытие сундуков с большей вероятностью одинаковый и лежит в отдельном классе "рандом". Когда происходит попытка апнуть камень, объект класса "камень" обращается к объекту класса "рандом" (и посылает тому значение шанса своего улучшения), который просто возвращает 1 или 0, успех или провал.
Возможно. Но чисто теоретически я могу представить себе ситуацию с криво работающим алгоритмом. Вопрос в том где обрабатывается алгоритм на клиенте или на сервере. Если на сервере то как обрабатываются исключительные ситуации с транспортом данных? Грубо говоря ответ от сервера не пришел по причине загрузки лагов и т.д. тоже клиентом считается провалом хотя ответ был положительным)
ЗЫ но это мои фантазии))
Думаю что все обрабатывается на клиенте и на сервер передается результат мол был 6-ой стал 7-ой таким образом обновляя профиль вашего перса на сервере)) Почти уверен)
Разработчик анализатора логов NCLA
А это имеет принципиальное отличие от того варианта который я написал?))
Вы различаете два понятия класс и объект или экземпляр класса?)
ЗЫ Если класс обеспечивающий улучшение, открытие и т.д. как вы представляете должен иметь тип static и быть в единственном эекземпляре на всех, то соответственно от всех тысяч клиентов/объектов должна генерироваться очередь и должен быть определенный стек очереди со своим "светофором" чтобы следующему клиенту было "сказано" - "Ок бро залетай я предыдущего посчитал" ))))))
Технически это усложняет реализацию и делает ее лагодромом)))
Разрабы на данный момент стараются нагрузку перенести на клиентов дабы разгрузить серваки которые они арендовали за три копейки)))
Чем меньше нагрузка на сервак тем дешевле аренда, тем больше бабосов в карман)
Разработчик анализатора логов NCLA
Профилактика - она такая.