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

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

Предисловие

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

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

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

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

Всем доброго времени суток, меня зовут Сергей Носков. Сегодня я бы хотел рассказать о создании моего первого полноценного инди-проекта под названием 35ММ, вышедшего в Steam в 2016 году. История конечно давняя, и с тех пор уже было опубликовано несколько статей и интервью на тему проекта, однако, подробного описания процесса разработки не было. Также, практически не были затронуты технические моменты реализации. Об этом, собственно, мы и поговорим.

Начнем с небольшой предыстории. 35ММ — это адвенчура с видом от первого лица в сеттинге постапокалипсиса на территории России. В народе — симулятор ходьбы. Игра повествует нам историю путешествия двух странников по опустевшим землям, оставленным цивилизацией. Основная часть населения вымерла после страшной болезни, и теперь природа отыгрывает у человечества свои очки. К сожалению, уже не помню точно, как зародилась идея данного проекта, но точно помню, что на тот момент я был ярым фанатом темы сталкера, игр «Метро» и вообще подобного атмосферного антуража. У меня всегда вызывали трепет и восторг пейзажи заброшенных городов, промышленных зон и деревень. Уж не знаю, что это за болезнь такая и как такую любовь объяснить, но нас таких много. В общем-то, подобной страсти по данной теме было достаточно для того, чтобы начать создание своего небольшого игрового мира.

«До того, как вы постигнете это, оно кажется чудом. Но после в нем нет ничего особенного.»

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

Введение

На Habr достаточно много публикаций, в которых рассматривается понятие энтропии, вот только некоторые из них [1÷5]. Публикации были позитивно восприняты читателями и вызвали большой интерес. Достаточно привести определение энтропии, которое дал автор публикации [1]: «энтропия — это то, как много информации вам не известно о системе». Публикаций о явлении хаосе на Habr тоже достаточно [6÷9]. Однако связь энтропии и хаоса в обеих группах публикаций не рассматривалась.

Это объясняется тем, что различные области знаний выделяют разные виды меры хаоса:

• информационная;
• термодинамическая;
• дифференциальная;
• культурная.

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

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

Что из этого получилось Вы узнаете заглянув под кат.

Захари Бир создаёт рисунки, используя цветовую палитру от цветовой схемы для Мака Solarized и собственную программу для генерации изображений Geometriq.

Пару лет назад я влюбился в цветовую палитру: цвет, чуть темнее белого, выделяемый жёлто-оранжевым и нейтральным голубым на тёмно-сером фоне, «цвете телевизора, переключенного на мёртвый канал», как писал Уильям Гибсон в «Нейроманте». Эти цвета принадлежали к теме Solarized Dark популярного редактора кода для MacOS под названием TextMate. Честно говоря, сначала мне она не очень понравилась. Но вскоре я обнаружил, что не могу работать ни в какой другой цветовой схеме. Если ты весь день пялишься на экран, то поневоле начнёшь придираться к шрифтам и цветам.

Оказалось, что я не один такой. По профессии я не кодер, но мне нравится использовать редакторы кода для написания текстов и организации заметок. Переключившись с Мака на Windows, я стал искать соответствующие инструменты, и начал видеть Solarized Dark и её близкую родственницу Solarized Light, использующую ту же палитру из 16 цветов, практически везде. Сложно сказать, какое количество программистов её использует. Схема свободна и имеет открытый код, поэтому статистики по продажам у неё нет. Она есть в любом крупном редакторе кода и многих других инструментах. Microsoft даже включила её в набор популярного редактора VS Code. У Solarized есть много поклонников.

Доброго дня!Немного об авторе: меня зовут Мария, младший гейм дизайнер. Это вторая статья из цикла по применению теории гейм дизайна в жизни.

Ссылка на первую статью: «Гейм дизайн в жизнь. Пример разбора механики игры»

После примера разбора игры хочется взяться за самую сочную часть гейм дизайна – создание/изменение экономики.

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

Фазовый переход происходит, когда система пересекает линию, разделяющую две фазы [1]. Для воды и льда это 0°C (если отбросить влияние атмосферного давление и других факторов). Помимо фазовых переходов в термодинамике можно выделить фазовые переходы и применительно к видеоиграм.

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

Картинка Frequency of miracles [2]

Далее будут рассмотрены наглядные примеры фазовых переходов и возможные способы работы с ними.

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

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

Внимание: просто рассматривать мой код, равно как и просто читать эту статью с чашкой чая в руке, смысла не имеет. Эта статья рассчитана на то, что вы возьмётесь за клавиатуру и напишете ваш собственный движок. Он наверняка будет лучше моего. Ну или просто смените язык программирования!

Итак, сегодня я покажу, как отрисовывать подобные картинки:

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

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

Итого, как в таких условиях нарисовать вот такую картинку за 180 строчек кода?

Привет, Хабр! Представляю вашему вниманию перевод статьи «Reflective Shadow Maps» автора Eric Polman.

Reflective Shadow Maps (RSM) (отражающие карты теней) ― это алгоритм, расширяющий “простые” shadow map. Алгоритм учитывает свет, рассеянный после первого попадания на поверхность (diffuse). Это означает, что кроме прямого освещения, вы получаете непрямое освещение. В данной статье я разберу алгоритм из официальной статьи, чтобы объяснить его по-человечески. Я также кратко расскажу о shadow mapping.

Советы по грамотному написанию технической документации для пользователей.
Часть 1

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

На этот раз под катом – руководство нашего технического писателя Андрея Старовойтова, которое поможет сделать вашу документацию для пользователей проще и понятнее (описанные приемы применяют при документировании своих продуктов Apple, Microsoft и другие компании).

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

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

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

Одним из этих средств является уникальный, нехарактерный для прочих СУБД механизм работы с переменными внутри запроса SQL. Мы можем объявить переменную внутри запроса, менять ей значение и подставлять в SELECT для вывода. Причем порядок обработки строк в запросе и, как следствие, порядок присвоения значений переменным можно задать в пользовательской сортировке!

Предупреждение. В статье подразумевается, что обработка выражений в предложении SELECT осуществляется слева направо, однако официального подтверждения такого порядка обработки в документации MySQL нет. Это необходимо иметь в виду при смене версии сервера. Для гарантии последовательности вычисления можно использовать фиктивный оператор CASE или IF.

Аналог рекурсии

Рассмотрим простой пример, который генерирует последовательность Фибоначчи (в последовательности Фибоначчи каждый член равен сумме двух предыдущих, а первые 2 равны единице):

Нельзя отрицать, что компания AMD покоряет рынок процессоров семимильными шагами. Началось всё с появления новинок на базе архитектуры Zen, которые получили имя Ryzen. Да, старт был не таким гладким, как хотелось бы, но шороху производитель навёл немало. В чём секрет успеха второго поколения? Почему энтузиасты обратили особое внимание не на «топовый» чипсет? Правда ли, что в сети есть программы-калькуляторы для настроек памяти? И даже в играх производительность заметно вырастет после тонкой настройки? А что, бывает разная память и какая-то может даже не заработать?

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

В помощь геймдизайнерам придумана масса инструментов: форматы ГДД, различные чек-листы, юзерстори, портреты, агенда и так далее. И все равно этого не хватает.

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

Привет Хабр! В этой публикации хочу поделиться опытом разработки массивной мобильной игры, с большим городом и трафиком. Примеры и приемы описанные в публикации не претендуют называться эталонными и идеальными. Я не являюсь дипломированным специалистом и не призываю повторять свой опыт. Целью работы над игрой было — получение интересного опыта, получение оптимизированной игры с открытым миром. При разработке я старался максимально упрощать код. К сожалению, я не использовал 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-текстуры информации об освещении/затенении. Однако как только они освоятся с этим рабочим процессом, то быстро понимают, что им гораздо проще управлять, чем традиционными средствами рендеринга текстур.

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

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

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

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

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