Малый старт, большой финиш. Почему лучше начинать с малых проектов?
В силу работы с начинающими дизайнерами, я часто вижу мечтателей, которые хотят делать большие и популярные миры, в которые будут играть миллионы. Мечтать – это хорошо, но начинать разрабатывать “ММОРПГ песочницу с открытым миром и пвп” лучше все-таки хотя бы с базовым набором знаний и опытом. Надо понимать, время — это самый главный ресурс в нашей жизни, и его надо использовать с умом. Для новичков нет ничего лучше, чем стартовать с маленьких игровых проектов, которые не требуют много времени для разработки. И в этой статье я хочу подробно рассказать почему это лучшая стратегия для начинающих.
Начнём с проблем больших игр. Во-первых, надо понимать, что чем больше игра — тем больше механик и других элементов она содержит. И сделать так, чтобы это всё вместе работало не только с технической точки зрения, но и дизайнерской, очень сложная задача, даже для опытных команд. Хочу отметить, что ключевое слово «команд».
В крупных компаниях над игрой работает далеко не один дизайнер, а целая команда, где каждый отвечает за определённый аспект игры. Конечно, бывают некоторые исключения, когда относительно крупная игра делается малыми силами, но за спиной у таких проектов мало кто любит замечать бесконечное поле усеянное трупами провалившихся или не вышедших игр.
«Провалились, значит делали неверно! Я точно смогу, я не как они!». Я часто слышу такие высказывания у новичков, на самом деле все в индустрии были такими, в том числе и я сам. Горячая кровь и страстное желание «создавать миры» притупляет ощущение реальности. По итогу, большинство новичков гейм-дизайнеров, да и разработчиков в целом, обладают одним набором проблем. Во-первых, это слабое понимание базовых процессов разработки игр. Через какие этапы проходит разработка не только игры в целом, а каждых отдельных её аспектов (механики, арт, звук и т.д.).
Во-вторых, отсутствие опыта планирования. Бесспорно, в крупных студиях есть отдельные менеджеры проектов, которые занимаются планированием, но происходит это вместе с командой разработки. Так что опыт планирования разработки будет очень полезен.
В-третьих, неумение и нежелание фичеката. Одно из самых важных и сложных умений любого дизайнера игр — фичекат. Очень сложно на старте отказываться от каких-то идей и механик, как правило, всё происходит наоборот, игру накачивают игровыми системами т.к. они: классные, были в популярных играх и т.д. Но правда жизни такова, что если хочется завершить разработку в нормальные сроки и получить качественный продукт, придётся что-то отрезать, а вот понимать что отрезать и как, чтобы не испортить игру надо учиться.
В-четвёртых, общая нехватка практических знаний. Какие бы крутые теоретические знания у вас не были, практика меняет всё, т.к. чистая теория стерильная и не отражает реальных условий разработки, когда может произойти что угодно и как угодно. Даже самая минимальная практики может очень сильно изменить качество игры в лучшую сторону.
И эти проблемы можно исправить на маленьких проектах. Как? Почему? Начну с того, что не зависимо от размера проекта, база остаётся единой. Все принципы разработки малых проектов применяются на крупных, очевидно, что с некоторыми изменениями с учётом объёма работы, но не настолько сильными, чтобы всё перевернуть с ног на голову. Но главное преимущество маленьких проектов — время.
На маленький проект вы потратите заметно меньше времени, при этом опыта вы получите заметно больше. Потому что вы сможете сделать много ошибок в меньший срок, а также исправить и учесть их в следующем маленьком проекте. Кроме того, короткие сроки разработки таких проектов помогут вам лучше увидеть прогресс ваших собственных умений, что очень важно, т.к. это мотивирует работать дальше.
Также при разработке маленькой игры, у вас будет возможность попробовать свои силы в разных аспектах работы над игрой. Это будет очень полезно в будущем при работе в команде, т.к. понимание как работают остальные люди позволит найти общий язык быстрее и избежать ненужных конфликтов. Чем меньше у вас опыта и скиллов, тем меньше шансы собрать хорошую команду, да и организация командной работы — это отдельная сложная задача, которая может помешать вам набираться опыта на старте. А маленькие проекты, не требуют наличия полноценной команды, их можно разрабатывать и в одиночку.
Но с чего лучше начать? С классики аркадных игр, особенно тех, в которые можно играть в рамках одного экрана, например Pac Man, Snake, Space Invaders, Galaga, Asteroids, Arkanoid. Такие игры обладают малым количеством механик, у них есть простой и понятный игровой цикл, а также есть пространство для некоторых изменений. Но самое главное, вы сможете поработать над всеми основными аспектами разработки игр обладая понятным примером и задачами, которые надо решить. Как альтернатива, вы можете начать с гиперказуальных игр. В целом, подойдёт любой маленький проект, который вы сможете сделать самостоятельно.
После нескольких таких простых игр вы уже будете себя чувствовать заметно уверенней при разработке, а значит, что сможете постепенно повышать сложность того, что вы делаете. Но не надо спешить сразу врываться в создание открытых миров, метроидваний и т.д. Начинайте с жанров, у которых достаточно низкий порог входа, например: платформеры, top-down шутеры. Начинайте с простых линейных игр, постепенно усложняя себе задачи.
Самое главное помнить, мало просто сделать игру или прототип, важно понять где вы допустили ошибки и как их исправить в будущем. Давайте ваши игры играть другим людям, собирайте фидбек. Анализируйте полученную информацию и учитывайте проблемы при разработке новой игры. Помните, опытом мы называем ошибки, которые мы совершили и осознали.
Кроме того, избегайте перфекционизм, зачастую силы и время затраченные на него не окупаются. Как говорится, перфекционизм — это вежливый способ показать свою боязнь провала. Конечно, я не говорю, что надо делать низкокачественный продукт, отнюдь. Просто стремитесь не к 100% результату, а к 80% и уже по мере необходимости итерационно улучшайте уже полученный результат. Лучше сделать игру, где будет простой low-poly арт, но которая круто играется, чем набросать много высококачественного арта из ассет сторов, но без геймплея.
Как найти мотивацию для разработки такой маленькой игры? Первое место, куда стоит пойти — это игровые джемы. Для тех, кто не знает, что это такое. Игровые джемы (game jam) — это события, в рамках которого люди делают игры в рамках ограниченного времени и по заданной теме. Своеобразный хакатон. Одни из самых крупных: Ludum Dare и GMTK Jam.
Почему это лучшее место для начала? Во-первых, никто не требует опыта и наличия команды. Во-вторых, в них участвует много людей, которые готовы давать фидбек на вашу игру (главное быть самим активным). В-третьих, вы ограничены по времени и есть тема, которые помогут вам довести игру до конца. Единственное, что советую, участвовать на старте в классических джемах, которые длятся 2-3 дня суммарно. Более долгие джемы могут утомить новичка. Так что, идя на джем, отбрасывайте сомнения и страхи и делайте свою игру, это фестиваль, где есть очень разные люди с разным уровнем умений и опытом.
А что если хочется делать игры не только на джемах? Делайте, но будьте строги к самому себе. Тщательно продумывайте и планируйте что вы хотите сделать. Выставляйте строгие дедлайны для самого себя. А самое главное, не раздувайте вашу текущую игру до огромных размеров. Например, поставьте условие, что игру вы должны сделать за 1 месяц и без каких-либо оправданий и сдвигов сроков.
Если резюмировать всё вышесказанное. Для новичка, 5 маленьких проектов за 1 год могут дать больше опыта, чем 1 большой за несколько лет. Теория теорией, но практика может сильно улучшить восприятие и понимание процессов разработки игр. Чем быстрее вы набьёте шишки на самых стандартных проблемах — тем лучше для вас, а на маленьких играх сделать это заметно проще. А самое главное, новичок с портфолио, где есть маленькие, но хорошо сделанные игры смотрится куда лучше на фоне тех, у кого нет такого.
Мы принципиально не размещаем рекламу на наших страницах, чтобы она не мозолила вам глаза, и существуем только за счет поддержки читателей и членов сообщества. Если вам нравится то, что мы делаем, и вы считаете это важным, поддержите нас так, как вам удобно:
Вам также может понравиться
Дизайн-документация. Часть II: ГДД не нужны?
Шоукейс на конференциях
