Hello
Iv'e notice that you can only define 200 collision categories in Z game 1.9.9
Is there anyway to have more? The game im working on already uses 60 of those. I think a nice new feature could be an increase of the number of cats.
More collision categories?
Moderator: Moderators
Re: More collision categories?
Hi jinxtengu,
two points:
1. I would recommend you to use the latest ZGE beta version 4.0.b (with 256 collision categories), because 1.9.9 is quite obsolete.
2. Is so huge amount of collision categories really necessary? Cannot, e.g., several models share the same category? Usually, the models which behave the same with respect to collisions with other models are put to the same category. Does your game with 60 different collision categories perform well?
two points:
1. I would recommend you to use the latest ZGE beta version 4.0.b (with 256 collision categories), because 1.9.9 is quite obsolete.
2. Is so huge amount of collision categories really necessary? Cannot, e.g., several models share the same category? Usually, the models which behave the same with respect to collisions with other models are put to the same category. Does your game with 60 different collision categories perform well?
Re: More collision categories?
I'll be upgrading to the latest version just as soon as i finish the project I'm working on.
The project that uses 60 categories seems to work well, although one or two stages run a little choppy and im working on optimizing those levels.
I think the reason they run choppy is just that they render alot of surfaces at once.
Using all 200 collision categories should i expect this to degrade performance?
You're probably right in that the game doesn't really need to use 60 categories, it was just a lazy way to solve a problem. The game contains doors, and each door uses a separate collision category to determine where they each lead to. I guess the doors could all use the same category and then check their current model status to provide the same result
btw; is it a good idea to have nested conditions in the collision event? for instance
on collision-->if current model==such and such==then==do whatever
?
Another thing, say someone was making a game where each level had a different player model and different creatures/objects,
also the game was quite long, say 300 levels.
Isn't it conceivable that such a game might need more than 250 collision categories?
or have i got the wrong idea about them?
The project that uses 60 categories seems to work well, although one or two stages run a little choppy and im working on optimizing those levels.
I think the reason they run choppy is just that they render alot of surfaces at once.
Using all 200 collision categories should i expect this to degrade performance?
You're probably right in that the game doesn't really need to use 60 categories, it was just a lazy way to solve a problem. The game contains doors, and each door uses a separate collision category to determine where they each lead to. I guess the doors could all use the same category and then check their current model status to provide the same result
btw; is it a good idea to have nested conditions in the collision event? for instance
on collision-->if current model==such and such==then==do whatever
?
Another thing, say someone was making a game where each level had a different player model and different creatures/objects,
also the game was quite long, say 300 levels.
Isn't it conceivable that such a game might need more than 250 collision categories?
or have i got the wrong idea about them?
Re: More collision categories?
It depends on complexity of collision callbacks, computer your game is running on, etc. Maybe, it will not be observable. In any case, it is recommended to reduce number of computations in one computation/rendering cycle.jinxtengu wrote:Using all 200 collision categories should i expect this to degrade performance?
Nested conditions are normal. They better readable if used in expressions.jinxtengu wrote:btw; is it a good idea to have nested conditions in the collision event? for instance
on collision-->if current model==such and such==then==do whatever
I would try to put each creature to the same category... and all environment obstacles (walls, etc.) to another category, player(s) to another category, etc. If the player model behaves to each creature in the same manner, you do not need to differentiate creatures by collision category. I do not remember version 1.9.9, but in newer ZGE versions you can use Model.CollidedWith property to obtain further information about the collided model instance; if you need to - e.g. each creature can have different life, damage, etc. stored as its local variables.jinxtengu wrote:Another thing, say someone was making a game where each level had a different player model and different creatures/objects,
also the game was quite long, say 300 levels. Isn't it conceivable that such a game might need more than 250 collision categories?
or have i got the wrong idea about them?
Re: More collision categories?
Thanks! I find this useful information.
Edit
----------------------------------------------------------------------------------------
I'm in the process of culling, and merging collision categories in my project.
Edit
----------------------------------------------------------------------------------------
I'm in the process of culling, and merging collision categories in my project.