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

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

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

Играм, в которых нельзя умереть (или, если угодно, проиграть), недостает глубины. Если проиграть невозможно, зачем пытаться выиграть? Иначе говоря, если вы не боитесь поражения, стремление к победе теряет всякий смысл. Однако после смерти персонажа игроку необязательно кусать локти и переигрывать все по новой. Механику смерти можно интегрировать в сюжет или геймплей, но главное – сделать это правильно.

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

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



Так что неудивительно, что в опросе CNet по субтитрам 79% игроков сказали, что играют с субтитрами. Цифра довольно ненаучная, но уже она говорит, что с субтитрами играют очень часто.

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

Важное уточнение — калькулятор обычный, без кнопки sin. Как в бухгалтерии или на рынке.



Под катом три разных варианта решения из разных эпох, от древнего Самарканда до США времён холодной войны.

Если вы хотите научиться программировать первоклассные игры, вам просто необходимо изучить язык С++. Эта книга поможет вам освоить разработку игр с самых азов, независимо от того, есть ли у вас опыт программирования. Гораздо интересней учиться, когда обучение превращается в игру. Каждая глава книги описывает самостоятельный игровой проект. В заключительной главе вам предстоит написать сложную игру, которая объединяет все приемы программирования, рас-смотренные в предыдущих главах. Книга идеально подойдет для начинающего программиста, планирующего не только как следует освоить непростой язык С++, но и поупражняться в программировании игр. Цель данной книги — познакомить вас с языком С++ в контексте программирования игр. Хотя невозможно представить себе такую книгу, которая сделала бы вас мастером в двух столь объемных темах, как программирование игр и язык C++, это издание пригодится вам в качестве вводного курса.

Здравствуйте, уважаемые Хаброобитатели!

UPD
Могу всех порадовать. Мы приступаем к переводу Unity in Action: Multiplatform Game Development in C#. Постараемся все сделать как можно быстрее, но при этом качественно.

Пришла нам в голову безумная мысль, а не пора ли перевести на русский язык книгу по Unity? Тем более сейчас, когда доступна полноценная пятая версия (да еще и бесплатно).
Книг на английском языке вышло немало, но хочется выбрать не слишком старую и самую интересную.
Если мы упустили что-либо интересное, напишите в комментариях, будем рады.

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

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

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

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

В этой статье речь пойдет о самом простом в реализации алгоритме генерации «идеального» лабиринта и его применении для поиска пути.

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

Заинтересовавшихся — прошу под кат.

Это топик-перевод статьи Eller's Algorithm. В ней рассказывается о способе программной генерации лабиринтов. Дальнейшее повествование идет от лица автора.

 __ __ __ __ __ __ __ __ __ __ __ __ __ __ __  
|__   |__       __ __|__   |   __|  |  |  |  |
|__   |__   |__|   __ __|   __ __      |     |
|        |  |  |     |  |__      |__|  |  |  |
|__|__|  |  |   __|   __|__   |   __|__|  |__|
|   __|  |     |__ __ __|  |  |__|  |     |  |
|  |  |  |  |__|  |__   |  |   __|__ __|  |  |
|  |__    __    __ __    __|  |   __   |  |  |
|  |  |  |  |      __|  |   __|  |  |__|  |  |
|  |     |     |__   |  |  |  |  |  |__    __|
|  |  |__|__|__ __|  |     |  |  |      __|  |
|__ __|  |  |  |__   |__|   __|     |   __ __|
|   __|  |   __|__      |__   |__|  |__    __|
|  |  |     |  |     |__|  |   __    __|   __|
|   __|  |__ __|__|      __|  |  |     |  |  |
|   __ __   |      __|__|  |__   |  |  |__|  |
|__ __ __|__ __|__ __ __ __ __|__|__|__ __ __|

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

Работая над своей игрой в Unity я подумал, зачем мне создавать множество однотипных скриптов описывающих поведение игровых объектов, но имеющих небольшие отличая друг от друга, если я мог бы создать один, а добавляя его как компонент объекту просто выбирал бы тип того самого объекта, а в редакторе (он же Inspector) видел бы только те свойства и поля, что имеют прямое отношение к выбранному типу. Так же это позволило бы в зависимости от выбора внутри скрипта использовать те или иные методы. В этом мне помогло пространство имён UnityEditor и её класс Editor.

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

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

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

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

Тут нам на помощь приходит Unity Asset Store, который позволяет покупать\продавать практически все, что поможет при разработке, будь то отдельные скрипты, паки с моделями или же целые игровые проекты и стартер киты, которые могут сэкономить огромный объем труда, позволив не писать базовые вещи, которые есть почти во всех играх.

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