Xil | Разработка проекта научно-фантастической игры
Этот текст появился уже после того как прототипирование игры прошло стадию перехода к многопоточности. Т.е. не сразу. И появилось понимание расходов для небольшой игровой студии если задумать переводить проект с частной разработки на уровень софтверной фирмы и пока это еще мало вероятно. Почему тексты большие по размеру и возможно водные, поисковые системы и Яндекс и Гугл очень плохо принимают в поиск небольшие тексты, было написано 50 текстов для данного сайта размером 1500 символов, в поиск было принято примерно 2 из них, большие же тексты наоборот были приняты в 90% случаев из 100%, если нужно что бы сайт показывался в поиске, текст нужен большой по размеру, иначе будут маленькие, содержательные статьи но они могут плохо влиять на рейтинг сайта по соотношению проиндескированных страниц к общему их числу.
Количество программистов на момент прототипирования исчисляется 1 единицей (может быть число будет больше в процессе дальнейшей попытки создания игры на тему научной фантастики). Обычно в играх которые достигли успеха число программистов 4 и выше, например 6 или 8, а кроме них еще десятки дизайнеров. После эффективной работы программиста много дней без перерыва требуется перерыв, например дней 10, в этот момент что бы проект не простаивал ключевую для проекта задачу вместо постановки на паузу можно передать другому специалисту, т.е. для программирования без вынужденных простоев нужны минимум двое, для исключения ситуации с уходом из студии специалиста на котором держится весь проект, нужна команда способная преодолеть уход из студии кого-то одного, кроме этого команда позволяет распределить задачи для повышения скорости работы над проектом, кто-то работает с созданием модели взрывов кораблей с применением оружия в научно фантастическом стиле, кто-то с экраном контруирования, потом эти уже налаженные наработки быстро соединяются вместе, это требует должность проектного менеджера - планировщика, который распределяет независимые задачи между программистами, планирует кто и что будет делать, а выполненые задачи разными сотрудниками проверяются тем кто читает код и признает его пригодным - не потребляющим лишние ресурсы, и который способен быть прочитан другими. Для этого должен существовать составленный план реализации задумок по независимым модулям и последовтельности реализации, но этот план возможно создать только точно зная что все эти задачи реально воплотить не сталкиваясь с багами, сбоями, критической просадки производительности которые просто закроют возможность релизации того или иного модуля вообще в какой-то момент, т.е. такое возможно только при применении ранее уже обкатанной технологии разработки, т.к. никто незнет сколько дней или месяцев потребуется не реализацию теней, пол года, год, две недели? А если это заденет сторонние коды и начнутся сбои в других подсистемах 3D, сколько потребуется времени на чтение кода сторонней библиотеки и поиск места сбоя, может быть пол года, пол года тут - еще пол года там, в таком случае сроки могут быть нереальными для создания научно фантастической игры. Что бы точно прописать план, нужна отработанная программная платформа - там где связка среды разработки и 3D движка уже отработанна, изучена, и проверена на практике по списку возможностей на других проектах - т.е. должен быть кто-то кто уже вложил силы и собщил можно ли при помощи этих программных средтсв сделать успешную игру или нет и это кто-то должен пойти на риск расходов или вложений для этого и уже потом если у него получится, последующие разработчики смогут закладывать информацю о успехе в свой проект что да, на этой системе можно сделать успешную игру и не столкнутся с неприемлемой ситуаций в процессе разработки через пол года из-за которой разработку игры придется остановить. Если отработанной технологии разработки нет, то такой план разработки может быть перечеркнут технической сложностью в какой-то момент. Т.е. невозможно прогнозировать и строить график выполнения задач специлистами не имея обкатанной технологии и наверняка известных сроков, в ином случае сроки которые проставляются и потом никогда не выполняются бессмысленны. Потому что задачи не отработаны в прошлом, и те задумки в реализации которых нет успешного опыта ранее немогут прогнозироваться получатся они или нет, в итоге крайне высок риск столкнутся с непреодолимой технической сложностью. И практика это показала, после столкновения с некоторыми такими сложностями которые нельзя решить никак, (например - на 60 3D моделях все отлично, а на 1200 возникают проглюки текстур - попробовав в начале кажется логичным начать разработку некоторой игры т.к. вроде все работает, но потратив усилия и ресурсы окажется что существует непреодолимая проблема которая скрыта изначально - так называемые острые подводные камни на которые есть риск наступить незаметив их.) - приходится менять движек что ведет к полной переработки проекта, его модулей, сильно увеличивая даже очень примерные сроки разработки и создавая можно сказать трехкратный рост временных затрат, т.е. нельзя запланировать даже 30%-е издержки, т.к. это слишком мало.
Кроме этого есть более узские специализации такие как разработка шейдеров, когда в прототипе после внедрения внего многопоточности появлся свободный FPS и возможность за счет него поднять уровень графики стало понятно что создание шейдеров требует опыта и мастерства, и это требует много времени. Т.е. кроме программистов и дизайнеров моделей и интерфейса разработка игры требует мастеров по созданию шейдеров и программист не всегда может совмещать в себе весь нужный опыт в них, достаточный для того что бы сделать их действительно красивыми именно в заданных областях применения, и если огнь, стекло, вода - имеют готовые примеры внутри движков которые можно применить для игры то многие другие эффекты требуют разработки именно под проект. Что бы исключить смену кадров (специалистов) при разработке игры и обеспечить стабильный темп работ, требуется постоянный оклад а не разовые выплаты за задачи по договору однократных услуг - а это уже необходимость создавать фирму, т.к. простые гражданские формы заказов услуг для своих проектов предусматривают некоторе ограничения, а фирме нужен офис, если офисного помещения нет то нужна его аренда а это сразу постоянные ощутимые траты на ежемесячной основе - т.е. крупная расходная часть. Что бы получить лучший вариант дизайна корабля или интерфейса требуется заказать его 3-м или больше дизайнерам для выбора лучшей итоговой модели что бы включить в игру действительно эффектную модель и не включать в нее других моделей, и не интегрировать в проект игры абсолютно все что будет создано в процессе разработки. Это не перерасход ресурсов на красоту, это именно то что делает игру красивой - вложение в разные варианты, выбор лучших и их интеграция в проект, обнаружение спустя 1-2 месяца того что было ранее сделано можно многократно улучшить, исключение ранее уже сделанного этого из проекта и замена еще более лучшим по каждному направлению - интерфейс, корабли, планеты, астероиды, конструирование, цивилизации и т.д.
Командная разработка помимо проектного менеджера распределяющего задачи по созданию кода для научно-фантастической игры иногда может приводить к необходимости использовать другой подход в разработке самого кода, использование в нем защищенных программных конструкций с проверкой данных для защиты от случайного вмешательства других программистов которые не всегда обязаны знать подробности работы кода написанного не ими еще до них, иногда даже может быть задействовано применение средств совместной разработки - позволяющих вести разработку одного кода одновременно из разных мест, для таких игровых студий это повышает требования к опыту программистов и их навыкам что бы он был еще и в средах команадной разработки а не просто самостоятельного программирования, одиночная разработка отличается от командной, а больше требований - значит выше расходы на проект. Что бы получить достоверно проверенную среду разработки и 3D движек, часто требуется платный движек - который проверен создателями которые готовы вести по нему поддержку и вносить в него исправления если произойдут критические сбои. Тогда можно получить с более высокой вероятностью годный продукт в приемлемые обозримые сроки (несколько дизайнеров и программистов более вероятно уложатся в сроки чем один) но все это - расходы, а что бы они были окупаемые нужен план и сроки, а так как план прописать невозможно в виду не отработанных решений которые еще предстоит решить и наладить, то сроки проставить просто нельзя, а значит и студию организовывать без наличия неограниченных финансов мало вероятно т.к это будет крайне затратно (много расходов для поддержания административного статуса фирмы, выплату зарплат - ну не покупать же офисное помещение что бы одному там поставить стул около большого игрового ноутбука и писать там на нем программу) требуются постоянные расходы на специалистов, а в какой-то момент может оказаться что произойдет непредолимая сложность и работы придется остановить на время, т.е. экономически спланировать затраты и сроки до появления технической демки в которой точно все работает и ее останется только наполнить содержимым, проблематично, это боле реально когда появится прочная основа которую останется лишь наполнять и расширять графикой, новыми кораблями, дополнениями и т.д. т.е. на этом этапе, когда основные технические сложности уже будут исключены.
Конечно еще остается фактор, что если у 3D движка нет вышедшей игры, это незначит что это 100% показатель что на нем сделать игру нельзя, отчасти иногда это так, нет готового крупного проекта потому что кто-то мог пытаться и столкнутся со сложностями - сбоями, нестыковками сторонних кодов и их конфликт с кодом трехмерного движка, невозможность затрачивать массу сил и времени на устранение сбоя и прекращение проектов, как следствие отсутствие вышедшей игры. Косвенно это позволяет будущим разработчикам давать оценку подбираемым для проекта движкам по этому показателю, делая некоторые выводы заранее. Однако остается то что платные игровые движки могут сами финансировать разработки некоторых игр, для привлечения внимания к своему информационному продукту, а так как игра это как видно процесс затратный то получается что среди платных игровых движков есть готовые крупные игры чаще чем у бесплатных. Однако большинство бесплатных движков имеют некоторые недостатки, которые требуют дополнительного неопределенного времени на их исследование, что может нарушать любые планы и сроки.