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

За исключением TDM, где цель игры именно высокий УП, все именно так. Притащить даже половину флагов, сохранив УП выше единицы - возможно только при сильном дисбалансе в командах. А на точках и, тем более, осаде, можно сидеть в углу набивая УП, не принимая никакого участия в захвате точек. Как и делают нубы. Хочется пострелять - ну так стой у точки и стреляй оттуда. Ах, там же сносят сразу же и УП низкий будет!

Вот я и не могу понять, зачем оно было указано? Ведь высокий УП в любом режиме, кроме TDM, говорит о том, что игрок нуб, не понимающий цели режима и играющего всегда в "Командный бой", вне зависимости от того, в какой режим зашел.

И какая же связь между контролем точек и УП? Да и в DM вполне можно быть на первом месте с УП меньше единицы. Там же не играет роль, сколько раз попал на респ. Важно только сколько фрагов набил.

Играл что ли только в "Командный бой"? Я просто не понимаю, о чем может говорить УП в остальных режимах, где можно оказаться в ТОП-3 c УП 0.5

Ну я лет тридцать назад поработал руководителем отдела разработки лет пять. Больше не осилил, так как самому все же хоть иногда кодить хочется. Но как ни отбиваюсь, все равно, то PM назначат, то архитектором, то хотя бы тимлидом.

Мне уже под 60. К моим годам тоже руководителем станешь, если будет на то желание )

Тоже раз в квартал приходится наматывать три сотни километров в московский офис и обратно ) У меня коллега так из Кемерово раз квартал на такие совещания летает. И ничего )

Я тоже руководитель. Очень даже возможно. Кто мешает проводить планерки и совещания по интернету? Особенно, если все твои подчиненные тоже на удаленке.

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

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

Да просто доверенность (токен) не успели отозвать и все. У меня как-то токен больше года после увольнения еще работал )

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

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

Это озвучка для детей дошкольного возраста?

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

В 2012 поиграть от души не стоило вообще ни копейки. Завел несколько десятков мультов и скриптом собираешь каждый день подарки. Так как играешь каждый день разным, то припасов немеряно, звание растет медленно, а значит спокойно сразу же покупаешь вооружение, как только оно становится доступным по званию.

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

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

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

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

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

А в продуктиве - кворум. Даже если где-то не мультимастер, а мастер-рабы (slaves), то это приводит всего лишь к выбору нового мастера кворумом. Зависит от компонентов. Например, в Kafka отказаться от зукипера в пользу кворума стало возможно только чуть больше года назад. А стабилизировано это решение для продуктивного использования было уже в текущем году. Так что наличие единой точки отказа до сих пор вполне возможно. Другое дело, что горячее переключение это не исключает. Просто логика горячего переключения должна быть прописана вручную, а не определяется кворумом динамически. К сожалению, лекарства от всех болезней не бывает, так же как и универсального решения. Для СУБД - один подход, для брокеров сообщений - другой, для (микро)сервисов - третий. Ну да, k8s, но подходы разные.

Это не ко мне Читать не пробовали научиться? Когда действительно бывает необходимость именно вставки, используютс другие решения. Например, TimescaleDB у меня поток в 50-60 тыс. записей в секунду держала без напрягов на далеко не топовом железе.

Это если снапшот есть. Я же как раз веду речь про ситуацию, когда при старте Redis снапшота не оказалось или он оказался поврежденным. И Redis больше ничего не оставалось, как загрузить для кеширования данные из реляционной СУБД, где они не обновлялись длительный срок. Никто не говорил, что запись в РСУБД из кеша не производится. Она, скорее всего, производится намного чаще, чем случаются рестарты. Я говорю, что уже не раз сталкивался с тем, что запись в лог об ошибке при такой операции игнорировалась больше года. Если Redis используется в качестве кеша не только для записи, но и для чтения, то внешних проявлений не наблюдается. В том то и дело, что в кеше при такой системе тоже только агрегаты. Если на пальцах, когда игрок использовал повышенную защиту, в Redis идет не вставка новой записи, а обновление существующей. А сам факт того, что в такой то момент времени количество повышенных защит у игрока стало на единицу (два в случае защитника, три в случае кризиса) меньше остается только в WAL (AOF).