Investigate Mode events

[GillianYue]

"IVS" will be an enum mode (go into gameFlow to add this) where we'll be telling it info on interactivity of gameObjects, condition to end, etc.

Not fully fleshed out yet. see #86 for current idea of looping a conditional switch to check for end. (in other words, IVS lines will only be for set-up and will be carried out instantaneously, where a GAME 99 conditional switch is always following the IVS set up)

[GillianYue]

in IVS, a few things are happening:

• listener tracking for clicks to trigger npc dialogue/some event (need to match sprites to the point-to lines somehow) - still need calculations on distance between player and clicked obj (close enough = interactable) √

• listener tracking whether investigate has ended (need to provide either: a bool variable or specific conditioning --> the latter might be hard to implement with csv input) √

• deactivate update position by phone accelerometer and activate navigation by pressing (constant speed limited range √

[GillianYue]

In game, we keep track of a list of everything that can be clicked on in GameControl and check if they're hit in Update(). For IVS, we can do the same thing: keep a list of interact-able gameObjects and check one by one if hit?

How do we indicate that a GO should be tracked? --> on start of IVS, maybe locate all interact-able GO by id so that GameControl adds it to the list (while we're at it, why not give the corresponding go-to line as well --> a list of go-to-lines in sync with the GO list) Then, how do we know npc C is indeed GO[2] in the list? --> we search through the list and compare the ids; is there any way to avoid the search through? If we can assign the index to the GO themselves somehow and be like, "I clicked on you; tell me what your list index is" --> a script --> in that case store the line number in that script too w getters and setters

[GillianYue]

IVS 0: all set-ups, should take no time to execute, gameFlow should do whatever is needed, and increment pointer

IVS 1: similar to conditional switch, gives out condition to end investigate mode. However, there's no multiple paths; if condition not met, wait and check again (loop), if yes, increment pointer.

Events triggered under IVS should point back to IVS 1 to resume investigation

sample row: IVS 1 0(type assignment same as in conditional switch) ivsDone(name of variable) true

Players will be able to move around as long as a boolean called ivsDone does not exist or its value is not equal to true

[GillianYue]

also: I'm making processCurrentLine() a singleton Coroutine because that makes sense: we will never ever be processing two lines of logic at the same time. Each time the coroutine runs it checks if the class' instance of the coroutine is null (if yes stop that previous coroutine and leave it unresolved so no interference with the current one), assign itself to that instance, and by successful end of this coroutine points away from that instance so it's null (no need to be stopped by future coroutines)

[GillianYue]

Something to think about: maybe we should move all touch listeners to a centralized place. Currently, multiple scripts check for touch and do things related to that script on their own. However, sometimes we want one thing to happen over the other (clicking on npc so no need to move the player's position in that direction; ideally we could check if it's hitting any ivs npc then direct that one touch to navigation; ?

worked!

[GillianYue]

Where this is currently at, I'd say a fair amount of things can happen already if I learn proper Excel (line tracking and keeping things orderly); but no map terrain colliders bc I just don't want to deal with it............ yet