Diversifying collision groups

Questions
#1

I’m out of collision groups because of the limit (16) and I’m out of ideas how I can efficiently separate different collisions.

It was convenient at the beginning to use player-ground, mob-ground, I’ve added also fov group to check if something is in field of view, then another group to check if in attack range, another groups for different elements like fire and water, separate for Bushes, separate for one way platforms, etc. It was convenient, to check for only collision with a proper group and instantly gave information about a character of the group and appropriately reacting to this collision just in trigger response message. When I reached a limit, I started to minimize it and use default “greetings” message exchange telling each object of which type this collision should be and then in response to that message - react, but I’m not very comfortable with it :confused:
To not duplicate, there is this answer by @ross.grams: The maximum group count has been reached (16), which I followed for half of year, but now I do think about something like context-based attacks and I still think about adding something like groups to indicate, where the enemy is and of what type is it

How do you cope with that?

#2

You could use some kind of lookup table maybe? If the collision group is “element” and you want sub groups such as “fire”, “water” etc you could have a naming scheme on the collision components and look that up when detecting a collision. Something like this (untested):

function on_message(self, message_id, message, sender)
	if message_id == hash("collision_response") then
		if message.other_group == hash("element") then
			local other_url = msg.url(message.other_id)
			if other_url.fragment == hash("fire") then
				print("Ouch, that's damn hot!")
			end
		end
	end
end

Or register collision component ids in some kind of lookup table with additional type data?

3 Likes
#3

I like that idea with naming - this is instant information about an object which I collided - instead of sending a message to this and know the type after a message back… two redundant messages each collision. Thanks, @britzl! Also the idea with lookup table is good when the naming convention would fail :smiley:

1 Like