Долгое Путешествие: Не так давно...

Мы немного поиграли с названием игры. Теперь она называется "Shquarkz: Meatrified!" и я нарисовал первую версию логотипа для нее. У меня появилось немного времени чтобы вкратце поведать историю разработки и показать пару скриншотов по теме.

Логотип Shquarkz: Meatrified!

В начале мы решили создать отдельные ячейки, заполненные астероидами, которые составлены из атомарных элементов, называемых блоками. Мы думали, что этого будет достаточно на первое время. Таким образом, мы создали три базовых класса: ячейку - это отдельная кубическая локация в пространстве, астероид - это шмат из более мелких элементов, и, блок - собственно, тот самый мелкий элемент. На практике данный процесс не был таким простым и мы провели некоторое время в написании, подгонке и отладке кода. Таким образом, мы получили некоторого рода геометрическую основу без графики, физики и звука.

После этого, мы начали разрабатывать алгоритмы генерации вселенной, и, так как нам было несовсем удобно наблюдать создаваемую вселенную в виде безразмерных массивов шестнадцатеричных величин в отладчике, нам понадобилась графика. Мы решили использовать графический движок OGRE, потому что с ним я уже работал ранее и имел некоторое представление о его устройстве и возможностях. Блоки были представлены трехмерными моделями, экспортированными из программ для трехмерного моделирования.


Простые 8-вершинные кубы в качестве блоков	Кубы с вмятинами в качестве блоков


Некоторые эксперименты на первых порах	Кости в роли костных блоков

      Как любая другая игра в стадии разработки, "Шкварки" меняются - мы добавляем новые элементы, подгоняем геймплей и дизайн игровых объектов чтобы получить более или менее завершенный образ на определенной стадии. Как сказал бы профессионал в разработке игр: "нельзя закончить игру, ее можно доделать до определенного момента". У нас постоянно появляется множество новых идей, мы их фильтруем и отсеиваем, а отобранные добавляем в игру. В любом случае, мы не планируем никаких стадий разработки и не используем никакой проектной документации, кроме комментариев в исходном коде. Не скажу, что это хорошо, но нас это устраивает. Каждый день мы пишем новый код, заменяем куски старого кода новым, более оптимизированным и быстрым. Мы ищем, изучаем и используем не совсем стандартные технологии, такие, как шустрые C++ контейнеры от Google, что выполняют предписанные им операции в 10-15 раз быстрее их аналогов из стандартной библиотеки. Не так давно мы получили прибавку в скорости при генерации и сохранении мира больше, чем в два раза, просто заменив стандартные контейнеры на карты от Google (около 7 секунд вместо 20 при максимальном размере астероида, который способен отображать OGRE при разумном FPS).

      Вернемся к истории разработки. Вся наша ячеистая геометрия является интегральной, то есть в ней мы не используем числа с плавающей точкой. Кроме этого, мы используем битовые массивы для хранения большинства необходимых данных. Блоку требуется 8 байт (одно 64-битное число) для сохранения всех его свойств: позиции (3 координат) и типа, и еще остается место для дополнительных флагов, которые могут быть использованы, например, для определения способа обработки блоков. На каждый астероид также выделяется 8 байт для всех его свойств, а это уже: 3 числа позиции, кватернион ориентации, тип биома и, опять же, дополнительные флаги. И мы как-то умудрились затолкать все это всего в 64 бита. 8-байтовые числа, что мы используем для представления данных блоков и астероидов, позволяют нам экономить память. Это ОЗУ, когда мы создаем объекты, считывая их из файла, или ПЗУ, когда мы выгружаем вселенную в файлы.

      Система геометрии и алгоритмы генерации мира работали достаточно быстро. Но графическая часть, что использовала отдельные блоки, не предоставляла нам достаточно высокой скорости и размера астероидов в процессе визуализации. Еще бы - движку приходилось каждый кадр обрабатывать десятки и сотни тысяч раздельных блоков, на каждый из которых тратится определенное время процессора. Можно легко посчитать, что в сплошном астероиде сферической формы с радиусом в 100 единиц, содержится более 4 миллионов отдельных блоков. OGRE, да и любой другой современный графический движок не потянет такое количество объектов при сносном количестве кадров в секунду. Кроме этого, такой астероид будет содержать более 48 миллионов треугольников, даже если каждый блок представить простейшим кубом.

      Ёд улучшил алгоритм генерации для определения тех блоков, которые лежат на поверхности, отключив невидимые. Такой шаг дал нам кое-какой прирост в количестве кадров в секунду, но этого было мало для осуществления грандиозных задуманных нами планов. Мы экспериментировали со статичной геометрией OGRE, со страничным менеджером ландшафтов, переделав его под трехмерные "страницы", но ничто не давало желаемых результатов. Тогда у меня в голове созрела неплохая мысль и я поспешил поделиться ею с Ёдом. Процедурная геометрия - вот решение. Пока Ёд возился с алгоритмами генерации, я проводил время в изучении тех мест Огра, в которые до того момента я не залазил, и которые, судя по всему, используются не очень часто. Я писал код для экспериментов, отрисовывавший сначала цветные кубики, потом сглаживаемые кубики (данный код был реально объемным). Собственно, мы получили объекты, которые вы можете увидеть чуть ниже.


Цветной кубик, представляет собой ничто иное, как сам себя	Простой сглаженный цветной куб, представляет собой отделенный блок, витающий в пространстве