ECS? На самом деле, я полагаю, что это не будет преждевременным, если так много думать о ориентированной на данные стороне проекта и оценивать различные повторы, потому что это может повлиять на ваш дизайн интерфейса , а последнее очень дорого менять в конце игра. Кроме того, ECS просто требует большой работы и обдумывания заранее, и я думаю, что стоит потратить часть этого времени, чтобы убедиться, что это не приведет к печальному падению производительности на уровне дизайна, учитывая то, как это будет в основе вашей работы. весь долбанный двигатель. Эта часть смотрит на меня:
unordered_map<string,[yada]>
Даже с небольшими оптимизациями строк у вас есть контейнер переменного размера (строки) внутри другого контейнера переменного размера (unordered_maps). На самом деле, небольшая строковая оптимизация может быть настолько же вредной, насколько и полезной в этом случае, если ваша таблица очень разреженная, поскольку небольшая строковая оптимизация подразумевает, что каждый неиспользуемый индекс хеш-таблицы будет по-прежнему использовать больше памяти для оптимизации SS ( sizeof(string)будет намного больше) до такой степени, что общие накладные расходы памяти вашей хеш-таблицы могут стоить больше, чем все, что вы храните в ней, особенно если это простой компонент, такой как компонент позиции, в дополнение к большим потерям кеша с огромным шагом получить от одной записи в хеш-таблице к следующей.
Я предполагаю, что строка является своего рода ключом, например, идентификатором компонента. Если это так, это уже делает вещи значительно дешевле:
unordered_map<int,[yada]>
... если вы хотите иметь возможность иметь удобные для пользователя имена, которые могут использовать сценарии, например, интернированные строки могут дать вам лучшее из обоих миров.
Тем не менее, если вы можете сопоставить строку с достаточно низким диапазоном плотно используемых индексов, то вы можете просто сделать это:
vector<[yada]> // the index and key become one and the same
Причина, по которой я не считаю это преждевременным, заключается в том, что, опять же, это может повлиять на ваш дизайн интерфейса. Смысл DOD не должен состоять в том, чтобы пытаться придумать наиболее эффективные представления данных, которые можно себе представить за один раз (как правило, это должно быть достигнуто многократно по мере необходимости), а в том, чтобы думать о них достаточно, чтобы разрабатывать интерфейсы на вершине, чтобы работать с этим. данные, которые оставляют вам достаточно места для профилирования и оптимизации без каскадных изменений дизайна.
В качестве наивного примера, программное обеспечение для обработки видео, которое связывает весь свой код с этим:
// Abstract pixel that could be concretely represented by
// RGB, BGR, RGBA, BGRA, 1-bit channels, 8-bit channels,
// 16-bit channels, 32-bit channels, grayscale, monochrome,
// etc. pixels.
class IPixel
{
public:
virtual ~IPixel() {}
...
};
Не удастся продвинуться далеко без потенциально эпического переписывания, так как идея абстрагирования на уровне одного пикселя уже чрезвычайно неэффективна ( vptrсама по себе часто будет стоить больше памяти, чем весь пиксель) по сравнению с абстрагированием на уровне изображения (который будет часто представляют миллионы пикселей). Поэтому заранее продумайте свои представления данных, чтобы вам не приходилось сталкиваться с таким кошмарным сценарием, а в идеале - больше, но здесь я думаю, что стоит подумать об этом заранее, поскольку вы не хотите создавать сложный двигатель вокруг вашей ECS и обнаружить, что сама ECS является узким местом в пути, которые требуют от вас что-то изменить на уровне проектирования.
Что касается ошибок кэша ECS, то, по моему мнению, разработчики часто слишком стараются сделать их ECS-дружественными к кешу. Он начинает приносить слишком мало денег, чтобы попытаться получить доступ ко всем вашим компонентам совершенно непрерывным образом, и часто подразумевает копирование и перетасовку данных повсюду. Обычно достаточно достаточно, скажем, просто использовать индексы компонентов радикальной сортировки до доступа к ним, чтобы вы обращались к ним таким образом, чтобы, по крайней мере, вы не загружали область памяти в строку кэша только для ее удаления, а затем загружали все снова и снова в одном цикле, чтобы получить доступ к другой части той же строки кэша. И ECS не должен обеспечивать удивительную эффективность по всем направлениям. Это не так, как система ввода извлекает из этого столько же, сколько физическая система или система рендеринга, поэтому я рекомендую стремиться к «хорошему». эффективность по всем направлениям и «отлично» только в тех местах, где это действительно нужно. Тем не менее, использованиеunordered_mapи stringздесь достаточно легко избежать.