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

Игра

Игра на тематику мафии. В игре я попытался воссоздать Америку 30-40. По сути игра является экономической стратегий от первого лица. Игрок захватывает бизнес и старается удержать его на плаву.
Реализовано: автомобильный трафик (светофоры, избегание столкновений), human трафик, бар, казино, клуб, квартира игрока, покупка костюма, смена костюма, покупка/покраска/заправка автомобиля, копы, охрана/гангстеры, экономика, продажа/покупка ресурсов.

Архитектура

Я жалею, что не использовал ECS, а пытался в велосипед. В итоге получилось все громоздко и слишком зависимо. У приложения одна точка входа — игровой объект application(go), на котором висит одноименный класс Application. Он отвечает за предварительную загрузку БД, заполнение пулов и первичные настройки. Кроме того, на плечи application(go) ложатся и несколько других singleton классов-компонентов-менеджеров.

Привет, Хабр!

Я работаю в игровой компании, которая разрабатывает онлайн-игры. На текущий момент все наши игры делятся на множество “маркетов” (один “маркет” на страну) и в каждом “маркете” есть дюжина миров, между которыми распределяются игроки при регистрации (ну или иногда они могут выбрать его сами). Каждый мир имеет одну базу данных и один или несколько web/app-серверов. Таким образом, нагрузка делится и распределяется по мирам/серверам почти равномерно и в итоге мы получаем максимальный онлайн в 6K-8K игроков (это максимум, в основном в разы меньше) и 200-300 запросов в “прайм”-тайм на один мир.

Такая структура с делением игроков по маркетам и мирам изживает себя, игрокам хочется чего-то глобального. В последних играх мы перестаём делить людей по странам и оставили только один/два маркета (Америка и Европа), но до сих пор со множеством миров в каждом. Следующим этапом будет разработка игр с новой архитектурой и объединением всех игроков в одном единственном мире с одной базой данных.

Сегодня я хотел немного рассказать о том, как мне была поставлена задача проверить, а что если весь онлайн (а это 50-200 тысяч пользователей одновременно) одной из наших популярных игр «отправить» играть в следующую игру, построенною на новой архитектуре и сможет ли вся система, в особенности база данных (PostgreSQL 11) практически выдержать такую нагрузку и, если не сможет, узнать, где же наш максимум. Расскажу немного о возникших проблемах и решениях подготовки к тестированию такого количества пользователей, самом процессе и немного о результатах.

Джои Ленц из Naughty Dog подробно рассказал нам об освещении в UE4: о значениях, источниках, световой температуре, освещении в PBR, ресурсах, по которым можно изучать освещение, а также обо многом другом. На официальном сайте Джои polyplant.co есть множество полезных советов о работе с освещением.

Про PBR

PBR (physically-based rendering, основанный на физике рендеринг) благодаря использованию замеренных данных реального мира предоставляет удобные средства для создания материалов/освещения с предсказуемыми, неизменными результатами при разных условиях освещения. Для студий разработки игр это означает, что их художники могут тратить меньше времени на итерации создания контента и его переработку для создания «корректного» внешнего вида в разных уровнях. В свою очередь, это экономит студиям деньги. На освоение PBR художникам, привыкшим к старым методологиям, потребуется какое-то время. Иногда сложнее всего им избавиться от привычки добавления в albedo-текстуры информации об освещении/затенении. Однако как только они освоятся с этим рабочим процессом, то быстро понимают, что им гораздо проще управлять, чем традиционными средствами рендеринга текстур.

Пример расчета теплового потенциала для уличной сети г. Нижнего Новгорода

Территория города – сложная, неоднородная система, находящаяся в постоянном изменении. Описать территорию и провести оценку городской среды можно с помощью пространственных объектов (факторов). Факторы, описывающие территорию, различны по характеру влияния (положительное, отрицательное) и геометрической конфигурации (точки, линии, полигоны).

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

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

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

В последние несколько месяцев Facebook заполонили 3D-фотографии. Если вам не довелось их увидеть, то объясню: 3D-фотографии — это изображения внутри поста, которые плавно меняют ракурс при скроллинге страницы или когда перемещаешь по ним мышь.

За несколько месяцев до появления этой функции Facebook тестировал похожую функцию с 3D-моделями. Хотя можно легко понять, как Facebook может рендерить 3D-модели и поворачивать их в соответствии с позицией мыши, с 3D-фотографиями ситуация может быть не столь интуитивно понятной.

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

Доброго времени суток!

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

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

Расскажем вам, как на самом деле ведется работа над локализациями фильмов и почему от эрудированности переводчика часто зависит результат.

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

За годы эксплуатации Kubernetes в production у нас накопилось немало занимательных историй, как баги в различных системных компонентах приводили к неприятным и/или непонятным последствиям, влияющим на работу контейнеров и pod'ов. В этой статье мы сделали подборку некоторых наиболее частых или интересных из них. Даже если вам никогда не повезёт столкнуться с такими ситуациями, читать о подобных кратких детективах — тем более, «из первых рук» — всегда занятно, разве не так?..

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

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

Предисловие

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

Одна городская легенда гласит, что создатель сахарных пакетиков-палочек повесился, узнав, что потребители не разламывают их пополам над чашкой, а аккуратно отрывают кончик. Это, разумеется, не так, но если следовать такой логике, то один британский любитель пива "Гиннесс" по имени Уильям Госсет должен был не просто повеситься, но и своим вращением в гробу уже пробурить Землю до самого центра. А все потому, что его знаковое изобретение, опубликованное под псевдонимом Стьюдент, уже десятки лет используют катастрофически неправильно.

Рисунок выше приведен из книги С. Гланц. Медико-биологическая статистика. Пер. с англ. — М., Практика, 1998. — 459 с. Мне неизвестно, проверял ли кто-нибудь на статистические ошибки расчеты для этой диаграммы. Однако и ряд современных статей по теме, и мой собственный опыт говорят о том, что t-критерий Стьюдента остается самым известным, и оттого — самым популярным в применении, по поводу и без.

Введение

Умножение матриц — это один из базовых алгоритмов, который широко применяется в различных численных методах, и в частности в алгоритмах машинного обучения. Многие реализации прямого и обратного распространения сигнала в сверточных слоях неронной сети базируются на этой операции. Так порой до 90-95% всего времени, затрачиваемого на машинное обучение, приходится именно на эту операцию. Почему так происходит? Ответ кроется в очень эффективной реализации этого алгоритма для процессоров, графических ускорителей (а в последнее время и специальных ускорителей матричного умножения). Матричное умножение — один из немногих алгоритмов, которые позволяет эффективно задействовать все вычислительные ресурсы современных процессоров и графических ускорителей. Поэтому не удивительно, что многие алгоритмы стараются свести к матричному умножению — дополнительная расходы, связанные с подготовкой данных, как правило с лихвой окупаются общим ускорением алгоритмов.

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

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

Несколько месяцев назад завершился мой проект по изготовлению USB-клавиатуры. Среди прочего, я выполнил дизайн электронных схем, спроектировал печатную плат, запрограммировал прошивку, сделал макет в CAD и произвёл сборку устройства. В результате получилась удобная клавиатура, которую я использую ежедневно и ласково называю KeeBee:


Клавиатура KeeBee в окончательном виде

Несколько целей проекта:

1. Самостоятельное создание схемы.
   
2. Написание прошивки клавиатуры.
   
3. Узнать, как работает протокол USB.

— Ямщик, а далеко до релиза?
— Да пара вёрсток.

Докатился — пишу на Хабр о том, как писать на Хабр. Хотя причины есть — я пять лет занимаюсь этим, перевидал и перепробовал кучу инструментов, так что теперь делюсь с вами самыми лучшими.

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

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

Мы с мужем давно хотели делать игры вместе, но времени на это никогда не хватало. Мы оба работали: он — UI-программистом в геймдеве, я — продакт-менеджером в social media, затем в финтехе, и сил на собственную игру не оставалось.

Год назад мы переехали в Канаду и решили, что это хороший шанс попробовать себя в качестве инди-разработчиков. Муж, правда, быстро нашёл работу в AAA игре, но мне это не удалось, и времени вдруг появилось очень много.

Как мы придумывали

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

Мы сами довольно много играем и всегда отмечаем то, что нам нравится, и что — не очень. Основной момент, который нас раздражает в современных мобильных казуалках — это однообразие их механик, обилие попапов с предложениями что-нибудь купить и длинными описаниями, а также перенасыщенный UI с кучей каких-то плашек, бабблов и объёмных шрифтов. Поэтому в нашей игре мы постарались сделать всё наоборот.

Учимся дебажить с perf — целых 18 страниц про основные подкоманды, фичи и устройство инструмента. Джулия рекомендует; “Я даже использовала его несколько раз для профилирования Ruby программ!”

Уровень сложности — для суперпродвинутого администратора.

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

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

Причина очень проста. Звуки и звукообразование в разных языках отличается кардинально.

В японском языке отсутствует звук [l]. И на первых этапах изучения английского языка они заменяют его звуком [r]. Все потому, что в японском звук [r] ударный, а не вибрационный. Во время произношения язык прикасается к нёбу лишь на долю секунды, поэтому на выходе получается что-то среднее между знакомыми нам [р] и [л]. Именно поэтому сложно понять, что имеет в виду японец: «law» или «raw».

Конечно, при целенаправленных тренировках японцы начинают выговаривать звук [l], но крайне малая часть изучающих английский тренирует произношение настолько глубоко.

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

Нередко такие нюансы полностью меняют смысл предложения.

И вместо «I like this beach» («Мне нравится этот пляж») собеседник услышит «I like this bitch» («Мне нравится эта девушка с пониженной социальной ответственностью»).

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

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



Статья написана, в основном, по материалам блога, который ведёт Fabian Giesen.

Здравствуй, Хабр!

Несколько лет назад в прикладных целях я реализовал обычный Force-based визуализатор графов.

На меня произвело впечатление, как простые итеративные преобразования могут производить субъективно сложные и интересные вычисления, формируя нетривиальные визуально-кинетические модели.

Со временем возникло несколько идей, что интересного можно смоделировать.

Вот что получилось с одной из них (в кадре мелкие объекты, смотреть в HD):