Последние пять лет я руковожу образовательными программами по игровой индустрии в Высшей школе бизнес-информатики НИУ ВШЭ. Мы проводим много бесплатных мероприятий с интересными спикерами, собирая аудиторию через Leader-ID. На одной из последних встреч прозвучала очередная классная история, где несколько единомышленников запустили в релиз игру, принесшую более 200 тыс. долларов.
История хороша тем, что в ней, кроме хеппи-энда, описаны и крупные промахи, благодаря которым приобретается бесценный опыт. А самое главное — ребята с радостью делятся всеми деталями и списком граблей, которые они собирали на этом длинном пути.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/7aa/194/d50/7aa194d508dbc298b2a42c2f6983b15c.jpg)
Знакомьтесь, Дмитрий Светлов. Более 10 лет он руководит собственной студией архитектурной визуализации — 3Dmode. В какой-то момент, когда дела в компании уже стабильно шли хорошо, у него появилась потребность в покорении новых вершин, и он решил вернуться к увлечению детства — созданию игр.
Следующие три года он, вместе с другом, посвятил разработке браузерного top-down шутера. Работали по большей части вечерами. Последний год друг корпел над кодом уже все свое время. Но проект в итоге так и не вышел в релиз. Затем последовала вторая попытка — VR-шутер Sacralith: the archer's tale — и она оказалась удачной.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/aac/711/02c/aac71102c0e670c35f5cfea4d90f4400.png)
Ниже — пересказ лекции Дмитрия, на которой он рассказал много интересных деталей и отметил пять главных препятствий, с которыми пришлось столкнуться команде на пути к успешному запуску.
Звучит странно, но на деле он стал главной причиной провала первого проекта. Когда Дмитрий вместе со своим другом-программистом начали делать браузерный top-down shooter, они не сомневались, что все получится.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/9b2/5d1/0f3/9b25d10f3f2bc5464d5ebfa3116f448c.png)
Но несмотря на собственный богатый опыт работы с 3D-графикой и опыт друга-программиста, довести игру до релиза ребятам так и не удалось. Вера в успех их ослепила.
Если оглянуться, то можно заметить, как много вокруг образов «уверенных в себе людей, четко представляющих конечную цель и добившихся небывалых высот». Такие характеры без устали тиражируются в медиа-пространстве, продвигая простую идею: «главное верить, и все получится». Однако в таком подходе есть существенный изъян.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/fc7/9f8/9e3/fc79f89e3de6b68bf585d1d4085f0420.png)
Схема развития компетентности
На схеме выше обозначены стадии, которые проходит каждый специалист. Очевидно, что большинство из тех, кто слепо верит в успех, находятся на первой стадии. Но реальность такова, что результата добиваются люди не столько талантливые, сколько трудолюбивые. Но и это тоже не главное.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/f5c/b55/6dc/f5cb556dcee46f53391106ecfc6c1136.png)
Чтобы сделать проект, нужно уметь делать проекты. Именно понимания, как «начать», как «сделать» и как «завершить» проект, не хватило тогда, чтобы выпустить свою первую игру.
Здоровый пессимизм — это именно то, что приходит с опытом. И речь не о вере в собственные силы, а о банальной осторожности и расчетливости. «Новичок», выходя из дома, возьмет с собой плеер, а «профессионал» захватит зонтик, таблетки от головной боли и, возможно, бронежилет.
Начиная проект, вы закладываете определенное время и ресурсы на разработку, а также представляете потенциальные доходы и расходы. Хорошо, когда ожидания и реальные цифры оказываются близки, но у большинства инди-разработчиков это получается далеко не с первого раза. Когда вокруг говорили о смерти флеша и угасании эры браузерных игр, они все равно верили в головокружительный успех.
С Sacralith было нечто похожее. Один из основных участников, даже когда ему показывали текущие метрики, слепо верил, что проект принесет миллионы долларов. И он в итоге принес миллионы, но рублей. Из-за чего тот покинул команду.
Для многих это самая интересная часть рассказа.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/9ad/25b/b82/9ad25bb8211b840479e576387a781cc8.png)
Выручка в Steam
Глядя на эти цифры, стоит помнить, что до вас дойдет только половина этой суммы. 30% уйдет Steam, 5% налог VAT, потом валютный контроль у нас и ряд других налогов.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/4ef/d87/832/4efd878328dc17d39ad52c2e6fb1e5a8.png)
Выручка в магазине Oculus
Всплески на графиках — это устроенные нами распродажи со скидками в 35-50%. А в PS Store дела и того хуже — там без продвижения вообще невозможно что-то продать. В итоге в сумме на всех площадках на текущий момент реализовали около 12 тыс. копий.
Разработка Sacralith: The Archer`s Tale стартовала в 2007 году. Параллельно Дмитрий проходил курс профессиональной переподготовки «Менеджмент игровых проектов» в ВШБИ НИУ ВШЭ, поскольку в какой-то момент понял, что начинать надо было именно с управления.
Расходы на весь проект оказались такими:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/c34/100/429/c34100429d5f60e47dfecfa064673bed.png)
Бюджет разработки
Расчет очень приблизительный. Если бы Дмитрий платил зарплату сам себе в объеме хотя бы 150 тыс. руб. в месяц, общая стоимость разработки выросла бы примерно на три с лишним миллиона.
Для оптимизации расходов были использованы самые разные приемы. Например, для записи лицевой анимации компания сделала свой шлем, который обошелся всего в 70€ (оригинал стоит 1800 €).
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/a71/27e/dc7/a7127edc7419d95fd652ef1ea86ec84f.png)
Также был собран специальный сканер лица (стоимость 80 000 рублей). Ранее сканирование одного персонажа в студии обходилось в 30 000 рублей.
![](https://habrastorage.org/r/w780q1/getpro/habr/post_images/16c/79b/dc6/16c79bdc6db076bcac91253503523c07.jpg)
Примеры лиц персонажей
На примере работы своей студии 3Dmode Дмитрий рассказал о планировании. В первые годы работы студия частенько не поспевала к срокам. Дмитрий принял решение провести внутреннее исследование и внедрил систему тайм-трекинга, в которой задачи разбивались на категории.
Изначально процесс оценки необходимого времени выглядел следующим образом:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/c55/54f/a68/c5554fa683ee32182ea233b5079471b0.png)
После анализа реальных затрат времени схема стала выглядеть так:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/ca9/080/944/ca908094434131360b67f36140015487.png)
Реальное время производства составляло уже 12 дней.
Не учитывалось время «внутренних правок», ожидания комментариев заказчика. Появился коэффициент x1,2 для страховки от непредвиденных ситуаций, например: ключевой специалист заболел, вылетел рендер, отрубился сервер…
И это все происходило с заранее известными и отработанными задачами. В разработке игр все задачи оказывались новыми. Например, во время записи анимаций движений монаха для Sacralith ребята сотрудничали со студией «Пилот» (это компания, которая создала популярных персонажей Хрюна и Степана). На первый взгляд все было натурально, но после финального рендера сцена выглядела как-то неестественно. Долго не могли понять почему. После двух недель поисков причину нашли. Оказалось, что проблем с анимацией тела нет, а все дело в неестественном взгляде героя.
Команде пришлось срочно разработать систему процедурного взгляда персонажа. В зависимости от ситуации герой мог смотреть четко в камеру, на ключевые точки интереса или просто потупить взор. Никто не думал, что на это уйдет еще месяц разработки. И таких «мелочей» на пути к релизу попадалось очень много.
Планирование — важнейший инструмент для работы со сложными проектами. Но ценность плана в условиях тотальной неизвестности и непредсказуемости стремится к нулю. Куда важнее четко видеть точку назначения, чем скрупулезно следовать заранее проложенному маршруту. Если каждый участник процесса понимает, что он делает, зачем он это делает и когда нужно закончить — разработка движется.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/a67/1d8/f52/a671d8f5263c7fca6f8127c6d9c5a31e.png)
При создании Sacralith Дмитрий заменил план на условную схему, состоящую из простых целей. Например финальной целью был релиз в феврале и 5000 продаж при цене в 20$ на старте.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/6ff/b07/fe3/6ffb07fe3e4d74a563a1503e187e9858.png)
Схема целей
Следующий принцип, который использовала студия — это принцип MVP (minimum viable product), т.е. создание минимально жизнеспособного продукта на каждом этапе разработки. При таком подходе вы создаете рабочую болванку, которую в дальнейшем улучшаете по всем основным показателям.
На картинке ниже вы можете увидеть, что уже на первом этапе должна получиться работоспособная машина, которая впоследствии «обрастает» деталями.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/1c9/f59/c47/1c9f59c4700042f52b0a4d4b2cf5dd86.png)
На примере Sacralith команда определила следующую пирамиду разработки, состоящую из фичей, преимуществ и ценностей:
После определения этих составляющих можно начинать работу над MVP. При этом важно делать фокус на ценностях проекта. Чем лучше вы продемонстрируете их на самой ранней стадии разработки, тем больше шансов на успех у вашего продукта.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/048/97f/5ca/04897f5ca17465e4cb1927090a1d5ce8.png)
Можно начать с фичей, как это показано на верхней левой пирамидке, но это плохой вариант. Нормальный вариант — когда мы делаем фичи, которые могут продемонстрировать ценность (внизу слева), а лучший вариант — когда мы думаем, как нам продемонстрировать ценность (внизу справа).
Полезное качество в бизнесе, но если мы говорим об инди-разработке, то иногда оно только мешает. Разберем это на примере создания mockup-анимаций для Sacralith. Для их записи нужно специальное оборудование и актеры, которые будут изображать нужные вам движения.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/953/545/e28/953545e282b22c4baea80a322a7abaa2.png)
Запись mockup-анимации. Один из актеров на фото — основатель студии «Пилот»
Дмитрий рассказал, что пытался добиться от актеров максимальной серьезности в движениях. И, несмотря на все старания, в жестах актеров проскакивали нотки родных для них Хрюна и Степана. Однако именно эта комичность персонажей позволила разработчикам взглянуть на проект по-новому.
В итоге в игре появился юмор, персонажи стали более харизматичными. Да, все эти решения появились спонтанно, но итоговый продукт от таких изменений только выиграл. Таким образом в условии ограниченных ресурсов важно плыть по течению, а иногда даже менять пункт назначения. Конечно, если вы верите, что это пойдет на пользу итоговому продукту.
Похожая история была с моделями персонажей. В отличие от классической схемы разработки, команда Дмитрия использовала строго противоположный подход:
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/aaa/475/501/aaa4755010838d7f858b222db836ac16.png)
Классический пайплайн (схема разработки)
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/d3f/6c8/092/d3f6c80928cd2e2db6fa964509501e16.png)
Пайплайн, отработанный на Sacralith
Т.е. разработка шла не от плана и сценария, а сценарий подгонялся под имеющиеся в наличии модели и другие ресурсы. Такой подход позволил сэкономить кучу времени и средств, благодаря чему итоговый продукт смог принести прибыль создателям.
Работа над продуктом не прекращается после релиза игры на платформе (Steam и других). Первые отзывы (особенно негативные) нужно воспринимать адекватно, пытаться найти рациональное зерно. И даже если вам написали всего пару слов, стоит поинтересоваться у автора, что именно его смутило в вашем продукте.
Например, после релиза Sacralith разработчики получили несколько гневных отзывов о нереалистичности лука. Как выяснилось из диалога с пользователем, проблема заключалась в расположении стрелы относительно древка. В игре этот момент был реализован исторически верно, как в средневековье. Но в современных луках «полочка» для стрелы находится слева. Из-за этого пользователи возмущались, мол «разработчики ни разу в руках лук не держали!» Быстро переделав эту деталь, ребята тут же получили положительный фидбек от аудитории. Несколько негативных отзывов удалось превратить в позитивные, что дало в итоге необходимые 90% положительных отзывов.
![](https://habrastorage.org/r/w1560/getpro/habr/post_images/4ac/f87/97a/4acf8797a5dc091b5a8e0c15492a4c90.png)
Наверняка, многие из вас боятся, что гениальную идею могут украсть. Если вы вернетесь к началу статьи и вспомните слова Эдисона, то поймете, что бояться этого вовсе не стоит. Даже наоборот, чтобы стать лучше и сделать более успешный продукт, важно рассказывать всем о своей идее и бережно собирать критику, после чего совершенствовать разработку.
Надеюсь, эта история и опыт Дмитрия окажутся полезными для тех, кто разрабатывает свой игровой проект или серьезно подумывает об этом. Главное — перебороть свою самоуверенность, прислушиваться к критике и реальным метрикам.
Если вам интересно посмотреть на его живое выступление, где чуть больше деталей, оно тут.
История хороша тем, что в ней, кроме хеппи-энда, описаны и крупные промахи, благодаря которым приобретается бесценный опыт. А самое главное — ребята с радостью делятся всеми деталями и списком граблей, которые они собирали на этом длинном пути.
![](https://habrastorage.org/getpro/habr/post_images/7aa/194/d50/7aa194d508dbc298b2a42c2f6983b15c.jpg)
Знакомьтесь, Дмитрий Светлов. Более 10 лет он руководит собственной студией архитектурной визуализации — 3Dmode. В какой-то момент, когда дела в компании уже стабильно шли хорошо, у него появилась потребность в покорении новых вершин, и он решил вернуться к увлечению детства — созданию игр.
Следующие три года он, вместе с другом, посвятил разработке браузерного top-down шутера. Работали по большей части вечерами. Последний год друг корпел над кодом уже все свое время. Но проект в итоге так и не вышел в релиз. Затем последовала вторая попытка — VR-шутер Sacralith: the archer's tale — и она оказалась удачной.
![](https://habrastorage.org/getpro/habr/post_images/aac/711/02c/aac71102c0e670c35f5cfea4d90f4400.png)
Ниже — пересказ лекции Дмитрия, на которой он рассказал много интересных деталей и отметил пять главных препятствий, с которыми пришлось столкнуться команде на пути к успешному запуску.
Оптимизм
Звучит странно, но на деле он стал главной причиной провала первого проекта. Когда Дмитрий вместе со своим другом-программистом начали делать браузерный top-down shooter, они не сомневались, что все получится.
![](https://habrastorage.org/getpro/habr/post_images/9b2/5d1/0f3/9b25d10f3f2bc5464d5ebfa3116f448c.png)
Но несмотря на собственный богатый опыт работы с 3D-графикой и опыт друга-программиста, довести игру до релиза ребятам так и не удалось. Вера в успех их ослепила.
Если оглянуться, то можно заметить, как много вокруг образов «уверенных в себе людей, четко представляющих конечную цель и добившихся небывалых высот». Такие характеры без устали тиражируются в медиа-пространстве, продвигая простую идею: «главное верить, и все получится». Однако в таком подходе есть существенный изъян.
![](https://habrastorage.org/getpro/habr/post_images/fc7/9f8/9e3/fc79f89e3de6b68bf585d1d4085f0420.png)
Схема развития компетентности
На схеме выше обозначены стадии, которые проходит каждый специалист. Очевидно, что большинство из тех, кто слепо верит в успех, находятся на первой стадии. Но реальность такова, что результата добиваются люди не столько талантливые, сколько трудолюбивые. Но и это тоже не главное.
![](https://habrastorage.org/getpro/habr/post_images/f5c/b55/6dc/f5cb556dcee46f53391106ecfc6c1136.png)
Чтобы сделать проект, нужно уметь делать проекты. Именно понимания, как «начать», как «сделать» и как «завершить» проект, не хватило тогда, чтобы выпустить свою первую игру.
Здоровый пессимизм — это именно то, что приходит с опытом. И речь не о вере в собственные силы, а о банальной осторожности и расчетливости. «Новичок», выходя из дома, возьмет с собой плеер, а «профессионал» захватит зонтик, таблетки от головной боли и, возможно, бронежилет.
Нереалистичные ожидания
Начиная проект, вы закладываете определенное время и ресурсы на разработку, а также представляете потенциальные доходы и расходы. Хорошо, когда ожидания и реальные цифры оказываются близки, но у большинства инди-разработчиков это получается далеко не с первого раза. Когда вокруг говорили о смерти флеша и угасании эры браузерных игр, они все равно верили в головокружительный успех.
С Sacralith было нечто похожее. Один из основных участников, даже когда ему показывали текущие метрики, слепо верил, что проект принесет миллионы долларов. И он в итоге принес миллионы, но рублей. Из-за чего тот покинул команду.
Доходы от Sacralith
Для многих это самая интересная часть рассказа.
![](https://habrastorage.org/getpro/habr/post_images/9ad/25b/b82/9ad25bb8211b840479e576387a781cc8.png)
Выручка в Steam
Глядя на эти цифры, стоит помнить, что до вас дойдет только половина этой суммы. 30% уйдет Steam, 5% налог VAT, потом валютный контроль у нас и ряд других налогов.
![](https://habrastorage.org/getpro/habr/post_images/4ef/d87/832/4efd878328dc17d39ad52c2e6fb1e5a8.png)
Выручка в магазине Oculus
Всплески на графиках — это устроенные нами распродажи со скидками в 35-50%. А в PS Store дела и того хуже — там без продвижения вообще невозможно что-то продать. В итоге в сумме на всех площадках на текущий момент реализовали около 12 тыс. копий.
Начало разработки и расходы на проект
Разработка Sacralith: The Archer`s Tale стартовала в 2007 году. Параллельно Дмитрий проходил курс профессиональной переподготовки «Менеджмент игровых проектов» в ВШБИ НИУ ВШЭ, поскольку в какой-то момент понял, что начинать надо было именно с управления.
Расходы на весь проект оказались такими:
![](https://habrastorage.org/getpro/habr/post_images/c34/100/429/c34100429d5f60e47dfecfa064673bed.png)
Бюджет разработки
Расчет очень приблизительный. Если бы Дмитрий платил зарплату сам себе в объеме хотя бы 150 тыс. руб. в месяц, общая стоимость разработки выросла бы примерно на три с лишним миллиона.
Для оптимизации расходов были использованы самые разные приемы. Например, для записи лицевой анимации компания сделала свой шлем, который обошелся всего в 70€ (оригинал стоит 1800 €).
![](https://habrastorage.org/getpro/habr/post_images/a71/27e/dc7/a7127edc7419d95fd652ef1ea86ec84f.png)
Также был собран специальный сканер лица (стоимость 80 000 рублей). Ранее сканирование одного персонажа в студии обходилось в 30 000 рублей.
![](https://habrastorage.org/getpro/habr/post_images/16c/79b/dc6/16c79bdc6db076bcac91253503523c07.jpg)
Примеры лиц персонажей
Время и проблемы с его расчетом
На примере работы своей студии 3Dmode Дмитрий рассказал о планировании. В первые годы работы студия частенько не поспевала к срокам. Дмитрий принял решение провести внутреннее исследование и внедрил систему тайм-трекинга, в которой задачи разбивались на категории.
Изначально процесс оценки необходимого времени выглядел следующим образом:
![](https://habrastorage.org/getpro/habr/post_images/c55/54f/a68/c5554fa683ee32182ea233b5079471b0.png)
После анализа реальных затрат времени схема стала выглядеть так:
![](https://habrastorage.org/getpro/habr/post_images/ca9/080/944/ca908094434131360b67f36140015487.png)
Реальное время производства составляло уже 12 дней.
Не учитывалось время «внутренних правок», ожидания комментариев заказчика. Появился коэффициент x1,2 для страховки от непредвиденных ситуаций, например: ключевой специалист заболел, вылетел рендер, отрубился сервер…
И это все происходило с заранее известными и отработанными задачами. В разработке игр все задачи оказывались новыми. Например, во время записи анимаций движений монаха для Sacralith ребята сотрудничали со студией «Пилот» (это компания, которая создала популярных персонажей Хрюна и Степана). На первый взгляд все было натурально, но после финального рендера сцена выглядела как-то неестественно. Долго не могли понять почему. После двух недель поисков причину нашли. Оказалось, что проблем с анимацией тела нет, а все дело в неестественном взгляде героя.
Команде пришлось срочно разработать систему процедурного взгляда персонажа. В зависимости от ситуации герой мог смотреть четко в камеру, на ключевые точки интереса или просто потупить взор. Никто не думал, что на это уйдет еще месяц разработки. И таких «мелочей» на пути к релизу попадалось очень много.
Энтропия и невротизм планирования
Планирование — важнейший инструмент для работы со сложными проектами. Но ценность плана в условиях тотальной неизвестности и непредсказуемости стремится к нулю. Куда важнее четко видеть точку назначения, чем скрупулезно следовать заранее проложенному маршруту. Если каждый участник процесса понимает, что он делает, зачем он это делает и когда нужно закончить — разработка движется.
![](https://habrastorage.org/getpro/habr/post_images/a67/1d8/f52/a671d8f5263c7fca6f8127c6d9c5a31e.png)
При создании Sacralith Дмитрий заменил план на условную схему, состоящую из простых целей. Например финальной целью был релиз в феврале и 5000 продаж при цене в 20$ на старте.
![](https://habrastorage.org/getpro/habr/post_images/6ff/b07/fe3/6ffb07fe3e4d74a563a1503e187e9858.png)
Схема целей
Следующий принцип, который использовала студия — это принцип MVP (minimum viable product), т.е. создание минимально жизнеспособного продукта на каждом этапе разработки. При таком подходе вы создаете рабочую болванку, которую в дальнейшем улучшаете по всем основным показателям.
На картинке ниже вы можете увидеть, что уже на первом этапе должна получиться работоспособная машина, которая впоследствии «обрастает» деталями.
![](https://habrastorage.org/getpro/habr/post_images/1c9/f59/c47/1c9f59c4700042f52b0a4d4b2cf5dd86.png)
На примере Sacralith команда определила следующую пирамиду разработки, состоящую из фичей, преимуществ и ценностей:
- Фичи (особенности игры): стрельба из лука, система прокачки, враги и кат-сцены.
- Преимущества (относительно конкурентов): крутая физика стрелы и красочная графика.
- Ценности (главные идеи): максимально кровавый симулятор лучника в средневековье.
После определения этих составляющих можно начинать работу над MVP. При этом важно делать фокус на ценностях проекта. Чем лучше вы продемонстрируете их на самой ранней стадии разработки, тем больше шансов на успех у вашего продукта.
![](https://habrastorage.org/getpro/habr/post_images/048/97f/5ca/04897f5ca17465e4cb1927090a1d5ce8.png)
Можно начать с фичей, как это показано на верхней левой пирамидке, но это плохой вариант. Нормальный вариант — когда мы делаем фичи, которые могут продемонстрировать ценность (внизу слева), а лучший вариант — когда мы думаем, как нам продемонстрировать ценность (внизу справа).
Упрямство
Полезное качество в бизнесе, но если мы говорим об инди-разработке, то иногда оно только мешает. Разберем это на примере создания mockup-анимаций для Sacralith. Для их записи нужно специальное оборудование и актеры, которые будут изображать нужные вам движения.
![](https://habrastorage.org/getpro/habr/post_images/953/545/e28/953545e282b22c4baea80a322a7abaa2.png)
Запись mockup-анимации. Один из актеров на фото — основатель студии «Пилот»
Дмитрий рассказал, что пытался добиться от актеров максимальной серьезности в движениях. И, несмотря на все старания, в жестах актеров проскакивали нотки родных для них Хрюна и Степана. Однако именно эта комичность персонажей позволила разработчикам взглянуть на проект по-новому.
В итоге в игре появился юмор, персонажи стали более харизматичными. Да, все эти решения появились спонтанно, но итоговый продукт от таких изменений только выиграл. Таким образом в условии ограниченных ресурсов важно плыть по течению, а иногда даже менять пункт назначения. Конечно, если вы верите, что это пойдет на пользу итоговому продукту.
Похожая история была с моделями персонажей. В отличие от классической схемы разработки, команда Дмитрия использовала строго противоположный подход:
- ребята набирают базу готовых ассетов (звуки, 3D-модели, окружение), которые есть в наличии или доступны для покупки в специализированном магазине;
- на ее основе делают дизайн уровней и персонажей;
- прорабатывают сценарий и финализируют сеттинг (уникальный стиль игры).
![](https://habrastorage.org/getpro/habr/post_images/aaa/475/501/aaa4755010838d7f858b222db836ac16.png)
Классический пайплайн (схема разработки)
![](https://habrastorage.org/getpro/habr/post_images/d3f/6c8/092/d3f6c80928cd2e2db6fa964509501e16.png)
Пайплайн, отработанный на Sacralith
Т.е. разработка шла не от плана и сценария, а сценарий подгонялся под имеющиеся в наличии модели и другие ресурсы. Такой подход позволил сэкономить кучу времени и средств, благодаря чему итоговый продукт смог принести прибыль создателям.
Первые отзывы: лук настоящий, но все думают иначе
Работа над продуктом не прекращается после релиза игры на платформе (Steam и других). Первые отзывы (особенно негативные) нужно воспринимать адекватно, пытаться найти рациональное зерно. И даже если вам написали всего пару слов, стоит поинтересоваться у автора, что именно его смутило в вашем продукте.
Например, после релиза Sacralith разработчики получили несколько гневных отзывов о нереалистичности лука. Как выяснилось из диалога с пользователем, проблема заключалась в расположении стрелы относительно древка. В игре этот момент был реализован исторически верно, как в средневековье. Но в современных луках «полочка» для стрелы находится слева. Из-за этого пользователи возмущались, мол «разработчики ни разу в руках лук не держали!» Быстро переделав эту деталь, ребята тут же получили положительный фидбек от аудитории. Несколько негативных отзывов удалось превратить в позитивные, что дало в итоге необходимые 90% положительных отзывов.
![](https://habrastorage.org/getpro/habr/post_images/4ac/f87/97a/4acf8797a5dc091b5a8e0c15492a4c90.png)
Воровство
Наверняка, многие из вас боятся, что гениальную идею могут украсть. Если вы вернетесь к началу статьи и вспомните слова Эдисона, то поймете, что бояться этого вовсе не стоит. Даже наоборот, чтобы стать лучше и сделать более успешный продукт, важно рассказывать всем о своей идее и бережно собирать критику, после чего совершенствовать разработку.
Итоги
Надеюсь, эта история и опыт Дмитрия окажутся полезными для тех, кто разрабатывает свой игровой проект или серьезно подумывает об этом. Главное — перебороть свою самоуверенность, прислушиваться к критике и реальным метрикам.
Если вам интересно посмотреть на его живое выступление, где чуть больше деталей, оно тут.