С момента выпуска в начале 2016 года Clash Royale скачали почти 200 миллионов раз, и игра заработала примерно один миллиард долларов только на внутриигровых покупках. Уникально в Clash Royale ещё и то, что она, скорее всего, заработает со временем больше, чем Clash of Clans. Теперь сравните это со всеми играми франшизы King, которые обычно с каждым разом показывают всё худшие результаты.

По моему мнению, Clash Royale — это лучшая игра из всех, созданных для устройств с сенсорным экраном. Я забрасывал и удалял её больше раз, чем могу посчитать. Но и устанавливал я её больше раз, чем удалял. Эта статья возникла из-за моего пристрастия к этой игре. В ней я подробно проанализирую элементы, привязывающие нас к этому шедевру.

Вот ещё пара интересных постов о Clash Royale:

5 причин, по которым я хочу бросить Clash Royale
Анализ следующей игры Supercell на миллиард долларов

1. Обновления

Как только вы устаёте от этих эмоциональных «американских горок», известных как Clash Royale, они добавляют ещё одно обновление с новыми картами. Картами, которые обязательно заставят вас начать новую охоту за трофеями.

Если забыть о печальном турнирном обновлении июля 2016 года, который обвалил доходы Clash Royale до минимума, выпускаемые раз в два месяца обновления получаются или хорошими, или потрясающими (подробнее: Clash Royale Tournaments Update Disappoints).

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

Путешествие по чёрно-белому метафорическому миру платформера OVIVO приводит в восторг, ты всё больше погружаешься в атмосферу минимализма… И даже не замечаешь, что в игре нет ни одного слова, всё на уровне чистой интуиции. Под катом история о том, как это работает и каких ошибок стоит избегать при создании такой игры. Передаю слово IzHard.

Мы выложили в открытый доступ видеозаписи последних пяти лет конференции разработчиков высоконагруженных систем HighLoad++. Смотрите, изучайте, делитесь и подписывайтесь на канал YouTube.

Более терабайта записей и 500 видеороликов! Это всё, под катом только реклама :)

Перейти в канал YouTube!

— Добрый день! Почём мороженое?
— Вот же ценник!

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

Очень много явно странных вопросов имеют совсем не то значение, которое озвучивается. Это касается и продаж, и обычной жизни. Давайте разберём ещё пару примеров. Начнём с риторических вопросов в духе «А этот пазл точно собирается? Там все детали внутри?».

Итак, сегодня мы соберём генератор миниатюрок на базе любимого народом веб-сервера — nginx-а. Что примечательно, сделаем мы это без единого гвоздя, т.е. без единой строчки кода, не считая конфигурации.

Итак, в новостях снова пишут, что кто-то еще умер из-за игромании. Да, опять Корея.

Какого ...? послушайте, я не пытаюсь доказать что видео игры — это героин. Я полностью понимаю, что в данном случае у жертвы было много проблем в жизни. Но, половина из вас знает что World of Warcraft затягивает и что доктора считают игровую зависимость серьёзной проблемой. А вопрос вот в чем: может быть какие-то игры намеренно разрабатывались, чтобы заставлять вас играть в них, даже если вы не получаете от этого удовольствия?

Эта статья является переводом цикла из четырёх статей «Linear algebra for game developers», написанных David Rosen и посвящённых линейной алгебре и её применению в разработке игр. С оригинальными статьями можно ознакомиться тут: часть 1, часть 2, часть 3 и часть 4. Я не стал публиковать переводы отдельными топиками, а объединил все статьи в одну. Думаю, что так будет удобнее воспринимать материал и работать с ним. Итак приступим.

Несколько дней назад в интернете появилась новость о самой масштабной битве в игре EVE Online, в которой было уничтожено кораблей на 300000 долларов. Многим оказалось интересно, как в какой-то битве в онлайн игре можно потерять столько денег. Но, большинство текстов про эту эпических масштабов битву написано языком, в котором не играющему в EVE Online человеку понятны лишь предлоги и матерные слова. Пару дней назад я наткнулся на очень интересную статью, где всё произошедшее описано очень простым и понятным языком.

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

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

Практически каждая современная графическая сцена являет собой результат работы некоторого кода, написанного специально для GPU — от реалистичных эффектов освещения в новейших ААА-играх до 2D-эффектов и симуляции жидкости.


Сцена в Minecraft до и после применения нескольких шейдеров.

Цель этой инструкции

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

Я работаю с node.js более трех лет и за это время успел хорошо познакомиться с платформой, ее сильными и слабыми сторонами. За это время платформа сильно изменилась, как, собственно, и сам javascript. Идея использовать одну среду и на сервере и на клиенте пришлась многим по душе. Еще бы! Это удобно и просто! Но, к сожалению, на практике все оказалось не так радужно, вместе с плюсами платформа впитала в себя и минусы используемого языка, а разный подход к реализации практически свел на нет плюсы от использования единой среды. Так все попытки реализовать серверный js до ноды не взлетели, взять тот же Rhino. И, скорее всего, node ждала та же участь, если бы не легендарный V8, неблокирующий код и потрясающая производительность. Именно за это его так любят разработчики. В этой серии статей, я постараюсь рассказать о неочевидных на первый взгляд проблемах и тонкостях работы, с которыми вы столкнетесь в разработке на nodejs.

Вы наверняка думаете, что писать на php — это просто. И «hello, world» выглядит примерно так так:

<?php
echo 'Hello, world!';

Конечно, чего еще ожидать от языка с низким порогом входа. Ну да, именно так и было раньше. Много лет назад. Но теперь, в 2017 году никто так уже не делает. Давайте рассмотрим, почему, и попробуем построить наше более реалистичное hello-world приложение по шагам, а их, скажу сразу, получилось не мало.

В этом топике я хотел бы рассказать о том, как устроена кассандра (cassandra) — децентрализованная, отказоустойчивая и надёжная база данных “ключ-значение”. Хранилище само позаботится о проблемах наличия единой точки отказа (single point of failure), отказа серверов и о распределении данных между узлами кластера (cluster node). При чем, как в случае размещения серверов в одном центре обработки данных (data center), так и в конфигурации со многими центрами обработки данных, разделенных расстояниями и, соответственно, сетевыми задержками. Под надёжностью понимается итоговая согласованность (eventual consistency) данных с возможностью установки уровня согласования данных (tune consistency) каждого запроса.

NoSQL базы данных требуют в целом большего понимания их внутреннего устройства чем SQL. Эта статья будет описывать базовое строение, а в следующих статьях можно будет рассмотреть: CQL и интерфейс программирования; техники проектирования и оптимизации; особенности кластеров размещённых в многих центрах обработки данных.

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

Например, мы захотели создать незатейливую RPGMMO-шечку «убийцу WoW», и у нас уже почти все готово. Мы уже нафантазировали, какая в игре будет крутая механика боя и система умений. Дело осталось за малым – абстрактные мысли превратить в конкретные значения. Причем, каким-то образом, сочетание этих значений должно убедить игрока в том, что фраза «баланс – говно» — это не про нас.

Развлекательная функция игр – вещь абстрактная. И чтобы создавать игровые миры, в которые пользователю захочется погружаться с головой снова и снова, придется очень многое продумать. Сара Сантиллан, Lead Designer в Boomzap Entertainment, рассказывает о требованиях к созданию игрового функционала. Что понадобится, а что – нет в этом творческом процессе?

Как-то утром, пробегая мимо славного урока, я подумал: «Это круто, только всё же кой-чего тут не хватает». Если надо много кода написать легко и быстро, то нужна нам, без сомнений, для сего библиотека. Только как её нам выбрать, если каждый, кто умеет на гитхабе заводить репозиторий, запилил велосипед свой? И об этом для тебя, друг, напишу сегодня пост вдруг.

У вас нет ни гроша? Питаетесь Дошираком? Отчаянно пытаетесь заработать пару баксов своим инди-детищем? Все мы были в точке невозврата в разработке, когда хотели получить какой-нибудь доход от игр, но не знали в какую сторону двигаться. На самом деле, иногда мы даже не представляли всех возможностей…

Хочу рассказать сообществу о проведённом мной эксперименте.

Мне всегда нравились игры, в которых есть физика. То есть, некоторые процессы не управляются скриптами, а эволюционируют во времени, следуя физическим законам. Из этого проистекают сложность и непредсказуемость игрового процесса.

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

Или те же гоночки: до чего приятней на полной скорости сшибать людей, рекламные щиты и помойки, чтобы разлетались во все стороны, вместо того, чтобы мгновенно останавливаться, врезаясь в мёртво врощенный в землю столб.

Или ещё замечательный пример — Kerbal Space Program. Там физика уже является непосредственым источником геймплея.

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

Я давно мечтал сделать именно такой, до предела физически реалистичный римейк Scorched Earth. Но все мои эксперименты с моделированием физических систем упирались в неумолимо медленные процессоры. Тысяча-две частиц были пределом для real-time симуляции.

Но недавнее моё «открытие» изменило ситуацию.

В первую субботу февраля состоялась первая неформальная игровая встреча Game Design meetup. И сегодня мы хотим поделиться материалами выступлений, под катом вас ждут презентации и видеозаписи четырех докладов.

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

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

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

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

Поехали?