Искал слово "игра". Три раза. Не нашел. А то что в той же Dota 2 рейтинговые игры не доступны без привязки номера телефона - это разве не требование?

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

И опять. Вы старательно доказываете, что не являетесь профессионалом. Вот поп уверен, что бог есть. Я же уверен только в том, что ни в чем не уверен. Как и любой человек с научным складом ума. И так же доказываете, что Вы не можете обходится без эмоциональной окраски, старательно пытаясь превратить техническую дискуссию в демагогическую склоку. А это и есть самая настоящая научная статья. Ну так отштампуйте рецензию на эту статью в Вашем университете. Я вроде бы уже призывал к этому. Как можно вытаскивать критику научной статьи на форум, где авторы статьи физически не смогут хоть слово сказать в ответ? Или именно так принято в "ваших университетах"? Не надо додумывать за оппонента то, что он не писал. Я не уточнял вид поиска. И в семантике русского языка, с которым Вы походу плохо знакомы, это обозначает любой вид поиска. Бритва Хитченса. А может это уходили только те, кто собирались очередной аккаунт завести, но у нех не было еще одного почтового ящика? Или те, кто опасались указывать свой адрес электронной почты, так как планировали заниматься читерством, рекламой или чем-то еще заведомо наказуемым? Или вообще малолетние дети, от наличия которых в своей команде выть хочется? Или даже потому, что эту электронную почту обязательно нужно было вводить руками, вместо того, чтобы создать аккаунт одним щелчком, авторизовавшись через VK, Google, Yandex, FaceBook, Instagram, Twitch или Discord? Если бы была сравнительная статистика между процентом донатов в случае необходимости ввода адреса электронной почты и без такой необходимости - можно было бы еще хоть о чем то говорить. Но мало клиента получить, нужно его еще удержать. Значит нужна еще статистика причин покидания игры, среди которых есть и неприязнь к читерам, саботажникам или даже к малолетним детям, не понимающим зачем на карте флаги, мяч, или точки. И для удержания клиента эффективна адресная реклама, рассылаемая по электронной почте или WhatsApp/Viber/Telegram. Когда клиенту напоминают, что его любят, что он важен, интересуются его мнением, предлагая принять участие в простейших опросах одним кликом прямо в сообщении - это его удерживает и он снова и снова возвращается к поставщику. Вообще интерес к Вам у меня начинает иссякать. Вы можете быть в чем то уверены и в этом не сомневаться. Для вас существуют объективные "никто", "нигде", "никогда" и "все", "везде" и "всегда", хотя они по определению возможны только субъективные. Общение с таким оппонентом бессмысленно, так он изначально вообще отвергает научный метод познания и правила диалектики. А общаться с демагогом тем более не имеет смысла. За тем раскланиваюсь.

Проблема в том, что профиль загрузки вычислительной мощности при обсчете ботов сильно отличается от профиля загрузки игрового сервера. Ему все же физику считать. Поэтому тут уже речь о новых выделенных серверах для управления ботами. А это совсем другая статья бюджета, чем разработка. Предполагаю, что сама идея ботов родилась в голове Стрижака, как способ освоить уже утвержденный бюджет на разработку, который ну никак не подразумевал роста бюджета на оплату услуг ЦОД. Отсюда и столь оригинальная идея считать ботов на клиентах, что порождает множество технических проблем, опыта решения которых в сфере разработки многопользовательских игр - кот наплакал. А даже мысль использовать опыт реализации распределенных вычислений из других сфер, Серену сразу бросает в жесткое неприятие.

Потому что поиск может подсказать только типовые решения с наибольшей селективностью. А то, что эти решения уже год-два как устарели может выясниться только потом. Да и высокая селективность часто обусловлена простотой решения, а вовсе не его качеством. Гуглим OLAP и в топе - многомерные БД, которые уже вытеснены ColumnStore. Еще 2-3 года назад никто бы и подумал обращаться к OLAP на SQL, а сейчас ClickHouse радикально изменил эту моду. Вопрос не задан. Проблемы с семантикой или терминологией? Вот это меня больше всего и смущает. Мне чрезвычайно сложно понимать людей, которые не сомневаются. Если человек обладает критическим мышлением, то оно в равной степени относится не только к окружащему миру, ни и к нему самому. Я подвергаю сомнению все, так как это базовый подход познания. Включая и собственное мнение, которое вполне может быть ошибочным. Да что там мнение. Собственные ошибки в коде приходится править чуть ли не на ежедневной основе. И чуть ли не ежеквартально объявлять на планерке о том, что я в очередной раз лоханулся и надо решать, как это исправить. Неужели действительно есть вещи в которых Вы не сомневаетесь? Возможно и так. Но не раз уже получалось наоборот, и не тысячи, но десятки, если не сотни, разработчиков делали потом то, что вопреки общепринятому сделал я. Я уже упоминал про "бегать голышом с дубинками". Если люди не будут хотя бы пытаться делать то, что до них еще никто не делал - вернемся в каменный век. Для меня блог первичный источник информации и вся дискуссия опирается на факты из него. Если нет общих начальных условий, то и дискутировать не о чем. А без неё - доходность. И что важнее? Уж простите, но клиент, готовый платить с кредитки, свой телефон скрывать от получателя платежа вряд ли будет. С электронной почтой вообще надуманную проблему изобрели, требуя ее уникальность для каждого аккаунта. Это же ничего не решает, так как разные папки gmail все равно воспринимаются как разные адреса электронной почты.

Это опять предложение обсудить религию? Мы же уже вроде бы решили, что раз НУ из видеоблога явно определили, что дроны будут работать на клиентах, то обсуждать этот вопрос уже просто бессмысленно. Решение принято, озвучено и уже реализуется. Понятно, что технологически поднять в ЦОД выделенные сервера для ботов проще и быстрей. Но я уже указывал выше, что это решение исключительно за владельцем бюджета. Фраза наоборот призывает использовать весь имеющийся опыт, а не ограничиватся только одной узкой областью. Например, несмотря на то, что двигатели внутреннего сгорания сотню лет успешно работали и без микроконтроллерного управления, применение опыта из кибернетики позволило сделать их намного лучше по всем параметрам. Это к тому, что я без НИОКР никакой проект не начну. Или он превратится в оутсорсинг, а не полноценный проект. Не важно что десятки тысяч до меня эту задачу решали именно таким способом. В максимально упрощенном виде. Eсли я знаю, что до прошлого года в ванильном PostgreSQL не было мультимастера, и, соответственно, ни одного внедрения с мультимастер не было, то из этого не следует, что я не должен предлагать мультимастер клиенту для 15-ой версии, в которой он появился. На них толку от этого еще меньше. Но если Вас это действительно так волнует, то сделайте, как в VK, обязательность идентификации по номеру мобильного телефона. И блокируйте сразу все аккаунты, привязанные к этому номеру или которые попытаются привязать в будущем. Облегчите себе работу. Покупать новую симку реальных денег стоит и только чтобы повеселиться 15 минут вряд ли кто на такое пойдет.

Для информационных систем. Как будто игры, не являются всего лишь одним из видов информационных систем и решения, давно типовые среди других видов информационных систем в них не применимы. Напомнило анекдот: Миллиарды раз бананы падали с дерева, когда его трясли А такое тоже происходило и не раз. В те времена, когда существующие тогда ОС никак не могли быть применены для видеоигр и игровых автоматов. Революцию тут совершила Atari. Если в Atari 2600 еще не было ОС и каждая игра имела свою собственную, то уже Atari 400 обзавелась примитивной ОС. Если можете дать ссылку на github с подходящим решением для реализации ботов - я только поддержу желание взять его за основу, чтобы минимизировать трудозатраты. Не можете? Все равно будете сами разрабатывать? Так к чему тогда отсылки к разработке ОС? Ну если игрок настолько недалек, что готов расстаться с прокачанной легендой ради 15 минут веселья - туда ему и дорога. В течении суток фоновый процесс проанализирует логи и отправит результаты техам для решения о предупреждении или блокировке аккаунта.

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

Какой же это бот? Сервер тебе передал вектор движения шарика. Твой клиент его считает и отображает. И легко может оказаться, что ты от этого шарика отправишься на респ, а сокомандник, который у тебя на экране был рядом с тобой - поедет дальше. Потому что на его клиенте он уже был далеко от шарика. Вряд ли. Таймаут довольно большой. Сервер тебя удалит с битвы намного позже, чем твоя бомба рванет.

Кто это написал? Я себе таких фраз не позволяю. Это как раз давно типовые решения. Как Kafka, так и распределенные вычисления. Для того, чтобы наш проект выиграл в тендере, мы должны предложить то, что не может предложить ни один из конкурентов. То есть мы должны или воспользоваться имеющимися know-how, или провести НИОКР для поиска новых. Специально для таких целей поддерживаем постоянные связи с научной средой МГУ, МФТИ, МИФИ и Бауманки. Иначе чем лучше конкурентов мы будем в тендере? Прошу прощения, но тот же самый ТО появился на свет и приобрел популярность именно благодаря каким-то своим инновациям, а вовсе не тупым копированием того, что уже и до него было. Именно так. Будет НИОКР - будет результат. Положительный или отрицательный, но обоснованный. До этого, мы можем только предполагать. Вы уж простите, но если бы все люди делали только то, что до них уже делали, то мы бы до сих пор голышом с дубинками бегали. И это в лучшем случае. Скорее вымерли бы. А какая от телепортации бота выгода? Очков за это не получишь. Кристаллов больше не заработаешь. Поприкалываться только? Или Вы уже про третий этап, о котором вообще толком мало что известно? Но тогда им же должен так же дополнительно шифроваться и весь мир, так как просчет дрона подразумевает учет его взаимодействия с миром. А это, как минимум, удваивает траффик от сервера. И это не считя того, что шифрование может загрузить сервер больше, чем требовалось бы для расчета физики бота на сервере без шифрования. Современные алгоритмы полного гомофорфного шифрования имеют весьма низкую производительность. А тут целый мир шифровать.

А что, флеш позволяет считать физику, но не позволит считать бота? Пока не вскроешь код - фиг разберешься.

Бритва Хэнлона Вы вообще понимаете, что доказать что что-то не существует невозможно? Овчинка должна стоить выделки. Одно дело - иметь преимущество в бою в течении 15 минут, а совсем другое - в течении 100 мс, да еще и не получить за это никаких очков, а лишь слегка напакостив противнику. Я не зря упоминал о синхронизации времени до 0.2-10 мс. Балансировщик точно знает, кто и когда управлял каждым ботом. Или с Kafka что-то случиться от лишних 20К раз в минуту с битвы? Или куда вы там логируетесь?

Вряд ли.

Издеваетесь или шутите? Если Вы не нашли утром свои тапочки то их что ли нет и не было? А это очень странно. Я все же рекрутингом тоже занимаюсь и командами руковожу. И, часто от джуна за 100 тыс. толка раз в пять меньше, чем от мидла за 200 тыс, и раз в десять меньше, чем от синьора за 300 тыс. И держишь джунов и мидлов только в расчете на их рос до синьора. А если роста нет - с ними расстаешься. И что дальше, если через 100 мс управление им будет утеряно? Выгода ничтожна, а риск блока аккаунта вполне реален.

Да кто же тебе это расскажет? Это знатный реверс-инжиниринг производить, чтобы такое выявить. Особенно если учесть, что распостранятся об использовании вычислительных ресурсов клиентов для своих внутренних технических нужд редко кто станет.

Без понятия и даже гуглить лениво. Потому что расчет ботов на клиенте для первого и второго этапа был явно озвучен в видоблоге. Таковы НУ. С другой стороны, с какой стороны не посмотри, но расчет ботов на сервере - это в любом случае дополнительная нагрузка. Ведь количество игроков остается тем же, причем еще и при росте количества одновременных боев. Отсюда резонный вопрос: за чей счет банкет? Кто будет на регулярной и постоянной основе оплачивать требующиеся дополнительные вычислительные ресурсы ЦОД? На одной чаше весов - разовые затраты конкретный проект с конечной целью. С другой - постоянные дополнительные платежи ЦОД. Это конечно не мне решать, не я владелец бюджета, но опыт мне показывает, что заказчик чаще выбирает понятные и конечные разовые затраты, чем постоянные платежи в течении неопределенного промежутка времени. В моем варианте реализации, когда клиент узнает, каким ботом он будет управлять следующие 100 мс не ранее, чем за 100 мс до этого, прикручивать к ботам античит смысла просто не имеет. А значит, остается нагрузка только примитивной валидации, что по любому ниже, чем полный просчет бота, с учетом всех физических воздействий от остальных ботов и игроков, которые сейчас сервером вообще не считаются. Вы серьезно хотите взвалить на сервер просчет физики всех ботов?

Альтернатива вдруг из софтверной компании резко превратилась в одного инди разработчика? Если бы для нее еще дошло, что если продать даже по сто рублей игрушку десяти тыс. клиентам, то это легко окупит два-три месяца, потраченные на ее разработку. И именно с указанным мной уровнем дохода. Не узнает, значит не пришлет подтверждение до окончания текущего кванта, что вынудит балансировщик отдать этот квант другому клиенту. У нас, простите, целых 100 мс предыдущего кванта, на то, чтобы определиться, кто будет считать следующий. Первый этап я даже не пытался обсуждать. Внимательно смотрим видеоблог про второй этап, где даже картиночка нарисована с ботами, расчитываемыми на клиентах.

Да никто с этим не спорит. Мы же о вычислительных задачах говорим. Не станешь же тот же микросервис на js писать? Вы прикалываетесь? Запустите NetHogs и увидите, что исходящий траффик клиента в среднем 3 килобита с редкими пиками до 4 килобит. Это же в какой деревне таким траффиком можно сеть перегрузить? Так в Multi-Edit это было из коробки еще в DOS. Другое дело, что добавление нового языка требовало еще и кодирования не языке MultiEdit. Единственный минус, который я указал выше, что автоматически модель проекта не обновлялась и требовалось периодически вручную запускать обновление, со сканированием файлов, измененых с момента последенго построения модели проекта. Ну не знаю. Интеграция с SVN еще ничего, а с интеграцией с Redmine я в свое время покувыркался, плюнул и сам на стороне Redmine на RubyOnRails добавил недостающие мне сервисы, доступные до этого только с пользовательского интерфейса, а не через REST . Еще раз, полный парсинг проекта и индекcация библиотек была в MultiEdit из коробки еще под DOS через ctags. Без особых требований к оперативке, благодаря наличию в нем встроенной БД и собственной эффективной системы кеширования.

Прошу прощения, но в каком случае тебе проще разъехаться с танком в узком проходе, когда он еще жив, или когда он уже труп? Я, порой, с респа до собственного трупа успеваю доехать

Ага, при очередном сетевом лаге на стороне сервера вся команда ботов из второго этапа дружно покидает игру, оставляя игроков в другой команде скучать? Не то, чтобы я был против, но так как проблема имеет решение, то должны быть серьезные основания от этого решения отказываться.

про г..но, палки и синюю изоленту, которую Вы пропагандируете А может все же выгнать архитектора с разработчиками, для которых это проблема и взять профессионалов, для которых это не будет проблемой, но с зарплатами 200-500 тыс. рублей в месяц, как в обычной для РФ профессиональной проектной команде? Плохо читали: Не обсчитывает 100 мс, а отвечает за управление ботом в течении 100 мс. При этом до истечения этих 100 мс уже узнает от балансировщика, каким ботом будет управлять следующие 100 мс, будет ли управлять ботом вообще, или добавится управление еще одним ботом. Так как в видоблоге явно было озвучено о том, что управляющие последовательности ботов будут приходить с клиентов, которым доверять ну никак нельзя, то смысл этой фразы для меня загадочен.

Потому что те, кому это нужно, используют, например, mono/dotnet на серверах или компилируют его в wasm для клиентов. А node.js остался только в клиентских приложениях, где вычислительных ресурсов хватает с избытком и для него. Сомневаюсь. С точки зрения сервера, бот будет очень мало отличаться от обычного игрока, и управляющие команды серверу для бота будут идти по той же сети, по тому же протоколу и такими же управляющими пакетами, как у игрока. Ну для меня ls - привычная команда консоли Linux, так что понять, о чем это Вы ведете речь я не могу Ну я бы не сказал, что на Multi-Edit проекты были сильно меньше, чем сейчас. Например, исходники Baan в нем редактировались и собирались. При этом интеграция с Redmine и SVN успешно работала, отладка правильно ходила по коду. Ну разве что ссылки на описание и имплементацию не обновлялись автоматически и их обновление требовалось периодически запускать вручную. В любом случае, посмотрев на Eclipse, когда он появился, я еще несколько лет оставался в Multi-Edit, так как последний был заметно шустрее.

Попробую объяснить на пальцах. Имеем уже озвученную проблему в видеоблоге об управлении ботами с клиентов и тем, что клиенты спонтанно могут исчезать, появляться или просто давать большие задержки при соединении с сервером. В общем случае, во втором этапе, в битве 10 на 10, у нас есть 10 ботов, которые должны просчитываться на не более, чем 10 клиентах. При этом клиентов может оказаться не десять, а четыре или пять. Да еще один из них с большими задержками, а другой с большой загрузкой системы, что не позовляет их использовать. Задача расчитывать движение, стрельбу, повороты башни, использование расходников и овердрайвов для N ботов на M<=N клиентах. При этом уже каждый клиент, фактически, имеет от сервера информацию о расположении и векторах движения всех объектов на карте, пусть даже и незначительно смещенное по времени, а потому различающееся на разных клиентах. С другой стороны, каждый игрок именно так и живет, поэтому если вдруг из 20 движущихся объектов на карте 2-3 объекта (игрок и бот(ы) расчитываемые в его браузере) будут пользоваться одинаковой картиной мира - ничего страшного не произойдет. Результатом расчета AI бота, утрированно, будет посылка серверу комбинации клавиш, как будто этим ботом управлял игрок с клавиатуры. А не утрировано - такие же сообщения серверу, которые возникают при нажатии клавиш игроком при управлении своим танком, только относящиеся к боту. И вот я в упор не могу понять, чем Вас так смутило решение расчитывать эти сообщения управляющие ботом квантами, например, по 100 мс, на выбранном балансировщиком клиенте? Тут даже проще, чем у меня, так как свой порядок в очереди управления каждым ботом клиент может узнавать от балансировщика заранее. Синхронизировать время можно с точностью 0.2-10 мс. А так как сервер все равно валидирует управляющие последовательности, то проблема с внеочередной попыткой клиента поуправлять одним из ботом легко блокируется. В результате, задержку в 100-200 мс мы получим только не получив ожидаемую управляющую последовательность от очередного клиента и передав ее на расчет другому клиенту балансировщиком. Не очень приятно, но не критично.

Аж интересно стало. Почему Multi-Edit не IDE и что он такого не мог, чего может VS Code? Я в свое время к нему сам десятки плагинов понаписал.