Вторник, 24.10.2017, 10:50

Сайт Infinitation Studio

Меню сайта
Сегодня наш сайт посетили:
Календарь
«  Апрель 2013  »
ПнВтСрЧтПтСбВс
1234567
891011121314
15161718192021
22232425262728
2930
Главная » 2013 » Апрель » 12 » Каким должен был стать Progress Engine 0
10:41
Каким должен был стать Progress Engine 0
В 2007 году IS был анонсирован движок, получивший название Progress Engine 0. Одной из его ключевых фишек должна была стать модульная система, позволявшая в любой момент заменить используемую движком физику, добавить\удалить какую-либо из используемых библиотек рендеринга, звука, и т.д.

Все это, разумеется, должно было работать стабильно. Однако, учитывая что для движка были запланированы такие библиотеки рендеринга как Direct3D 6, 7, 8, и даже Software, хотя основными должны были стать Direct3D 10 и 9, а в дальнейшем мог прибавиться мифический тогда Direct3D 11, то проблемой становилась разработка игр под данный движок. И не только для разработчика - даже у более-менее технически продвинутого обывателя в голове не укладывалось, как это так может быть столько разных рендереров у одного движка, и под каждым игра должна выглядеть не хуже чем под другими.

На самом деле, говоря о мультирендере, стоит вспомнить, что одни рендеры не поддерживали, скажем, разрешение текстур больше 256х256 пикселов, а о предельно возможной детализации полигональных моделей говорить и вовсе не приходится. Так, Direct3D 8 не смог бы отрисовать модель с наложенной на нее текстуру имеющую разрешение выше 1024х1024, таковы были технические ограничения данного графического API. Текстуру большего размера он автоматически ужал бы и только тогда она попала бы в видеопамять.

Рендер-библиотеки с Direct3D меньших версий или вообще Software явно имели проблемы с поддержкой шейдеров, коих там попросту не было. Да и размеры текстур и максимальное количество вершин на модель там были еще меньше. Из всего этого следовало выкручиваться, да так чтобы и там и там игра, разработанная на движке смотрелась, по крайней мере, достойно.

Тогда пришла такая идея - не использовать один и тот же игровой контент для всех рендереров, а разработать под каждый рендер свою сборку контента, и при смене библиотеки просто подгружать все ресурсы игры заново. Но тут могла возникнуть проблема иного толка - общий объем разработанной на PE игры должен был неплохо так разрастись ради поддержки различных графических API. Ради уменьшения объема игры на жестком диске и увеличения ее производительности придумывались многочисленные фейки - как автоматическая сборка текстур из отдельных элементов, так и множество других. Была и такая идея - заменять далеко расположенный от игрока элемент окружения, либо персонаж спрайт. Выглядеть такой персонаж или элемент окружения должен был подобно монстру из первого Doom - плоским и не особенно интересным.

Особенно полезными все эти техники оптимизации должны были быть в самом масштабном проекте IS - Расколе. Там предполагалось создать исполинские локации, представляющие собой города, леса, различную местность. Поначалу предполагалось, что все эти локации будут одним целым миром, но впоследствии от этой идеи решено было отказаться в пользу технологий потоковой подгрузки контента для создания иллюзии нескончаемого мира. Кроме того, Раскол должен был стать игрой с поддержкой технологии Realtime RayTracing, честно считающей освещение в игре в реальном времени.

Со временем, а именно - после прогона нескольких внутренних демок движка, впрочем, стало понятно, что данная игра не сможет работать с включенной технологией освещения RT на заявленном качестве (Direct3D 10 со включенной тесселяцией и прочими плюшками), а кроме того сказались определенные изменения в сюжетной линии игры, потребовавшие кардинально переделать весь созданный к тому моменту контент игры.
Просмотров: 328 | Добавил: admin | Рейтинг: 0.0/0
Всего комментариев: 0
Добавлять комментарии могут только зарегистрированные пользователи.
[ Регистрация | Вход ]