Взаимодействие двух контейнеров объектов

@just_one · Регистрация: 21.10.2015

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

Здравствуйте. Вопрос, наверное, уместнее задать на геймдеве, но всё же попробую здесь.
Есть два контейнера объектов (монстры и пули), количество элементов которых непрерывно изменяется в силу различных обстоятельств (пуля попадает в монстра и исчезает, у монстра заканчивается здоровье и он исчезает и т.п.). Само собой, удаление объектов происходит по произвольному индексу в зависимости от соответствующего игрового события.
Пробовал использовать вектора указателей, а удалять элемент с помощью swap с последним элементом, вызова для нового последнего delete и последующего pop_back. Всё работает, но сдаётся мне, что такое жонглирование динамической памятью не есть хорошо и работает медленно. Как лучше поступить в такой ситуации (довольно тривиальной, как мне кажется) - возможно, стоит использовать статические объекты и просто менять их статусы/координаты, используя один и тот же объект многократно?

@Mr.X · 15.12.2015, 10:02

Ну, можно иметь вектор монстров, из которого они никогда не удаляются, а только добавляются, если их не хватает, и два списка индексов этого вектора - один для живых, другой для мертвых. Если нужно ввести монстра в игру, то берем индекс из мертвых и перемещаем его в список живых. Если список индексов мертвых пуст, то добавляем в вектор элемент, а его индекс добавляем в список живых. Если нужно удалить монстра из игры, то переносим его индекс из списка живых в список мертвых.

@just_one · 15.12.2015, 10:14 **[ТС]**

Спасибо, а как быть с пулями? По аналогичному принципу? Их одновременно может быть довольно немного даже при максимальной скорострельности, они удаляются при столкновении или достижении края экрана, а летят очень быстро.

@Renji · 15.12.2015, 10:40

std::list и удаление по итератору чем не мило? Как раз будет константное время удаления/вставки в середину, с сохранением валидности ссылок на не удаленные элементы.

@just_one · 15.12.2015, 10:48 **[ТС]**

Да всё в порядке с std::list, меня изначально смущает сам факт постоянного выделения/очистки памяти вне зависимости от выбора конкретного контейнера. Класс игрового объекта у меня не очень большой пока, но будет расширяться, и я не могу спрогнозировать, как упадёт производительность от постоянных new/delete, потому и спрашиваю про удачное в такой ситуации решение.

Ilot · 15.12.2015, 10:59

Для монстров следует использовать, что-то вроде вектора т.к. как скорость появления/исчезновения монстров не высока.
А вот для пуль придется писать свой класс, управляющий всеми пулями в сцене. Так как они создаются и уничтожаются очень быстро, то полагаю следует создать что-то похожее на пул.

@Renji · 15.12.2015, 11:11

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

Класс игрового объекта у меня не очень большой пока, но будет расширяться, и я не могу спрогнозировать, как упадёт производительность от постоянных new/delete, потому и спрашиваю про удачное в такой ситуации решение.

На сколько я представляю себе алгоритмы работы менеджера памяти, ему, в плане времени работы, практически пофиг на размер вашего класса. Вот если нужно изменить размер уже выделенного блока (чем постоянно занимается вектор), тут уже возможны тормоза.

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

Так как они создаются и уничтожаются очень быстро, то полагаю следует создать что-то похожее на пул.

Создаются они наверняка самое большее по одной штучке за миллион тактов (миллиард тактов в секунду делить на тысячу пуль). На фоне этого миллиона, ТС даже не заметит времени ушедшего на создание.

@Mr.X · 15.12.2015, 11:29

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

Спасибо, а как быть с пулями? По аналогичному принципу? Их одновременно может быть довольно немного даже при максимальной скорострельности, они удаляются при столкновении или достижении края экрана, а летят очень быстро.

Ну да, это позволит вообще избежать выделения памяти в процессе игры. Перед началом игры нужно создать векторы монстров и пуль достаточного размера.

Croessmah · 15.12.2015, 11:43

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

вызова для нового последнего delete и последующего pop_back. Всё работает, но сдаётся мне, что такое жонглирование динамической памятью не есть хорошо и работает медленно.

пул объектов пробовали?

@Renji · 15.12.2015, 11:56

Сообщение от Mr.X

Ну да, это позволит вообще избежать выделения памяти в процессе игры. Перед началом игры нужно создать векторы монстров и пуль достаточного размера.

В древнем XCOM так и сделали. В результате на высоких уровнях сложности начинал пропадать шмот, потому что превышен лимит на максимальное число предметов на карте. А игрок должен был решать увлекательную головоломку "как одеть десяток солдат, если можно взять только 80 предметов на всю команду?".

@just_one · 15.12.2015, 11:59 **[ТС]**

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

пул объектов пробовали?

С паттернами проектирования пока не знаком, похоже, пора начинать ))

Сообщение от Mr.X

Перед началом игры нужно создать векторы монстров и пуль достаточного размера.

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

@Mr.X · 15.12.2015, 12:17

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

В древнем XCOM так и сделали. В результате на высоких уровнях сложности начинал пропадать шмот, потому что превышен лимит на максимальное число предметов на карте. А игрок должен был решать увлекательную головоломку "как одеть десяток солдат, если можно взять только 80 предметов на всю команду?".

А у них не была предусмотрена возможность добавлять во время игры? Странное решение. И какой смысл запрещать это?

@Renji · 15.12.2015, 13:04

Сообщение от Mr.X

А у них не была предусмотрена возможность добавлять во время игры? Странное решение. И какой смысл запрещать это?

Во время игры можно было подбирать вещи с трупов, но вещи типа аптечки из них не выпадали никогда. Ограничение "80 предметов на всю команду", равно как и лимит на общее количество предметов на карте, были продиктованы именно экономией памяти. Игра под Дос, гигабайт оперативки это что-то из разряда фантастики. Хотя, зачем делать на столько жесткие лимиты - действительно, загадка.

@just_one · 15.12.2015, 13:12 **[ТС]**

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

Хотя, зачем делать на столько жесткие лимиты - действительно, загадка.

Гораздо большей загадкой является хранение характеристик оперативника в переменной char, что рано или поздно обездвиживало элитных бойцов при обнулении числа ОД.

Croessmah · 15.12.2015, 13:17

Не по теме:

Воспоминания из прошлого:
Помнится игрушка была "Mission: Humanity" (1С почему-то назвали её "Восьмая цивилизация").
Там была такая штука, что нельзя было на одной планете более 80-ти юнитов держать.
И был там баг. Достигаешь максимум юнитов. Сажаешь юнитов по максимуму в десантный корабль, приказываешь ему взлететь и хоба - на планете уже нет 80-ти юнитов. Строим опять до максимума, сажаем транспорт на планету и хоп - транспорт пуст, можно в него сажать еще юнитов. Сажаем туда еще юнитов, поднимаем транспорт в воздух и так по кругу, пока не надоест. Самое интересное, что юниты из транспорта не пропадают, просто войска не отображаются, если превышен лимит юнитов на планете. Можно этот транспорт послать на другую планету и там уже высадить всех :D

Новые блоги и статьи Все статьи Все блоги /
SDL3 для Web (WebAssembly): Основы отладки веб-приложений на SDL3 по USB и Wi-Fi, запущенных в браузере мобильных устройств 8Observer8 07.02.2026 Содержание блога Браузер Chrome имеет средства для отладки мобильных веб-приложений по USB. В этой пошаговой инструкции ограничимся работой с консолью. Вывод в консоль - это часть процесса. . .	SDL3 для Web (WebAssembly): Обработчик клика мыши в браузере ПК и касания экрана в браузере на мобильном устройстве 8Observer8 02.02.2026 Содержание блога Для начала пошагово создадим рабочий пример для подготовки к экспериментам в браузере ПК и в браузере мобильного устройства. Потом напишем обработчик клика мыши и обработчик. . .	Философия технологии iceja 01.02.2026 На мой взгляд у человека в технических проектах остается роль генерального директора. Все остальное нейронки делают уже лучше человека. Они не могут нести предпринимательские риски, не могут. . .	SDL3 для Web (WebAssembly): Вывод текста со шрифтом TTF с помощью SDL3_ttf 8Observer8 01.02.2026 Содержание блога В этой пошаговой инструкции создадим с нуля веб-приложение, которое выводит текст в окне браузера. Запустим на Android на локальном сервере. Загрузим Release на бесплатный. . .
SDL3 для Web (WebAssembly): Сборка C/C++ проекта из консоли 8Observer8 30.01.2026 Содержание блога Если вы откроете примеры для начинающих на официальном репозитории SDL3 в папке: examples, то вы увидите, что все примеры используют следующие четыре обязательные функции, а. . .	SDL3 для Web (WebAssembly): Установка Emscripten SDK (emsdk) и CMake для сборки C и C++ приложений в Wasm 8Observer8 30.01.2026 Содержание блога Для того чтобы скачать Emscripten SDK (emsdk) необходимо сначало скачать и уставить Git: Install for Windows. Следуйте стандартной процедуре установки Git через установщик. . . .	SDL3 для Android: Подключение Box2D v3, физика и отрисовка коллайдеров 8Observer8 29.01.2026 Содержание блога Box2D - это библиотека для 2D физики для анимаций и игр. С её помощью можно определять были ли коллизии между конкретными объектами. Версия v3 была полностью переписана на Си, в. . .	Инструменты COM: Сохранение данный из VARIANT в файл и загрузка из файла в VARIANT bedvit 28.01.2026 Сохранение базовых типов COM и массивов (одномерных или двухмерных) любой вложенности (деревья) в файл, с возможностью выбора алгоритмов сжатия и шифрования. Часть библиотеки BedvitCOM Использованы. . .

@just_one 0 / 0 / 0 Регистрация: 21.10.2015 Сообщений: 7

	Взаимодействие двух контейнеров объектов 15.12.2015, 09:36. Показов 1411. Ответов 14 Метки c++, memory, pointer, stl (Все метки) Здравствуйте. Вопрос, наверное, уместнее задать на геймдеве, но всё же попробую здесь. Есть два контейнера объектов (монстры и пули), количество элементов которых непрерывно изменяется в силу различных обстоятельств (пуля попадает в монстра и исчезает, у монстра заканчивается здоровье и он исчезает и т.п.). Само собой, удаление объектов происходит по произвольному индексу в зависимости от соответствующего игрового события. Пробовал использовать вектора указателей, а удалять элемент с помощью swap с последним элементом, вызова для нового последнего delete и последующего pop_back. Всё работает, но сдаётся мне, что такое жонглирование динамической памятью не есть хорошо и работает медленно. Как лучше поступить в такой ситуации (довольно тривиальной, как мне кажется) - возможно, стоит использовать статические объекты и просто менять их статусы/координаты, используя один и тот же объект многократно? 0

@Mr.X 3225 / 1752 / 436 Регистрация: 03.05.2010 Сообщений: 3,867
	15.12.2015, 10:02
	Сообщение было отмечено just_one как решение Решение Ну, можно иметь вектор монстров, из которого они никогда не удаляются, а только добавляются, если их не хватает, и два списка индексов этого вектора - один для живых, другой для мертвых. Если нужно ввести монстра в игру, то берем индекс из мертвых и перемещаем его в список живых. Если список индексов мертвых пуст, то добавляем в вектор элемент, а его индекс добавляем в список живых. Если нужно удалить монстра из игры, то переносим его индекс из списка живых в список мертвых. 1

@just_one 0 / 0 / 0 Регистрация: 21.10.2015 Сообщений: 7
	15.12.2015, 10:14 [ТС]
	Спасибо, а как быть с пулями? По аналогичному принципу? Их одновременно может быть довольно немного даже при максимальной скорострельности, они удаляются при столкновении или достижении края экрана, а летят очень быстро. 0

@Renji 2784 / 1937 / 570 Регистрация: 05.06.2014 Сообщений: 5,602
	15.12.2015, 10:40
	std::list и удаление по итератору чем не мило? Как раз будет константное время удаления/вставки в середину, с сохранением валидности ссылок на не удаленные элементы. 0

@just_one 0 / 0 / 0 Регистрация: 21.10.2015 Сообщений: 7
	15.12.2015, 10:48 [ТС]
	Да всё в порядке с std::list, меня изначально смущает сам факт постоянного выделения/очистки памяти вне зависимости от выбора конкретного контейнера. Класс игрового объекта у меня не очень большой пока, но будет расширяться, и я не могу спрогнозировать, как упадёт производительность от постоянных new/delete, потому и спрашиваю про удачное в такой ситуации решение. 0

Ilot $Эксперт по математике/физике$ 2223 / 1425 / 420 Регистрация: 16.05.2013 Сообщений: 3,642 Записей в блоге: 6
	15.12.2015, 10:59
	Для монстров следует использовать, что-то вроде вектора т.к. как скорость появления/исчезновения монстров не высока. А вот для пуль придется писать свой класс, управляющий всеми пулями в сцене. Так как они создаются и уничтожаются очень быстро, то полагаю следует создать что-то похожее на пул. 0

Croessmah
	15.12.2015, 13:17
	Не по теме: Воспоминания из прошлого: Помнится игрушка была "Mission: Humanity" (1С почему-то назвали её "Восьмая цивилизация"). Там была такая штука, что нельзя было на одной планете более 80-ти юнитов держать. И был там баг. Достигаешь максимум юнитов. Сажаешь юнитов по максимуму в десантный корабль, приказываешь ему взлететь и хоба - на планете уже нет 80-ти юнитов. Строим опять до максимума, сажаем транспорт на планету и хоп - транспорт пуст, можно в него сажать еще юнитов. Сажаем туда еще юнитов, поднимаем транспорт в воздух и так по кругу, пока не надоест. Самое интересное, что юниты из транспорта не пропадают, просто войска не отображаются, если превышен лимит юнитов на планете. Можно этот транспорт послать на другую планету и там уже высадить всех :D 0

Взаимодействие двух контейнеров объектов

Решение