Feedback Initial thoughts on GM from an experienced hobbyist

[Flab]

I have never had issues with events firing in both instances rather than just the once.
Even hypothetically I cannot think of any cases where it would be preferential.
Most of the time you are looking at collisions between different instances anyways so the event will only fire in the instance with the event.

Also, this would cause issues when parenting is used. All of a sudden, you would ether break your projects, or have the event firing in each instance, as opposed to firing just in one of the istances.

I also cannot think of any physics engines that only generate collisions for the one instance. Though, most of them actually use manifolds, but thats not really compatible with GM's instance model (What instance should get the manifold?).

The most important Issue is deciding on what instance should get the event.
If you have a bullet colliding with an enemy: your bullet now needs to know about every response an enemy can have to being hit by a bullet, because it could be recieving the event, and not the enemy,

As you can see, single events rather than events in each instances cause a few problems.

Having coded physics engines and collision detection stuff (quite a lot), I tend to disagree. I think you'd find in many physics engines that contacts/collision events are minimized (for good reason) and that in say, a typical impulse based rigidbody engine, a single "event" basically "weights" collision response for both objects (not entirely since you tend to have multiple force/impulse vectors to account for with the planar and friction directions possibly other constraints, etc). This is of course only about the physics, but it is a fair enough example. Apart from that, for instance, I've rarely (if ever) had to have multiple collision response events even for different kinds of objects. Normally it's down to like:
" if (objA.type < objB.type) coltypefunc[objA,objB]; else coltypefunc[objB,objA]; " Edit: Sorry that doesn't quite describe what I mean, rather just that you (can) only use one func for collision between the two object types.

Hey, I dunno. I can understand in some cases where it's preferable.

Here's an example of where duplicates causes degeneracy in GM:
Enemy can damage other enemy (even if temporarily) by touching it. If you have damage based on collision event, how many times will they damage each other? It's pretty easy to list more.

 

[GMWolf]

Having coded physics engines and collision detection stuff (quite a lot), I tend to disagree. I think you'd find in many physics engines that contacts/collision events are minimized (for good reason) and that in say, a typical impulse based rigidbody engine, a single "event" basically "weights" collision response for both objects (not entirely since you tend to have multiple force/impulse vectors to account for with the planar and friction directions possibly other constraints, etc). This is of course only about the physics, but it is a fair enough example. Apart from that, for instance, I've rarely (if ever) had to have multiple collision response events even for different kinds of objects. Normally it's down to like:
" if (objA.type < objB.type) coltypefunc[objA,objB]; else coltypefunc[objB,objA]; "

Hey, I dunno. I can understand in some cases where it's preferable.

You have to realize collision events are more than about physics.

It's also about game mechanics.

 

[Juju]

Thanks for your perspective Flab, this has been a good read.

I don't know about your specific experiences - and I wouldn't want to presume anything - but in the commercial work I've done, GM's performance has been a minor annoyance at its absolute worst. Most of the time, I can just forget about it. It's not the fastest engine but it gets the job done. For chumps like me, that's good enough : )

(Also thanks for the shout-out @DukeSoft!)

 

[Flab]

You have to realize collision events are more than about physics.

It's also about game mechanics.

I know perfectly well, but I've given some examples where duplicates can be broken, slower and how you don't necessarily need events for both objA vs objB. I'll leave it at that.

 

[rwkay]

Well unfortunately our hands are tied by backward compatibility at present and I am not breaking previous games because you consider it to be superfluous, we have to live within the system as Mark Overmars created. We have made many changes over the last few years and had to revert several because while the change was better it broke too many pre existing games for us to justify.

I doubt that any change will be made on how the current collision events will be processed (other than me looking at that issue with the object being the same type and getting 4 collisions, which I can see why but also it should be caught, so I will need to debug when awake).

We will take a look at allowing OBB collisions on rectangles (at some release in the future) though as having to go down the precise collision path is just not a good way of forcing the issue.

Russell

 

[Flab]

Well unfortunately our hands are tied by backward compatibility at present and I am not breaking previous games because you consider it to be superfluous, we have to live within the system as Mark Overmars created. We have made many changes over the last few years and had to revert several because while the change was better it broke too many pre existing games for us to justify.

I doubt that any change will be made on how the current collision events will be processed (other than me looking at that issue with the object being the same type and getting 4 collisions, which I can see why but also it should be caught, so I will need to debug when awake).

We will take a look at allowing OBB collisions on rectangles (at some release in the future) though as having to go down the precise collision path is just not a good way of forcing the issue.

Russell

The collision system most likely won't need much change to actually remove duplicate collisions and it wouldn't affect existing things if it's optional and not default. Basically, it would amount to removing duplicate collisions, where flagged, before events are generated.

Of course, I say most likely, since I can't actually imagine situations where it would particularly difficult or not feasible.

But thanks for the replies, I do get an idea of where this is going.

If you do get the collisions down to two, at least you can use if objA.id>objB.id return; to only have one response, preferably not in the collision events though, but yeah.

 

[DukeSoft]

How I hope for the day you drop BC and introduce more awesomeness

 

[GMWolf]

How I hope for the day you drop BC and introduce more awesomeness

BC?

 

[DukeSoft]

Backwards Compatibility