При разработке собственного игрового проекта независимые разработчики или даже целые студии часто упускают ряд важных моментов, которые крайне важны для успешного завершения начатого. Из-за этого проблемы могут возникнуть даже в проекте, в котором с виду все хорошо, например, присутствует хорошая команда и есть некоторые средства на раскрутку. Если брать среднестатистического инди-разработчика, то чаще всего это один человек, выполняющий одну или несколько ролей. При необходимости он добирает в команду необходимых специалистов. Чаще всего он не знает основ тайм-менеджмента и не умеет держать баланс между работой, другой занятостью, здоровьем и личной жизнью. Это не казалось бы таким важным, если бы не сотни хороших проектов, которые не увидели финала из-за эмоционального выгорания основного разработчика. Поэтому при создании игры, какой бы интересной она не была, не стоит забывать про семью и спортзал. Очевидность этого простого совета станет ясна, когда появится энергия на новые и новые этапы развития своего проекта при отсутствии дефицита времени на остальные стороны жизни.
При работе с командой важно помнить, что незаменимых людей не бывает. Каждого человека, несмотря на его высокую квалификацию и ограниченный бюджет разработки, необходимо «страховать» другим человеком, который бы был в курсе специфики и деталей его работы. Необходимо использовать гибкий подход к разработке архитектуры, используя паттерны проектирования. Стоит внедрить в обиход правила оформления кода и требовать от программистов переписывания тех его частей, которые могут быть непонятны. Немаловажно привить специалистам привычку покрывать свои коды документацией и тестами. Тогда потеря командой даже самого сильного разработчика пройдет наименее болезненно. В случае инди-игр это особенно важно, потому что обычно команды очень маленькие, ресурсов мало, а разница в квалификации разработчиков может быть очень большой. Важен и грамотный подход к созданию и ведению игрового комьюнити вокруг проекта. Большинство команд создают его на этапе релиза, пытаясь собрать сообщество игроков для увеличения популярности продукта. Однако правильно организовывать сообщество на этапе разработки, причем на самых ранних стадиях. Тогда уже к релизу величина сообщества и его заинтересованность проектом будет намного большей, что позволит сделать старт игры в магазинах быстрым и мощным. Еще одним плюсом будет постоянная обратная связь и «тестирование толпой» от энтузиастов. В отсутствие ресурсов на полноценное тестирование это позволит сократить число багов и недочетов, а также почерпнуть новые идеи. Наконец, наличие некой группы вокруг проекта позволит при случае набрать новых специалистов в команду. Чтобы собрать комьюнити без конечного проекта, достаточно предоставлять интересный контент, посвященный самой разработке. Людям интересны концепт-арты, наметки геймплея, диздоки, кусочки кода, ассеты игровых движков и многое другое. Все промежуточные версии также стоит выкладывать в сеть, это даст новую порцию идей и полезной критики. Что касается идейной составляющей, то главных правила успешного начала в инди-разработке два: «не начинай делать проект, который займет более одного месяца» и «зачастую лучше скопировать готовую идею, чем реализовать свою, какой бы удачной она ни казалась». Корректность этих эмпирических правил становится очевидна лишь с получением некоторого опыта в сфере разработки проектов.
При работе с командой важно помнить, что незаменимых людей не бывает. Каждого человека, несмотря на его высокую квалификацию и ограниченный бюджет разработки, необходимо «страховать» другим человеком, который бы был в курсе специфики и деталей его работы. Необходимо использовать гибкий подход к разработке архитектуры, используя паттерны проектирования. Стоит внедрить в обиход правила оформления кода и требовать от программистов переписывания тех его частей, которые могут быть непонятны. Немаловажно привить специалистам привычку покрывать свои коды документацией и тестами. Тогда потеря командой даже самого сильного разработчика пройдет наименее болезненно. В случае инди-игр это особенно важно, потому что обычно команды очень маленькие, ресурсов мало, а разница в квалификации разработчиков может быть очень большой. Важен и грамотный подход к созданию и ведению игрового комьюнити вокруг проекта. Большинство команд создают его на этапе релиза, пытаясь собрать сообщество игроков для увеличения популярности продукта. Однако правильно организовывать сообщество на этапе разработки, причем на самых ранних стадиях. Тогда уже к релизу величина сообщества и его заинтересованность проектом будет намного большей, что позволит сделать старт игры в магазинах быстрым и мощным. Еще одним плюсом будет постоянная обратная связь и «тестирование толпой» от энтузиастов. В отсутствие ресурсов на полноценное тестирование это позволит сократить число багов и недочетов, а также почерпнуть новые идеи. Наконец, наличие некой группы вокруг проекта позволит при случае набрать новых специалистов в команду. Чтобы собрать комьюнити без конечного проекта, достаточно предоставлять интересный контент, посвященный самой разработке. Людям интересны концепт-арты, наметки геймплея, диздоки, кусочки кода, ассеты игровых движков и многое другое. Все промежуточные версии также стоит выкладывать в сеть, это даст новую порцию идей и полезной критики. Что касается идейной составляющей, то главных правила успешного начала в инди-разработке два: «не начинай делать проект, который займет более одного месяца» и «зачастую лучше скопировать готовую идею, чем реализовать свою, какой бы удачной она ни казалась». Корректность этих эмпирических правил становится очевидна лишь с получением некоторого опыта в сфере разработки проектов.
