Как напряжение углубляет геймплей

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

https://www.youtube.com/watch?v=VUhPd2a8Vkw&list=PLEt38_gfsmsJgjBy7v7Z7sxIYWAVPfh-X&index=26

Об игровых гипотизах

У вас бывало такое, что вы делаете какой-то долгосрочный проект, не важно какой: фильм, книга, игра, то идеи то и дело меняются? То есть вы видите одно видение сегодня утром, и оно кажется вам офигенско крутым и такого вы нигде ранее не встречали. А затем к вечеру видите, что Вася Пупкин пошел по какому-то стандартному пути и у него всё выглядит ок.

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

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

Его слова об этой механике: "ну пипец она странная. Какая-то бредовая."
Я сразу запаниковал и подумал. Блин ну давайте сделаем как в других играх, на что получил такой ответ от этого же разработчика: "Погоди, погоди... да механика выглядит странной, но давай проверим её. Реализуем, если будет плохо работать что-нибудь подкрутим и если ничего не получится, то вернёмся к стандарту"

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

#Опрос #Мысли #Геймдизайн

Любите движок анриал? Любите митапы? Значит вам вдвойне зайдёт эта ссылка. Я стараюсь подобные мероприятия не посещать) да тут ещё и в онлайн формате)

https://wargaming.wnhub.io/ru#program

Мы открыли наш блог на DTF

После фестиваля keep calm, do games у нас осталась тонна материала на DTF. Одна из целей фестиваля была возможность вытащить людей на свет и рассказывать о своих проектах. Так и получилось. Нас "вытащили на свет". Теперь на DTF, будем вести дневник разработки. Вот кстати первая статья в подсайте "Инди".

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

Небольшой вывод из недавнего фестиваля

После участия в месячном фестивале, где мы вели дневник, я получил билет на DevGamm. Мероприятие конечно не плохое, но на оффлайновом наверняка было бы лучше. Так вот вывод не в этом. Очень полезно вести дневник разработчика, так как сразу можно получить фидбэк от возможной аудитории. Пуской он местами бывает и злой) хотя в целом адекватных людей больше чем нет. Согласитесь.

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

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

Само собой после написания первой статьи не стоит ожидать что прямо толпами люди ворвутся к вам в комментарии. Люди набираются только при долгом и постоянном ведении дневника. Дальше... больше.

У меня есть хороший друг из Эстонии, который больше читает "международные издания", типа Reddit и Medium. Если проект планирует выходить на международный рынок, а само собой никто сейчас не делает чисто русскую игру для русских :) то следует подумать о том, чтобы размещаться там. Само собой на иностранном языке.

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

Две ключевых механики без которых слэшер не слэшер или сравнение двух последних частей Darksiders

Я, честно очень люблю слэшеры и к серии игр про всадников апокалипсиса у меня особо тёплое отношение. После прохождения Darksiders 3 (Gunfire games), я принялся за предысторию в виде Darksiders: Genesis (Airship syndicate). Обе эти игры в рамках одной вселенной, но имеют некоторые различия. Например, камеры. В первом случае мы играем от третьего лица с камерой за спиной. Во втором камера в изометрической проекции сверху.

Казалось бы... небольшое изменение, которое на геймплей в целом влиять не должно. Однако это не так. Камера и поведение противников изменили буквально всё, и оставили игру при этом в почти в том же жанре. Как я понял перед нами Beat them up, Hack'n'Slash и Slasher. Хотя читая вики, я уже запутался где что есть)))

Влияние расположения камеры на противников

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

В Darksiders: Genesis
Видно всех противников и это правило не действует и противники не сильно замедляются. Я лишь замечал, что количество одновременно нападающих вблизи было не больше 4х существ, в то время когда в предыдущей игре, одновременно на меня нападало максимум 2. Это создаёт более активную динамику, потому как вам необходимо фокусировать внимание над большим числом врагов.

Разные противники, разный фокус на управлении персонажем...

В Darksiders 3
Я применяю две ключевых механики - это все атаки и рывок. Примерное соотношение нажатия на кнопки у меня было при игре было на 5 нажатий удара приходилось 1 рывок для уклонения. То есть уклоняться мне приходилось в 16% случаев нажатия клавиш, вне зависимости от количества противников - этот показатель оставался прежним.

В Darksiders: Genesis
Провёл тот же эксперимент. И здесь у меня всё варьировалось. Когда противников рядом было не много 1-2, то динамика похожая на Darksiders 3. Однако, когда речь заходила о толпе мобов, происходил скос при котором каждое третье нажатие нажатие было рывком (30%).

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

Какой я сделал из этого вывод?

В зависимости от того какие ощущения, вы хотите передать игроку при разработке слешера, можно отталкиваться от камеры в игре.
- Хотите сделать "переходящую динамику игры", и добавить ощущения божества, можно сделать изометрическую камеру с большим числом слабых противников.
- Если хочется сделать уничтожение каждого противника для игрока более ценными, то камера от третьего лица, поменьше противников посильнее характеристики.

С одной стороны, ничего нового,, с другой Darksiders: Genesis стал для меня открытием. Очень советую для тех кому есть с кем погонять. Там можно вдвоём.

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

"Джемы, джемы, джемы, нужно больше джемов!" (с) Евгений Пузанков

Да, Индикатор Онлайн вновь организует Геймджем!
12-14 июня, онлайн, общение в Дискорде, игры и судейство на itch.

В это раз мы вводим ограничение уже на этапе анонса – джем будет посвящен ГиперКазуальным играм. В этом джеме мы хотим посмотреть на ГК игры с двух сторон.

❗️ Первая – ГК это яркая иллюстрация "Easy to Learn, Hard to Master" – в разработке такой игры чаще всего нет серьёзного вызова с технической точки зрения, но есть супер вызов с точки зрения творческой.

❗️ Вторая – ГК игры это своеобразный способ медитации 21 века. Расслабь меня, говорит ГК-игрок, погрузи меня в состояние потока, дай мне вызов, ровно такой, чтобы я чувствовал сопротивление, но всегда побеждал.

Гиперказуальный жанр – это сложная задача для авторов игр. Необходимо за первые 5 секунд объяснить всё управление, в процессе погрузить игрока в состояние потока, чтобы он продолжал играть и после просмотра рекламы, оптимизировать управление под один палец и т.д.

Мы видим в этом джеме интересный вызов как для опытных, так и для начинающих разработчиков.

Джем пройдет с 12 по 14 июня, на нашей площадке в Дискорде. Регистрация открыта уже сейчас. Подробности о том, как зарегистрироваться, как пройдет джем, какие крутые штуки мы для вас приготовили на этапе подготовки, как найти команду и другие важные вопросы – в дискорде по ссылке - https://discord.gg/HJnSqTH

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

И в связи с этим у меня вопрос к вам:

Как сделать бота для карточной игры?

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

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

Итак, какую логику я описал? Сторону каждого игрока выразил в виде числа его силы, которая складывается из суммы чисел всех показателей существ на его стороне. Например, за каждую единицу атаки и здоровья существа даю 10 очков на сторону игрока, а за каждую инициативу 1 единицу. Так Скелет с характеристикам 2/2/15 имеет вес в виде 55 единиц. 20+20+15.

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

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

Часть моих открытий, при ведении разработки инди-проекта

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

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

3. Давать тестовое задание для некоммерческого проекта - это ок. У нас были случаи, когда человек без тестового задания заходил в команду, ничего не делал и пропадал. Выходило фигово( Тратили на него время, ждали ответа, а он пропадал. В итоге теперь отсекаем людей, не сильно заинтересованных давая им тестовое. Ежели у человека нет желания попасть в проект, он сразу отвалится. Небольшая статистика, по проекту.
- Разработчики. Прошли тестовое и остались: 3. Прошли тестовое и отвалились (но закрыли часть задач): 3. Попросились в проект без желания сделать тестовое: 9
- Художники. Прошли тестовое и остались: 3. Прошли тестовое и отвалились (но закрыли часть задач): 3. Попросились в проект без желания сделать тестовое: 4
- Геймдизайнеры (самоё тяжелое для меня). Прошли тестовое и остались: 0. Прошли тестовое и отвалились: 0. Попросились в проект без желания сделать тестовое: ~21

Небольшое обновление по проекту

Друзья, я тут небольшую статейку написал :) Там пара новых артов для игральных карт и чутка ЛОРа игры. Буду рад комментариям и фидбеку с советами.

https://dtf.ru/indie/139364-magic-word-sword-24-chut-chut-lora-i-novye-arty-dlya-igralnyh-kart?comments

Проектирую логику развития замка в игре

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

Чтобы не тратить много времени на детальный анализ этих компьютерных игр, сделал кое что проще. Для построения своей модели управления замком обратил внимание на настольную версию Цивилизации 2010 года издания.

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

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

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

Сейчас разложил всё в Miro. Можно посмотреть на краткий результат моего анализа.

А дальше дело простое.
1. Искать закономерности
2. Осмыслять почему геймдизайнер так задумал
3. Подходит ли найденные решения
4. Подойдут ли потенциальному игроку найденные мною решения

Происходит это примерно так:

https://www.youtube.com/watch?v=xZpspMh3TFE

Если лень заходить в Миро, то примерно такая там схемка

Художники и программисты

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

Такой такт работы немного взрывает мозг. Поясню почему.

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

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

Иногда забываю об этой разнице и пишу художественную тарабарщину в ТЗ для разработки. Видимо поэтому разновидностей геймдизайнеров так много. Нарративный ближе к художникам, Балансер и технический геймдизайнер ближе к разработчикам. Разработчикам - техническое описание, художникам - художественное. Всё просто и одновременно нет...

Я прямо залип

Классное видео от DTF, о том как игровые механики управляют игроками на примерах известных игр

https://www.youtube.com/watch?v=SEaoISAEmxM

При разработке нужно работать на опережение

Вчера я писал диз-док на фичу наёма существ в замке. Перелопатил несколько игр, где был реализован более менее приятный интерфейс, но ничего более удачного кроме героев 5х увы найти не сумел. Интерфейс там одновременно приятен и не выглядит минималистичным. Есть аналогичные решения в той же цивилизации и героях другой серии, age of wonders. Но там интерфейс несёт скорее функциональную ценность и никак не помогает погрузится в атмосферу.

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

К чему я это? Для себя я обнаружил 2 способа ведения проекта:
Первый: написать ТЗ и постоянно ждать пинка от программиста и потихоньку допиливать проект до конечной задумки, которая происходит буквально на ходу. - расходуем мало личного времени, но это чревато ошибками и недодумками. Потом может исправите, может нет.

Второй: писать ТЗ не ожидая никого постепенно шаг за шагом. - расходуем больше времени и каждый день и есть риск, что к моменту как разработчики доберутся до вашей фичи, идея будет уже другой. Такое случается когда механика "долго залёживается" и вам приходит в голову что-то получше. Но есть шанс, что вы определитесь к этому моменту как будет лучше.

Механики, они знаете ли как вино или коньяк. Должно пройти выдержку временем, перед тем как вы "нальёте их в бокал своего проекта". Жаль, что данные мысли сложно масштабировать, когда на проекте вы и геймдизайнер и разработчик и программист. У меня кстати интересный вопрос к таким людям.