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

Может ли существовать тороидальная планета?

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

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

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

Черт! Он вылез опять! Я ведь еще успел только до Варварки дойти.

И, повинуясь зову природы, я расчехлил опять свое оружье.

На прошедшей неделе в Инстаграм Илона Маска появилась фотография нового скафандра SpaceX для пилотируемой версии корабля Dragon. По плану, новые корабли Boeing CST-100 и Dragon v2 полетят в следующем году, логично, что сейчас нам начали показывать скафандры. В чем полетят астронавты недалекого будущего?

Легко подумать, что от профилирования не стоит ожидать больших новостей: поскольку разработчики профилируют уже десятилетиями, до чего там можно было ещё не додуматься? Но в Java-профилировании кроются серьёзные подводные камни вроде safepoint bias, и появляются новые инструменты для решения подобных проблем.

Андрей apangin Паньгин (Одноклассники) недавно создал один из таких инструментов: на конференции JPoint в апреле он представил опенсорсный проект async-profiler, которому safepoint bias не страшен. Другой эксперт в этой теме — Нитсан Вакарт: о той же проблеме с safepoints многие узнали благодаря его блог-посту «Why (Most) Sampling Java Profilers Are Fucking Terrible».

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

Как и обещал, рассказываю о том, как мы мигрировали свой бэкенд на Go и смогли уменьшить объем бизнес логики на клиенте более, чем на треть.

Для кого: небольшим компаниям, Go и мобильным разработчикам, а также всем, кто в тренде или просто интересуется данной тематикой.
О чем: причины перехода на Go, с какими сложностями столкнулись, а также инструкции и советы по улучшению архитектуры мобильного приложения и его бэкенда.
Уровень: junior и middle.

Я всегда считал, что с flexbox довольно легко работать — глоток свежего воздуха после стольких лет float'ов и clearfix'ов.

Правда недавно я обнаружил что борюсь с ним; что-то растягивалось, когда я не думал, что оно должно тянуться. Я поправил здесь, другой элемент сжался. Я починил это, что-то другое ушло за экран. Какого Джорджа Буша тут происходит?

В конце концов, все заработало, но солнце село, а мой процесс был привычной игрой с CSS. Или… как называется та игра, где надо ударить крота, а затем другой крот выпрыгивает и надо ударить и его тоже?

Как бы там ни было, я решил что пора вести себя как взрослый разработчик и выучить flexbox должным образом. Но вместо того, чтобы прочитать 10 очередных блог-постов, я решил отправиться прямиком к исходнику и прочитать The CSS Flexible Box Layout Module Level 1 Spec

Вот хорошие отрывки.

Реализацию порядко-независимой прозрачности (order-independent transparency, OIT), наверное, можно считать классической задачей программирования компьютерной графики. По сути, алгоритмы OIT решают одну простую прикладную задачу – как нарисовать набор полупрозрачных объектов так, чтобы не беспокоиться о порядке их рисования. Правила смешивания цветов при рендеринге требуют он нас, чтобы полупрозрачные объекты рисовались в порядке от дальнего к ближнему, однако этого сложно добиться в случае протяженных объектов или объектов сложной формы. Реализация одного из самых современных алгоритмов, OIT с использованием связных списков, была представлена AMD для Direct3D 11 еще в 2010 году. Скажу откровенно, производительность алгоритма на широко доступных графических картах тех лет не произвела на меня должного впечатления. Прошло 4 года, я откопал презентацию AMD и решил реализовать алгоритм не только на Direct3D 11, но и на OpenGL 4.3. Тех, кому интересно, что получилось из этой затеи, прошу под кат.

Лекс очнулся и открыл глаза. Его взору предстал всё тот же невесёлый ангар. Недалеко стоял его корабль с открытым люком и выдвинутой аппарелью. Лекс осторожно сел. Голова болела, но он уже не чувствовал слабости в теле, как в своё прошлое пробуждение.

«Что-то изменилось», — подумал Лекс. Он покрутил головой. «Точно – стула нет! — отметил он изменения в обстановке. — А вместе с ним исчез и хранитель – может они как-то связаны друг с другом?» Пришедшая в голову мысль настолько развеселила его, что он рассмеялся в пустоту ангара. Искажённое и пугающее эхо заставило его замолчать. Лекс попробовал подняться и у него это легко получилось. Он покрутил головой, но никаких изменений в обстановке ангара больше не заметил.

Недавно я детально изучил отчёт GameAnalytics, содержащий некоторую статистику различного поведения геймеров. Анализируя, можно понять кое-что существенное в этих играх.

Помимо большой группы неплатящих геймеров, игроки в этом отчёте подразделяются на 3 типа: «пескари» (игроки «по случаю») (minnows (lowcore)), «дельфины» (регулярные игроки) (dolphins (midcore)) и «киты» (геймеры-фанаты) (whales (hardcore)).

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


Удержание различных игроков (источник: GameAnalytics, 2016)

Поводом для написания данной статьи послужила эта публикация про "хрущёвки", в которой была поднята интересная для меня тема программной генерации мешей в Unity.

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

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

Выступления и посты в блогах о производительности JavaScript часто обращают внимание на важность мономорфного кода, однако обычно не дается внятного никакого объяснения, что такое мономорфизм/полиморфизм и почему это имеет значение. Даже мои собственные выступления зачастую сводятся к дихотомии в стиле Невероятного Халка: «ОДИН ТИП ХОРОШО! ДВА ТИП ПЛОХО!». Неудивительно, что когда люди обращаются ко мне за советом по производительности, чаще всего они просят объяснить, что на самом деле такое мономорфизм, откуда берется полиморфизм и что в нем плохого.

Ситуацию осложняет еще и то, что само слово «полиморфизм» имеет множество значений. В классическом объектно-ориентированном программировании полиморфизм связан с созданием дочерних классов, в которых можно переопределить поведение базового класса. Программисты, работающие с Haskell, вместо этого подумают о параметрическом полиморфизме. Однако полиморфизм, о котором предупреждают в докладах о производительности JavaScript – это полиморфизм вызовов функции.

Я объяснял этот механизм столькими различными путями, что наконец-то собрался и написал данную статью: теперь можно будет не импровизировать, а просто дать на нее ссылку.

_{Я также попробовал новый способ объяснять вещи – изображая взаимодействие составных частей виртуальной машины в виде коротких комиксов. Кроме того, данная статья не покрывает некоторые детали, которые я посчитал незначительными, излишними или не связанными напрямую.}

Написать этот пост меня вдохновила замечательная статья в блоге Gaffer on Games «Reading and Writing Packets» и неуёмная тяга автоматизировать всё и вся (особенно написание кода на C++!).

Начнём с постановки задачи. Мы пишем сетевую игру (и сразу MMORPG, конечно же!), и независимо от архитектуры у нас возникает необходимость постоянно посылать и получать данные по сети. У нас, скорее всего, возникнет необходимость посылать несколько разных типов пакетов (действия игроков, обновления игрового мира, просто-напросто аутентификация, в конце концов!), и для каждого у нас должна быть функция чтения и функция записи. Казалось бы, не вопрос сесть и написать спокойно эти две функции и не нервничать, однако у нас сразу же возникает ряд проблем.

• Выбор формата. Если бы мы писали простенькую игру на JavaScript, нас бы устроил JSON или любой его самописный родственник. Но мы пишем серьёзную многопользовательскую игру, требовательную к трафику; мы не можем позволить себе отправлять ~16 байт на float вместо четырёх. Значит, нам нужен «сырой» двоичный формат. Однако, двоичные данные усложняют отладку; было бы здорово, если бы мы могли менять формат в любой момент, не переписывая целиком все наши функции чтения/записи.
• Проблемы безопасности. Первое правило сетевой игры: не доверяй данным, присланным клиентом! Функция чтения должна уметь оборваться в любой момент и вернуть false, если что-то пошло не так. При этом использовать исключения считается неважной идеей, поскольку они слишком медленные. Мамкин хакер пусть и не сломает ваш сервер, но вполне может ощутимо замедлить его беспрерывными эксепшнами. Но вручную писать код, состоящий из if'ов и return'ов, неприятно и неэстетично.
• Повторяющийся код. Функции чтения и записи похожи, да не совсем. Необходимость изменить структуру пакета приводит к необходимости поменять две функции, что рано или поздно приведёт к тому, что вы забудете поменять одну из них или поменяете их по-разному, что приведёт к трудно отлавливаемым багам. Как справедливо замечает Gaffer on Games, it is really bloody annoying to maintain separate read and write functions.

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

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

Наверное, дайджест, посвященный Unity, вы ждали с нетерпением, но, даже если не ждали, в нем всё равно много интересных материалов и новостей.

В январе этого года наш игровой департамент выпустил мобильную игру «Эволюция: Битва за Утопию». Игру хорошо приняли, людям нравится играть в нее. Я часто вижу людей с «Эволюцией» в метро. Даже начал желания загадывать, когда оказываюсь между игроками. И в этом посте, подготовленным по моему докладу на КРИ 2014, я хотел бы подробнее рассказать о процессе разработки и особенностях «Эволюции».

Я не понимаю причины существования бесконечных споров вокруг Объектно-ориентированного (ООП) и Функционального (ФП) программирования. Кажется, что такого рода вещи находятся за пределами человеческого понимая, и о них можно спорить бесконечно. Много лет занимаясь исследованием языков программирования, я увидел четкий ответ, и зачастую я нахожу бессмысленным обсуждение этих вопросов.

Если кратко, то как ООП, так и ФП неэффективны, если доходить в их использовании до крайности. Крайностью в ООП считается идея о том что “все что угодно является объектом” (чистое ОП). Крайностью для ФП можно рассматривать чистые функциональные языки программирования.

Разработка игр на сегодняшний день является не только интересным, но и выгодным делом. Объем игрового рынка уже превосходит киноиндустрию и догоняет спортивный рынок, а доходы некоторых игровых компаний исчисляются в миллиардах долларов. Но что ждет индустрию, и какие у нее перспективы? В этой статье я приведу краткие выдержки и графики на эту тему от ведущих мировых исследовательских агентств: SuperData, Digi-Capital, NewZoo, SensorTower, Zenna Apps, AppAnnie, J’son & partners.

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

Да, для вертикального выравнивания в CSS есть специальное свойство vertical-align с множеством значений. Однако на практике оно работает совсем не так, как ожидается. Давайте попробуем в этом разобраться.

Последние несколько лет HTML5 все больше вытесняет FLASH.

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

Эта статья — перевод статьи Simon Schreibt «Diablo 3 – Resource Bubbles».



В мире есть три вещи, на которые я могу смотреть вечно: Огонь, как другие работают и сферы ресурсов в Diablo3. Я уже полюбил стиль Blizzard, как вы могли, возможно, заметить по моей статье о их 2.5D деревьях. Сегодня речь о другом. Сегодня мы всмотримся глубокооо в кристальные сферы Diablo в поисках истины.
(внутри много картинок)