Ok lets say I have a component called Perception, which periodically updates a list with creatures in a nearby radius. Simple enough. Overlapsphere, getcomponent, add to list, yadda yadda.
Now lets say I want to add a Stealth component to a creature. I want this component to hide the creature from perception checks. So either prevent it, or remove it from a perception list after the fact, whatever.
Now Stealth was made in response to Perception, not vise versa. So ideally, Stealth can know about Perception, but Perception doesn’t know about Stealth. I don’t want to have to edit any existing code in Perception (or Creature), I want all the work to be done in Stealth. Makes sense right?
So my question is, realistically, is there any way this could work? How could we have Stealth know when it’s Creature is getting caught in a Perception check? And then edit that check? Without touching the Creature or Perception scripts?
This is a theoretical question for a bigger idea. Mainly, the ability to add hundreds of new scripts over time throughout development, that can modify previous scripts’ behaviors at run time, without having to edit any previously created scripts. For example, after Stealth next we add Detection, which will negate Stealth. The code for that should be done entirely in Detection. No edits made to any other script before it. Could we set this up in any practical way? Keeping performance in mind. If so how?
Set a tag or layer when an entity is in stealth mode that Perception ignores when casting OverlapSphere. BTW…It really doesn’t matter if the compoenent knows about the other as long as it does not act on it.
The point is to not make any changes to the existent Perception script. The contents of Perception already have no reference to any kind of Stealth mechanic. We’re not allowed to change the existent Perception script for any reason, no adding Stealth checks to Perception, no checking tags, no checking bools, nothing can be added to the Perception script.
What kind of contrived madness is this?! Is this just mental onanism or is this for a class?
You do realize this is SOFT-ware, right? As in it is SOFT, you review and refactor it as necessary.
Code rots steadily over time. You think it doesn’t, you think it’s frozen in stone and immutable, but it changes: it ROTS!
If you don’t refactor code then it goes bad, becomes stale, and horrible bone-rotting communicable diseases spawn inside your old code and spread through your codebase, making everything unstable and brittle and prone to failure.
Sheesh, for all we know the 'rona spawned inside code that wasn’t refactored in a timely enough fashion!
In theory you’d have already written a function like bool canBePerceivedBy(perceiver p). At first that would be a distance check and raycast (for line-of-sight). After stealth was invented the function would include that. Since you’re just plugging in that function, the original perception-using code can stay the same. Or, since we don’t want to lose the speed of a sphereCast, we could always do that but have cleverly added bool additionalPerceivedByTest(perceiver p) (which starts off returning “true” and changes to return stealth==false later on).
But what if the perceiver gets a another anti-stealth check every 5 seconds or whenever the sneaker does certain things? Then it’s so much easier to build that into the perception system.