Дневник разработки «Arithmagicka»: как оно началось и продолжается
Доброго времени суток!
В ближайшее время постараюсь публиковать результаты работ над своей долгоиграющей "Арифмагикой", которую начинал уже десятки раз, и снова что-то приходит в голову, чтобы сделать её немного иной и получше. Пост получился немного дневником разработки, немного познавательным в плане систем и механик старых игр.
Суть игры заключается в том, что мы играем за мага, который метает заклинания во врага с помощью решения примеров. Таким элементом я хочу дать игрокам возможность почувствовать себя сильнее (или слабее, но только в начале), не только ограничиваясь игровой условностью и навыками, полезными только внутри игры, но и позволить ощутить прогресс на самом себе, упражняясь время от времени в арифметике. Последнее умозаключение сформулировалось и пришло ко мне, конечно, гораздо позже, потому что в начале всё было примитивнее, наподобие:
Хы, решать примерчики и убивать врагов — это прикольно
Идея пришла где-то в универские года около 2014-16 годов, когда я приболевший засел дома за комп и баловался в GameMaker: Studio 1.4, где создал врагов-циферок, которые уничтожаются при нажатии соответствующей клавиши, а также сделал сундук, который надо взламывать суммированием всех чисел, и выглядело это вот так. Мой 2014 мне можете не возвращать.
Эта версия выглядела следующим образом:
Эта версия пришла в соответствующий вид за 2 недели до сдачи, когда я в очередной раз додумался, что лучше сделать dungeon crawler (бродилка по подземелью) и сражение с одним врагом одновременно, нежели толпа со случайными примерами над их головами. Мы решаем из книги один пример, который наносит урон, относительно нашего уровня, а потом заменяется на иной.
В эту версию можно поиграть здесь на сайте itch.io (осторожно, громкие звуки), почти полностью переведена (слово «таймер» забыл перевести, лол) на английский (а вдруг кто англоговорящий заглянет (я грешу скобками, простите, люблю всё конкретизировать)).
Где-то в тот момент я понял, что лучше примеры привязывать не к врагам, а к самому игроку. Также я допёр и до увеличения диапазона чисел у примеров с прогрессом игрока, самое очевидное — увеличение уровня игрока и его характеристик (здоровье, урон, и чуть позже добавленное увеличение таймера перед каждым ударом).
От самого примера зависело, сколько опыта получит игрок. В критериях были оператор примера (× и ÷ давали больше опыта), разнообразие чисел и наименьшее количество нулей (за 100+500 опыта много не получишь). С каждым уровнем необходимый объём опыта для поднятия следующего уровня увеличивался и достаточно оперативно устремлялся в бесконечность. Соответственно, и единственным концом игры было поражение и финальный экран со статистикой игрока: сколько примеров решил, какие операторы и сколько раз ошибся.
Между показанными версиями, первой и курсовой, было множество промежуточных. Все можно описать одинаково: игрок находится на арене с врагами, враги преследуют игрока, игрок решает примеры над головами врагов и попутно убегает. То есть таким был первый вариант курсовой. Шаблон, от которого я ушёл к более оптимальному варианту. Также в некоторых версиях надо сначала ввести число, чтобы выбрать врага, а потом уже можно было порешать врага (ба-дум-тсс). В версии с 4-мя примерами это решено гораздо лучше: нет необходимости выбирать врага, а также немаловажный момент — примеры генерируются с уникальными ответами. Чтобы выбрать, что решать, не нужно кликать на кого-либо, брать какой-нибудь идентификационный номер или чего ещё. Я знаю, что это очевидно, но с тех дремучих и неопытных лет даже самые очевидные решения кажутся открытием. Ну а с текущего времени старый код выглядит тем ещё неприятным зрелищем :D
Это код сундука. Я представления не имею, что же я хотел делать, но программированию я ещё тогда не учился.
После окончания учёбы начались более интересные варианты: dungeon-crawler'ы от первого лица с вот такими анимашками (я буду по вам скучать, мои ручки)…
Ротоскопия рулит! Сделано в Godot
Была пауза и я внезапно вернулся в GameMaker Studio 2.3, чтобы сделать то же, но лучше
И другим интересным вариантом является мой текущий. Увы, это уже не будет ещё более мощным вариантом и вообще это 3д на Юнити!
Всё же простота должна стоять во главе, особенно если хочется сделать это своим первым коммерческим проектом. Тем более если такие анимации занимают так много времени и знакомых не попросишь (в стиле «Хэй, сначала на энтузиазме, а потом процент от доходов!»), то всё остальное графическое наполнение должно быть выдержано в том же стиле. А для одиночного программиста, который только в пиксель-арт и обводку умеет, это будет достаточно времязатратно.
Сейчас же я занимаюсь проектом в Godot (читается Годо́). GameMaker хорош, однако после обучения на прогера некоторые эстетические и языковые придирки перетянули меня в сторону Годо (они оба классные в чём-то своём, прогайте на чём хотите).
Однако отвлёкся, чем же интереснее новый вариант №999 с лишним?
* * *
НОМЕР РАЗ. Избавление от физического пространства карты. Этот вариант скорее проще, чем интереснее. Связано это с тем, что сначала я посматривал на первые части Final Fantasy, где в режиме перемещения по карте персонаж игрока скорее походит на фишку на поле, ибо локации, на которые они заходят, размером с людей, но это уже чистая условность.
Или же Fallout 1 или 2, где персонаж — это просто условная точка на карте (стрелочка вниз, если быть точным). А локации это окружность на карте, мол, вот в этой округе находятся токсичные пещеры.
Скриншот Fallout 2
В каждой из этих игр есть условное перемещение по карте, случайные события/сражения, более подробные перемещения по самим локациям (вот это, увы, не про нас, будем попроще), а также пошаговые бои (но к ним позже).
Сначала я пытался повторить метод FF с перемещением по карте, нужно сделать объект, в котором игрок при перемещении накапливает шкалу сражения. У каждой такой зоны есть свой темп накопления. К примеру, биом леса будет более мирный, а некий проклятый лес кишит тварями, поэтому у последнего темп будет выше. Подсмотреть конкретнее эту систему «случайной встречи» можно тут.
В самой первой части дело обстоит так:
После каждой битвы игра генерирует случайное число от 50 до 255. После каждого шага значение убывает. Когда значение становится 0, начинается случайная битва.
И следующие условности:
- На мировой карте каждый шаг сокращает значение на 6;
- Внутри подземелья шаг сокращает значение на 5;
- На мировой карте, когда плывёшь на корабле, каждый «шаг» сокращает значение на 2;
- На напольных ловушках (лава, провалы, ловушки), во время вождения воздушного корабля, в морском порту или в городе, значение не сокращается (никакой битвы не случается). (Вот этот пункт я кривовато перевёл, но суть поняли)
То есть таким образом ребята из Square Enix такой простой системой могут рассказывать игроку, как персонажи перемещаются при достаточно малой детализации в отображении.
После некоторых недель кумекания, как сделать проще, но интереснее, я пришёл к новому варианту:
- Карта представляет собой сеть локаций с фиксированными расстояниями меж друг другом;
- У каждой локации есть свой биом или список биомов, за ними закреплена библиотека врагов, которые могут встретиться игроку;
- В каждой локации указано, какие у неё соседи и какое до них расстояние (чтобы не мучать метры/мили представим, что это количество часов в пути);
- Игрок может идти в сторону необходимой локации (по часу за одно перемещение) или же скитаться по локации, чтобы «порешать» местных врагов (так сказать, пофармить).
Чем оно лучше? Это ситуативно, но для игры про сражения с помощью примеров нужно сделать более частые встречи с врагами, чтобы игрок мог прокачиваться (о новой системе прокачки будет дальше), встречать новых врагов и больше себя занимать более интересным аспектом игры.
Пока что вероятность битвы при каждом перемещении я выставил в 1/3. То есть в одном из трёх перемещений вы попадёте в битву (но это не факт (это теоретически)). Я не стал привязывать вероятность попадания в битвы с местностью, чтобы не было затруднений с постижением местной фауны, однако иной элемент от местности всё же зависит (об этом упомяну позже).
Так же то, что я считал своим спагетти-кодом (плохо написанным кодом), оказалось достаточно неплохим инструментом для описывания ландшафта локаций. Моя проблема была в том, что я в локациях-соседях дважды описывал одну и ту же дистанцию друг до друга, но потом осознал: можно ведь обусловить дистанцию временем в пути, и тогда можно представить, что в горную локацию ты можешь идти 10 часов, а спуститься обратно за 2 часа, или же можно обратно не указывать путь, то есть ты можешь заплутать, забредя в лес, и искать в этой опасной местности другой путь, это оказалось неплохим инструментом для создания карты и некоторого повествования путешествия! Главное надеяться на то, что у людей будет столько же фантазии, чтобы это оправдывать...
* * *
НОМЕР ДВА. Система сражений!
Как бы так не получилось, что я делаю руководство по созданию моей игры ._.
Здесь я больше склонялся к системе Active Time Battle (сражения в настоящем времени), созданной Хироюки Ито, опять же сделанной для Final Fantasy, подробнее об этом здесь.
Вкратце, у каждого персонажа в сражении накапливается шкала атаки (шкалы — это круто), после накопления которой данный персонаж может атаковать/выпить зелье/сделать ещё чего-нибудь, но только одно. Так решалась очерёдность атак между врагами и персонажами игрока.
Данная система частично реализована в моей курсовой версии, у врага просто было определённое время до его редкой, но сильно больнючей атаки. Пока время идёт, игрок может постараться затыкать врага до смерти, оглушить его, поставить на себя щит или ослабить врага, чтобы уменьшить урон. Урон врага, как и его здоровье, зависело от уровня игрока: на высоких уровнях они сносят здоровье очень сильно, но у тебя есть больше времени, а также случайный эффект примера «лечение» (восстановление 25% от максимума здоровья), которым я пытался это всё сбалансировать, ибо он появлялся чуть-чуть чаще других.
В данный момент я занимаюсь реализацией сражений (поэтому тут может меняться), и план состоит в следующем:
Враг по таймеру атакует игрока, игрок старается успеть нарешать как можно больше примеров (1 из 4 операторов (+,-,×,÷)) перед атакой врага. Так просто, НО...
У каждого врага есть собственное время перед атакой. Если игрок ничего не успел решить, ему позволено решить 1 пример, но первым атакует враг, а потом игрок (если выживет, ха :D).
В ином случае игрок набирает заряд из примеров, урон каждого успешно решённого примера копится и при окончании таймера урон наносится врагу, а потом атакует враг (если этот смелый выживет, мвахах).
Только здесь я решил сделать арифмагику больше похожей на магику, одну из моих любимых игр (воть → Magicka (я люблю игры про магов)).
В первой магике есть 8 исходных элементов (стихий) и парочка образующихся из исходных (Пар = Вода + Огонь; Лёд = Вода + Холод). Игрок может сделать заклинание из 5 элементов. Игрок выбирает элементы, а затем творит эту комбинацию, куда попало. Также некоторые элементы имеют противоположности, из-за которых несовместимые элементы убираются из этого набора.
То есть все эти элементы взаимодействуют друг с другом «внутри посоха» и во внешней среде (об этом можете узнать сами). Это достаточно трудно, поэтому я снова пошёл по пути упрощения, я представил 4 оператора в качестве первичных стихий. Сначала хотел сделать такие же заклинания, создаваемые при определённом наборе (наподобие «огонь+земля+земля+огонь»), которое бы делало некое особое заклинание, отличающееся от обычного удара, однако надо действовать ещё проще.
Сколько может быть уникальных комбинаций операторов? Можно просто успеть до атаки врага засыпать его одним оператором (это 4 варианта), можно парой (6 уникальных пар), можно тройкой (это снова 4) и можно успеть решить по одному, как минимум, каждого оператора (единичичка). Итого 15. Именно столько вариантов заклинаний для атаки врага (круче инвокера из доты, хы).
Карта стихий
Правда суть в том, а будет ли это эффективно? Можно ведь сразу заспамить умножением, это ведь самое лёгкое, ведь сложение и вычитание мы учимся считать в уме, деление мы прикидываем примерно, а в умножении запоминаем комбинации (эта таблица умножения, фу). Этот довольно читерский способ я долго пытался решить, ведь именно так отвечали мне некоторые мои знакомые на показ им арифмагики. Достаточно простая система сопротивляемости врагов. Каждый враг имеет свои уязвимости, сопротивляемости и иммунитеты к стихиям, ведь толку от твоего спама огнём, если враг — это элементаль огня или… пожарный?
Тут достаточно просто, поэтому переходим дальше.
* * *
НОМЕР ТРИ. Характеристики и прокачка игрока!
Вместо того, чтобы брать пресловутую систему уровней и увеличивать таким образом сложность примеров и силу игрока, я решил привязаться к операторам сильнее. Чем чаще вы решаете определённый оператор, тем сильнее становится он и чуточку слабее становятся остальные. Генерация же примеров теперь не увеличивает потолок примеров, давая шанс вам встретить как сложный, так и простенький пример. Она смещает весь диапазон вверх по значению.
От прокаченной силы ваших операторов характеристики игрока в бою также улучшаются:
- Земля(+) увеличивает здоровье;
- Вода(-) увеличивает весь урон;
- Огонь(×) увеличивает критический шанс (увеличенный урон заклинания);
- Воздух(÷) увеличивает шанс уворота при атаке врага.
Таким образом, игрок сам улучшает то, что ему нужно в данный момент сильнее.
Это помогает построить разные локации и пойти немного по пути Zelda: The Breath of The Wild. В данной игре вы оказываетесь в открытом мире, где можете сразу же пойти на финального босса, однако у вас всего 3 сердечка, меч, ломающийся от парочки ударов, и куча простора, квестов и дел, которыми вы можете заняться, чтобы подготовить себя к финальному сражению. Здесь нет врагов, подстраивающихся под вас, здесь есть возможности, которые вам помогут стать сильнее и выйти на равных с более сильными. Подстраиваются под слабых, мы же сами тянемся к сильным! Возможно, сказано слишком пафосно, но в этом суть.
И эта суть предполагает, что могут быть локации, где есть больно бьющие враги, поэтому вам стоит прокачать здоровье себе или шанс уворота. Или же есть непробиваемые ко всему враги, которые уязвимы к молнии, поэтому вы прокачиваете умножение и деление. Эта двоякая система, помогающая наносить больший урон или лучше выдерживать приходящий урон, делает решение примеров более интересным.
Однако оно ж в бесконечность будет усиливаться, как бы это исправить? Так придумалась эссенция первичных стихий: вы можете сами понижать сложность оператора, выделяя определённое количество эссенции, которое усиливает некоторое количество следующих примеров этого оператора. Это позволит подготовиться к битве в более сложной области с врагом, усилив оператор и, соответственно, стихию, к которой он уязвим.
Есть ещё пара любопытных систем, лечения и сохранения, зависящих от перемещения по карте, которые хочу я описать в следующем посте вместе с результатом того, какой же получилась битва и эти описанные механики.
На этом всё, спасибо за прочтение! Надеюсь, это было достаточно интересно и познавательно для вас, если есть вопросы по содержанию или как бы лучше писать посты, я с радостью прочту ваши предложения и комментарии по этому поводу, всем до скорого!
P.S. По крайней мере я освоил магию воды :D
