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

В этой статье я, Артур, основатель и гейм-дизайнер инди команды ArmNomads Games (состоящей из трех человек), хочу поделиться пройденным нами путем в опасные дебри мобильного гейминга. От идеи до конечного релиза.



Главной задачей при создании идеи был поиск определенного издателя и целевой аудитории. Мы прекрасно понимали, что сделать что-то универсальное очень сложно. Руководствуясь ограниченностью ресурсов и времени, было принято решение сотрудничать с издателем Ketchapp, но, в то же время, иметь пути отхода. Для этого мы предприняли попытку сочетать минималистичный геймплей и красивый арт. Имея опыт работы с движком Unity, мы думали, что это лучший вариант. Из плюсов этого движка можно отметить быстроту разработки, графический интерфейс и кроссплатформенность.

Введение

Однажды мне потребовалось создать защищенный канал связи между своим сервером и своим приложением. Я помнил, что в документации к Boost Asio упоминалось, что он может работать с защищенными соединениями, используя OpenSSL. Я начал искать информацию по этой теме, но, увы, мало что нашел, тем более под Windows. Так что теперь, разобравшись с этим вопросом, я решил написать эту инструкцию, чтобы другим людям было проще разобраться.

Хочу обратить ваше внимание на важную, на мой взгляд, проблему, которой пренебрегают даже самые крупные и инновационные компании мира. Проблема заключается в отсутствии у большинства доменов SPF-записи, которая защищает домен от его несанкционированного использования в электронной почте.
SPF (Sender Policy Framework) представляет из себя текстовую запись в TXT-записи DNS домена. Запись содержит информацию о списке серверов, которые имеют право отправлять письма от имени этого домена и механизм обработки писем, отправленных от других серверов.
Например, SPF-запись «example.com. TXT «v=spf1 +a +mx -all»» говорит о том, что отправлять письма от имени домена «example.com» могут сервера, указанные в A и MX-записях этого домена, а письма, отправленные от других серверов должны быть удалены (Fail).

Многие статьи об оптимизации производительности, в первую очередь пытаются «заглянуть под капот» Angular и перегружают читателя информацией о внутренней организации фреймворка. Знакомство с внутренними механизмами работы очень важно, но в данной статье я попытался собрать самые простые примеры, которые оказывают наибольшее влияние на производительность приложения и помогают максимально быстро решить типичные проблемы.

Почему видеохостинг такой дорогой

Из всех видов статических файлов, используемых на веб-сайтах, с видеороликами связаны наиболее жёсткие требования к хостингу:

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

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

Чтобы решить эту проблему, нам пришлось сделать софт умнее.

Третьего дня, во время сортировки старых закладок, попалась мне на глаза блок-схема с алгоритмом выбора STL-контейнера. «Почему же для контейнеров есть, а для стандартных алгоритмов нет? — подумал я. — Это необходимо исправить». Подумано — сделано. Сперва планировалось за пару часов нарисовать нечто простенькое, но в дальнейшем обнаружилось, что алгоритмы никак не хотят умещаться в простенькую схему. Я слегка увлекся, и спустя два вечера схема вобрала в себя 84 алгоритма, а также немного дополнительной информации. Под катом можно увидеть, что получилось в итоге.

Предисловие

Данная статья выросла из проблемы, которую мне относительно недавно пришлось решить: скорость кода, предназначенного для работы одновременно в нескольких потоках, резко упала после очередного расширения функционала, но только на Windows XP/2003. С помощью Process Explorer я выяснил, что в большинство моментов времени исполняется только 1 поток, остальные находятся в ожидании, причём TID активного потока постоянно меняется. На лицо явная конкуренция за ресурс, и этим ресурсом оказалась куча по умолчанию (default heap). Новый код активно использует динамическое выделение/высвобождение памяти (копирование строк, копирование/модификация STL контейнеров большого размера), что собственно и привело к возникновению данной проблемы.

Немного теории

Как известно, аллокатор по умолчанию (default allocator) для STL контейнеров и std::basic_string (std::allocator) выделяет память из кучи по умолчанию, а операции выделения/высвобождения памяти в ней являются блокирующими (косвенное подтверждение). Исходя из этого, при частых вызовах HeapAlloc/HeapFree мы рискуем намертво заблокировать кучу для других потоков. Собственно это и произошло в моём случае.

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

В июне этого года в России был принят новый стандарт блочного шифрования — ГОСТ Р 34.12-2015. Этот стандарт помимо старого доброго ГОСТ 28147-89, который теперь называется «Магма» и имеет фиксированный набор подстановок, содержит описание блочного шифра «Кузнечик». О нем я и расскажу в этом посте.

В этой статье по геймдизайну Майк Стаут, в прошлом дизайнер студии Insomniac Games, делится полезной информацией о глубине игровых механик и рассматривает вопросы их излишней перегруженности на примере серии игр Ratchet & Clank.

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

Внимание! Реклама! Пост оплачен Капитаном Очевидность!

Ниже под катом вы найдёте 15 пунктов, описывающих правильную организацию ресурсов, доступных по протоколу HTTP — веб-сайтов, «ручек» бэкенда, API и прочая. «Правильный» здесь означает «соответствующий рекомендациям и спецификациям». Большая часть ниженаписанного почти дословно переведена из официальных стандартов, рекомендаций и best practices от IETF и W3C.



Вы не найдёте здесь абсолютно ничего неочевидного. Нет, серьёзно, каждый веб-разработчик теоретически эти 15 пунктов должен освоить где-то в районе junior developer-а и/или второго-третьего курса университета.

Однако на практике оказывается, что великое множество веб-разработчиков эти азы таки не усвоило. Читаешь документацию к иным API и рыдаешь. Уверен, что каждый читатель таки найдёт в этом списке что-то новое для себя.

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

Если вкратце — эксперимент провалился, в людях я в очередной раз разочаровался, а в последующих обновлениях мы пришли к банальной схеме «платежи + реклама». Зато удалось нащупать такой баланс между бесплатным контентом, премиум конктентом и ненавязчивой рекламой, который позволил и не разочаровать игроков (средняя оценка на Android — 4.75 при ~280.000 установок!), и окупить разработку (около 150.000 руб).

О рекламе стоит упомянуть сразу отдельно — в нашем случае это исключительно «видеореклама с вознаграждением за просмотр» (rewarded/incentivized video ads). В конце статьи расскажу, каких значений eCPM можно ожидать при ~10.000 показов в день в России от таких платформ, как UnityAds, Vungle, AdColony и Applovin.

Представляем вам Intel Media Server Studio 2015 – набор инструментов для разработки, отладки и оценки медиа приложений и решений корпоративного уровня на базе процессоров Intel.
Если вы занимаетесь как раз такими решениями, то сейчас самое время попробовать Intel MSS, ведь буквально недавно вышло ее очередное обновление. Под катом — список основных улучшений, появившихся в новой версии.

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

В данной статье я затрону некоторые принципы безопасности, касающиеся всех современных систем, а также поделюсь своими находками, сделанными благодаря выполнению ROP-тестов на моей PS4.

Если вы плохо знакомы с применением эксплойтов, вам cледует сначала прочитать мою прошлую статью про взлом игр DS с помощью уязвимости целостности стека (stack smash) в файлах сохранений.

Загрузить всё необходимое для собственных экспериментов можно здесь, на данный момент поддерживается исключительно прошивка 1.76.

Началось все с того, что я оптимизировал отдачу ошибки HTTP 408 Request Timeout в сервере приложений Impress, работающем на Node.js. Как известно, у нодовского http.Server есть событие timeout, которое должно вызываться для каждого открытого сокета, если тот не закрылся за указанное время. Хочу уточнить, что не для каждого запроса т.е. не для каждого события request, функция которого имеет два аргумента (req, res), а именно для каждого сокета. Через один сокет может последовательно поступить много запросов в режиме keep-alive. Если мы задаем это событие, через server.setTimeout(2 * 60 * 1000, function(socket) {...}) то должны сами уничтожать сокет socket.destroy(). Но если не установить свой обработчик, то http.Server имеет встроенный, который уничтожит сокет через 2 минуты автоматически. На этом самом таймауте можно отдать ошибку 408 и считать инцидент исчерпанным. Если бы не одно но… С удивлением я обнаружил, что событие timeout вызывается и для тех сокетов, которые подвисли и для уже получивших ответ и для закрытых клиентской стороной, вообще для всех, находящихся в режиме keep-alive. Это странное поведение оказалось достаточно сложным, и я расскажу об этом ниже. Можно было бы вставить одну проверку в событие timeout, но со своим идеализмом я не удержался и полез исправлять баг на уровень глубже. Оказалось, что в http.Server режим keep-alive реализован не то что не по RFC, а откровенно не дописан. Вместо отдельного timeout для соединения и отдельного keep-alive timeout, там все на одном таймауте, который реализован на быстрых псевдо-таймерах (enroll/unenroll), но задан по умолчанию в 2 минуты. Это было бы не так страшно, если бы браузеры хорошо работали с keep-alive и переиспользовали его эффективно или закрывали бы неиспользуемые соединения.

Вас интересуют игры? Хотите создать игру но не знаете с чего начать? Тогда вам сюда. В этой статье я рассмотрю простейший физический движок, с построения которого можно начать свой путь в GameDev'e. И да, движок будем писать с нуля.

Все началось с того что я наткнулся на статью. Вкратце, в ролике показано, как два пользователя подключаются к сети заведения и заходят в браузер, в котором открывается страница с предложение авторизоваться через «ВКонтакте»: необходимо ввести логин/пароль, вот только домен не vk.com, типичный фишинговый сайт. В итоге, при такой авторизации передаются третьей стороне учетные данные, и устанавливается приложение с неограниченными правами, которое имеет круглосуточный доступ к вашей странице.

Если погугулить можно найти большое количество компаний, готовых сделать подключение к вашему Wi-Fi через регистрацию в SMM.

Классические компьютерные игры начались ещё, собственно, до появления компьютеров в виде интерактивных книг. Скорее всего, в детстве у вас была одна такая либо Браславского, либо вообще из цикла про Стальную Крысу Гаррисона.



Смысл очень прост: внутри подаётся сюжет, который зависит от вашего выбора. Простейшее ветвление такое: вы дошли до развилки. Если вы хотите повернуть направо, откройте страницу 11, если налево – 182. На соответствующих страницах будет продолжение истории про то, что случится после вашего выбора.

Базовый сюжет строился в виде системы узлов и переходов. За один проход вы задействовали примерно 25-35% страниц книги.



То есть техническая вариативность сводилась к тому, что вы всё равно получали 80% основного сюжета, но просто не всегда линейно и не всегда с одной и той же точки зрения. И автоматизации там не было почти никакой, кроме того, что вы листали страницы.

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