![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
12:20pm - Well I'm getting a later start today but I felt like working so I'm out and about.
12:37pm - Lunch was good, and sudden.
Now then. First thing I'm doing is getting rid of the WorldManager. Not doing anything, don't want it anymore, it's going.
Bam. Gone.
Next up is PlayManager. I'm going to take out the unused event system first...
Okay actually now that I look at it, I'm going to just delete it 'cause we don't need it anymore. I'm going to completely redo all the features in a different class using ScriptableObject.
Of course, that breaks the remaining two Managers, which shows why having all these Singleton Managers is bad. XD
Alright. Before I 'fix' those other Singleton Managers I'm going to try and make my new GameState object.
1:04pm - Alright, now I'm going to do a bit of research on using ScriptableObjects as Enums and also my specific case of using them to handle the game's state without being a Singleton Manager. My problem that I'm seeing now is that the ability to check the Game State is intrinsic to pretty much everything, so if I'm doing dependancy injection I'll be injecting it basically everywhere. An alternative might be setting it up as a static class without making it a singleton, but I'm not sure if that's better.
2:51pm - I had a distracting conversation with a friend while working for the last couple hours, but I did work and research despite it.
And it looks like using a ScriptableObject style enum for this won't work for the general state manager. But then I'm wondering if I even need a general state manager? The input will be read by a component on the player object after this, and then it'll be turned off when it goes to a menu or whatever, which will have its input handler turned on.
That sounds a little like it's going to turn itself off and on again. That would be crazy. What I'm actually thinking is that there will be an InputHandler component on the Player object and also a component that actually reads the input from the handler on the same game object, and that's the one that turns off the InputHandler.
This is important because I want the InputHandler to be a generic component so that other components on the object being handled can deal with the input in their own way. Normally you'd just put the Input.GetButton() or whatever function in the component that uses it, but then I'd have to turn off the input in a lot of different places, or use a state manager to say 'Are you in this state? No? Then don't do anything!'.
So to clarify, in map and worldmap style scenes there will be the following objects able to read input, and they'll switch on and off eachother's InputHandler when they're in focus:
Player controlled Mobiles
Dialogues
Menus
That's it.
Alright I think this will really work! Since only one thing is handling input at any given time, they'll always be able to pass the baton, and they should work independantly as well, if I keep to my many components architecture style.
3:23pm - My butt's getting sore and I'm getting hungry again, very frustrating. I'd buy something to eat but this cafe charges out the nose for food. I'm closer to home than the McDonalds so the sensible thing would be to go home, eat some sandwiches, then do something else. But I want to sort this out a little more first.
The way I was thinking of doing Dialogues was to have a Dialogue component on an NPC that contains a reference to a textobject of the dialogue XML file, and the code to display the Dialogue UI. But, now I'm thinking that I'll do something similar, but with the UI being completely seperate. Hmm...
It'll work something like this:
The player looks at NPC Steve and presses the talk button. The player's InputHandler lights up that the Talk button was pressed, and the player's interaction component reads that and says, "Hey, I should do my thing!" and it finds that there is an NPC there who has a dialogue component. So it turns of the InputHandler, preventing the player from putting anymore input into the game. Then it activates the DialogueWindow, which also activates the DialogueWindow's InputHandler component. At the same time, it passes a reference to the text object that it got from NPC Steve. This is used by the DialogueWindow to do it's dialogues.
When the end of the dialogue is reached, the DialogueWindow returns control to the Player, or more generally to the mobile that called it (which is controlled by the player) by reactivating the Player's InputHandler.
The same basic mechanism will happen if the player presses the Menu button, except without the NPC stuff.
So yeah I think this'll work! Now I just have to code it.
But first I need to go home and eat.
12:37pm - Lunch was good, and sudden.
Now then. First thing I'm doing is getting rid of the WorldManager. Not doing anything, don't want it anymore, it's going.
Bam. Gone.
Next up is PlayManager. I'm going to take out the unused event system first...
Okay actually now that I look at it, I'm going to just delete it 'cause we don't need it anymore. I'm going to completely redo all the features in a different class using ScriptableObject.
Of course, that breaks the remaining two Managers, which shows why having all these Singleton Managers is bad. XD
Alright. Before I 'fix' those other Singleton Managers I'm going to try and make my new GameState object.
1:04pm - Alright, now I'm going to do a bit of research on using ScriptableObjects as Enums and also my specific case of using them to handle the game's state without being a Singleton Manager. My problem that I'm seeing now is that the ability to check the Game State is intrinsic to pretty much everything, so if I'm doing dependancy injection I'll be injecting it basically everywhere. An alternative might be setting it up as a static class without making it a singleton, but I'm not sure if that's better.
2:51pm - I had a distracting conversation with a friend while working for the last couple hours, but I did work and research despite it.
And it looks like using a ScriptableObject style enum for this won't work for the general state manager. But then I'm wondering if I even need a general state manager? The input will be read by a component on the player object after this, and then it'll be turned off when it goes to a menu or whatever, which will have its input handler turned on.
That sounds a little like it's going to turn itself off and on again. That would be crazy. What I'm actually thinking is that there will be an InputHandler component on the Player object and also a component that actually reads the input from the handler on the same game object, and that's the one that turns off the InputHandler.
This is important because I want the InputHandler to be a generic component so that other components on the object being handled can deal with the input in their own way. Normally you'd just put the Input.GetButton() or whatever function in the component that uses it, but then I'd have to turn off the input in a lot of different places, or use a state manager to say 'Are you in this state? No? Then don't do anything!'.
So to clarify, in map and worldmap style scenes there will be the following objects able to read input, and they'll switch on and off eachother's InputHandler when they're in focus:
Player controlled Mobiles
Dialogues
Menus
That's it.
Alright I think this will really work! Since only one thing is handling input at any given time, they'll always be able to pass the baton, and they should work independantly as well, if I keep to my many components architecture style.
3:23pm - My butt's getting sore and I'm getting hungry again, very frustrating. I'd buy something to eat but this cafe charges out the nose for food. I'm closer to home than the McDonalds so the sensible thing would be to go home, eat some sandwiches, then do something else. But I want to sort this out a little more first.
The way I was thinking of doing Dialogues was to have a Dialogue component on an NPC that contains a reference to a textobject of the dialogue XML file, and the code to display the Dialogue UI. But, now I'm thinking that I'll do something similar, but with the UI being completely seperate. Hmm...
It'll work something like this:
The player looks at NPC Steve and presses the talk button. The player's InputHandler lights up that the Talk button was pressed, and the player's interaction component reads that and says, "Hey, I should do my thing!" and it finds that there is an NPC there who has a dialogue component. So it turns of the InputHandler, preventing the player from putting anymore input into the game. Then it activates the DialogueWindow, which also activates the DialogueWindow's InputHandler component. At the same time, it passes a reference to the text object that it got from NPC Steve. This is used by the DialogueWindow to do it's dialogues.
When the end of the dialogue is reached, the DialogueWindow returns control to the Player, or more generally to the mobile that called it (which is controlled by the player) by reactivating the Player's InputHandler.
The same basic mechanism will happen if the player presses the Menu button, except without the NPC stuff.
So yeah I think this'll work! Now I just have to code it.
But first I need to go home and eat.
