Предыдущая статья про баланс персонажей и снаряжения собрала много отзывов и я решил не тянуть с продолжением.

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

Бонусом в конце — несколько ссылок по теме.

По опыту, многие начинающие геймдизайнеры избегают работы с балансом, словно это черная магия или нужно иметь серьезное математическое образование. Специалисты поопытней уже авторитетно заявляют, что математика не нужна.

В первую очередь надо разбираться в самих играх, а потом уже уметь что-то считать. Поэтому я расскажу о работе с балансом без использования математики — на палках урона посмотрим, как уравновесить силу оружия, чем танк отличается от разбойника, и как точки спавна влияют на винрейт.

Статья будет полезна тем, кому надо заняться балансом, но не знает с чего начать, а также начинающим геймдизайнерам, которые будут выбирать специализацию. Ну и всем, кто просто интересуется, чем занимаются ГД, когда не придумывают новые виды лутбоксов.

Как человек, который в качестве хобби начал делать свою первую игру без всякого опыта программирования, постоянно читаю разные туториалы и гайды по геймдеву. А как человек из PR и журналистики, который часто работает с текстом, хочу сценарий и персонажей, а не просто геймплейные механики. Будем считать, что перевел эту статью для себя, как напоминание, но хорошо, если кому-то тоже зайдет.

А еще там разбирается характер персонажей на примере сторонников теории плоской Земли.


Сценарий фильма «Апокалипсис сегодня» (1979) по мотивам книги Джозефа Конрада «Сердце тьмы» (1899)

Как бы ни старались геймдизайнеры, в любой игре можно найти механику или контент, которые страдают от недостаточно детального продумывания. Последствия — от мелких эксплойтов до ненужных или даже вредных фичей.

В помощь геймдизайнерам придумана масса инструментов: форматы ГДД, различные чек-листы, юзерстори, портреты, агенда и так далее. И все равно этого не хватает.

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

На днях тестировали новую графику в War Robots и получили уйму положительного фидбека от игроков. И хотя речь о мобильной графике, места для роста там очень много. С десктопом еще интереснее. Если раньше на рендер качественной сцены с фотореалистичными моделями могли уйти недели, то сейчас это делается real-time в самом Unreal. Увидел работы 3D-художника на ArtStation, а следом нашел интервью с ним на 80 level, выглядит круто. Под катом преимущественно картинки и ролики.

Generative art (генеративное или процедуральное искусство) может отпугнуть, если вы никогда с ним раньше не сталкивались. Если коротко, то это концепция искусства, которое буквально создает само себя и не требует хардкорных знаний программирования для первого раза. Поэтому я решил немного разбавить нашу ленту, погнали.

Я всегда любил и умел торговаться. Со стороны покупателя это своего рода игра на получение максимальной выгоды, а для продавца — способ показать, что он ценит труд и нелегкую жизнь человека, которому делает скидку. Видел, как торгуются за 10 рублей, за 5 и даже жвачку.

Статья же призвана раскрыть определенную точку зрения на ведение переговоров для заключения контрактов с максимально выгодными для вашей компании условиями. За 14 лет эволюции от инженера первой категории до заместителя техдиректора по направлению внутренней и внешней инфраструктуры (а также консалтинга медиа-холдингов, стартапов, криптобирж и соцсетей) мне пришлось договориться о сотнях контрактов с контрагентами. Могу сказать, что подобный опыт применим везде — выбираете ли вы дата-центр, закупаете оборудование или ищите новый автомобиль. Как говорится: смелость города берет, а наглость и деревнями не брезгует.

Рассказывать о новых проектах это, конечно, хорошо, но не всегда всё получается, как мы хотим.

В общем, начали тут вспоминать факапы из прошлого, когда решение одной проблемы прибавляло новых, увлеклись и решили поделиться парочкой. Как забанить невиновных игроков, заддосить собственные сервера, ошибиться в одной букве и словить тонны негатива от пользователей — вот это всё, как мы любим.

Количество серверов в нашей инфраструктуре уже перевалило за 800, хотя еще год назад их было около 500. Для работы с этим всем активно используются решения от Red Hat. Про FreeIPA — для организации и управления доступами для Linux-серверов — мы уже писали, сейчас же я хочу затронуть тему управления конфигурациями. Для этих целей у нас юзается Ansible, а с недавних пор к нему добавился AWX — представленное полгода назад решение для централизованного управления плейбуками, расписанием их запусков, управления инвентори, учетными данными для доступа к серверам, а также механизм callback'ов для запроса конфигураций со стороны сервера.

Из-за ряда вещей мы не сразу смогли интегрировать его для работы с нашим основным проектом War Robots, но полей для проверки AWX нашлось предостаточно. Во-первых, в компании ведутся разработки новых проектов, которым нужны dev/stage-окружения и, само собой, production-окружения в перспективе. А недавно к этому добавился еще и проект для внутренней аналитики, которому потребовался полностью новый кластер.

Итак, начнём!

Первый прототип (например, игры в новой для вас нише) часто делается «на коленке» из палок и самизнаетечего. Причем палки, как правило, тоже из этого самизнаетечего. И на то есть несколько причин.

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

Забегу вперед и расскажу, что сейчас DAU в наших проектах около 1,5 млн. Но так было не всегда.

Несколько лет назад появился прототип игры War Robots (тогда она еще называлась Walking War Robots). Это был первый опыт Pixonic в жанре тактического PvP, поэтому многие будущие проблемы были заложены в коде изначально. Но несмотря на ряд трудностей (популярность проекта стремительно росла, небольшая команда не могла полностью изменить архитектуру игры в краткие сроки), нам в итоге удалось свести к минимуму количество читеров, а также исправить другие недостатки оригинального кода. Расскажу немного подробнее.

Необходимость мониторинга должна быть очевидна практически для любой компании, однако я не раз сталкивался с примерами, когда к такому выводу ребята приходили только после падения продакшна. Причем нередко команда узнавала об этом уже постфактум — от своего генерального директора, которому на недоступность проекта пожаловались его друзья, решившие вдруг взглянуть на стартап. И вот он в гневе звонит членам команды с вопросом даже не «почему все упало», а почему он об этом знает, а они — нет. И тут им в голову приходит мысль, а почему бы не настроить мониторинг? Казалось бы, что может быть проще…

Нам, например, круглосуточно требуется мониторить более 46 000 метрик на более чем 500 серверах в 6 дата-центрах и 4 странах, а DAU игры War Robots стабильно переваливает за 1 500 000 человек.

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