Основатели разработчика мобильных игр Playrix и фонд Льва Левиева LVL1 увеличили свою долю в компании «Комитет», которая издаёт Vc.ru, TJournal, DTF и Coub. По итогам очередного раунда и выкупа инвесторами долей у партнёров и сотрудников «Комитет» получил $2 млн инвестиций на развитие общей для всех проектов контентной платформы.
Игорь Бухман,Читать полностью »
Disclaimer: Эта история произошла несколько лет назад. Но кажется, что она и до сих пор не утратила актуальности.
… Мы разрабатывали Gardenscapes. В нём всё ещё оставались следы старого Gardenscapes под Windows. Он даже был не Match-3, а Hidden Object. И никто даже и представить не мог высот, которых достигнет игра.
И вот в один прекрасный день…
Читать полностью »
Команда должна фокусироваться на создании прекрасных и успешных игр, для всего остального есть CI.
Где мы применяем CI? Какие подходы и концепции используем? Зачем собирать и тестировать билды? Развернутый рассказ о CI и о том, как он устроен в Playrix, потянет на курс лекций. Под катом — краткая выжимка и немного акцентов.
Привет, я Леонид Парфёнов. Это Вологда, центр Вологодской области, где я родился и вырос и которая для меня прежде всего и есть Россия.
Кафедральный Софийский Собор XVI века:
А это Дублин, Ирландия. Кафедральный Собор Святого Патрика, основанный в XII веке. И кажется, что между этими городами нет ничего общего… Теперь есть. Самые богатые вологжане за все девять веков существования Вологды переехали отсюда сюда:
Братья Игорь и Дмитрий Бухманы, разработчики компьютерных игр, владельцы компании Playrix. Ведущее мировое агентство мира «Блумберг» оценивает сейчас их бизнес в 2,8 миллиарда доллардов, по 1,4 миллиарда на брата. Бизнес был построен в Вологде, но теперь компания перенесена братьями Бухманами в Дублин.Читать полностью »
Привет! Мы тут в Playrix решили сделать свой Unity3D. А там есть Animator. В этой статье я расскажу, как мы сделали его у себя и как он работает.
У нашей компании есть свой игровой движок, который используется для всех разрабатываемых игр. Он предоставляет всю важную базовую функциональность:
Однако в нем не хватало того, чем так ценится Unity, — удобной системы организации сцен и игровых объектов, а также редакторов к ним.
Здесь я хочу рассказать, как мы внедряли все эти удобства и к чему пришли.
Читать полностью »
Релиз часто подкрадывается незаметно. И любая ошибка, внезапно обнаруженная перед ним, грозит нам сдвигом сроков, хотфиксами, работой до утра и потраченными нервами. Когда подобный аврал стал происходить систематически, мы поняли, что так больше жить нельзя. Было решено разработать систему всесторонней валидации, чтобы спасти рядового Райана разработчика Артёма, который перед релизом уходил домой в 9 вечера, или в 10, или в 11… ну вы поняли. Идея была в том, чтобы разработчик узнавал об ошибке, пока изменения еще не попали в репозиторий, а он сам не потерял контекста задачи.
Сегодня вносимые изменения бережно проверяются вначале локально, а затем серией интеграционных тестов на сборочной ферме. В этой статье мы поговорим о первом этапе проверки — статическом тестировании, которое следит за корректностью ресурсов и анализирует код. Это первая подсистема в цепочке и на её долю приходится основная масса найденных ошибок.
Читать полностью »
Художники нарисовали яркую графику, программисты встроили ее в игру, аниматоры добавили движения — казалось бы, все, готово. Но нет, менеджерам не нравится:
«Надо убрать серые пятна и белые линии. Тут пульсирующая кнопка дергается, там прогресс-бар лесенкой идет».
Смотришь игровые ресурсы — нет в них ничего такого, все спрайты обрезаны. Читаешь код — формулы правильные, точности шейдера хватает. Но результат все равно получился неважный. Где ошибка?
Небольшой опрос для тех, кто уже знает откуда берутся артефакты. Что делать в такой ситуации?
Какой вариант ответа правильный, почему именно он и как побороть артефакты графики читайте под катом.
Читать полностью »
Одна из основных характеристик успешной мобильной игры — ее постоянное оперирование: это и переработка существующего контента, и добавление нового. Но есть и обратная сторона медали – нужно постоянно оценивать риски изменений в очередной версии приложения. Необходимо заранее представлять, как изменения в апдейте повлияют на показатели проекта. Иначе можно оказаться в ситуации, когда во время планового обновления внезапно ломается баланс и нужно срочно поднимать всю команду разработки для выпуска хотфикса.
Еще до сборки нового продакшен-билда мы должны понимать, на какие показатели повлияет нововведение. Ведь в новых версиях игры может быть множество изменений баланса. Без предварительного планирования неизбежно возникнет один из таких вопросов: «Что же повысило ARPU в Канаде — локальные мероприятия в честь национального праздника или общее повышение сложности группы каких-то уровней; а может, просто звезды так совпали?». Безусловно, и после выхода апдейта выполняется всесторонний анализ результатов, но понимать характер изменений нужно заранее.
Finite State Entropy (FSE) – алгоритм энтропийного кодирования, чем-то похожий и на алгоритм Хаффмана, и на арифметическое кодирование. При этом он взял лучшее от них обоих: работает так же быстро, как хаффмановский, и со степенью сжатия как у арифметического кодирования.
FSE принадлежит семейству кодеков ANS (Asymmetric Numeral Systems), изобретённых Яреком Ду́дой. На основе его исследований Ян Коллет разработал оптимизированный вариант алгоритма, впоследствии названный FSE.
В заметках Яна Коллета непросто разобраться, поэтому я изложу объяснение в несколько ином порядке, более удобном для понимания, на мой взгляд.
