[REG-2230, REG-2231] Implement Validations Within Segments

[vontell]

Note to reviewers: I am headed to lunch rn so will make my own self-review changes when I get back, but I didn't want to stall having people take a look at this, so opening it now.

This review is now ready... This PR implements an initial validations-in-editor feature. This doesn't report or record the results of the validations (as that is going to be done next as part of this ticket), but it implements all of the internal-facing parts of this. More particularly, it does the following:

• Adds a new validations field to the bot segments which will contain the types of validations to run for that segment
• Implements a Script validation type that is essentially a C# file inheriting from a MonoBehaviour-esque class specifically for writing validations.
• Adds logic to the bot segment execution that will prepare these validation scripts and then run them. However, right now, the only type is a Script that manages its own update loop, so the ProcessValidations function doesn't really do much. I implemented things like pausing and cleanup, too.
• It is technically possible for a segment to finish running before validations can be tried... so there is a new endCriteria of "ValidationsCompleted" that makes the segment wait until all validations are met. This is not typically needed from the user, it was really only for situations where you have a validation-only segment.

Here is where I have some questions and might need some help with some debates:

• There are some tricky timing concerns with this... if the bot segment ends instantly (say there is one endCriteria that is instantly met), the validation script might only be loaded after it missed its chance to execute. Any thoughts on this?
• The way that validations are terminated is very tricky... for example, some validations are in the format of "this should never be true." This means that technically, this validation never ends... right now, this would be terminated by the endCriteria being met, in which case the validation script is told to stop, but what if they have a ValidationsCompleted endCriteria?

I'll make some notes about other concerns in the PR - TLDR; I am very open to changing things in here, there are some concepts and ways this work that I am not tied to.

If you are curious, here is the associated Boss Room PR: https://github.com/Regression-Games/RGBossRoom/pull/81

[vontell]

This is not related or relevant to the current PR... will remove in a moment, so you can ignore this for now

[vontell]

This has been removed

[vontell]

Need to remove this.

[vontell]

This will be adjusted as part of my behaviour rewrite

[vontell]

Removed/added really I guess (added the part where it actually does process based on some outside update loop)

[vontell]

Oops also need to remove this old readme from IF, skip this

[vontell]

Removed and will add back new docs later today.

[vontell]

@RG-nAmKcAz this is now ready for an actual review, thank you for the high level points, I think things are much cleaner now. I do need to work on the merge conflicts since I bet there are a lot of changes in bot segments I might need to worry about... but will try it out.

Also update the boss room PR with the relevant changes: https://github.com/Regression-Games/RGBossRoom/pull/81

[nAmKcAz]

@vontell The merge will restructure your code in the Controller completely, so let's do that first

[vontell]

Back to you, @RG-nAmKcAz. I do need to add even more tests to bossroom, mine are very very simple, but I will be doing that tonight. No rush to review this tonight of course, but note that I do plan on giving Kachi an experimental branch to play around with since I promised them a timeline (this was intentional, I needed to get this to them in the first half of the week), but I expect to continuously making fixes over the next few days depending on whether they use it or not.

Appreciate all the comments so far!

[vontell]

Update on this from evening work (TLDR; no new review needed yet unless you want to be proactive): I actually need a few more hours on this to think through a few small pieces... see this video if you are interested in seeing what I changed (hint: I reasoned that I need to support validations over sequences or multiple segments to really get any utility out of this). https://www.loom.com/share/31165d0f9a9f471db710b1d3b48f68a3?sid=4c8b3ec9-b2e9-4882-93ab-c295353fe804

[batu]

I would like to better understand
//Debug.LogError($"Validation method {validator.Method.Name} was never passed or failed, so it is technically passed."); but beyond that it looks good.

I skimmed the infrastructure and set up parts, nothing popped out to me but I am deferring to Zack's comments there.

[batu]

@vontell For my understanding and speeding up reviews, this is a good example of a PR that I would have appreciated a top level walkthrough in the form of a video. I am realizing that I spend a good amount of time identifying which of the 30+ file changes I should give my attention and trying to simulate the code flow to resolve assumptions. Things clicked when I got to BossRoom/.../ValidateUI.cs but it took a sec. I think the 'code walkthrough video' helps especially when I don't have the context in (SDK in this case) in my recent memory.

[nAmKcAz]

Aaron, marking this approved while you test / iterate as I agree with the fundamental design.

[vontell]

@batu back to you! Really like your suggestion of a loom video, I will do that in the future upfront, but also for other reviewers here is that video: https://www.loom.com/share/d6e9a506ccbd4605bdb7bdaa0d2448a0?sid=8ce1048a-d759-481f-b059-8fd58e98c046

[batu]

@vontell this looks good to me! I really appreciate the loom video, it helped my understanding drastically, and it is very useful to me to see the thought process of the author.