We want to be more flexible assigning colliders and meshes to game items without breaking backwards compatibility to Visual Pinball.
Common use cases are:
- A flipper needs a custom mesh, i.e. the collision is handled by a invisible flipper, but what's rendered is a primitive.
- A ramp needs a custom mesh. Like the first example, the ramp is modeled as a primitive, but collides with an invisible ramp (for performance reasons)
- A rubber uses one (or more) primitive colliders, i.e. the built-in rubber is rendered, but the collision is handled by an invisible primitive. Reason is to fine-tune physics depending on which part of the rubber is hit, and performance too (rubbers are relatively expensive).
The goal for VPE here is to recognize the relation between the game item (the logical entity), its mesh (how it's rendered) and its colliders (how it behaves in the physics world).
The advantage of doing that is that the author doesn't have to juggle with different objects and names for the same logical thing. If a rubber needs another collider, it can just be created, assigned to the game item, and nothing else needs to be changed.
Authoring
We currently have Authoring Components, which are Unity components that represent game items. Apart from being the logical entity for the game items, they also generate the built-in meshes and colliders.
For example, the FlipperAuthoring component will (re-)generate the flipper mesh based on the flipper's parameters (base radius, end radius, length, rubber parameters, etc). Also, the collider will be based on the same parameters.
The idea is to separate these three reponsibilities. To pick up the previous example, the FlipperAuthoring component would only handle the game logic, i.e. provide the API and trigger events. The first new component would be the FlipperMeshAuthoring component, which is solely responsible for generating the built-in mesh. And finally, the FlipperColliderAuthoring component would handle collisions.
This gives us more flexibility. If no mesh generation is needed, because a custom mesh is used, there would just be no FlipperMeshAuthoring at all. If the built-in mesh is used, like the rubber example above, but the collider was a primitive, we'd use a PrimitiveColliderAuthoring component for the rubber. You'd be able to mix and match as you like.
Import
Visual Pinball doesn't have this flexibility (yet?), so we would fall back to naming conventions. A game item name would have three components, separated by underscores:
- The name
- An optional suffix to indicate whether it's a collider or a mesh
- Another optional suffix to name the collider or mesh
For the flipper example, you would create a LeftFlipper flipper item, which acts as your flipper collider. If you create a LeftFlipper_Mesh game item, it will act as the flipper's mesh when loaded into VPE. Typically you'd choose to use a primitive for that, but nothing would prevent you to use a wall if you prefer your flipper to look like a wall.
For the rubber example, you would create a let's say LeftSlingShot rubber item for the mesh. Then, if you want to have two different collider meshes, let's say one for the rubber around the posts and another for in between posts, you'd create a LeftSlingShot_Collider_Hard and LeftSlingShot_Collider_Soft primitive. VPE would then use the colliders of these primitives for the LeftSlingShot rubber item.
You've noticed that in the first example, LeftFlipper acts as collider while in the second example, LeftSlingShot acts as mesh (both act as game items as well, obviously). So how to distinguish?
The principle is overrides. Using none of the naming suffixes will create all three components on the same object (game logic, mesh and collider). Using a suffix will replace the standard component with the suffixed one.
In other words, suffixing a game item with Collider will create no game item in VPE, but assign its built-in collider to the game item with the same name. Equally, suffixing a game item with Mesh will create no game item but assign its mesh to the game item with the same name.
We want to be more flexible assigning colliders and meshes to game items without breaking backwards compatibility to Visual Pinball.
Common use cases are:
The goal for VPE here is to recognize the relation between the game item (the logical entity), its mesh (how it's rendered) and its colliders (how it behaves in the physics world).
The advantage of doing that is that the author doesn't have to juggle with different objects and names for the same logical thing. If a rubber needs another collider, it can just be created, assigned to the game item, and nothing else needs to be changed.
Authoring
We currently have Authoring Components, which are Unity components that represent game items. Apart from being the logical entity for the game items, they also generate the built-in meshes and colliders.
For example, the
FlipperAuthoringcomponent will (re-)generate the flipper mesh based on the flipper's parameters (base radius, end radius, length, rubber parameters, etc). Also, the collider will be based on the same parameters.The idea is to separate these three reponsibilities. To pick up the previous example, the
FlipperAuthoringcomponent would only handle the game logic, i.e. provide the API and trigger events. The first new component would be theFlipperMeshAuthoringcomponent, which is solely responsible for generating the built-in mesh. And finally, theFlipperColliderAuthoringcomponent would handle collisions.This gives us more flexibility. If no mesh generation is needed, because a custom mesh is used, there would just be no
FlipperMeshAuthoringat all. If the built-in mesh is used, like the rubber example above, but the collider was a primitive, we'd use aPrimitiveColliderAuthoringcomponent for the rubber. You'd be able to mix and match as you like.Import
Visual Pinball doesn't have this flexibility (yet?), so we would fall back to naming conventions. A game item name would have three components, separated by underscores:
For the flipper example, you would create a
LeftFlipperflipper item, which acts as your flipper collider. If you create aLeftFlipper_Meshgame item, it will act as the flipper's mesh when loaded into VPE. Typically you'd choose to use a primitive for that, but nothing would prevent you to use a wall if you prefer your flipper to look like a wall.For the rubber example, you would create a let's say
LeftSlingShotrubber item for the mesh. Then, if you want to have two different collider meshes, let's say one for the rubber around the posts and another for in between posts, you'd create aLeftSlingShot_Collider_HardandLeftSlingShot_Collider_Softprimitive. VPE would then use the colliders of these primitives for theLeftSlingShotrubber item.You've noticed that in the first example,
LeftFlipperacts as collider while in the second example,LeftSlingShotacts as mesh (both act as game items as well, obviously). So how to distinguish?The principle is overrides. Using none of the naming suffixes will create all three components on the same object (game logic, mesh and collider). Using a suffix will replace the standard component with the suffixed one.
In other words, suffixing a game item with
Colliderwill create no game item in VPE, but assign its built-in collider to the game item with the same name. Equally, suffixing a game item withMeshwill create no game item but assign its mesh to the game item with the same name.