9 вещей, которые я уже понял о разработке первой игры

Че-кого бродяги?

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

Плохие новости: кабаныч всё ещё здесь мазафаки!

Более того, за это время я начал собирать концепт своей первой небольшой 2D-игры - вертикального аркадного платформера с ручным левел-дизайном, физикой и упором на мастерство игрока. И в чём-то даже начал разбираться. Чуть позже как придёт время расскажу подробнее о самой игре.

А пока вот 9 вещей, (5й пункт мать его очень важный) которые я уже понял о разработке первой игры:

1. Идея игры и сама игра - вообще не одно и то же

Можно придумать сеттинг, персонажа, сюжет и сто прикольных механик. Но пока нет ответа на вопрос «что игрок делает снова и снова и почему ему хочется это продолжать?» - игры по сути ещё нет.

Поэтому сейчас в первую очередь смотрю на core loop:

действие → результат → новое решение → снова действие.

И если этот цикл сам по себе скучный, никакой арт, сюжет и тонна контента его уже не спасут.

2. У игры должно быть ядро

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

У проекта должно быть понятное ядро вокруг которого собираются остальные системы.

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

3. Контент должен зачем-то существовать

Недостаточно просто постоянно подкидывать игроку новые механики, противников, препятствия, локации и прочее.

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

Показали правило → дали попробовать → проверили → смешали с уже знакомым → добавили давление, ВСЕ!

4. Игрок должен понимать почему он обосрался

Если игрок проиграл потому что игра не дала ему возможности заранее понять опасность или правило - это не сложность, это очко.

Нормальный фейл выглядит примерно так:

увидел ситуацию → понял правило → принял решение → плохо исполнил или сознательно рискнул → рипнул.

И в идеале после смерти думаешь не:

«Что за шляпа?» а: «Епта, понял. Ещё раз».

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

5. Сначала прототип, потом уже большие планы

Технически реализовать можно очень многое.

Главный вопрос прототипа другой: интересно ли в это играть?

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

6. Scope - моё новое любимое непонятное слово

Каждая «маленькая прикольная фича» внезапно требует кода арта, анимации, звука тестирования, а потом ещё каким-нибудь образом ломает соседнюю систему (говорю это как вплотную вникаю сам и веду диалог с разработчиком).

Так что часто главная тема это «Что отсюда можно выкинуть?» Особенно для первой игры.

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

7. Хорошая механика должна создавать решения

Хорошая механика должна давать игроку выбор. Если какое-то действие всегда выгодно - игрок быстро перестаёт о нём думать и просто делает его автоматически. Интерес начинается когда у каждого решения есть плюсы и минусы: рискнуть или сыграть безопасно, потратить ресурс сейчас или сохранить на потом. Тогда игрок не просто нажимает кнопки, а постоянно решает как ему поступить.

8. Механики должны разговаривать друг с другом

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

9. Теперь я лучше понимаю зачем мне самому во всё это лезть

Я всё ещё не собираюсь становиться разработчиком и вникать на все бабки в C#. Но основы изучаю, потому что продюсер без технического понимания быстро превращается в человека: «Браза, тут делов на пять минут». А там три дня. Поэтому хочу хотя бы понимать что прошу сделать, насколько это сложно и зачем это вообще нужно игре.

Короче пока моя картина разработки эволюционировала примерно сюда:

Небольшой масштаб → основная механика → core loop → быстрый прототип → тесты → убираем лишнее → повторяем → рабочая часть игры.

Вместо:

Четкая идея → добавим ещё вот это → и это → и это тоже прикольно → два года разработки → почему никто не играет?

Сейчас докручиваю концепт и готовлюсь переходить к первому прототипу.

Так что не переживайте.

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

P.S.

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