Схема делегата обнаружения столкновения

Question

Эй, ребята! Мой физический движок работает довольно хорошо (спасибо за вопрос!), И я готов начать работу над еще более продвинутым мусором. В данном случае я пытаюсь настроить свой механизм коллизий, чтобы произвольный делегат мог получать уведомления о коллизиях. Позвольте мне настроить сценарий для вас:

Скажем, у нас есть объект A, объект B и объект C в физическом моделировании. Я хочу иметь возможность проинформировать делегата о коллизии между A и B, И проинформировать потенциально РАЗНОГО делегата о коллизии между A и C.

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

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

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

Answer 1

Я должен сказать, что немного странно, что два объекта могут иметь разных делегатов (при столкновении), и все же было бы плохо, если бы при столкновении сработали два одинаковых делегата. Мне кажется, что они оба должны стрелять все время или только один из них должен. Последовательность - вот что меня беспокоит. Объясняя, что это поможет еще немного.

Во-вторых, если вы используете наивную версию удержания делегата для каждого объекта и затем кондиционирования, активирующего его функциональность («если (! Какой-то логический элемент, указывающий, что этот делегат уже запущен) {сделать что-то}»), это можно решить с помощью очень маленькие накладные расходы. Это работает, но мне не нравится такой код.

Мое предложение (немного сложное, поэтому подумайте об этом, прежде чем работать над ним), это попытаться сфокусироваться на объекте менеджера, который прошел бы по всем делегатам, и вызвать два из них, которые имеют отношение к коллизии. Например, , A и B сталкиваются, и менеджер вызывается с ними в качестве параметров. Теперь вы можете циклически перебирать всех известных в системе делегатов (при условии, что их немного) и запускать тех, которые соответствуют "делегат == a.del или делегат == b.del". Это связано с большими накладными расходами, но если мы говорим о небольшом количестве делегатов, то это мало что изменит. С другой стороны, это позволит вам еще больше тратить свой механизм обнаружения столкновений в этой области в будущем (например, наличие более одного делегата на объект).