-
Публикации
586 -
Зарегистрирован
-
Посещение
Все публикации пользователя ptr128
-
Забейте. "Не кормите тролля" (с)
-
Так Kafka и выступает тут в качесте шины от множества публикаторов к ClickHouse, При это, выигрывая в производительности, еще дает лучшую надежность и меньшую задержу, чем альтернативы. ClickHouse не любит частые мелкие вставки. В него вливать лучше крупными пакетами. И Kafka замечательно такие пакеты собирает автоматически.
-
В X5 довольно неплохие специалисты в IT. Я при внедрении там SAP PI с ними пообщался. Так что есть чему поучиться.
-
Оно и видно ( Балансировка - это уже оптимизация. Для этого нужен solver. Я использую Gurobi. Но для solver нужен прогноз. И как раз задача математической модели этот прогноз сделать.
-
Я тоже использовал ElasticSearch до ClickHouse для агрегации журналов. Но все течет, все изменяется. Уж такая судьба у нас в IT - учиться ежедневно, или безнадежно отстанешь от молодежи. Факт в том, что Kafka, благодаря хорошей горизонтальной масштабируемости, способна пережевывать намного больше и быстрее, чем Prometheus. Обычно, в разделах брокеров храню неделю, на случай падения подписчиков или связанных с ними сервисов. Чтобы не напрягаться по выходным или даже ночами )
-
Вы что ли действительно читать не умеете? Вы уж простите, но дообучить уже обученную модель в десятки раз быстрее, чем обучить модель с нуля. На входе же для обучения фактические реальные действия игроков.
-
А почему нет? Я уже давно все журналы работы всех сервисов в нее заворачиваю, на лету считая статистики, детектируя алерты и загоняя пакетами детали в ClickHouse. Очень удобно. И не я один: https://kafka.apache.org/documentation/#uses_logs
-
Так оперативно не реально. Обученная модель за пару дней смоделирует несколько месяцев игры живых игроков. То есть, при использовании математического прогнозирования Вы увидите результат предполагаемых модификаций в игре через два-три дня и до того, как игроки с этими изменениями познакомятся. И сможете принять решение, стоит ли вообще эти изменения публиковать в продуктивную систему, или от них стоит если не отказаться, то хотя бы подправить.
-
Принципиальная разница в том, хотят ли игроки быть подопытными крысами или нет. Вот Вам явно нравится роль лабораторной крысы в игре. А мне нет. И у меня есть основания считать, что таких как я - большинство.
-
Естественно. Поэтому такие моделирования должны проводиться на регулярной основе, чтобы вовремя увидеть изменившиеся предпочтения игроков. Я разве говорил, что это можно сделать один раз и все будут в шоколаде? )
-
А обычный посетитель форума, прежде чем что-то писать в тему, сначала читает эту тему
-
А что еще надо для того, чтобы модифицировать игровой баланс не "Увидев результаты последних изменений" наблюдая за игроками, изображающими из себя подопытных крыс, а просто смоделировав несколько месяцев игры и увидеть тот же самый результат за два-три дня? Причем совершенно не раздражая такими экспериментами живых игроков.
-
Например, Dota 2, где обученные боты выиграли 99% игр в киберспортивном турнире. Во-первых, совершенно непонятно зачем нужны роботы для сбора статистики. Все действия игроков и так известны игровому серверу. Достаточно протоколировать их локально или публиковать в Kafka. А уже с накопленным массивом данных разбираться впоследствии. В том числе и в целях обучения математической модели. Во-вторых, обученная математическая модель лишь позволит за несколько дней увидеть результат влияния идей дизайнеров на игровой процесс. Никто не говорит, что она заменит дизайнера. Но она избавит дизайнера от необходимости проверять свои идеи месяцами на живых игроках, будто на лабораторных мышах. В-третьих, математическая модель позволит не только определить качество игрового баланса, но еще и оптимизировать его подходящим solver.
-
Вы уж сначала распишитесь ))) До свидания. Я не намерен метать бисер перед свиньями.
-
Я думаю, уже лет 10 это применяется в подавляющем большинстве реальных и успешных игр. Просто потому, что это существенно дешевле месяцев игрового тестирования, а дает лучший результат. Читайте статью по моей ссылке выше.
-
Зря сомневаетесь. Эта задача решаема даже для прототипа игры, на что я дал ссылку выше. А уж если речь об игре в эксплуатации, то обучить нейросеть поведению игроков на основании истории их действий в игре - совсем не сложно. Естественно, кластеризовав их не только по используемому вооружению (включая дроны и устройства) но и по стилю игры и уровню.
-
Могу поучить пользоваться поисковыми системами. За час тренинга возьму всего 10 тыс. рублей. До пяти студентов по скайпу. Точно про обсуждаемую тему дизбаланса в игре и использовании нейронных сетей для балансирования: Leveraging Machine Learning for Game Development Переводить, раз Вы все веремя сваливаетесь на английский, надеюсь не надо? А мне интересен, чтобы я представлял с кем общаюсь. Так что жду.
-
Но я этих вопросов не вижу. Куда подевались? Извиняюсь. Журналы работы игровых серверов. Так устроит? Я перечислил два крупных успешно завершенных проекта. Гуглятся легко. Если что, во время этих проектов я работал на стороне GMCS, которая была подрядчиком. Давайте Вы все же хоть немного раскроете свое портфолио и озвучите хотя бы пару успешно завершенных своих проектов. Чтобы я понимал хоть с кем общаюсь. Догадались и очень многие. Гуглите, если там Вас не забанили. У меня, например, то, о чем я говорил, нагуглилось сразу же Leveraging Machine Learning for Game Development Если дизайнер некомпетентен, его увольняют. Это нормально. Просто в XXI веке дизайнер должен заниматься творческой деятельностью. А вот моделировать свои идеи и их влияние на игровой процесс должен уметь на компьютере, а не использовать живых игроков в качестве подопытных лабороторных мышей, чтобы потом, на основании их реакции, делать выводы об удачности своих идей.
-
Вы на полном серьезе считаете, что игровой процесс может быть сложнее реальной жизни? Я Вас разочарую - жизнь намного сложнее любой игры. И ежели в жизни математическое прогнозирование приносит ощутимый экономический эффект, то уж в любой игре - принесет без сомнений. P.S. И постарайтесь все же общаться по-русски на русскоязычном форуме. Или, если Вы не знаете перевода слов "case" и "game" - создавайте ветку на англоязычной версии форума и приглашайте меня туда. Я могу общаться и на английском.
-
О достижении успешных результатов именно для TensorFlow смотрите на его сайте. Вообще об успешном применении машинного обучения для прогнозирования - гуглите. Очень много найдете. Сам я применяю математическое прогнозирование, оказывая услуги крупнейшим российским компаниям. Например, Почте России или СУЭК. Поверьте, модели там требовались на порядки сложнее, чем нужно для оптимизации игрового процесса в TO. А причины я написал: Возможно, в мире существуют люди, которые в прогнозировании могут соперничать с математическими моделями. Я слышал что-то о Ванге, например. ) Но даже если такого человека получится найти, то компенсация такому человеку за работу явно не по бюджету "Альтернативе Гейм".
-
Например при помощи TensorFlow. Oбучить модель на основании фактов игрового процесса и прогнозировать последстия любых модификаций с ее помощью. Детализация обучения зависит исключительно от доступных вычислительных мощностей. В принципе, если обучать детальными логами действий всех игроков всех игр за относительно небольшной срок (несколько десятков деней), то одного хорошего GPU хватит. Тут же время обучения не критично. Результат нужен далеко не в реальном времени.
-
Пока Орех, демонстрируя свое неполное служебное соответствие, вместо математического прогнозирования будет пользоваться методом интуитивного тыка - ничего не изменится. Просто перекос пойдет в другую сторону. Я уже который год никаких признаков сходимости в модификациях игрового процесса не наблюдаю.
-
Если в мобильной версии менять за рекламу ежедневные задания так, чтобы их можно было выполнить буквально за одну игру (очки/кристаллы, пять оверов, ящики), то тогда можно быть в плюсе. До сегодняшнего дня в начале челленджа еще был недельный контейнер. Но, увы, жадность Ореха сделала это историей (
-
Самостоятельное изготовление HTML5 клиента под Linux на примере Ubuntu
ptr128 ответил ptr128 в теме Самостоятельное изготовление HTML5 клиента под Linux на примере Ubuntu Архив
Установите npm sudo apt install npm Затем установите nativefier sudo npm install nativefier -g Перейдите в директорию, в которой хотите, чтобы была создана директория с клиентом и создайте его nativefier https://tankionline.com/play Будет создана директория TankiOnline-linux-x64, а в ней клиент TankiOnline, который можете уже запускать, как исполняемый файл Если nativefier будет ругаться на слишком старую версию node.js, обновите node.js sudo npm cache clean -f sudo npm install -g n sudo n stable Возможно, потребуется не стабильная, а последняя версия node.js. Не делайте этого, если nativefier согласился работать со стабильной версией node.js sudo n latest -
Где? Я даже такого слова не вижу: Пушка Терминатор: (Комментарий) Это пушка Джаггернаута Увеличен урон ракет с 435-1760 до 450-1800; Уменьшено время наведения ракет до 1,4-1,2 секунды; Увеличена стартовая скорость ракет с 25 до 120 м/с; Уменьшена максимальная скорость ракет с 700 до 60 м/с; Уменьшено время разгона ракет с 3 до 2 секунд; Увеличена угловая скорость ракет с 55 до 90 град/с.
Перейти к содержимому






























































