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

Вы не сделали ничего, но собираете команду

Не надо так

Амбиции, амбиции и еще раз амбиции — вот что не дает работать в рамках инди команды… не верите, или считаете это сугубо субъективным опытом? Ну, посмотрите, что ли сериал Halt and Catch Fire. Но амбиции — это пол беды — лень и не профессионализм, довершают свое дело.

Увы, пока вы не сделали ничего — это про вас, а не про тех, кого пытаетесь найти. Да и найдете вы таких же )

Вы должны четко понимать, что двум амбициозным людям в команде уже будет тесно и вы больше потратите времени на разговоры, чем на разработку. Это не означает, что вы не должны обсуждать проект — дело в том, как вы это делаете.

Прежде, чем искать команду — у вас должна быть идея игры, что вы хотите сделать. Она состоит из названия игры, жанра, и цикла геймплея. И это должно быть на бумаге. Если у вас нет, названия, вам кажется, оно появится позже — все бы хорошо, но у вас наверняка и нет понимая игры. Я с таким проектом никогда не свяжусь — это трата времени. Не понимание жанра приводит к тому, что хочется в игру впихнуть всё и это поддается под тем соусом, что это будет интересно. Цикл геймплея — это один из полезных терминов геймдизайна — изучить и придумать, тут без вариантов. И естественно, ни каких диздоков — на этом этапе его у вас еще быть не может. Теперь у вас есть смутное представление, что вы хотите (для вас оно, может казаться ясным — но лучше понимать, что это не так).

Начинаем говорить с командой. Не секрет что 95% ищут партнеров на энтузиазме и удалено. Никогда не говорите голосом с кандидатами в партнеры — зря потрачено время на болтовню. И для начала выясните с кем имеете дело, понимания что без разницы лишь бы у него бы интерес — это снова ваше потраченное время.

Адекватность самый главный критерий первых переговоров — никогда не решайте за других, не говорите, что им делать, не назначайте сроков. Таких людей очень быстро сочтут диреХторами и в зависимости от профессиональности команды будут терпеть больше или меньше.

Заинтересованные люди сами сделают и напишут покажут вам, что получилось. Давайте людям возможность иметь свое мнение, не подымайте тон беседы при несогласии. Вы поймете достаточно быстро или человек спорит из-за спора или сам берется сделать то, что предлагает. Возьмите за правило, что вы не можете сделать — не вам и решать, как надо. В итоге работайте с теми, кто что-то реально делает. Но тут многое зависит от роли в команде.

Это очень академический подход, что геймдизайнер придумывает игру, программист кодирует, художник рисует. Все зависит от профессиональности человека в своем деле.

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

Что до художника/3d моделера — то если это первая ваша игра — он вам не нужен вообще, используйте готовые модели, коих теперь достаточно или вообще сделайте прототип на квадратах, серый прототип. Вместо этого вам понадобится левел дизайнер.

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

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

Текучка при смутном виденье проекта

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

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

Сказал ли я, что четкое виденье проекта невозможно в процессе разработки? Да. Оно это виденье придет к вам при наличии опыта не сразу и как правило при отрыве от процесса разработки, и скорее всего под влиянием чего-то — игры в которую вы сыграли, фильма/книги или хорошего секса )

А до этого, постарайтесь реализовывать законченными частями/задачами, не берясь за все сразу и фиксировать, и фиксировать, а потом структурировать что вы делаете.

Итак, что же значит это четкое виденье проекта? Это не то как выглядит проект для вас, а то как вы думаете этот проект выглядит для игрока/пользователя.

Лучше всего это объяснить одним принципом объектного программирования от Г.Буч.:

понятия достаточности, полноты и примитивности. Под достаточностью подразумевается наличие в классе или модуле всего необходимого для реализации логичного и эффективного поведения. Иначе говоря, компоненты должны быть полностью пригодны к использованию. Для примера рассмотрим класс set (множество). Операция удаления элемента из множества в этом классе, очевидно, необходима, но будет ошибкой не включить в этот класс и операцию добавления элемента. Нарушение требования достаточности обнаруживается очень быстро, как только создается клиент, использующий абстракцию. Под полнотой подразумевается наличие в интерфейсной части класса всех характеристик абстракции. Идея достаточности предъявляет к интерфейсу минимальные требования, а идея полноты охватывает все аспекты абстракции. Полнотой характеризуется такой класс или модуль, интерфейс которого гарантирует все для взаимодействия с пользователями. Полнота является субъективным фактором, и разработчики часто ею злоупотребляют.

Когда же мы говорим о ясном виденье проекта, мы должны узреть его законченность в одном мысленном представлении, при этом понимая, как каждый элемент реализован и зная, что это не потребует расширения при дальнейшей разработки. Вот тогда мы сможем сказать наш проект полон. Вы можете сказать, что такого никогда не бывает и всегда надо проект развивать. Нет скажу я вам, и дело в том, что мы разработчики определяем абстракции и наполняем их смыслом. Если нам удается увидеть красоту и законченность выбранных наших абстракций — вот тогда мы и получим ясное виденье проекта и готовую игру.