Различные игровые форматы карты (внутренний и наружный)
Используя Платформа Зенда и Доктрина , моя структура папок обычно похожа на это:
root
app
config (db config, routing config, misc config)
doctrine (fixtures, migrations, generated stuff, etc)
lib
logs
models (doctrine models)
modules (zend mvc modules)
bootstrap.php
docs (db diagrams, specs, coding standards, various docs)
pub (web root)
tests
tools (console tools, i.e. doctrine-cli)
vendor (zend and doctrine libraries, preferably as svn-externals)
4 ответа
This article introduces the use of quadtrees for terrain storage, which I believe are commonly used. Basically, they're like the BSP trees used in Quake, but better suited for storing heightmaps.
Вне помещения обычно используются карты высот местности. По сути, это гигантская сетка с информацией о высоте каждой ячейки. Также каждая ячейка содержит информацию об используемых текстурах.
Вы можете создавать эти карты, используя генераторы ландшафта на основе фракталов и шума Перлина
Я думаю, он ищет способ сохранять и загружать карты из файла, а не способ хранить их в памяти. (Или, может быть, я неправильно понял?)
ИМХО, есть четыре пути решения этой проблемы.
Экстремум: Создайте свой собственный формат
Вы можете создать свой собственный формат файла. Самый простой способ - выбрать широко используемый и расширяемый формат файла (например, XML), поскольку вы найдете множество парсеров, свободно доступных в Интернете. (За простым, но полным анализатором XML обратитесь на application-mat Mathematics.net.)
Проблема в том, что вам придется создать свой собственный редактор карт. Без сомнения, это «лучший» способ, если вы хотите узнать массу вещей и иметь чистый формат. Но вы также должны учитывать время, которое вам потребуется потратить на создание всех этих инструментов.
Экстремум: используйте формат другой игры / инструмента.
Вы также можете использовать формат файла существующей игры , и разработайте его в стиле ретро (или просто используйте формат игры с открытым исходным кодом, такой как Quake).
Проблема в том, что вы унаследуете ограничения выбранного вами формата. Но время разработки значительно сокращается, вам нужно только найти способ загрузки этих форматов.
Компромисс 1: Отделение геометрии от метаданных
Вы также можете выбрать нужные вам вещи из существующего формата и для хранения ваших метаданных в другом месте.
Например, вы можете создать формат, который будет выглядеть так:
<?xml version="1.0" encoding="UTF-8"?>
<map>
<name>MyMap</map>
<geometry type="bsp">my_map.bsp</geometry>
<spawn id="1">
<monster type="1" spread="5" />
</spawn>
</map>
Здесь у вас есть лучшее из двух миров. Вы можете создать свою карту в любом редакторе .bsp (3DSmax, Blender) и сохранить нужные данные в XML.
Середина 2: адаптировать другие форматы к вашим потребностям
Идея состоит в том, чтобы просто создать свой собственный унифицированный форматировать и создавать экспортеры для широко используемых редакторов. Вы можете, например, написать сценарии экспортера для Blender, которые будут генерировать файлы для вашего собственного формата.
Еще несколько советов, если я неправильно понял, и вы искали память для хранения ваших карт. (В случае, если просто спросите, и я дополню свой ответ :))
- Ищите Quad / Octrees. Это способ разрезать вашу карту на квадраты / кубики. После этого вы сможете реализовать быстрый поиск в этих структурах и, таким образом, отображать только видимые части карт, LOD и т. Д.
- Ускорьте загрузку карты, выбрав формат файла, близкий к макету памяти вашей карты.
- 12103] Объедините несколько парадигм хранения карт. Карты высот хороши для больших открытых карт, но очень ограничены (особенно для многоуровневых карт). Вы можете использовать карты высот для пола, а камни / цветы хранить в виде четырехугольников и т. Д.
There are many ways to implement game worlds maps.
Anyway, for huge maps check out Spatial indexes, and specifically the Quadtrees.