Это третья статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Цикл будет состоять из четырех статей.

Это вторая статья из цикла о процедурно генерируемых с помощью Unity и C# картах мира. Цикл будет состоять из четырех статей.

В этом цикле статей мы научимся создавать процедурно генерируемые карты мира с помощью Unity и C#. Цикл будет состоять из четырех статей.

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

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

Сформулируем определения и задачу.
Графом будем называть несколько точек (вершин), некоторые пары которых соединены отрезками (рёбрами). Граф связный, если от каждой вершины можно дойти до любой другой по этим отрезкам. Циклом назовём какой-то путь по рёбрам графа, начинающегося и заканчивающегося в одной и той же вершине. И ещё граф называется взвешенным, если каждому ребру соответствует какое-то число (вес). Не может быть двух рёбер, соединяющих одни и те же вершины.
Каждый из алгоритмов будет решать какую-то задачу о кратчайших путях на взвешенном связном. Кратчайший путь из одной вершины в другую — это такой путь по рёбрам, что сумма весов рёбер, по которым мы прошли будет минимальна.
Для ясности приведу пример такой задачи в реальной жизни. Пусть, в стране есть несколько городов и дорог, соединяющих эти города. При этом у каждой дороги есть длина. Вы хотите попасть из одного города в другой, проехав как можно меньший путь.

Это вторая часть моей статьи с левел-дизайнерскими Tips and Tricks, которые разработчик может использовать, чтобы повысить общее качество своей игры. Это ни в коем случае не пошаговое руководство, а только сборник идей и полезных советов, основанных на моём личном опыте. Первая часть статьи была больше ориентирована на визуальную составляющую дизайна уровней, в этот же раз мы поговорим о ещё более фундаментальных вещах, начиная с прототипирования и заканчивая плэйтестингом с аналитикой.

На Хабрахабре достаточно много инди-разработчиков, некоторым из них приходится в той или иной степени заниматься левел-дизайном. В течение последних нескольких месяцев я безвылазно работал над примерно полусотней различных игровых уровней, и хотел бы поделиться своим опытом. Эта статья содержит эффективные Tips and Tricks, которые вы можете использовать, чтобы повысить общее качество вашей игры. Это ни в коем случае не пошаговое руководство, а только сборник идей и полезных советов. Первая часть статьи направлена больше на работу с визуальной составляющей игры, вторая же часть, доступная по ссылке, содержит более фундаментальные вещи, такие как прототипирование, определение размера героя и окружения, плэйтестинг и аналитику.

Привет!
У издательств я узнал, что с 1 по 10 января люди читают больше, чем за год. Поэтому небольшой подарок от нас — мы договорились с Даниилом Куком (бывшим геймдизайнером Epic Megagames), взяли и перевели несколько его хардкорных материалов про разработку игр. И засунули их в PDF на сотню страниц.

• Как игры формируются внешней средой: как рынок влияет на сюжет игры (например, из-за уменьшения среднего дохода на игру уменьшается роль открытого мира – слишком долго делать) и так далее. Очень хороший аналитический обзор от гуру с конкретными советами.
• Организация игровых процессов в многопользовательской игре — как собирать игроков вместе, как делать асинхронные взаимодействия и много чего ещё с числами и примерами. Годный хардкор.
• ТОП-5 споров о разработке 2014-го года — прошлогодний материал о том, что за тренды обсуждались. Всё актуально и сейчас.
• Декларация независимости разработчика — американский крик души о том, что «уберите грязные лапы финансового директора от сюжета игры». Ну, примерно.
• Критика критики игр — что делать, если обзоры пишут дилетанты, и как выделиться из балласта.
• Создание эффективных причинно-следственных связей в играх — невероятно полезная вещь для всех тех, кто хочет понять, как работают когнитивные схемы игр. Полезна не только разработчикам, но и для UI/UX-спецов.
• Таблицы трофеев – математика выковыривания лута из трупов врагов. Начинается с ликбеза и стремительно ускоряется до весьма крутых решений.

Вот PDF и полные тексты. Ниже в посте – основные тезисы, если лень читать всё или хочется здесь и сейчас.

Must-have плагины Unity, работа с анимацией, опыт разработчиков – вы знаете, что с этим делать. Приятного прочтения и веселых праздников!

Эта статья — перевод выступления Джона Нески (John Nesky) с GDC14.

Вторая часть тут

Джон — один из разработчиков в компании TGC, известной своей игрой Journey. Он начал работать там в роли гейм-дизайнера, но впоследствии увлёкся настройкой работы камеры в Journey, поэтому теперь его должность звучит как Feel Engineer.

Вряд ли вы найдёте какое-нибудь сообщество разработчиков, специализирующихся на игровых камерах. И есть, пожалуй, всего одна книга на эту тему — Real Time Cameras за авторством Марка Хэйг-Хатчинсона (Mark Haigh-Hutchinson). Но хотелось бы глубже изучить эту тему и узнать, как люди решают те или иные трудности.

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

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

Давным-давно я имел радость играть в замечательнейшую RTS под названием «Периметр: Геометрия Воины» от отечественного разработчика K-D Labs. Это игра о том, как огромные летающие города под названием «Фреймы» бороздят просторы «Спанджа» — цепи соединенных между собой миров. Сюжет достаточно странный и абстрактный, но гораздо более интересной и инновационной составляющей игры была одна из ее технических особенностей, а не сюжет. В отличие от большинства RTS, где сражения происходят на статической местности, в «Периметре», одной из ключевых игровых механик был терраформинг. У игрока были средства манипулировать ландшафтом с целью возведения на нем своих сооружений а также целый арсенал боевых единиц, способных этот ландшафт превратить в потрескавшийся, поплывший и изрыгающий раскаленные камни/противных насекомых ужас.

Как известно, мир RTS нынче переживает некоторый упадок. Инди-разработчики слишком заняты тем, что клепают ретро-платформеры и rouge-like игры зубодробительной сложности, и поэтому, переиграв в «Периметр» некоторое время назад я решил, что должен и сам попробовать реализовать что-то подобное — идея была интересной и с технической и с геймплейной точек зрения. Обладая некоторым практическим опытом в разработке игр (ранее я совершал попытки сделать кое-что на XNA), я подумал, что чтобы добиться хоть какого-то успеха в одиночку мне придется воспользоваться чем нибудь более высокоуровневым и простым. Выбор мой пал на Unity 3D, чья пятая версия только-только вышла из под пресса.

Вооруженный вагоном энтузиазма, вдохновением от только что пройденного «Периметра» и просмотренной серией видеотуториалов по Unity, я начал делать наброски и знакомиться с инструментарием, который мне предложил Unity Editor.

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

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

Эта статья является адаптированным под современны редактор переводом на русский язык оригинальной инструкции: «Terrain export from world machine to unity».

---

World Machine может служить отличным генератором местности для Unity. Unity же имеет нативную поддержку текстур и splatmaps. Вы можете создать и использовать несколько слоёв текстур местности одновременно. Здесь представлен простой рабочий код для импорта в Unity местности из World Machine. Пожалуйста, обратите внимание, что, хотя этот метод работает для основных местностей в unity, многие продвинутые пользователи могут создать собственные шейдеры местности, которые могут потребовать другую технику исполнения.

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

В видеоиграх красивое освещение в реальном времени сильно бьёт по производительности, что особенно заметно на мобильных устройствах. Таким образом, разработчики вынуждены искать методы обхода этой проблемы. Lightmapping — технология, сохраняющая информацию об освещении в текстуру, что позволяет высвободить вычислительные ресурсы под другие нужды.
В этой статье я познакомлю читателя с теорией освещения в играх, опишу процесс создания “лайтмапа” в Unity 5 и поделюсь рядом советов.

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

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

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

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

Чем выгодно отличается шум Перлина, легко можно заметить, если сравнить картинки.

Обычный шум (из той самой статьи):


Шум Перлина:


И увеличением количества октав первую картинку ко второй никак не приблизишь. Я не буду описывать достоинства шума Перлина и область его применения (потому что статья о программировании, а не о применении), а постараюсь объяснить как он реализован. Думаю, это будет полезно многим программистам, ведь хакерские исходники Кена Перлина мало объясняют даже при наличии комментариев.

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

Механика базы работает чертовски просто:

1. В игре создаётся некое место, где игроку приятно и безопасно проводить время.
2. После периода напряжения игрок отправляется в это место.
3. Закончить в этот момент сложно. Кто будет отказываться от приятного «отдыха»? Нет, из игры не выходят перед приятной частью.
4. Далее мы стараемся без перехода выводить игрока в следующий цикл, требующий напряжения – так, чтобы игрок не успел понять, как там оказался.

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