Браться за написание игры с продвинутыми механиками просто так нельзя. Вернее, можно.
Однажды я видел, как один молодой программист начал писать RPG. Первым делом он нарисовал красивую анимацию рыцаря, который махал мечом. Анимация была безусловно талантливая, но игра после этого так и не была написана.
Нужно чётко понять, что именно мы хотим реализовать в игре, и насколько сложно будет потом добавить что-то ещё.
Я не буду до буквы следовать правилам оригинальной Rogue, так как многое там реально устарело и неудобно. Вместо этого лучше сконцентрироваться на том, как сделать новую игру, чтобы в ней было всё хорошее и ничего плохого.
Поэтому я, некоторое время подумав, составляю такой список требований:
1. Клиент и сервер
Это самое первое требование, и вот почему. Теоретически игра может быть например браузерной, и работать с сервером, который принимает команды от клиента, генерирует все данные и отправляет в клиент.
Если даже обмен происходит не через интернет, а вся игра находится на локальной машине, сервер всё равно нужно оформить отдельным модулем.
Это устранит любые зависимости между чисто игровой логикой и интерфейсными решениями, которые могут быть какими угодно - текстовыми, графическими, с вводом через клавиатуру или мышь или тач-дисплей.
Можно будет спокойно разрабатывать любые игровые механики на сервере, а для клиента так же спокойно думать, как эти механики отобразить.
Клиент и сервер могут быть даже написаны на разных языках.
2. Походовость
Игра будет походовой, как и в оригинале. Это принципиальное решение, которое нельзя будет изменить в дальнейшем, и мы соглашаемся с этим ограничением. Оно прекрасно ляжет в архитектуру клиента и сервера, так как в каждый ход клиент будет слать запрос на сервер, а сервер будет слать ответ.
3. Процедурная генерация
Это характерная особенность рогалика, которой пренебрегать не будем. Единственное, что нужно доработать, это сделать более интересную генерацию. В оригинале на уровне генерируются просто три ряда по три комнаты разного размера (некоторые комнаты могут отсутствовать), и комнаты соединяются друг с другом случайно расположенными коридорами.
Можно придавать комнатам более интересные формы или вообще делать органические, неровные пещеры. Что приводит к очевидному выводу: нужно использовать разные методы генерации, чтобы получать тематически разные уровни с характерными признаками.
Кроме уровней, процедурно генерировать нужно также предметы и монстров.
4. Seed-генерация
Так назовём процедурную генерацию, которая начинается не с полностью случайного состояния, а с некоторого набора предустановленных значений (seed). Скажем, на уровне можно заранее разместить какие-то фиксированные элементы вроде домов или магазина, а остальное пространство достроить уже генерацией. Это позволит получать в нужных местах уровни с нужными элементами.
5. Размер уровня
Размер карты уровня не должен быть ограничен одним экраном. Уровень может занимать неограниченное пространство, и визуализация ложится на клиента. Это можент быть скроллинг или смена экранов, зуммирование и т.п.
6. Изменяемая карта уровня и переключатели
Требуется, чтобы в топологии уровня могли происходить какие-то изменения. Например, обрушение потолка, появление ловушек, открытие и закрытие дверей по каким-то триггерам, наличие дверей, требующих ключа или артефакта.
7. Монстры разного размера и формы
Хочется ввести инновацию, чобы монстр мог занимать не одну клетку, а несколько. Тогда можно будет делать больших, длинных или изогнутых монстров.
8. Сплэш-эффект
Применение некоторых видов оружия или предметов должно поражать несколько клеток карты одновременно (пример: граната).
9. Чейн-эффект
Ущерб от определённых видов оружия может переходить на соседние цели по цепочке (пример: молния).
10. Предметы
В игре могут быть следующие типы предметов:
- Оружие
- Броня
- Еда
- Зелья
- Ключи
- Артефакты
Чтобы не фиксировать каждый тип отдельно, необходима гибкая и расширяемая система настроек типов предметов.
11. Комбинирование предметов
Нужно, чтобы предметы в инвентаре можно было комбинировать, получая новые предметы или с модифицированными свойствами. Пример: граната + сонное зелье = сонная граната.
12. Свойства предметов
Предметы и не только (враги, местность...) должны иметь набор свойств, которые могут активно или пассивно влиять на владельца предмета или того, кто находится с ними в контакте. Пример: свойство огня, которое наносит ущерб огнём, но может быть также свойство защиты от огня, которое обнуляет ущерб огнём.
Свойства этих свойств (хаха) должны задаваться в некой универсально расширяемой системе, чтобы можно было внедрять новые свойства в любой момент.
13. Система параметров и умений
Игрок и монстры могут иметь различные параметры (жизнь, сила, защита и др.) и умения. Чтобы не ограничивать их сразу каким-то списком, нужно придумать, как безболезненно внедрять новые параметры и умения.
14. Магазины и NPC
На уровнях можно ввести магазины, где игрок может что-то купить или продать, а также NPC, с которыми можно как-то взаимодействовать.
15. Графика
Будет использоваться карта из клеток, как в оригинале, но каждая клетка будет отрисована спрайтом. Естественно, что игрок, монстры и предметы - тоже. Хотя это конечно на откуп клиента, но себе клиент я выбрал вот такой. Всё-таки играть в текстовые символы на экране не очень занятно.
Также требуется сделать возможность анимации спрайтов. Если не сразу, то в дальнейшем надо закладываться на это.
16. Интерфейс
Нужно переработать визуальную составляющую игры и управление, чтоб максимально облегчить взаимодействие игрока с игрой. На этом этапе пока нельзя выдать никаких определённых указаний, они появятся в процессе разработки.
Как с этим всем взлететь?
Все эти пункты не нужно делать сразу. Для начала нужно сделать какой-то минимально рабочий продукт (MVP, Minimum Viable Product), и затем его дорабатывать. Требования приведены именно для того, чтобы обеспечить архитектуру для внесения доработок.
А в нашем случае MVP будет: модули клиента и сервера, и получение некого взаимодействия между ними.
Читайте дальше:
