Конечно, я расскажу вам просто несколько банальностей, в которые никогда не поверил бы сам в начале своего пути. Да и путь не большой и не сильно успешный. Просто немного хобби, но после которого проясняется взгляд, позволяющий сказать какой проект имеет шанс на успех, а какой заведомо неудачен. Конечно, мой путь один из таких, и теперь я жалею только время, которое потерял, а вам мой читатель может быть лишь интересно какие ошибки я в свое время сделал.
Вы не сделали ничего, но собираете команду
Не надо так
Амбиции, амбиции и еще раз амбиции — вот что не дает работать в рамках инди команды… не верите, или считаете это сугубо субъективным опытом? Ну, посмотрите что ли сериал Halt and Catch Fire. Но амбиции это пол беды — лень и не профессионализм, довершают свое дело.
Увы, пока вы не сделали ничего — это про вас, а не про тех кого пытаетесь найти. Да и найдете вы таких же )
Вы должны четко понимать, что двум амбициозным людям в команде уже будет тесно и вы больше потратите времени на разговоры, чем на разработку. Это не означает, что вы не должны обсуждать проект — дело в том как вы это делаете.
Прежде, чем искать команду — у вас должна быть идея игры, что вы хотите сделать. Она состоит из названия игры, жанра, и цикла геймплея. И это должно быть на бумаге. Если у вас нет, названия, вам кажется, оно появится позже — все бы хорошо, но у вас наверняка и нет понимая игры. Я с таким проектом никогда не свяжусь — это трата времени. Не понимание жанра приводит к тому, что хочется в игру впихнуть всё и это поддается под тем соусом, что это будет интересно. Цикл геймплея — это один из полезных терминов геймдизайна — изучить и придумать, тут без вариантов. И естественно, ни каких диздоков — на этом этапе его у вас еще быть не может. Теперь у вас есть смутное представление, что вы хотите (для вас оно, может казаться ясным — но лучше понимать, что это не так).
Начинаем говорить с командой. Не секрет что 95% ищут партнеров на энтузиазме и удалено. Ни когда не говорите голосом с кандидатами в партнеры — зря потрачено время на болтовню. И для начала выясните с кем имеете дело, понимания что без разницы лишь бы у него бы интерес — это снова ваше потраченное время.
Адекватность самый главный критерий первых переговоров — ни когда не решайте за других, не говорите, что им делать, не назначайте сроков. Таких людей очень быстро сочтут диреХторами и в зависимости от профессиональности команды будут терпеть больше или меньше. Заинтересованные люди сами сделают и напишут покажут вам, что получилось. Давайте людям возможность иметь свое мнение, не подымайте тон беседы при не согласии. Вы поймете достаточно быстро или человек спорит из-за спора или сам берется сделать то, что предлагает. Возьмите за правило, что вы не можете сделать — не вам и решать как надо. В итоге работайте с теми кто что-то реально делает. Но тут многое зависит от роли в команде.
Это очень академический подход, что геймдизайнер придумывает игру, программист кодирует, художник рисует. Все зависит от профессиональности человека в своем деле.
В идеале работа геймдизайнера заканчивается там где начинается работа программиста и художника. Если геймдизайнер с превосходящим опытом, чем программист или художник (что наверное бывает только в сказках, но все же), только тогда он может распределять работу, ставить им задачи, точнее описывать, что надо сделать программисту или художнику. Находите такого геймдизайнера, который не болеет такими амбициями, а может работать в поставленных условиях. Его задача детализировать идею, а не изменять её.
Что до художника/3d моделера — то если это первая ваша игра — он вам не нужен вообще, используйте готовые модели, коих теперь достаточно или вообще сделайте прототип на квадратах, серый прототип. Вместо этого вам понадобится левел дизайнер.
Что до программистов — то главный критерий, найти тех, кто не болеет движкописанием, умеет работать с любым чужим кодом, и использует его как части в своей разработке.
Про команды можно говорить много, иногда кажется, что она тебя тянет вниз, или вширь, а вам хочется в глубь. Но дайте команде шанс работать с вами, никогда еще не бывало, что работа с профессионалами была напрасной, постарайтесь оценить их виденье. Если, что-то решаете не спорьте — походите недельку оцените другие варианты. Если при обсуждении вариантов видите, что оппонент не идет на компромиссы, может вы работаете с не профессионалами? а надо ли оно вам? Но в любом случае фиксируйте все что делаете, контроль версий и бэкапы минимум раз в неделю.
Текучка при смутном виденье проекта
Если это ваш первый проект, или вы еще не поработали в команде с текучкой кадров, руганью, а не понимаете как это делается реально, а не на бумаге — то в 99% у вас так и будет текучка при смутном виденье проекта. По другому просто и быть не может.
Энтузиазм же пропадает, да так устроен человек, он может увлечься чем то другим и начать делать другой проект. Это, кстати вторая причина текучки кадров, о первой если обобщить не адекватности — говорилось выше. Именно поэтому если не фиксировать документально, не делать комментариев, говорить голосом — проект не оставляет ни каких артефактов и даже при желании через год вы к нему никогда не сможете возвратится. А значит и четкого виденья проекта у вас так и не появится )
Сказал ли я, что четкое виденье проекта не возможно в процессе разработки? Да. Оно это виденье придет к вам при наличии опыта не сразу и как правило при отрыве от процесса разработки, и скорее всего под влиянием чего-то — игры в которую вы сыграли, фильма/книги или хорошего секса )
А до этого, постарайтесь реализовывать законченными частями/задачами, не берясь за все сразу и фиксировать и фиксировать, а потом структурировать что вы делаете.
Итак, что же значит это четкое виденье проекта? Это не то как выглядит проект для вас, а то как вы думаете этот проект выглядит для игрока/пользователя.
Лучше всего это объяснить одним принципом объектного программирования от Г.Буч.:
понятия достаточности, полноты и примитивности. Под достаточностью подразумевается наличие в классе или модуле всего необходимого для реализации логичного и эффективного поведения. Иначе говоря, компоненты должны быть полностью пригодны к использованию. Для примера рассмотрим класс set (множество). Операция удаления элемента из множества в этом классе, очевидно, необходима, но будет ошибкой не включить в этот класс и операцию добавления элемента. Нарушение требования достаточности обнаруживается очень быстро, как только создается клиент, использующий абстракцию. Под полнотой подразумевается наличие в интерфейсной части класса всех характеристик абстракции. Идея достаточности предъявляет к интерфейсу минимальные требования, а идея полноты охватывает все аспекты абстракции. Полнотой характеризуется такой класс или модуль, интерфейс которого гарантирует все для взаимодействия с пользователями. Полнота является субъективным фактором, и разработчики часто ею злоупотребляют,
Когда же мы говорим о ясном виденье проекта, мы должны узреть его законченность в одном мысленном представлении, при этом понимая, как каждый элемент реализован и зная, что это не потребует расширения при дальнейшей разработки. Вот тогда мы сможем сказать наш проект полон. Вы можете сказать, что такого никогда не бывает и всегда надо проект развивать. Нет скажу я вам, и дело в том, что мы разработчики определяем абстракции и наполняем их смыслом. Если нам удается увидеть красоту и законченность выбранных наших абстракций — вот тогда мы и получим ясное виденье проекта и готовую игру.
Автор: tac
