Статья о краткой истории, и описывает в том числе и новейшую. Добавление в движки поддержки VR — один из последних на текущий момент процессов в их развитии, при этом до сих пор не завершившийся и спорный (многие разработчики могут поделиться описанием проблем с запуском на различных мобильных VR-устройствах, особенно для UE4).
Не упомянуть этот процесс было бы достаточно странно, а упомянув — стоило и немного описать сложности в нем, чтобы хотя бы кратко дать понимание ситуации далеким от этой темы.
Тема статьи — краткая история, и хотелось в первую очередь описать менее известные (и потенциально более интересные аудитории) исторические вопросы — начало формирования игровых движков и ответвления в мобильные/браузерные и VR игры.
Ситуация с клиентскими движками в недавней истории, Unreal Engine 3-4/CryEngine/Unity/Gamebryo и «чем один лучше другого и для чего», как и будущее движков, более известные вопросы и достойны отдельной статьи :)
10 лет назад — да, «единый текст» нередко применялся. Но уже тогда в крупных компаниях (на Западе, в основном; хотя, к примеру, документация Аллодов уже была на MoinMoin — 2006 год) распространялся вики-подход и разбиение диздоков на компоненты… а за 10 лет почти все перешли на новый формат. Кроме статей в интернете о диздоках ;)
Возможно, через еще 10 лет парадигма снова изменится, хотя пока очевидных предпосылок еще нет.
В этом нет упрека — можно делать и такие диздоки (наследие старой школы документации геймдизайна на Западе — которой уже почти нет), просто последующий опыт работы в крупной компании может оказаться шокирующим.
Если же у вас нет иллюзий, это отлично! ;) Диздок — дизайн-документ — просто вариант оформления геймдизайна (всей игры или ее части) в проектной документации. И всё. Остальное — уже зависит от проекта и работодателя ;)
Примеры, как сделать это «оформление» более структурированным и удобочитаемым для коллег — это уже тема отдельных статей и курсов.
Для небольших команд Google Docs в принципе применим — в статье просто речь о крупных компаниях. Для них же поднимаются такие вопросы:
— интеграция с системами отслеживажния ошибок/управления проектом/… принятыми в компании. К примеру, драму насчет решения Atlassian про интеграцию с Google Docs можно почитать тут — answers.atlassian.com/questions/140987/linking-google-docs-documents-to-jira-issue-in-jira-ondemand — и в целом, вики-решения интегрировать как правило намного проще.
— необходимость держать документы в внутренней офисной сети (соображения безопасности, логгирования всего доступа)
— уже упомянутые перекрёстные ссылки на внутренние ресурсы
— на вики-движках намного проще обеспечить распределение прав доступа по компании — соответствующие доступы по отдельным проектам/командам, новые сотрудники и увольнения,… всё решается проще.
И, наконец, в крупных компаниях редко бывают реально коллаборативные дизайн-документы — обычно только один гейм-дизайнер (ответственный за направление либо исполнитель задачи) пишет документ, а коллеги только комментируют. Подход «дизайним сразу всей командой» очень редок.
Кстати, Google Docs нередко применяются и параллельно вики-движку — как раз для общего редактирования текста, к примеру, сбора отзывов после плейтеста. После чего «выжимка» из общего набора мнений перекладывается на вики.
Не упомянуть этот процесс было бы достаточно странно, а упомянув — стоило и немного описать сложности в нем, чтобы хотя бы кратко дать понимание ситуации далеким от этой темы.
Ситуация с клиентскими движками в недавней истории, Unreal Engine 3-4/CryEngine/Unity/Gamebryo и «чем один лучше другого и для чего», как и будущее движков, более известные вопросы и достойны отдельной статьи :)
Возможно, через еще 10 лет парадигма снова изменится, хотя пока очевидных предпосылок еще нет.
К сожалению, эволюция этих иллюзий была весьма печальна, к примеру
www.gamedev.ru/projects/forum/?id=8221 (2005 год)
gmakers.ru/index.php?topic=54.0 (2008)
smartresponder.ru/web_version.php?Action=ShowArchiveMessage&q=001Xja002EXc00ip0N3cb53b0c (2014)
И даже в 2014… «Детальное описание игры… Под детальным описание подразумевается, как и общий концепт так и объектная модель мира т.е опись каждого игрового объекта с его характеристикой.»
В этом нет упрека — можно делать и такие диздоки (наследие старой школы документации геймдизайна на Западе — которой уже почти нет), просто последующий опыт работы в крупной компании может оказаться шокирующим.
Если же у вас нет иллюзий, это отлично! ;) Диздок — дизайн-документ — просто вариант оформления геймдизайна (всей игры или ее части) в проектной документации. И всё. Остальное — уже зависит от проекта и работодателя ;)
Примеры, как сделать это «оформление» более структурированным и удобочитаемым для коллег — это уже тема отдельных статей и курсов.
— интеграция с системами отслеживажния ошибок/управления проектом/… принятыми в компании. К примеру, драму насчет решения Atlassian про интеграцию с Google Docs можно почитать тут — answers.atlassian.com/questions/140987/linking-google-docs-documents-to-jira-issue-in-jira-ondemand — и в целом, вики-решения интегрировать как правило намного проще.
— необходимость держать документы в внутренней офисной сети (соображения безопасности, логгирования всего доступа)
— уже упомянутые перекрёстные ссылки на внутренние ресурсы
— на вики-движках намного проще обеспечить распределение прав доступа по компании — соответствующие доступы по отдельным проектам/командам, новые сотрудники и увольнения,… всё решается проще.
И, наконец, в крупных компаниях редко бывают реально коллаборативные дизайн-документы — обычно только один гейм-дизайнер (ответственный за направление либо исполнитель задачи) пишет документ, а коллеги только комментируют. Подход «дизайним сразу всей командой» очень редок.
Кстати, Google Docs нередко применяются и параллельно вики-движку — как раз для общего редактирования текста, к примеру, сбора отзывов после плейтеста. После чего «выжимка» из общего набора мнений перекладывается на вики.