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

Введение

Алгоритм был написан как часть работы на получение степени бакалавра и основан на статье Ma et al (2014). Целью работы было ускорение алгоритма и дополнение его новыми функциями. Я вполне доволен результатом, потому что мы сделали алгоритм достаточно быстрым, чтобы использовать его во время выполнения игры. После завершения бакалаврской работы мы решили превратить её в статью и отправить на конференцию Game-ON 2018.

Алгоритм

Для создания уровня игры алгоритм получает в качестве входных данных набор полигональных строительных блоков и граф связности уровня (топологию уровня). Узлы графа обозначают комнаты, а рёбра определяют связи между ними. Цель алгоритма — назначить каждому узлу графа форму и расположение комнаты таким образом, чтобы никакие две формы комнат не пересекались, и каждая пара соседних комнат могла соединяться дверьми.

Однажды я прочитал в одной статье, которую теперь не могу найти, высказывания директора одного стартапа-«единорога» [частная компания с капитализацией более $1 млрд / прим. перев.], которые не понравились многим людям. Такие вещи вообще неприлично говорить по поводу других людей. Более того, такие вещи даже думать не стоит по отношению к другим людям – однако этот гражданин, очевидно, не справился с этим. Люди ахнули от дерзости, с которой говорилось об этих вещах, но упустили при этом тот факт, что многие на самом деле думают именно так. Даже сегодня.

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

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

Одно из преимуществ Unity в качестве платформы для разработки игр — её мощный 3D-движок. В этом туториале вы познакомитесь с миром 3D-объектов и манипуляций мешами.

В связи с ростом технологий виртуальной и дополненной реальности (VR/AR) большинство разработчиков сталкивается со сложными концепциями 3D-графики. Пусть этот туториал будет для них отправной точкой. Не волнуйтесь, здесь не будет сложной 3D-математики — только сердца, рисунки, стрелки и куча интересного!

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



Во многих процедурных генераторах карт, в том числе и некоторых моих предыдущих проектах, для генерирования карты высот используются функции шума (midpoint displacement, фракталы, diamond-square, шум Перлина и т.д.). Здесь я их не применял. Вместо неё я использовал структуру графов для моделирования элементов, определяемых ограничениями геймплея (высота, дороги, течение рек, места квестов, типы монстров) и функции шума для моделирования того, что не ограничивается геймплеем (форма побережья, расположение рек и деревьев).

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

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

Вместо равномерно распределённых случайных чисел (какие выдаёт генератор Math.random в большинстве языков), я использую нормальное распределение Парка-Миллера. В результате вероятность появления маленьких комнат превышает вероятность появления больших. Зачем это надо, объясню позже.

Кроме того я проверяю, что соотношение длины и ширины комнаты не слишком велико. Нам не нужны как идеально квадратные комнаты, так и сильно вытянутые.

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

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

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

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

9. Чтобы превратить его в коридоры, для каждого ребра строится серия прямых линий (в форме Г), идущих по рёбрам графа, соединяющим комнаты. Тут нам пригождаются те клетки, которые остались неиспользованными (те, что не превратились в комнаты). Все клетки, накладывающиеся на Г-образные линии, становятся коридорами. А из-за разнообразия размеров клеток стены коридоров будут неровными, что как раз хорошо для подземелья.

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

Нередко слышишь мнение, что составление Технического задания по ГОСТ 34 (ТЗ) занятие не только трудоемкое, но и крайне раздражающее, поскольку приходится писать много всякой ерунды, воды. Но подумайте: разработкой этого ГОСТа занимались целые НИИ, это был проект на государственном уровне, обобщен опыт сотен проектов автоматизации, сложных проектов. Неужели они могли написать чушь?

На самом деле, при грамотном подходе ГОСТ очень сильно помогает не только при разработке ТЗ, но и в ходе реализации проекта автоматизации в целом (и не только в госконтрактах, но и для коммерческой разработки). Грамотные люди его писали. Но чтобы воспользоваться плодами их трудов, нужно немного понять замысел не только ТЗ, но и ГОСТ 34 в целом.

В данной статье мы пункт за пунктом разберем все требования ГОСТа и попробуем сделать разработку ТЗ по ГОСТ 34 не обременением, а большой помощью в проекте.

Пост-ответ на статью "Иди-ка ты на !@# со своей "токсичностью"".

Если бы я последовал советам из этой статьи, мне достаточно было бы проявить эмоцию и сказать автору "Иди-ка ты сам на ..., ты ничего не понимаешь!".

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

Часть вторая

В части первой этой статьи я рассказал, почему для игры M.E.R.C. мы выбрали процедурную генерацию уровней, и описал требования к ней. Также я описал процесс генерирования структуры процедурного уровня и соединения множества фрагментов для создания целостного уровня. Во второй части статьи мы обсудим решение проблем освещения и NavMesh в Unity и создание NPC на основании темпа.

Аналогов подобных теней для точечного источника света (Pointlight с эффектом размытия на расстоянии, имитирующий arealight) в компьютерных играх я почему-то до сих пор не встречал. Везде — либо полностью запечённые тени, либо «лампочки» вообще без теней, максимум — обыкновенная PCF-фильтрация. Хотя для направленного солнечного света уже давно применяются PCSS-тени (GTA5, например). В Unreal есть интересный алгоритм сродни рейтрейсингу, который рисует красивые arealight-тени, но только для статической геометрии (требуется генерация дополнительных объёмов). В Unity же всё совсем плохо — мягко фильтруется только солнечный свет, а «прожекторы» и «лампочки» в пролёте.

Привет!

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



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

Разработчик — в среднем человек увлеченный, спорить с этим смысла мало. Объективно, из-за того, что обучение программированию с самой юности отнимает много времени и сил, многие разработчики становятся чуть-чуть похожими на медведей. И сейчас объясню почему.

Медведь — вообще уникальное животное. Одна только система зимней спячки вызывает уважение. Добавить к этому размеры, всеядность и ареал обитания и мы получаем высшего хищника, у которого нет естественных врагов. Любой зоолог скажет вам, что медведь — зверь-одиночка. И как раз в образе жизни в качестве одиночек и кроется основная проблема взаимодействия с медведем: у него практически нет мимической сигнальной системы. Вред медведю в природе может причинить только другой медведь, но они просто расходятся в разные стороны предпочитая тактическое отступление кровавой схватке. То есть уровень эмоциональности этого зверя можно сравнить с эмоциональностью Чака Норриса, посмотрите сами:



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

Предисловие для читателей Хабра — статья о поиске работы на рынке разработки в Украине (который в основном об аутсорсе на иностранных заказчиков), поэтому некоторые вещи могут показаться странными (LinkedIn, собеседования с заказчиками, обязательное требование разговорного английского, обсуждение ЗП в долларах) или нерелевантными для РФ. Тем не менее, статья имела большой успех на локальных ресурсах, и читатели попросили меня перевести её на русский.

Этой статьей я хочу начать цикл рассказов о том, как я на протяжении нескольких месяцев проходил собеседования в примерно 20-и разных компаниях на разные должности. Тут будут мои мысли о рынке труда, процессе найма, советы а так же несколько самых интересных историй. Цикл будет состоять из нескольких частей — HR собеседования, технические собеседования, финальные собеседования. Итак, первая часть.

Немного о себе. Программирую со школьного возраста, за деньги работаю 10 с хвостиком лет. Работал админом, программистом, тимлидом, РМ-ом, линейным менеджером. Выполнял обязанности SRE/DevOps, архитекта, HR, офис-менеджера, эникейщика.

Работал в кровавом энтерпрайзе, в стартапе, в аутсорсе. В основном занимался формошлёпством и крудами, имел дело с Java и бэкендом. За последние несколько лет пересел на фуллстек микс из Java, Ruby/RoR, Python, Node.js.

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

Всего я прошел примерно 20 собеседований с рекрутерами: половина из которых были из агенств и половина — штатные рекрутеры/HR компаний. Так что, могу сказать что некоторая статистика у меня есть.

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


Стив поверил в себя, так и ты поверь

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

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

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



Все это очень сильно бьет по эго и самооценке. Почему это происходит? Как с этим справиться? И надо ли справляться? Давайте разбираться вместе.

Источник фото

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

В данной статье приводится обзор мнений экспертов с минимальными комментариями.

Изначальная статья "Что всё-таки не так с наймом в IT?" многим порвала шаблон мышления месяц назад. Не все смогли адекватно воспринять суть трудового права. От шуток к делу, теперь слово берёт Министерство труда и социальной защиты Российской Федерации.

Ниже дословно:

В соответствии со статьей 64 Трудового кодекса Российской Федерации (далее — ТК РФ) необоснованный отказ в заключении трудового договора запрещается, если это не связано с деловыми качествами работника.
В целях проверки его соответствия поручаемой работе в трудовом договоре по соглашению сторон может быть предусмотрено условие об испытании работника (статья 70 ТК РФ).

UPD: вопросы приведены в комментарии, это прямой ответ на общий вопрос: "чем регулировать тестовое задание".

Поэтому тестовое задание без трудового договора — это сразу ст.5.27. КоАП РФ:

• Соответственно 30-50 тыс. рублей за первое, и 50-70 тыс. рублей за каждое последующее нарушение для работодателя.
• Если работодатель отказывается признавать трудовые отношения, то ещё:
  
  • 50-100 тыс. рублей для работодателя, 100-200 тыс. рублей за повтор;
  • 3-5 тыс. рублей для конкретного работника, который выдал тестовое задание, 5-7 тыс. рублей за повтор.
• Невыплата зарплаты за тестовое задание — 30-50 тыс. рублей, 50-100 тыс. рублей за повтор.

Разбираемся под катом.

Вступление

Здравствуй, уважаемый читатель. Прежде чем начать, мне хотелось бы немного рассказать о цели и формате моей статьи. Обычно с такими заголовками статьи носят обозревательный характер, в них описываются технические стороны реализации того или иного решения или приводится инструкция по эксплуатации и т.д. Выводы же читатель делает самостоятельно. Прежде чем написать эту статью, я провел небольшую исследовательскую работу на предмет аналогов. И нашел несколько статей как на самом хабре, так и массу видео материалов на ютубе. Поэтому я решил не писать очередной обзор технологии, а поделиться впечатлениями, рассказать о граблях, на которые мы наступили, и привести немного “кухонной” аналитики.
Цель этой статьи – помочь вам определиться, использовать или нет данный метод. В первую очередь она рассчитана на технических специалистов, хотя и не пестрит техническими деталями. Но так же будет полезна и всем остальным – арт-специалистам, менеджерам проектов да и просто всем, кто, так или иначе, связан с разработкой игр. Возможно, ссылка на данную статью поможет выбить бюджет у начальства и ускорить разработку/повысить качество вашей будущей игры. Итак, приступим.

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

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

Части 1-3: сетка, цвета и высоты ячеек

Части 4-7: неровности, реки и дороги

Части 8-11: вода, объекты рельефа и крепостные стены

Части 12-15: сохранение и загрузка, текстуры, расстояния

Части 16-19: поиск пути, отряды игрока, анимации

Части 20-23: туман войны, исследование карты, процедурная генерация

Части 24-27: круговорот воды, эрозия, биомы, цилиндрическая карта

Часть 8: вода

• Добавляем в ячейки воду.
• Триангулируем поверхность воды.
• Создаём прибой с пеной.
• Объединяем воду и реки.

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


Вода прибывает.