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