Хранение объектов - что оптимальнее?

01.05.2012, 10:23. **Показов** 1414. **Ответов** 3

Студворк — интернет-сервис помощи студентам

Доброго времени суток, товарищи. Пишу простенькую РПГ. Имеется карта тайлов - массив вида map[W][H]. На уровне также есть ≈25 персонажей и ≈50 предметов.
Собственно, вопрос: какой вариант будет оптимальнее?
1). для персонажей и предметов также создать карты-массивы (либо завернуть их в массив map) - charMap[W][H] и itemMap[W][H];
2). использовать одномерные массивы/векторы, являющие собой список персонажей и предметов.
Первый способ выгоден, допустим, для поиска персонажа по его позиции: charMap[10][5] - и у нас уже есть указатель на него. Однако, чтобы быстро пробежаться по ВСЕМ персонажам - гораздо быстрее будет второй способ. Что посоветуете, господа? Выбрать что-то одно, комбинировать оба варианта или придумать третий?

@Algiz · 01.05.2012, 11:05

Я бы вообще список использовал.

01.05.2012, 12:58

Сообщение от Algiz

Я бы вообще список использовал.

Ну список, вроде как, помедленнее того же вектора будет в конкретном случае - поиск персонажа по определённой позиции. Но, в любом случае, вопрос в другом: использовать ли полноразмерную карту - двумерный массив (где, разумеется, заняты будут только те элементы, где на игровом поле расположен персонаж):

C++
1
enemy *enemyMap[WIDTH][HEIGHT]

... или пользоваться списками/векторами и т. п., в которых хранится только то, что есть в действительности, никаких пустых элементов, в отличие от предыдущего случая:

C++
1
std::vector<enemy> enemyList

@Algiz · 02.05.2012, 18:26

Список медленнее, если необходимо извлекать элемент по номеру(индексу), тогда доступ будет за линию, т.к. едементы в связной памяти. В векторе доступ по индексу за константу, т.к. элементы в последовательной. Но ты каждый раз при поиске элемента, по координатам будешь ПОСЛЕДОВАТЕЛЬНО пробегать ПО ВСЕМ элементам, по этому вектор и список будут работать с одинаковой скоростью, а добавление в список и удаление из него происходят гораздо быстрее чем в векторе.

Добавлено через 2 минуты
так же ты можешь иметь отдельно карту с указателям на элементы списка если в ячейки карты что-то есть или нулевым если там ничего нет. Получишь быстрый доступ обеими способами, но затраты по памяти возрастут.

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Реализация движения на Box2D v3 - трение и коллизии с повёрнутыми стенами 8Observer8 20.02.2026 Содержание блога Box2D позволяет легко создать главного героя, который не проходит сквозь стены и перемещается с заданным трением о препятствия, которые можно располагать под углом, как верхнее. . .	Конвертировать закладки radiotray-ng в m3u-плейлист damix 19.02.2026 Это можно сделать скриптом для PowerShell. Использование . \СonvertRadiotrayToM3U. ps1 <path_to_bookmarks. json> Рядом с файлом bookmarks. json появится файл bookmarks. m3u с результатом. # Check if. . .	Семь CDC на одном интерфейсе: 5 U[S]ARTов, 1 CAN и 1 SSI Eddy_Em 18.02.2026 Постепенно допиливаю свою "многоинтерфейсную плату". Выглядит вот так: https:/ / www. cyberforum. ru/ blog_attachment. php?attachmentid=11617&stc=1&d=1771445347 Основана на STM32F303RBT6. На борту пять. . .	Камера Toupcam IUA500KMA Eddy_Em 12.02.2026 Т. к. у всяких "хикроботов" слишком уж мелкий пиксель, для подсмотра в ESPriF они вообще плохо годятся: уже 14 величину можно рассмотреть еле-еле лишь на экспозициях под 3 секунды (а то и больше),. . .
И ясному Солнцу zbw 12.02.2026 И ясному Солнцу, и светлой Луне. В мире покоя нет и люди не могут жить в тишине. А жить им немного лет.	«Знание-Сила» zbw 12.02.2026 «Знание-Сила» «Время-Деньги» «Деньги -Пуля»	SDL3 для Web (WebAssembly): Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 12.02.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами и вызывать обработчики событий столкновения. . . .	SDL3 для Web (WebAssembly): Загрузка PNG с прозрачным фоном с помощью SDL_LoadPNG (без SDL3_image) 8Observer8 11.02.2026 Содержание блога Библиотека SDL3 содержит встроенные инструменты для базовой работы с изображениями - без использования библиотеки SDL3_image. Пошагово создадим проект для загрузки изображения. . .

kefir500

	Хранение объектов - что оптимальнее? 01.05.2012, 10:23. Показов 1414. Ответов 3 Метки нет (Все метки) Доброго времени суток, товарищи. Пишу простенькую РПГ. Имеется карта тайлов - массив вида map[W][H]. На уровне также есть ≈25 персонажей и ≈50 предметов. Собственно, вопрос: какой вариант будет оптимальнее? 1). для персонажей и предметов также создать карты-массивы (либо завернуть их в массив map) - charMap[W][H] и itemMap[W][H]; 2). использовать одномерные массивы/векторы, являющие собой список персонажей и предметов. Первый способ выгоден, допустим, для поиска персонажа по его позиции: charMap[10][5] - и у нас уже есть указатель на него. Однако, чтобы быстро пробежаться по ВСЕМ персонажам - гораздо быстрее будет второй способ. Что посоветуете, господа? Выбрать что-то одно, комбинировать оба варианта или придумать третий?

@Algiz 165 / 164 / 23 Регистрация: 23.02.2011 Сообщений: 347
	01.05.2012, 11:05
	Я бы вообще список использовал. 0

@Algiz 165 / 164 / 23 Регистрация: 23.02.2011 Сообщений: 347
	02.05.2012, 18:26
	Список медленнее, если необходимо извлекать элемент по номеру(индексу), тогда доступ будет за линию, т.к. едементы в связной памяти. В векторе доступ по индексу за константу, т.к. элементы в последовательной. Но ты каждый раз при поиске элемента, по координатам будешь ПОСЛЕДОВАТЕЛЬНО пробегать ПО ВСЕМ элементам, по этому вектор и список будут работать с одинаковой скоростью, а добавление в список и удаление из него происходят гораздо быстрее чем в векторе. Добавлено через 2 минуты так же ты можешь иметь отдельно карту с указателям на элементы списка если в ячейки карты что-то есть или нулевым если там ничего нет. Получишь быстрый доступ обеими способами, но затраты по памяти возрастут. 1