Мы вписались в
конкурс, потому что нам интересно узнавать про новых разработчиков, которых мы до этого еще не нашли и не узнали. Плюс, в такой классной компании должно что-то хорошее получиться.
Mid-core? Сейчас же все говорят про гипер-казуалки, что деньги там, надо заниматься этим. Я понимаю этот интерес к гипер-казуальным играм, но надо понимать свое соотношение нас как небольшого инди-издателя и, например,
Voodoo. Мы не можем с ними тягаться. Мы можем пробовать, но изначальные условия уже не такие крутые, плюс рынок гипер-казуальных игр очень перегрет. Даже по последним отчетам можно увидеть, что заход новых игроков не так финансово успешен, как проекты, которые работают на рынке уже какое-то время. Поэтому мы решили, что в mid-core мы понимаем лучше, нам интересно и мы можем позволить себе заниматься этим.
И вы как инди-издатель, который занимается mid-core, ищет интересные механики, наверняка хорошо видите основные проблемы, ошибки, совершаемые чаще всего начинающими и не только разработчиками. Конечно. Поскольку за прошлый год уже сделали порядка 10−15 софт-лончей и до этого еще много экспериментировали и делали с различными инди-командами, у нас появилось понимание основных вещей, в которых часто допускаются ошибки, и которые, на наш взгляд, просто исправить, что эффективно повлияет на коммуникацию между разработчиком и издателем и на продукт, который презентуется и пытается пройти первые этапы, такие как софт-лонч. Собственно, на софт-лонче есть 3 важные вещи, которые мы видим.
Первая ошибка, которую допускают многие —
отсутствие внятного позиционирования. Многие разработчики, когда показывают концепт, продумывают его не до конца. Под концептом я имею в виду то, о чем игра, что она хочет донести, какие эмоции вызывает, чем она может быть нова и интересна. Это нужно как раз для эффективной работы вместе с разработчиком, потому что нужно какое-то единое видение. Важный момент в том, что мы не придираемся или не хотим заниматься маркетингом игры на 360, а в том, что сформированное видение помогает сократить время на переговоры, на принятие решений, а также на наши комментарии как издательства. Если эти комментарии будут, то получится их сделать более прицельными, детальными и полезными.
На самом деле этот концепт — буквально одна страничка с описанием того, какую игру вы делаете, что это за игра, на какие платформы она рассчитана. Какая у нее цель: о чем-то показать, рассказать, заставить ощутить эмоции, чем она отличается от похожих в жанре, кто в нее будет играть с вашей точки зрения и какие проблемы видит разработчик, с чем может помочь издатель, чего хотелось бы достичь по масштабам, по эмоциям, по какому-то воздействию на людей. Такое внятное, продуманное позиционирование очень помогает в работе.
Второй момент, на который хотелось бы обратить внимание — чрезмерное увлечение механиками. Мы реально получаем очень много проектов от разработчиков, которые берут классные механики, но усложняют их настолько, что игра теряет ценность, становится очень сложной. Получается некий «Франкенштейн».
Нам приходится многих из них тормозить, когда мы начинаем разговаривать про проект. Почему так происходит? Разработчики много играют в свою игру и мало показывают её людям. Возможно, показывают друзьям, родственникам, а это не всегда целевая аудитория. Потому что те же друзья у них могут оказаться хардкоными игроками. Им кажется, что игра примитивна, поэтому ее стараются разнообразить, но по факту оказывается, что все эти усложнения лишние.
Мы исповедуем подход, что лучше потратить денег на софт-лонч и понять сильные слабые стороны, подумать над стратегией продвижения заранее, чем сразу лончить и разбираться по ходу. Потратив больше на софт-лонч и подготовку, мы лучше поймем как работать и игрой. И лонч будет более успешен. Соответственно, и механики: мы считаем, что лучше добавлять, чем отрезать. Игра в зачатке должна быть простой. Если игрокам она понравится в таком виде, можно расширять мету, геймплей, добавлять функции. И, наверное, тут вопрос встает — сколько механик будет «слишком много»? В момент начала работы над игрой у команды, как правило, есть некое базовое представление о том, что он хочет сделать, именно в момент придумывания идеи. И вот эта идея и является достаточным количеством механик. Никто не придумывает мало механик изначально. Есть механики неинтересные и скучные, а есть интересные.
Все это надо тестить. Но мы видим, что после реализации базового функционала разработчикам кажется, что это все интересно, но недостаточно. И тут есть ключевая проблема, потому что-либо базовые механики сами по себе неинтересны и это тоже нормально, когда в голове представляется что-то невероятное, а в реализации такого не выходит. Большим количеством механик эту ситуацию не исправить.