Меня зовут Саша, я работаю системным архитектором и очень люблю все игры серии Star Control. И хочу поучаствовать в проекте на некоторых ролях (архитектор, программист и переводчик). У меня есть опыт ведения проектов с разработчиками, и я сам работал им, поэтому накопился определённый опыт, которым я готов делиться.
В связи с этим у меня родилось несколько предложений для обсуждения.
В результате переписки с Васякой, я взялся на разработку черновика концепции разработки, основная цель которой звучит лаконично и просто - наиболее быстро начать программировать. Понять, как с наименьшими затратами по времени на разработку и обучение написать законченную игру, которая имеет реальные шансы быть действительно написанной, розданной друзьям, пройденной до дыр в одиночной игре и испитыми ящиками пива вместе с друзьями при игре по сети. Короче, той игрой, в которую клёво играть, у которой, вполне возможно, будет вторая часть и свои фанаты.
Здесь есть ремарка - быстро НЕ означает некачественно. Быстро можно трактовать как "оптимальное соотношение скорости и качества, отбалансированное по скорости". Быстро и поэтому дёшево по ресурсам (времени, обучения, энергии), но с соблюдением стандартов качества.
Написанная игра по мотивам SCII, в которую можно поиграть - для меня является ценностью номер один. Именно этот смысл я вкладывал в то, что пишу. Я могу описать уже известные вещи или кому-то они покажутся само собой разумеющимися, но многое бывает просто необходимо проговорить, даже несмотря на очевидность.
Итак, есть пять критических предложений для проекта, каждое из которых требует принятия того или иного решения:
1. Предлагаю вначале заложить только технический дизайн игры, наиболее упрощённым, с минимум деталей. Этот компромисс связан с издержками и ловушкой хобби-проектов. Пример, чуть утрированный: люди углубляются в обсуждении того, какого цвета будет левая пушка на правом крыле истребителя, но в то же время не написано ни строчки кода. В технических процессах утонуть на порядок сложнее.
ПРИМЕР такого дизайна:
Стратегия. Пошаговая. С сетевой игрой. В ней будет глобальная карта с координатами долготы и широты, как в SC2. На карте будут объекты-звёздные системы, которые генерируются случайным образом. Эти системы колонизируются и могут генерировать войска. Войска перемещаются по глобальной карте меж звёздами в пошаговом режиме. Если два войска разных игроков встретились в системе или на глобальной карте, включается режим боя. Режим боя полностью аналогичен модели Master of Orion. Победил тот, кто захватил все планеты или добыл много ресурсов.
По аналогичному, но, конечно, более подробному описанию уже можно начинать выполнять работы и корректировать их по ходу, выделяя фундаментальные детали игры, которые не изменятся ни при каких условиях. При корректно заложенном техническом дизайне - деталями, дополнениями, фичами, сеттингом и его дизайном можно обогатить игру в любой момент. Нам нужно не одна глобальная карта, а пять таких карт? Не проблема, сделаем на основе уже созданной. Нам нужны чёрные дыры? Не вопрос, сделаем объект по аналогии звёздных систем. Нам нужно, что бы системы двигались? Тоже справимся.
Хотим ли мы написать синтетический клон других игр, или это вырастет в нечто совсем уникальное - это будет ясно в процессе. Вначале предлагается заложить простую и понятную каждому модель мира.
2. Предлагаю в начале проекта использовать свой собственный движок и реализовать все функции собственными силами. Если понадобится какой-либо фреймворк или стоонний движок - то рассматривать его с точки зрения прикладных задач, которые нерешаемы собственными силами. Это связано с тем, что сторонние движки требуют серьёзной квалификации в основном языке из-за того, что нужно читать чужой код. Такую квалификацию можно получить, например, сначала написав что-то своё полностью, а затем поняв, нужен ли сторонний движок вообще (этот вопрос является лично для меня камнем преткновения, т.е. - зачем?). Лично я, опять же, для себя - не вижу препятствий в написании всего с нуля без использования сторонних движков.
3. Предлагаю начать программировать сразу же при тех навыках что есть. Платформа .NET, C# и VB2010, на котором я могу программировать, вместе дают нам возможность модульного разделения - один разработчик пишет мировую карту, другой пишет систему боя, третий - интерфейс развития города на планете. И всё это - на разных языках (разумеется, если разработчиков больше, чем 1). При этом сначала разрабатываются и документируются, а затем используются согласованные функции и глобальные договоренности, дабы не допускать рассинхронизации структур кода, но сделать его связанным. Такой подход не требует переучиваться кому-либо из команды на новый язык.
Фактически, проекты вроде SCII или Master of Orion можно написать на большинстве известных языков программирования.
4. Предлагаю решить вопрос с использованием 3D в пользу 2D вследствие простоты последнего.
Если вопрос об использовании 3D стоит принципиально остро, предлагаю внести на обсуждение информацию о том, какие конкретно есть проблемы в 2D и как 3D их может решить, тем самым обосновать использование 3D. Исключительно в рамках экономия сил и времени.
5. Предлагаю ввести некоторые требования к проектной деятельности, пришедшие из коммерческой среды, которые смогут скрепить проект и команду обязательствами и договорённостями.
Предлагаю договорится о следующих требованиях:
- Существует чёткое разделение по ролям в проекте - геймдизайнер, графический дизайнер, программист, тестировщик, менеджер и пр. Есть ответственный за определённую часть процесса разработки, и его роль меняется лишь в крайних случаях - например, из-за ухода кого-то из проекта, кого надо заменить, либо когда предыдущая роль исчерпала себя - например, переход от архитектора к разработчику, или от разработчика к графическому дизайнеру. Например, глобальный сеттинг придумывает Васяка и только Васяка, он же за неё и отвечает. Техническую архитектуру кода закладываю только я, и я за неё отвественный. Модели рисует только кто-то другой и только он. Модель боя разрабатывает кто-то четвёртый и только он. И так далее, во всех задачах и подзадачах.
- У каждого будет свобода творчества на его участке ответственности, но никто не останется в одиночестве на своей задаче. Это означает, что программисту поможет архитектор, который заранее разработает схему и архитектуру кода, а графическому дизайнеру поможет геймдизайнер, который заранее определит, из какой вселенной нужны модели и каковы минимальные рамки, а геймдизайнеру поможет программист, который будет во время процесса говорить, что мы можем реализовать, а за что браться всё-таки не стоит. И так далее. Каждый сможет принимать ключевые решения - в рамках своей зоны ответственности.
- Решения производятся в открытом и прозрачном режиме, с описанием своих намерений. Можно и нужно коллективно его обсуждать, в тоже время понимая, что окончательные решения принимает тот, кто отвечает за определённый ему участок игры.
- Возражения по процессу, если они весомо аргументированы и обоснованы, должны высказываться сразу же. После принятия решения возражения неуместны.
- Нет отступлений от идей и схем игрового мира, если она была единогласно принята командой в эксплуатацию. Если в процессе проекта был потерян интерес - проблем никаких, реальная жизнь есть у всех. Однако возражения о первоначально принятом пути в середине проекта будут неприемлемы. Исключения - критичные несхождения в концепции, которые внезапно открылись лишь в процессе разработки и делают невозможным её продолжение.
- При принятии решения всегда рассматриваются риски того или иного решения. Приоритет отдаётся тем решениям, которое имеет наименьшее количество рисков. Например, мы решим создавать игру с графикой, как в Crysis 2, с производительностью 50 fps и что бы она была написана на чистом C. Да, мы можем решить так, но будут вполне определённые риски закончить бета-версию игры через 10-15 лет. Допустим, мы решим создавать игру, используя низкокачественные картинки из интернета, не оптимизируя её скорость вообще никак и писать на скриптовом языке двадцатилетней давности. Да, мы так тоже можем решить, однако будут риски получить неиграбельный, некрасивый и глючный вариант некой поделки-недоигры. Описание рисков - это приемлимый вариант оспорить что-либо, приведя рациональную аргументацию.
- Вводится понятие ожидаемых сроков различных этапов разработки и планирование времени - проще говоря, у проекта будет существовать конечный срок выполнения. Например, 9 месяцев. Не год, не два, не пять, а за девять месяцев мы напишем первую играбельную версию игры, уверенно следуя написанному плану. Срок очень короткий, но я уверен, при грамотном планировании всё получится.
Такие мысли мне пришли за несколько дней размышлений.
Прошу высказать любые мысли по процессу. Также предлагаю обозначить, что хорошо в предлагаемом, а что плохо и нуждается в доработке.
Предлагаю опираться, в первую очередь, на наличие физических ресурсов и балансировки под них требований к игре, при учёте, что она должна быть написана в доступные для городского человека рамки планирования (полгода-год).
Впоследствии, результат дискуссии я готов срезюмировать и подвести краткие итоги.
Игровой процесс
Отсюда же вытекает полная свобода перемещения в планетарной системе.