Я, конечно, просто расскажу вам несколько банальностей, которым сам бы никогда не поверил в начале своего пути.
И путь не долгий и не очень успешный.
Всего лишь небольшое хобби, но после которого ваше видение проясняется, позволяя сказать, какой проект имеет шансы на успех, а какой заведомо неудачный.
Конечно, мой путь – один из таких, и теперь я только сожалею о потерянном времени, а вам, мой читатель, может быть, только интересно, какие ошибки я совершил в свое время.
Ты ничего не сделал, но собираешь команду
Не надо так Амбиции, амбиции и еще раз амбиции — вот что мешает вам работать в рамках инди-команды… вы не верите или думаете, что это чисто субъективный опыт? Ну посмотрите сериал «Остановись и загорись».Но амбиции – это половина дела – лень и непрофессионализм завершают свое дело.
Увы, вы пока ничего не сделали — речь идет о вас, а не о тех, кого вы пытаетесь найти.
Да и вы найдете такие же) Вы должны четко понимать, что двум амбициозным людям в команде уже будет тесно и вы больше времени потратите на разговоры, чем на разработку.
Это не значит, что вы не должны обсуждать проект — это то, как вы это делаете.
Прежде чем искать команду, у вас должно быть представление об игре, чем вы хотите заниматься.
Он состоит из названия игры, жанра и цикла игрового процесса.
И это должно быть на бумаге.
Если у вас нет названия, вам кажется, что оно появится позже, все бы ничего, но у вас скорее всего нет понимания игры.
Я никогда не буду участвовать в таком проекте – это пустая трата времени.
Непонимание жанра приводит к тому, что хочется впихнуть в игру все и это поддается соусу, что будет интересно.
Цикл геймплея — один из полезных терминов геймдизайна — изучайте и придумывайте, вариантов нет. И конечно, никакой проектной документации – на данном этапе ее у вас пока быть не может. Теперь вы имеете смутное представление о том, чего хотите (вам это может показаться ясным – но лучше понять, что это не так).
Начинаем общаться с командой.
Не секрет, что 95% ищут партнеров на энтузиазме и удаленно.
Никогда не разговаривайте с кандидатами в партнеры голосом – время на болтовню тратится впустую.
И для начала выясните, с кем вы имеете дело, понимая, что неважно, заинтересован ли он – это опять же ваше потерянное время.
Адекватность — важнейший критерий первых переговоров — никогда не решайте за других, не указывайте им, что делать, не устанавливайте сроки.
Такие люди очень быстро будут считаться менеджерами и, в зависимости от профессионализма команды, будут более или менее терпеть.
Заинтересованные люди сделают это сами, напишут и покажут, что получилось.
Дайте людям возможность иметь собственное мнение, не повышайте тон разговора, если не согласны.
Вы достаточно быстро поймете, спорит ли человек из-за спора или он сам берется сделать то, что предлагает. Возьмите за правило, что этого делать нельзя – не вам решать, как это делать.
В конечном счете, работайте с теми, кто действительно что-то делает. Но многое зависит от роли в команде.
Это очень академический подход: геймдизайнер придумывает игру, программист кодирует, художник рисует. Все зависит от профессионализма человека в своей области.
В идеале работа геймдизайнера заканчивается там, где начинается работа программиста и художника.
Если у геймдизайнера больше опыта, чем у программиста или художника (что, наверное, только в сказках бывает, но все же), только тогда он сможет распределить работу, поставить перед ними задачи и точнее описать, что нужно программисту или художнику.
делать.
Найдите геймдизайнера, который не имеет таких амбиций, но может работать в данных условиях.
Его задача — детализировать идею, а не изменить ее.
Что касается художника/3д моделлера, то если это ваша первая игра, то он вам вообще не нужен, используйте готовые модели, которых сейчас достаточно, или вообще сделайте прототип на квадратиках, серый прототип.
Вместо этого вам понадобится дизайнер уровней.
Что касается программистов, то главный критерий — найти тех, кто не занимается написанием движков, умеет работать с любым чужим кодом и использует его как части в своей разработке.
О командах можно говорить много, иногда кажется, что они тебя тянут вниз, или вширь, но хочется глубже.
Но дайте команде возможность работать с вами, еще никогда не было, чтобы работа с профессионалами была напрасной, постарайтесь оценить их видение.
Если вы что-то решили, не спорьте – потратьте неделю на оценку других вариантов.
Если при обсуждении вариантов вы видите, что оппонент не идет на компромисс, возможно, вы работаете с непрофессионалами? тебе это надо? Но в любом случае записывайте все, что делаете, контроль версий и резервное копирование хотя бы раз в неделю.
Оборот при смутном видении проекта
Если это ваш первый проект, или вы еще не работали в команде с текучестью кадров, матерью и не понимаете, как это делается в реальности, а не на бумаге, то в 99% у вас будет текучка кадров со смутным видением проекта.По-другому просто быть не может. Энтузиазм пропадает, но так устроен человек, он может увлечься чем-то другим и начать заниматься другим проектом.
Это, кстати, вторая причина текучести кадров, о первой, если обобщить неадекватность, говорилось выше.
Поэтому, если вы его не документируете, не комментируете и не говорите вслух, проект не оставляет никаких артефактов, и даже если бы вы захотели, вы никогда не сможете вернуться к нему через год. Это значит, что у вас никогда не будет четкого видения проекта) Я говорил, что четкое видение проекта невозможно в процессе разработки? Да.
Это видение придет к вам не сразу, если у вас есть опыт и, как правило, когда вы отвлечены от процесса разработки и, скорее всего, под влиянием чего-то - игры, в которую вы играли, фильма/книги или хорошего секса) А до этого старайтесь выполнять целые части/задачи, не берясь за все сразу и записывая, и фиксируя, а затем структурируя то, что вы делаете.
Так что же означает это четкое видение проекта? Дело не в том, как проект выглядит для вас, а в том, как, по вашему мнению, проект выглядит для игрока/пользователя.
Лучше всего это объясняется одним принципом объектного программирования Г.
Буха:
понятия достаточности, полноты и примитивности.Когда мы говорим о четком видении проекта, мы должны видеть его завершенность в одном мысленном представлении, при этом понимая, как реализуется каждый элемент, и зная, что он не потребует расширения при дальнейшей разработке.Достаточность означает наличие в классе или модуле всего необходимого для реализации логичного и эффективного поведения.
Другими словами, компоненты должны быть полностью пригодными к использованию.
Например, рассмотрим класс set. Операция удаления элемента из множества в этом классе, очевидно, необходима, но было бы ошибкой не включить в этот класс операцию добавления элемента.
Нарушение требования достаточности обнаруживается очень быстро, как только создается клиент, использующий абстракцию.
Полнота означает наличие в интерфейсной части класса всех характеристик абстракции.
Идея достаточности предъявляет минимальные требования к интерфейсу, тогда как идея полноты охватывает все аспекты абстракции.
Полнота характеризуется классом или модулем, интерфейс которого гарантирует все для взаимодействия с пользователями.
Полнота — субъективный фактор, которым разработчики часто злоупотребляют.
Тогда мы можем сказать, что наш проект завершен.
Можно сказать, что такого никогда не бывает и проект всегда нужно развивать.
Нет, я вам скажу, а дело в том, что мы, разработчики, определяем абстракции и наполняем их смыслом.
Если нам удастся увидеть красоту и завершенность выбранных нами абстракций, то мы получим четкое видение проекта и готовой игры.
Теги: #игры #Разработка игр #Разработка игр
-
Хитрости Со Squid В Корпоративной Сети
19 Oct, 24 -
Правительственный Бункер В Шотландии
19 Oct, 24 -
Серверы Ibm Будут Работать На Solaris
19 Oct, 24
