Working through Jeremy Gibson Bond's excellent "Introduction to Game Design, Prototyping, and Development (Third Edition)".
Chapter 20, Variable and Components, gives a useful overview of Unity GameObjects and their components.
It also enumerates several of the bizarre gotchas in Unity, including:
The constants in the Color class (like Color.red) don't follow the usual capitalization convention for constants (SCREAMING_SNAKE_CASE).
"Mesh Colliders can only collide with other Mesh Colliders if both of them have Convex set to true."
"For the position of a Collider component to move with its GameObject, the GameObject must have a RigidBody. Otherwise ... the Collider will not move ...the GameObject will appear to move across the screen, but ... the location of the Collider component will not be updated, and therefore the physical presence of the GameObject will remain in the same location."
The Inspector changes the spacing and capitalization of class and variable names when it displays them, so (e.g.) damageState is displayed as Damage State.
This reminds me of heavy historical wargames that have all kinds of special rules like, "You can have up to three armor units in a city hex, except for hex 2334, which is limited to two armor units until the June 1943 turn (when, historically, the sewage plant exploded)."
#GameDev #unity #unity3d #wargames #inelegant #HistoricalReasons
@LouisIngenthron I wasn't aware of static GameObjects.
Would it be accurate to say, for this first two of Bond's statements, "Whether this is true depends on whether the objects in question are static"?
It just all seems like such a bottomless morass!
@peterdrake Take a look at the bottom of this doc page. It's got a table that shows, in depth, under which circumstances colliders will interact:
https://docs.unity3d.com/Manual/CollidersOverview.html
For MeshColliders, they have to be convex to work with Rigidbodies, so the only config they really tend to work in without being convex is when they're static (like a terrain).
@LouisIngenthron Terrifying. The matrices aren't even triangular, so one can't just remember "category
A collides with anything in category A or higher".
How is one supposed to internalize this? When I run into a weird edge case in (say) Python, I can often resolve it by slightly adjusting my mental model (e.g., "the system MAY reuse objects for integer literals, but isn't required to do so") and/or adopting a simple policy to avoid the issue ("never use 'is' to compare ints"). Here it feels like there's always one more special situational exception to memorize.
Is it just me?
@peterdrake Well, most of those boxes are edge cases to begin with. Really, in Unity, there are only three configs you'll be using regularly for physics collision:
[A] static colliders (houses, terrain, etc)
[B] regular Rigidbodies (regular physics objects, i.e: books, crates, balls, etc.),
[C] kinematic Rigidbodies (physics objects driven by script, i.e.: the player or anything the player holds, some vehicles, objects with agency, etc.)
All three of those types will collide with each other.
Then, for colliders, best practice is to use MeshColliders as infrequently as possible. They're much less performant than the built-in colliders. You can use 10 BoxColliders to approximate a mesh and get better performance than a mesh collider. If you absolutely must use a mesh collider, there are two configs to use:
[A] convex on a rigidbody, for colliders that need to move or interact with physics
[B] static non-rigidbody, for (usually big) stuff that doesn't move. Can be convex (better performance) but doesn't have to be. This is the only config non-convex meshcolliders should ever be used in (terrain is the obvious example)
@peterdrake Some of these are incorrect...
"Mesh Colliders can only collide with other Mesh Colliders if both of them have Convex set to true."
This isn't actually true. Convex mesh colliders can collide with static non-convex mesh colliders.
"For the position of a Collider component to move with its GameObject, the GameObject must have a RigidBody. Otherwise ... the Collider will not move ...the GameObject will appear to move across the screen, but ... the location of the Collider component will not be updated, and therefore the physical presence of the GameObject will remain in the same location." This description is only true for static GameObjects. Non-static colliders move just fine with their parent (although it's still a good idea to put them on a kinematic rigidbody).
"The constants in the Color class (like Color.red) don't follow the usual capitalization convention for constants (SCREAMING_SNAKE_CASE)." This one is correct, but worth noting it also applies to many of the math constants, like Vector2.one.