If you’re reading this, there probably aren’t very many posts yet. But don’t worry, you can be the first! Either create a new post or just reply to this one to say ‘hi’.
Ok, here are my thoughts on how this stuff should be refactored/recoded.
Combine CameraRayCaster and CursorAffordance
CameraRayCaster is a source of events triggered by user interaction with terrain and Gameobjects. CursorAffordance changes the cursor to indicate what will happen if the click on that locaton. Reasons to combine them include:
- they are only used on the main camera
- CursorAffordance is the only consumer of CameraRayCaster’s OnCursorLayerChange events
- cursor presentation is tightly coupled with the user reasoning about how to click on something.
Move RaycastHit interpretation and layer handling out of the consumer classes
The OnClickPriorityLayer and OnRightClick events have the same function signature (RaycastHit raycastHit, int layerHit). In both cases the consumer classes are responsible for translating a RayCastHit into actionable information
- Determining whether the hit was on an Enemy is duplicated between Player and Energy.
- Player calls PlayerMovement.Move (RaycastHit raycastHit, int layerHit), which must then extract a target move position.
All processing of the RayCastHit and layer handling should be moved to the combined CursorAffordance/CameraRayCaster class. This class should provide:
- an event that passes a Vector3 location when walkable terrain is clicked on, and
- an event that passes an Enemy when an enemy is clicked on
By doing this, we eliminate duplicate code and enable change without needing to evaluate impact all over the code base. For example, I’m unclear where Ben is going with move/attack interaction. Are we moving to LMB for movement, RMB for attacks? The issue will be confined to the combined class. Also, less code means fewer bugs as there are fewer places for error.
3 Likes
What this guy said. /didMyHomework>
To try to paraphrase — long ago, layers in the Flash IDE worked because a lot of stuff was piled on top of each other and it helped manage groups of objects that may or may not have had the same “z order” in that pile, even before z order was a thing in Flash. Without layers, you would have to edit the bottom bun of a hamburger by taking all the sprites on top of it off, then putting them back, instead of just turning the “top” and “middle” layers off temporarily.
But in Unity, the world is expansive and 3D and there’s no need for keeping track of objects piled on top of each other on the screen the same way there was in Flash. If you had a hamburger you could just rotate around it and edit the middle or bottom of it from the best angle, or just find all the parts in the object hierarchy. Therefore layers in Unity are more like labels or qualifiers than literal layers.
I think I’ve got a crude handle on what Ben is saying. Layers work fine in 2D - very similar to Photoshop. When you are in a 3D space, things get complicated quite quickly.
Ben is recommending that we do away with layers but still use camera raycasting. We are going to detect enemies not based on their layer but instead on if the GameObject has the Enemy script. That does sound more reliable.
Furthermore, simplifying code just makes life easier. There’s less to deal with. Less is more! I’ve been imagining how complex things can get with all the different attributes and attacks and defenses, etc. Having a simple but effective code in place will really help with such a complex goal.