Перейти к содержимому

Как создать рогалик

  • автор:

Как написать рогалик за 15 шагов

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

Пожалуйста, оставьте свои комментарии — возможно, мы сделаем эту статью действительно полезной. Какие у вас есть пути?

Шаг 1 — Принятие решения написать свою игру

Большинство из вас, скорее всего уже прошли этот момент, но тут есть несколько намёков о направлении первого шага. Я думаю, лучшая причина начать разработку собственного рогалика — это создание игры, в которую ты сам мог бы играть с удовольствием. Это как в моём случае.

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

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

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

Шаг 2 — Привет, мир (Hello world)!

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

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

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

Напиши простенькую ‘Hello world!’ программу и проверь её работоспособность. Протестируй свои библиотеки и т.д. — тебе не нужно никаких сюрпризов.

Начинай писать код.

Шаг 3 — Это человек!

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

Сделай функцию чтения нажатых клавиш (никаких файлов настроек, никаких переопределений клавиш).

Создай демо — «@ бегает по пустому экрану». Поиграй в неё немного, измени, если что-то не понравится, поиграй ещё, представь, будто игра уже закончена, и ты играешь в неё. 😉

Напиши функции вывода сообщений — особенно для отладочных сообщений — это очень удобно.

Шаг 4 — Карта

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

Пусть «@» появится на карте — сначала не как её элемент, а просто как курсор. Проверь скроллирование, можно добавить команду «просмотр» (look).

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

Шаг 5 — Сохранение/Загрузка

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

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

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

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

Шаг 6 — Он живой! Живой!

Создай других существ (монстров) и время. Для начала одного монстра. Дай ему простенький AI (скажем, просто стоять, либо двигаться в случайном направлении).

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

Не забывай тестировать всё, что ты реализуешь.

Шаг 7 — Взаимодействие

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

Сделай, чтобы существа могли видеть действия других — движения, атаки и т.д. Улучшай их AI, так, чтобы они смогли преследовать игрока.

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

Шаг 8 — Файлы данных

Помести существ, свойства карты и т.п. информацию в файлы данных. Забудь пока что о скриптах. Если что-то нельзя переместить в файлы, пусть пока остаётся.

Шаг 9 — Вещи

Добавь вещи. Сначала это будут просто объекты, которые можно подобрать — без каких-либо свойств. Затем давай им свойства, типы, характеристики и т.д. Реализуй инвентарь, «поднятие» и «выкидывание», «одевание» и «использование» (пока без эффектов), а также складывание в кучи, контейнеры (если такие нужны) и т.д.

Это довольно большой шаг, требующий много тестирования.

Шаг 10 — Магия

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

Шаг 11 — Простенькая игра

Попробуй создать простую игру. Поиграй в неё и дай поиграть своим друзьям. Протестируй реализованную механику. Смотри, в какие моменты игра интересна.

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

Этот период займёт достаточно много времени, до тех пор, пока не получишь играбельную, интересную мини-игру.

Шаг 12 — Уровни

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

Распредели монстров и вещи на определённых уровнях. Добавляй больше монстров и существ, со своими свойствами, если нужно.

Шаг 13 — Опыт

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

Много играй в свою игру.

Шаг 14 — Жители

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

Шаг 15 — Полная свобода

Начинай добавлять и тестировать все «уникальные» игровые возможности, о которых ты думал, что они «реально классные» несколько месяцев (лет?) назад. Исправляй их, если нужно, чтобы они были действительно классные.

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

Автор: Radomir ‘The Sheep’ Dopieralski.
Источник: неизвестен.
Перевел: Sanja, 3.12.2006.

Краткое введение

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

Почему именно Python?

Большинство людей, знакомых с этим языком, находят его очень интересным. Python стремится быть простым, но мощным, и крайне понятным для новичков. Проходить данный учебник без знания этого языка будет трудновато. Поэтому мы рекомендуем вам установить Python 2.7 и освоить хотя бы первые главы Python Tutorial (Примечание для пользователей Windows 7 x64: устанавливайте 32-битную версию, так как, по-видимому, 64-битный Python не дружит с libtcod). Если вы хоть немного поэкспериментируете с языком, то понять учебник вам будет гораздо проще. Не забывайте, что Справка Python Library — ваш лучший друг в этом деле. В стандартной библиотеке есть всё, что вам нужно для работы. И будьте готовы к тому, что в процессе разработки вам придётся искать в ней справку по любой неизвестной функции.

Почему именно libtcod?

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

Начало учебника

Начните с первой главы!

  • Глава 1: Графика Начнём создание игры с настройки окна. Нарисуем классическую @ и заставим её перемещаться нажатием клавиш стрелок.
  • Глава 2: Объект и карта Здесь мы освоим две новых идеи: это система универсального объекта, которая станет основой всей игры; и это общий объект карты, в котором будет храниться наше подземелье.
  • Глава 3: Подземелье Узнаем как написать небольшой и понятный генератор подземелья.
  • Глава 4: Поле зрения и исследование Отображение поля зрения игрока (FOV) и постепенное исследование подземелья (также известное как «туман войны»).
  • Глава 5: Подготовка к бою Разместим в подземелье несколько орков и троллей (ненадолго!). А ещё, разберёмся с блокирующими объектами и состояниями игры. Всё это нам понадобится в следующей главе.
  • Глава 6: Впадаем в ярость берсерка! Охота на монстров, сражения, крошилово — о чём тут ещё говорить?
  • Глава 7: Интерфейс Вкусный интерфейс с полосками состояния и разноцветный журнал сообщений, дающий глазу наибольшую усладу. Кроме того, старая-добрая команда «обзор» с небольшой доработкой: можно рассматривать объекты мышью.
  • Глава 8: Вещи и инвентарь Игрок сможет поднимать вещи с пола и использовать их через удобный экран инвентаря. Больше вещей мы добавим в следующей главе.
  • Глава 9: Заклинания и дистанционный бой Варианты действий игрока вырастут экспоненциально с добавлением нескольких свитков магии. Создадим заклинания урона и разума, не забудем и про дистанционный бой.
  • Глава 10: Главное меню и сохранение Готовое главное меню с фоновой картинкой и возможностью сохранять и загружать игру.
  • В 11-ой главе будет разобран переход между этажами подземелья, прокачка игрока по уровням и его характеристики.

Приложения

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

  • Удобный ярлык Python для Notepad++ Настройка ярлыка для пользователей программы Notepad++. Удобно для отладки.
  • Олдскульные тайлы стен и полаs Использование символов в тайлах без получения странных глюков с графикой. По сути, метод очень простой.
  • Бой в реальном времени Система скорости, меняющая пошаговый бой из учебника на бой в реальном времени!
  • Прокрутка карты Код, реализующий прокрутку карты на экране при движении игрока
  • Создание исполняемого файла Легко и просто упаковываем игру!

Автор и благодарности

Код и учебник написаны João F. Henriques (a.k.a. Jotaf). Спасибо: George Oliver, за помощь с форматированием, сортировкой глав и подсветкой синтаксиса; Teddy Leach за его рецензии; и всем форумчанам с форума libtcod за их неоценимую поддержку!

Спокойно заходите на libtcod/Python forum если у вас возникли проблемы, если вам хочется показать свой проект или просто пообщаться! Всегда приятно получить обратную связь по этому учебнику и узнать о разработке других рогаликов.

Примечание переводчика

Текст учебника будет адаптироваться под самую свежую версию libtcod. На текущий момент, это версия 1.5.1rc1.

Автор: João F. Henriques (a.k.a. Jotaf)
Источник: Complete Roguelike Tutorial, using Python+libtcod
Перевод: Sanja, 25.03.2012

Как создать Roguelike

image

Я всегда хотел написать подробное руководство для начинающих о том, как создать roguelike, содержащее как общие, так и более специфические советы. Проведённый в этом году очередной праздник Roguelike Celebration показался мне отличной возможностью наконец-то заставить себя это сделать, поэтому я подготовил получасовой доклад по этой теме.

У меня есть довольно большой опыт — в течение последних семи лет я работал только в этом жанре (Cogmind, Cogmind 7DRL, POLYBOT-7, REXPaint, X@COM), и в течение последних пяти эта работа была моей основной. К тому же, все эти годы я помогал превращению r/RoguelikeDev в крупнейшее сетевое сообщество разработчиков roguelike.

Доклад «Как создать Roguelike» доступен и в форме видео (см. клип ниже). Данная статья является текстовой версией того же доклада для тех, кто предпочитает читаемый формат или захочет повнимательнее разглядеть кучу изображений из доклада.

Введение

Пару лет назад на первом празднике Roguelike Celebration я прочёл доклад, о том, как я стал разработчиком, но сейчас я хочу рассказать о том, как любой может приступить к разработке собственного roguelike. Довольно часто игроки в roguelike хотя бы пробуют заняться их созданием. Мы вдохновляемся играми, в которые играем, и хотим сделать что-то лучшее, что-то иное, или просто что-то своё. Мой доклад совершенно точно не будет являться туториалом, он больше посвящён тому, как начать разработку и общим советам, способным помочь вам на этом пути.

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

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

Непрямое приближение к своей цели. Когда-нибудь… (Это анимация — откройте изображение в отдельном окне, чтобы процесс начался снова.)

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

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

Сначала направляйтесь прямиком к цели и начинайте с прочного фундамента. (Это анимация — откройте изображение в отдельном окне, чтобы процесс начался снова.)

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

  • Язык
  • Масштаб
  • Базовая механика
  • 7DRL
  • Ресурсы
  • Приманки
  • Советы

Язык

Давайте начнём с первого и самого стандартного вопроса: какой язык использовать.

Ответ прост: любой.

Немного более длинный ответ: это не очень важно. Если вы уже имеете опыт работы с каким-то языком, то это отлично, берите и пользуйтесь им. Язык — это только средство, и для создания roguelike люди уже пользовались почти всеми языками.

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

Пример кода на python из туториала по libtcod.

Начинающим разработчикам roguelike часто рекомендуют Python, потому что с ним довольно просто работать. Достаточно посмотреть на этот код. Здесь нет кучи странного синтаксиса, и если даже вы не знаете программирования или Python, то, вероятно, всё равно сможете разобраться, что в нём происходит.

Но не волнуйтесь, его «простота» не является ограничивающим фактором — в Python вы всё равно можете создавать замечательные вещи.

Ultima Ratio Regum написан на Python. Это красивый массивный проект с открытым миром, который ещё не завершён, но уже невероятно впечатляет.

Temple of Torment — это ещё один объёмный и завершённый фэнтезийный roguelike, написанный на Python.

Существуют буквально сотни написанных на Python roguelike. То есть если вы начнёте с него, то ваше путешествие будет более лёгким, и позже мы вернёмся к тому, как с него начинать.

Выборка языков программирования, используемых разработчиками roguelike.

Более сложные языки наподобие C и C++ хороши тем, что они популярны очень давно, то есть вы найдёте по ним множество ресурсов и справочной информации. Я работаю с C++, но пользуюсь я им только потому, что уже был с ним знаком. Я бы не рекомендовал его для новичков, особенно если вы хотите создать roguelike, а не тратить всё своё время на отладку! Вы всё равно найдёте множество других разработчиков, пользующихся Python, поэтому тоже будете иметь доступ к куче ресурсов.

Масштаб

Ещё одна проблема, встающая перед новыми разработчиками: создание «roguelike их мечты». Должно ли это стать вашей первой целью? Почти никогда нет!

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

Вернёмся к рассмотренной выше карте разработки. Вот основной путь, на котором вам нужно сосредоточиться:

Основной маршрут разработки затрагивает только выборку из необходимых функций (заметьте, что обычно напротив боя («combat») я ставлю вопросительный знак, потому что в roguelike бои не всегда используются!).

Это может быть или завершённой игрой, или надёжным основанием, на котором можно развиваться дальше. Все остальные области могут казаться интересно исследовать, но постарайтесь на ранних этапах не слишком отдаляться от основного пути. Это похоже на игру в roguelike: если вы начнёте с того, что вслепую бегаете по неизвестности, вместо того, чтобы делать необходимое, то если RNG не будет полностью на вашей стороне, вы быстро где-нибудь умрёте. И много раз. Да, так играть тоже интересно, но создание roguelike — это совсем другая история, требующая бОльших вложений времени, поэтому постарайтесь сосредоточиться.

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

Пристройка к ядру roguelike новых кусков.

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

В результате вы приклеите к основе так много кусков, что не заметите, как пройдут десять лет!

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

Базовая механика

Так что же действительно требуется небольшой roguelike? Базовая механика. Именно с неё начинается игровой процесс. Нужно, чтобы её можно было объяснить одним предложением, и именно её надо прототипировать первой. Прямиком приступайте к самой интересной части игры.

Каким будет уникальный взгляд игры на жанр roguelike? Если в вашей игре есть только эта механика, будет ли она интересной? Если вы уже думаете о большем, то может ли эта механика служить основой остальной части игры? Задумайтесь о том, чем будет заниматься игрок минута за минутой, скорее всего, это и будет нечто связанное с базовой механикой. Если этот повторяющийся процесс не интересен, то неважно, что вы надстроите поверх него!

Визуализация базовой механики как фундамента дизайна roguelike.

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

Чтобы ещё немного изучить базовую механику, давайте рассмотрим 7DRL.

7DRL

7DRL — это roguelike, созданная за 7 дней. Примерно в марте каждого года проводится мероприятие, на котором множество разработчиков пытается создать собственную roguelike. Это мероприятие проводится уже 14 лет. И это здорово, потому что если вы закончите игру, то совершенно точно найдётся хотя бы несколько людей, которые в неё сыграют и оставят отзывы. Кроме того, существуют судьи, оценивающие игры по различным критериям, однако почти все разработчики считают 7DRL в первую очередь вызовом себе (мероприятие не рассматривается как соревнование).

Успехи 7DRL по годам (2005-2018).

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

Мероприятия 7DRL — это отличные примеры подхода «начинать с малого и расширяться по необходимости после того, как вы убедились, что базовая механика выглядит хорошо». То есть на 7DRL по сути создаются хорошие прототипы, и во многом мероприятия экспериментальны по своей природе. Каждый год мы видим множество отличных инновационных идей!

Давайте рассмотрим несколько примеров…

Knight (7DRL 2014)

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

A Roguelike Where You Dodge Projectiles (7DRL 2016)

Мне нравится, что в этом 7DRL базовая механика изложена прямо в названии («Roguelike, в которой нужно избегать снарядов», скачать можно здесь). Персонаж игрока — корабль в космосе, и хоть вы автоматически атакуете врагов в пределах своей области действия, выстреливаемые врагами снаряды летят очень медленно. Вы можете видеть, где они окажутся в следующем ходу, и должны маневрировать так, чтобы и продолжать их атаковать, и избегать попадания в свой корабль.

Seven Day Band (7DRL 2015)

В Seven Day Band вы создаёте собственную roguelike в процессе игры. Блуждая по миру, вы встречаетесь с новыми, неизвестными врагами и объектами и должны давать им имена и способности при первой встрече, или когда они станут для вас важны. («Band» в названии обозначает создание собственной игры в стиле Angband.)

Broken Bottle (7DRL 2011)

В Broken Bottle вы играете за алкоголика в постапокалиптическом мире. Хорошо это или плохо, но основная часть игрового процесса связана с потреблением алкоголя. (Игра сильно сосредоточена на сюжете.)

Drakefire Chasm (7DRL 2012)

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

Golden Krone Hotel (7DRL 2014)

В Golden Krone Hotel вы пользуетесь преимуществами разных способностей вампирской и человеческой форм персонажа, в том числе и взаимодействием с динамическим светом. Эта игра со временем превратилась в серьёзную коммерческую roguelike, и после выпуска год назад хорошо показала себя в Steam.

Cogmind 7DRL (2012)

Это моя первоначальная Cogmind 7DRL, в которой игрок управляет роботом, создающим себя с нуля, используя части других роботов. Предметы разрушаются чрезвычайно быстро, поэтому игроку приходится часто себя отстраивать заново. Эта игра позже тоже стала гораздо более крупным коммерческим проектом. Я никак не ожидал, что мой небольшой эксперимент на 7DRL шесть лет назад превратиться в работу, но очень рад, что поучаствовал в мероприятии, ведь оно доказало интересность базовой механики.

POLYBOT-7 (7DRL 2018)

В этом году для 7DRL я создал POLYBOT-7, который в чём-то похож на Cogmind, но играется совершенно иначе, потому что базовая механика сильно изменена. Игрок больше не выбирает, какие части прикрепить к роботу, теперь они притягиваются автоматически и он не может от них избавиться. Детали удаляются только в случае их уничтожения. Изначально я планировал, что игра станет Cogmind в меньшем масштабе, но с приближением 7DRL начал ощущать, что такую игру создавать не стоит — у неё должна быть действительно уникальная привлекательная черта, совершенно новая базовая механика. Она оказалась довольно интересной и стала хорошей причиной для создания множества дополнительных механик, поддерживающих новый тип геймплея (сравнение есть здесь; также я написал объёмный постмортем, описывающий процесс его разработки от начала до конца).

Итак, хоть у этих игр очевидно есть несколько систем, довольно очевидно, в чём заключается их базовая механика, и вместе со многими другими 7DRL они благодаря этому сильно выделяются из толпы.

Примеры не с 7DRL

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

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

В Demon игрок нанимает множество разнообразных демонов, автономно следующих за ним, и тренирует их.

The Ground Gives Way

Есть The Ground Gives Way, в которой присутствует развитие полностью на основе предметов.

Xenomarine построена на механике дальнего боя и учёта направления взгляда — не во многих roguelike такое есть.

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

Источники

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

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

Давайте рассмотрим наиболее полезные ресурсы…

r/RoguelikeDev

Сабреддит RoguelikeDev — это самая крупная группа активных разработчиков roguelike во вселенной. У нас собралось очень гостеприимное и готовое помочь сообщество, а хорошо организованная боковая панель содержит ссылки на множество полезных ресурсов.

r/RoguelikeDev и его информативная боковая панель.

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

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

Как и большинство игровых библиотек, libtcod берёт на себя работу с основными аспектами, такими как окно игры, поддержка мыши и клавиатуры, растровые шрифты, палитры и манипуляции цветами. Однако кроме этого она выполняет множество сложных задач, специфичных для roguelike, таких как генерация карты, FOV (область видимости) и поиск пути.

Примеры функций, используемые в интерактивном демо libtcod.

Описанные выше Ultima Ratio Regum и Temple of Torment начались как игры, созданные с помощью этого туториала, и постепенно выросли в уникальные проекты. libtcod великолепна, для неё уже десять лет выпускаются обновления.

Ещё один способ начать обучение — поучаствовать в летнем мероприятии «кодируем вместе» r/RoguelikeDev. Если вам нужна дополнительная мотивация и помощь в пути, то вместе с другими разработчиками вы будете следовать шагам туториала libtcod.

Логотип летнего «кодируем вместе» r/RoguelikeDev

Пока мы выполняли туториал пару лет, и интерес по-прежнему был высок, в каждом году участвовало примерно по 100 человек. Строго говоря, для участия даже необязательно использовать libtcod или Python — многие люди используют другие языки и движутся вместе с нами в своей собственной roguelike или похожих туториалах.

Через два месяца у вас будет своя играбельная roguelike! Вот некоторые из игр, вышедшие после мероприятия за последнюю пару лет:

Примеры проектов летнего мероприятия r/RoguelikeDev «кодируем вместе».

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

Также в RoguelikeDev есть сборники FAQ, объясняющие различные аспекты разработки, чтобы вы поняли, как подходить к решению различных задач. Мы ответили уже на довольно много вопросов.

Темы пятничных FAQ, номера с 1 по 74

Также сюда включены метатемы, например планирование и мотивация, такие подробности, как обычно применяемые системы, дизайн и всё остальное! За долгие годы свой вклад в FAQ сообщества сделали довольно много разработчиков, в том числе и авторов хорошо известных roguelike.

Обычно в сабреддите постоянно есть куча разработчиков, многие из которых разрабатывают долговременные хобби-проекты. Они компетентны и готовы вам помочь. Также у нас есть Discord для помощи и обсуждений в реальном времени. (Этот сервер мы делим с сабреддитом r/Roguelikes, поэтому в других его каналах вы всегда найдёте множество людей, играющих во всевозможные roguelike и обсуждающих их.)

RogueBasin

Много лет назад Сантьяго Запата создал отличный веб-сайт, о котором вы могли слышать: RogueBasin. Здесь можно найти целый раздел со статьями, посвящёнными разработке.

Содержание раздела статьей RogueBasin.

Там довольно много статей (показанный выше список — это всего лишь общее содержание!). Хоть некоторым статьям уже много лет, большинство из них не утратило своей актуальности. Именно отсюда я начал свой путь много лет назад, статьи показались мне и вдохновляющими, и просвещающими. (А также немного поначалу пугающими, но не забывайте, что roguelike разрабатываются по кусочкам — делайте за раз только один шаг!)

Roguelike Radio

Дэррен Грей, Эндрю Дулл, Марк Джонсон и другие ведут подкаст Roguelike Radio.

Список тем Roguelike Radio (2011-2018).

Прослушайте все эти темы! В них также содержатся интервью с большим количеством разработчиков roguelike. Даже я участвую в двух или трёх, в том числе и там, где я говорю, что Cogmind, возможно, будет завершён в 2016 году или около того (Ха-ха-ха) (Скоро наступит 2019, но не требуйте от меня невозможного — всё больше игроков находит его и я постоянно добавляю в проект новый контент и функции, просто потому что могу.)

Также вы увидите, что во множестве подкастов рассказывается о 7DRL, которое является довольно важным для сообщества мероприятием.

Итак, мы получили довольно большой объём знаний, но при разработке игр в целом существует ещё одна важная сторона — ресурсы

Ресурсы

Вот наши ресурсы:

Ресурсы при разработке Roguelike

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

Если вы знакомы с roguelike, то могли уже узнать Brogue, но за долгие годы я собрал большую коллекцию вдохновляющих ASCII-скриншотов, и хочу поделиться ею, чтобы вы осознали возможности:

22 изображений из различных ASCII-roguelike. (И чтобы пресечь неизбежные вопросы: названия этих проектов можно найти здесь.)

Вариативность просто поражает — огромное пространство для реализации уникальных стилей!

При работе с монохромными тайлсетами в формате ASCII или с ASCII-подобным, вы можете использовать мой редактор REXPaint (бонус — к тому он интегрируется с libtcod!). Для меня он стал совершенно незаменимым инструментом, и его использует довольно много других разработчиков для таких вещей, как создание дизайна интерфейса, карт и графики.

Логотип REXPaint, частичный интерфейс и примеры изображений (учтите, что в записи слишком много цветов и gif искажает палитру).

Тайлсеты

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

Примеры 2D-тайлсетов для roguelike.

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

Демо тайлсетов для roguelike.

Хорошие отправные точки

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

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

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

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

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

Тема

Существуют сотни фэнтезийных бродилок по подземельям (fantasy dungeon crawler), поэтому если вы хотите, чтобы ваш проект выделялся из толпы, то стоит выбрать любую уникальную тему, которая не является fantasy dungeon crawler.

Мозговой штурм возможных тем для roguelike.

Roguelike обычно базируются на хорошем/интересном геймплее, однако наличие уникальной темы не только делает уникальным весь геймплей, но и даёт источник, из которого можно получать совершенно новые механики. (Уникальная тема практически вынуждает вас пойти таким путём.) В частности, исторические и мифологические темы предоставляют огромный объём материала для исследований и экспериментов. Похоже, людям всегда хотелось больше научно-фантастических roguelike, чем у нас есть. Несмотря на её широту, это довольно неисследованная группа тем, особенно по сравнению с объёмом научно-фантастического контента в других жанрах.

За последние годы появилось несколько действительно уникальных тем.

MakaiRL — это отличный концепт, основанный на японской мифологии и исторической фэнтези. Хотел бы я в неё поиграть!

Skies of Bloody April — это roguelike, посвящённый самолётным дуэлям Первой мировой войны.

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

Примером уже завершённой игры является Lone Spelunker, где игрок исследует естественные и иногда опасные чудеса подземных пещер.

Среди тем, спрос на которые ещё не удовлетворён, в сообществе roguelike довольно часто упоминаются пираты. Существует одна игра, Pirate Rogue, одна из самых популярных тем в сабреддите Roguelikes.

Концепт-арт Pirate Rogue.

Но Pirate Rogue — это просто концепт, который разработчик прототипировали, после чего приостановил проект, потому что осознал, что для создания игры его мечты ему немного не хватает опыта. Однако спрос на эту тему очевидно не удовлетворён.

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

В сабреддите RoguelikeDev появляется множество отличных историй, а также потрясающих проектов, как новых, так и с долговременных. Но в особенности я хотел бы поделиться одной историей, которую я считаю очень вдохновляющей — историю Armoured Commander.

Игрок управляет одним танком Второй мировой войны, внутри которого он может командовать несколькими членами экипажа в наземных кампаниях. Разработчик игры Грегори Скотт начинал этот проект, имея небольшой опыт программирования, и занялся им в процессе изучения туториала libtcod.

Год спустя игра была завершена и её обзор сделал Rock, Paper, Shotgun.

Armoured Commander в Rock, Paper, Shotgun.

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

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

Сейчас Грегори работает над сиквелом: ArmCom 2.

Помните, что ваша игра необязательно должна быть только roguelike. Здесь я немного покощунствую, сказав, что не стоит ограничиваться определениями. Часто мы видим людей, придумывающих идею игры, которую они хотят создать, но слишком беспокоящихся о том, все ли сочтут её roguelike. На самом деле это неважно, потому что есть столько же жанров, сколько и игроков! Если игра целостна и следует вашему собственному плану, то вы идёте верным путём. (Но не волнуйтесь, в сабреддите Roguelikes всё равно еженедельно будут возникать споры, является ли ваша игра roguelike xD)

XRL

Теперь совершим разворот на 180 градусов. Можно выбрать другой подход, который имеет собственные преимущества — XRL. Такие игры основаны на уже существующих франшизах, и экономят вам много усилий по планированию и дизайну, которые можно направить на создание игры, потому что чаще всего на многие вопросы есть готовый ответ. Максимум, что вам нужно сделать — адаптировать их под формулы roguelike. Работая над XRL, вы можете сосредоточиться на реализации и других основах, не экспериментируя с чем-то новым.

Этот путь выбирает множество разработчиков. Какое-то время назад я создал список примеров XRL на RogueBasin. Все описываемые ниже roguelike основаны на уже существующей интеллектуальной собственности (IP).

Неполный список XRL.

Лично я считаю, что это хороший способ начать разработку первой игры.

Вероятно, самой знаменитой XRL является DoomRL. После получения письма-предупреждения от Zenimax за использование торговой марки теперь она официально называется просто DRL.

Примечание: учтите, что нужно быть аккуратными с особо любящими судебные тяжбы компаниями, например Nintendo (крайне не рекомендую браться за roguelike по Pokemon!), но в целом roguelike — очень нишевый жанр, незаметный для правообладателей, так что для хобби-проекта XRL вполне подойдёт. Только те, которые получают значительную известность, могут вызывать проблемы, но к этому моменту вы или можете ребрендировать игру своим собственным контентом, или будете обладать достаточным опытом, чтобы начать всё с нуля. Обычно XRL являются короткоживущими мелкомасштабными учебными проектами, однако множество XRL находится в разработке уже долгое время. (Как бы то ни было, забудьте о любых попытках заработать на чужой интеллектуальной собственности!)

Сейчас разработчик DoomRL Корнел Киселевич активно работает над преемником DoomRL под названием Jupiter Hell. Отличный пример того, как с помощью XRL можно собрать огромную базу фанатов, а затем использовать их поддержку для создания ещё более масштабной коммерческой roguelike.

Ещё раньше Корнел создал две другие XRL: AliensRL (одна из первых roguelike, в которые я играл) и DiabloRL.

Продуктивный разработчик roguelike Slashie создал roguelike на основе Castlevania, Metroid, Zelda, Star Wars, Megaman, и вероятно ещё десятка франшиз, о которых нам не рассказывал 😛

Коллекция XRL Slashie.

Даже мой собственный полу-roguelike проект XCOMRL относится к этой категории. Он основан на первой UFO Defense, и начинался с IP и механик, которые были мне хорошо знакомы и любимы мной.

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

Модифицированные карты X@COM, часть из которых является переходом во вселенную, совершенно отличающуюся от X-Com.

Ещё одно серьёзное преимущество XRL заключается в том, что у вас сразу же появляются фанаты — другие люди, которым нравятся roguelike и выбранная вами IP. И это очень помогает мотивации, потому что всегда найдутся поддерживающие вас люди. Множество моих сторонников сегодня — это те же люди, которые следили за моей работой над X@COM.

Советы на долгую перспективу

Вот несколько советов, которые помогут вам не сдаваться в работе над долгим проектом…

Выпускайте релизы сразу и часто

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

История объявления релизов на RogueBasin.

Sharing Saturday

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

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

Приходите и делитесь с нами!

Ведите блог

Кроме Sharing Saturday, неплохо также сосредоточить всю информацию о разработке вашего проекта в одном месте. В доступном всем месте. На самом деле блогинг имеет множество преимуществ; вот список самых важных:

  • он позволяет привести мысли в порядок
  • изучить свою работу под другим углом
  • документировать процесс
  • создать полезные справочные материалы на перспективу
  • получить обратную связь
  • построить сообщество вокруг проекта

Пять лет блогинга Grid Sage Games.

Возможно, там вы найдёте полезную информацию, которая дожидается вас

Важна доступность

Доступность — это важно. Традиционно это не относилось к roguelike, но сегодня, если приложить усилия, мы можем достучаться до гораздо большей аудитории. Под усилиями я подразумеваю достаточную документацию, туториал, полную поддержку мыши, тайлсет и т.д…

Чтобы понять, насколько ценными могут быть поддержка мыши и тайлсет, посмотрите на статистику игроков из Cogmind:

Предпочтения игроков в Cogmind: преимущество у мыши и тайлов!

Учтите, что некоторые аспекты доступности игры необходимо учесть в дизайне с самого начала, но для первого roguelike этим заниматься не стоит. Достаточно начать с ASCII и клавиатурного управления.

Начало

Это конец моей статьи и начало вашей отличной новой roguelike.

Пишем свою игру в жанре Roguelike

Обложка поста Пишем свою игру в жанре Roguelike

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

Игры в жанре roguelike, такие как Dungeons of Dredmor, Spelunky, The Binding of Isaac и FTL, в последнее время стали очень популярны, а различные комбинации элементов этого жанра теперь добавляют многим играм глубины и реиграбельности.

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

Следуя инструкциям этого руководства, вы создадите традиционный «рогалик», используя игровой движок Phaser на JS+HTML5. Кстати, недавно мы публиковали обзор таких движков. В результате вы получите полнофункциональную игру в жанре «roguelike», запускаемую в браузере. (Под рогаликом мы подразумеваем одиночный рандомизированный пошаговый dungeon-crawler с одной жизнью.)

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

Примечание: хотя в этом руководстве и используются JavaScript, HTML и Phaser, вы можете использовать эти принципы для реализации на любом другом языке и движке.

Подготовка

Вам понадобятся текстовый редактор и браузер. Я использую Notepad++ и Google Chrome, но это не принципиально.

Затем вы должны скачать исходники и начать с папки init : она содержит файлы Phaser, HTML и JS, необходимые для нашей игры. Наш код мы будем писать в пустом файле rl.js .

Файл index.html file просто загружает Phaser и вышеупомянутый файл с кодом игры:

  roguelike tutorial   

Инициализация и определения

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

Давайте зададим несколько констант для размера шрифта, размера карты и количества персонажей:

// font size var FONT = 32; // map dimensions var ROWS = 10; var COLS = 15; // number of actors per level, including player var ACTORS = 10; 

Также инициализируем Phaser и слушатели сигналов с клавиатуры, так как мы создаём пошаговую игру и хотим создавать действие после каждого нажатия клавиши:

// initialize phaser, call create() once done var game = new Phaser.Game(COLS * FONT * 0.6, ROWS * FONT, Phaser.AUTO, null, < create: create >); function create() < // init keyboard commands game.input.keyboard.addCallbacks(null, null, onKeyUp); >function onKeyUp(event) < switch (event.keyCode) < case Keyboard.LEFT: case Keyboard.RIGHT: case Keyboard.UP: case Keyboard.DOWN: >> 

Так как ширина стандартных моноширинных шрифтов равна 60% от высоты, мы зададим размер поля как 0.6 * размер шрифта * количество столбцов . Мы также говорим Phaser, что он должен вызвать нашу функцию create() сразу после завершения инициализации, когда инициализируется и управление с клавиатуры.

Можете взглянуть на нашу игру — правда, там пока и смотреть не на что:)

Карта

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

// the structure of the map var map; 

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

function initMap() < // create a new random map map = []; for (var y = 0; y < ROWS; y++) < var newRow = []; for (var x = 0; x < COLS; x++) < if (Math.random() >0.8) newRow.push('#'); else newRow.push('.'); > map.push(newRow); > > 

Таким образом мы получим карту, примерно на 20% занятую стенами.

Мы инициализируем новую карту в функции create() сразу после запуска слушателей клавиатуры:

function create() < // init keyboard commands game.input.keyboard.addCallbacks(null, null, onKeyUp); // initialize map initMap(); > 

Можете посмотреть, что получилось — пока что мы всё равно не отрисовали наши карту.

Экран

Настало время вывести нашу карту на созданный экран:

// the ascii display, as a 2d array of characters var asciidisplay; function drawMap()

Тем не менее, перед отрисовкой карты экран нужно инициализировать. Вернёмся к функции create() :

function create() < // init keyboard commands game.input.keyboard.addCallbacks(null, null, onKeyUp); // initialize map initMap(); // initialize screen asciidisplay = []; for (var y = 0; y < ROWS; y++) < var newRow = []; asciidisplay.push(newRow); for (var x = 0; x < COLS; x++) newRow.push( initCell('', x, y) ); >drawMap(); > function initCell(chr, x, y) < // add a single cell in a given position to the ascii display var style = < font: FONT + "px monospace", fill:"#fff">; return game.add.text(FONT*0.6*x, FONT*y, chr, style); > 

Теперь при запуске проекта вы должны видеть случайную карту.

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

Персонажи

Теперь займёмся персонажами: нашим игроком и его врагами. Каждый персонаж будет объектом с тремя полями: координаты x и y и хитпоинты hp .

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

// a list of all actors; 0 is the player var player; var actorList; var livingEnemies; // points to each actor in its position, for quick searching var actorMap; 

Мы создаём всех персонажей и рандомно размещаем их на свободных ячейках карты:

function randomInt(max) < return Math.floor(Math.random() * max); >function initActors() < // create actors at random locations actorList = []; actorMap = <>; for (var e=0; e; do < // pick a random position that is both a floor and not occupied actor.y=randomInt(ROWS); actor.x=randomInt(COLS); >while ( map[actor.y][actor.x] == '#' || actorMap[actor.y + "_" + actor.x] != null ); // add references to the actor to the actors list & map actorMap[actor.y + "_" + actor.x]= actor; actorList.push(actor); > // the player is the first actor in the list player = actorList[0]; livingEnemies = ACTORS-1; > 

Настало время показать персонажей! Мы изобразим всех врагов буквой e , а игрока — количеством его хитпоинтов:

function drawActors() < for (var a in actorList) < if (actorList[a].hp >0) asciidisplay[actorList[a].y][actorList[a].x].content = a == 0?''+player.hp:'e'; > > 

Возьмём только что написанные функции и передадим их в create() :

function create() < . // initialize actors initActors(); . drawActors(); > 

Теперь мы можем увидеть размещённых на поле противников и игрока!

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

Блокирующие и неблокирующие клетки

Нам нужно убедиться, что персонажи не выходят за пределы уровня и не проходят сквозь стены, поэтому добавим простую проверку:

function canGo(actor,dir) < return actor.x+dir.x >= 0 && actor.x+dir.x = 0 && actor.y+dir.y

Перемещение и сражение

Наконец-то мы дошли до движухи! Так как в классических рогаликах персонажи атакуют друг друга при столкновении, мы обработаем это в функции moveTo() , которая принимает персонажа и направление (направление задаётся разностью координат x и y текущей и желаемой клеток):

function moveTo(actor, dir) < // check if actor can move in the given direction if (!canGo(actor,dir)) return false; // moves actor to the new location var newKey = (actor.y + dir.y) +'_' + (actor.x + dir.x); // if the destination tile has an actor in it if (actorMap[newKey] != null) < //decrement hitpoints of the actor at the destination tile var victim = actorMap[newKey]; victim.hp--; // if it's dead remove its reference if (victim.hp == 0) < actorMap[newKey]= null; actorList[actorList.indexOf(victim)]=null; if(victim!=player) < livingEnemies--; if (livingEnemies == 0) < // victory message var victory = game.add.text(game.world.centerX, game.world.centerY, 'Victory!\nCtrl+r to restart', < fill : '#2e2', align: "center" >); victory.anchor.setTo(0.5,0.5); > > > > else < // remove reference to the actor's old position actorMap[actor.y + '_' + actor.x]= null; // update position actor.y+=dir.y; actor.x+=dir.x; // add reference to the actor's new position actorMap[actor.y + '_' + actor.x]=actor; >return true; > 
  1. Мы убеждаемся, что персонаж может переместиться в эту клетку.
  2. Если в ней есть другой персонаж, мы атакуем его (и убиваем, если счётчик его хитпоинтов достигает нуля).
  3. Если клетка пуста, мы перемещаемся в неё.

Заметим также, что мы выводим простое сообщение о победе после смерти последнего врага и возвращаем false или true в зависимости от того, валидно ли желаемое перемещение.

Теперь вернемся к функции onKeyUp() и изменим её так, чтобы при каждом нажатии клавиши мы стирали предыдущие положения персонажей (отрисовывая поверх них карту), перемещали игрока и снова отрисовывали персонажей:

function onKeyUp(event) < // draw map to overwrite previous actors positions drawMap(); // act on player input var acted = false; switch (event.keyCode) < case Phaser.Keyboard.LEFT: acted = moveTo(player, ); break; case Phaser.Keyboard.RIGHT: acted = moveTo(player,); break; case Phaser.Keyboard.UP: acted = moveTo(player, ); break; case Phaser.Keyboard.DOWN: acted = moveTo(player, ); break; > // draw actors in new positions drawActors(); > 

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

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

Простой ИИ

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

Заметим, что противнику неважно, кого атаковать: таким образом, при правильном размещении противники будут уничтожать друг друга, пытаясь догнать игрока. Прям как в классическом Doom!

function aiAct(actor) < var directions = [ < x: -1, y:0 >, < x:1, y:0 >, < x:0, y: -1 >, < x:0, y:1 >]; var dx = player.x - actor.x; var dy = player.y - actor.y; // if player is far away, walk randomly if (Math.abs(dx) + Math.abs(dy) > 6) // try to walk in random directions until you succeed once while (!moveTo(actor, directions[randomInt(directions.length)])) < >; // otherwise walk towards player if (Math.abs(dx) > Math.abs(dy)) < if (dx < 0) < // left moveTo(actor, directions[0]); >else < // right moveTo(actor, directions[1]); >> else < if (dy < 0) < // up moveTo(actor, directions[2]); >else < // down moveTo(actor, directions[3]); >> if (player.hp < 1) < // game over message var gameOver = game.add.text(game.world.centerX, game.world.centerY, 'Game Over\nCtrl+r to restart', < fill : '#e22', align: "center" >); gameOver.anchor.setTo(0.5,0.5); > > 

Также мы добавили сообщение, которое выводится на экран при смерти игрока.

Теперь нам осталось сделать так, чтобы враги перемещались с каждым ходом игрока. Дополним функцию onKeyUp() :

function onKeyUp(event) < . // enemies act every time the player does if (acted) for (var enemy in actorList) < // skip the player if(enemy==0) continue; var e = actorList[enemy]; if (e != null) aiAct(e); >// draw actors in new positions drawActors(); > 

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

Бонус: версия на Haxe

Изначально я писал это руководство на Haxe, кроссплатформенном языке, компилирующемся в JavaScript (и не только). Эту версию мы можете найти в папке haxe в исходниках.

Сперва вам потребуется установить компилятор haxe, после чего скомпилировать написанный в любом текстовом редакторе код, вызвав haxe build.hxml и дважды кликнув по файлу build.hxml . Я также добавил проект FlashDevelop, если вы предпочитаете пользоваться удобной IDE: просто откройте rl.hxproj и нажмите F5 для запуска.

Заключение

Вот и всё! Мы закончили создание простой roguelike-игры со случайной генерацией карты, движением, боёвкой, ИИ и условиями победы/поражения.

Вот некоторые фичи, который вы могли бы добавить:

  • несколько уровней;
  • бонусы;
  • инвентарь;
  • аптечки;
  • снаряжение.

Следите за новыми постами по любимым темам

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *