Work Post

10:00am - Weird, I was all worried about getting to the library too early, and here I am sitting down an hour after they open. Oh well.

Working on the Estheria Prototype again today. Targeting the mechanics I outlined yesterday.

10:16am - Bit of a track jump; I realized that the way I was handling input wouldn't work with AI; if it's checking an InputHandler for input reveals, it won't be checking an AI system for what to do. So instead I'm going to have the InputHandler directly tell the Mobile components what to do.

I don't like it, though. Hmm... The problem is that they could either be an InputHandler or an AIModule. Could this be a case for polymorphism? I could make a base class that reveals the input properties, and subclass it into InputHandler and AIModule, and then AIModule into whatever sorts of AI Modules I want to implement. That way the other components on a mobile could look for the revealed properties on a, let's call it ControlModule, and it wouldn't matter that it was a different class than the base class if it inherits from it.

Hmmm.... This brings up a new problem though. Normally when you've got just one copy of a component on an object you can simply do GetComponent() to get the instance. This way, every one of the other components on the object would need to have their ControlModule injected in the inspector. I'm not sure if that's better or worse than having the InputHandler or AIModule polling the object to see what components it has, and taking control of them.

Oh and I just realized something! If I do it by way of the injection, what happens if a Mobile needs to switch between Player and AI Control, like for a cutscene or for switching your main character?

I guess that puts me back into having the InputHandler and AIModules grabbing all the other components and controlling them directly. That way I can turn one or the other off as needed.

That's rather roundabout, returning to where I started, but at least I considered the other idea and figured out what problems it would have instead of just implementing it.

10:37am - I'm also changing the InputHandler class name to PlayerInput so it's clear that it's not a generic input anymore.

10:55am - Okay we've got movement rebuilt. Now for the Dialogue...

10:59am - Alright so there'll be a MobileInteract component on the player and probably on NPCs as well, allowing them to interact with interactables in their environment. Most importantly this'll be the player talking to NPCs.

But the code I had for wasn't good enough. It didn't determine facing; it automatically resets the player to an idle pose facing down, and it uses the player's movement input to determine their facing. If the player stops pushing towards the NPC then they won't be able to talk to them. So, I need to determine and reveal facing somewhere.

I'm thinking of making it a public property on the MobileMover so that the MobileInteract can read it, but that will couple the two components a little. It should be okay as long as the MobileInteract checks to make sure there's a MobileMover before it tries to read the value, though.

The alternative would be to make the MobileInteract track facing on its own, but I don't think it'll be the only component that wants to know what direction the mobile is directed.

One problem I've still got though is how to determine which direction the mobile is facing. When it's got input it's obvious, but I'm not sure how to recognize when the facing direction changes. Hmm...

Maybe if the facing only changes when the input flips from positive to negative? That way it'll track the last positive input while ignoring zero inputs. I'll try that.

11:29am - No, that won't work. That only gets me the four diagonal directions. Hmm...

11:52am - I tried looking for other people who had this problem and I found a solution. Constantly save a 'previous direction' and when the input is zero, the facing will be the last direction the player looked. That makes sense.

11:56am - Huzzahulations! The facing works and all it took was one line of code. XD

Feeling good, but also hungry. I've only been here two hours. ^.^;;

I'll try to squeeze in one more hour before I go for lunch.

So anyways now that I've got my facing, the MobileInteract needs to know what sort of interaction system I'm going to use. Previously, I had set it up by searching for a DialogueEvent component on a Raycast hit target, but I want my interactions to be more generic. So I came up with an idea while I was thinking about this. I'll make an Interactable component for it to search for, and the Interactable component will have one public property, a Delegate! That's kind of a function pointer in C#. Depending on what the interaction does the delegate could point to anything. Hopefully this works. I'll have to test it out.

1:02pm - Alright I've got the interaction working. Right now all it does is have a test object do a debug.log call, but next I'll rework the dialogue system to be called by the interaction, and do my baton pass.

But first, lunch.

Work Post

2:53pm - I'm done lunch and lunch activities and I'm back at the library. Unfortunately, while I was away some more people came and the good table is all filled up, so I'm stuck either sitting at one of the regular, non-electrified tables, or one of the exotic chairs near the window that do have power. I'm hoping to be at this a while so I took a seat with power, but it's very uncomfortable and I worry about my pocket stuff falling out.

If I had known the Library was so busy I might have gone to the McDonalds again. Well, there's always next time.

For now I'm going to try and get the Dialogue working with the new Interactable system.

3:05pm - Something's nagging at me. It's a problem with the whole UnityEvent delegate thing. In order to do the baton pass my MobileInteract component needs to turn off the PlayerInput component on the Object it's a part of. But I was all set to activate any sort of event with my MobileInteract/Interaction intersection. So, there might be other types of interaction that don't require the PlayerInput to be shut down, and which wouldn't know to start it up again. Hmm... Things you interact with in JRPGs... Mostly they're things that come with a dialogue. Are they all? They all could be. So maybe this is okay?

I'm not sure. Doors are an example where you want to just push the button and enter, without having to have a dialogue pop up and ask if you want to go in. There might be buttons you want to push that don't have a dialogue, too. Chests/treasures have a whole different sort of dialogue.

So yeah, it's not okay.

What shall I do as an alternative?

3:23pm - Bleh, someone just put on some fragrance. I've never had to deal with that at the McDonalds. :/

There's a lot of stuff here that bugs me that I don't have to deal with at the McDonalds. I'm definately reconsidering the idea of working here more often.

Anyways, I'm trying to figure out what to do with my interactables...

I think what I need to do is have the MobileInteract know what sort of interaction it's interacting with, rather than just firing off a remote function on some other object.

Maybe instead of passing a function, the Interactable component should pass an object? But if I have different components for different interaction types, how would it know what sort to recieve?

If I used polymorphism here, I don't think it would work, because the MobileInteract needs to know the type it's interacting with. Treating it as a base class won't work. I could put a function on the base class though that returns the type of the interaction so it knows what it's working with. That might work...

Alright let me run through the logic again to make sure I've got it clear in my head.

First the MobileInteract activates and gets a reference to the Interactable. Then it activates the Interactable's interact function.

...

Oh hang on. I could have the interact function return an enum that says what kind of interactible it's activating. But then, how would the Interactible know that? o.o;;

There's a third hand in this pot and that's the Interaction that the Interactable is triggering. So yeah, the Interactable component won't even know what type of Interaction it is. It'll fall to the MobileInteract component to figure out what it's been passed.

So let's try that logic again.

First the MobileInteract activates and gets a reference to the Interactable. Then it takes the public Interaction component from Interactable's reference. Then it uses the Interaction component's GetInteractionType() method to figure out what type of interaction it's dealing with, and it responds accordingly, potentially turning off the PlayerInput component. Then it runs the Interact() method on the Interaction, causing it to do its thing.

It almost seems like I could combine Interactable and Interaction, except that then there wouldn't be an easy way to find it. So all Interactable does is provide an easy to lookup redirection to the actual Interaction.

I'm going to code that up and see how it works.

5:12pm - I need to use the washroom and I don't feel safe leaving my laptop out in the library. I'm going to pack up and head to the McDonalds and work there until I'm tired of working.

Work Post

6:05pm - Man it's been a long day. Third work post. XD

I'm at the McDonalds now; I almost went to the Tim Hortons instead but they were full.

6:18pm - Hah, this sounds like a magic spell. Just about to test it and see if it works.

interactable.interaction.Interact();

Well it worked. <3


6:36pm - I'm looking at the Dialogue system now. I guess I forgot my Unity Best Practices when I wrote it though. It instantiates a new object for each text window, and the windows aren't scripted to be special or anything.

8:00pm - I've got the Estheria Prototype nearly back to where it was before, but with a much more sensible architecture. The only thing remaining is to make the up and down buttons work in the dialogue mode. They're a little complicated because I have to implement a counter between registering inputs, otherwise it just goes nuts and flickers between the two options super fast. XD

But it's 8pm and I've been working all day, so I'mma go home and get some rest.