![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
relee4:02am - Well I'm down at a different McDonalds this morning. I decided to leave at 3am and my usual McDonalds doesn't open until right about now, and I've already eaten a little meal that I had to wait a long time for. They gave my meal to someone else in a bout of confusion. I think one of the other people in line picked up a discarded reciept and claimed my food as if he had ordered, then left. The things people will do, huh? And they left the tea I ordered and some random guy peeled off the Monopoly stickers, and the McDonalds was just going to give me the tea like that. I asked them to remake it, since it had been steeping way too long anyways and it had been tampered with like that. So, that was a thing.
Anyways I'm back to where I left off yesterday morning. I've got Unity and Visual Studio open and I'm looking at the code to see where I can mix in some Threading, and how.
4:11am - Well it's been a while since I've worked on any of this code and that means I notice features I wouldn't have before. A big glaring one has me asking, "What was I thinking when I coded this?"
In the update loop, every update, I've got a while loop looping on the condition that the current actor has a Brain. Well, this IS the part I originally started looking into Multithreadding to fix, because the code inside the loop could potentially last longer than a frame. But geez!
Everything waits for the player's input anyways so why don't I just run this loop after the player takes their turn, and keep the Update function/loop clear?
The code block is even basically the same for a player controlled actor or an NPC actor, the differences are that one gets its input from the InputController and one gets its commands from it's brain. I wonder if I could combine them in some way?
4:40am - I'm thinking of something and I want to write it down so that I can look at it.
First off, I'm thinking about making an enum of commands, to unify the references instead of passing Strings. It's awkward because right now the input command strings and the brain command strings are different for the same actor commands. Those should be unified first.
Right now, the OnUpdate and OnInput functions are basically doing the same thing in different directions. One tests if the actor is controlled by the player, and if it is then execute the input command's function. The other tests if the actor is not controlled by the player, and if it is not then executes a command retrieved by the Actor's brain.
The Brain'ed Actor test is also run every frame, even when it's waiting for the player to input something.
So I'm thinking, make a function that processes a command and runs it on the CurrentActor, brain or not, and call that from the end of the OnInput function in a loop that runs until we get an actor under the player's control again, and then wait for new input.
There's a couple problems though. First is that the player might not be first in the turn order when the World starts, and second is that I'm not sure I can multithread it. Oh I just thought of a third problem. I've still got that infinite loop going if there aren't any actors under player control.
Let's start with the starting problem. I could have it so that when we load in a new World we run a starting loop of turn processing until we get to a player controlled actor.
Oh one aside; I guess because of the hour? they've got infomercials showing on one of the TVs in the McDonalds and it's really distracting. XD Infomercials always make their products seem really great and show you all sorts of weird use cases, or not so weird. In this case it's a kind of non-stick frying pan and they keep cooking stuff and showing off food you can make/make better with it.
Anyways back to work.
So that starting solution sounds good, but ideally I want to be only processing Actor behaviors one way.
Ah, here's an idea that's just coming to me. We have a 'ProcessCurrentActor' function, that runs in the background/on another thread and we wait for it to finish processing that actor before continuing. But the trick is, the Update loop keeps going, and checks if the current actor is done yet each frame. If it is, we check if the next actor is under player control, and if it is then we check the current input... Hmmm.....
But we're not checking input, we're receiving input directly as a cross class method call. The InputController calls the WorldController's OnInput method, or the MenuController's OnInput method, depending on which one has context at the current time.
At this point I'm wondering if I want the AI controlled actors to keep moving when the UI is up and the player actor isn't capable of recieving input?
Well anyways I've got an idea that might work. Instead of having WorldController's OnInput method directly initiate control of the current actor, if that actor is player controlled, instead I make it so that it sets a property on WorldController, so WorldController always has a Command waiting, or no-Command.
Basically, the OnInput method will change the parameter to whatever Command the user is currently inputting.
When a player controlled Actor comes along in the turn order, instead of being directly commanded, it checks the WorldController's new inputCommand property, and if it has a command, then it executes it. And if it doesn't have a command, it waits.
Hmm...
So I guess I'll put it in the Update function after all, since we'll either need to be regularly checking if the Actor has finished being processed or if the User has input a command.
Still, this should be much better than what I've currently got.
5:46am - I should open up HackNPlan and make tasks for all this.
Implement the Command Enum
Implement the inputCommand Property
Implement the ProcessActors Method
That should do! <3
5:59am - I guess now I'll get started on the first task.
6:47am - Alright! I've implemented the Command Enum without breaking anything. Next up I need to implement the inputCommand property on the WorldController object.
But first, toilet, and more food. I hunger!
7:49am - Okay I did those things and also had a filling come out (FACK) and watched a video while I ate and for a while after. Now it's back to work again.
8:03am - Okay so this is kind of weird. I'm looking at the code for the InputController and I'm realizing that the way it's written, as a bunch of if statements, it'll pour down the list changing the inputCommand value over and over again until it reaches the last command, for each command that was true.
So, I can either restructure it so that it posts multiple simultaneous command values, maybe by building up a bitwise ANDed value, or I can put them in order of importance... I could also seperate out directional inputs, which the Actor consumes, from other inputs that would be for GUI or other player centeric things.
Geez. This is a tough decision.
9:07am - Alright so I decided to go with the combination route, and spent a while re-writing the input handlers for the menu to use the bitwise ActorCommand options. Now I just have to do the same thing to the WorldController's input handlers.
9:15am - That went a lot faster than the other one. Let's see if it works!
9:36am - It didn't but it does now. I had to implement some Menu controls to get the menu to show up but that seems to work fine now. So I officially have the groundwork set up for the last of this three stage programming program.
Next up is implementing the ProcessActors method.
How it should work is that it checks if the CurrentActor is an NPC. If it's an NPC it runs the ProcessActor method in a seperate thread, and while that's running in the background, a check in the Update function will be checking if it's done. When it is done, it runs ProcessActors again.
Basically in the Update function, I'll just be checking a property on the WorldController to see if there's an Actor being processed or not. If there isn't, I'll process one. NPCs will be straightforward, but when it comes to a PC it'll only process that PC if there's a Command waiting in the inputCommand property that the actor can handle.
And that's about it.
9:51am - Now, it's about ten am and that means I'm pretty close to my goal of six hour shifts. I don't want to overwork myself, so I'm going to stop working now, get some groceries, and head home. But I've made a lot of progress today and I'm happy with myself, and I can see this all working right soon!
Anyways I'm back to where I left off yesterday morning. I've got Unity and Visual Studio open and I'm looking at the code to see where I can mix in some Threading, and how.
4:11am - Well it's been a while since I've worked on any of this code and that means I notice features I wouldn't have before. A big glaring one has me asking, "What was I thinking when I coded this?"
In the update loop, every update, I've got a while loop looping on the condition that the current actor has a Brain. Well, this IS the part I originally started looking into Multithreadding to fix, because the code inside the loop could potentially last longer than a frame. But geez!
Everything waits for the player's input anyways so why don't I just run this loop after the player takes their turn, and keep the Update function/loop clear?
The code block is even basically the same for a player controlled actor or an NPC actor, the differences are that one gets its input from the InputController and one gets its commands from it's brain. I wonder if I could combine them in some way?
4:40am - I'm thinking of something and I want to write it down so that I can look at it.
First off, I'm thinking about making an enum of commands, to unify the references instead of passing Strings. It's awkward because right now the input command strings and the brain command strings are different for the same actor commands. Those should be unified first.
Right now, the OnUpdate and OnInput functions are basically doing the same thing in different directions. One tests if the actor is controlled by the player, and if it is then execute the input command's function. The other tests if the actor is not controlled by the player, and if it is not then executes a command retrieved by the Actor's brain.
The Brain'ed Actor test is also run every frame, even when it's waiting for the player to input something.
So I'm thinking, make a function that processes a command and runs it on the CurrentActor, brain or not, and call that from the end of the OnInput function in a loop that runs until we get an actor under the player's control again, and then wait for new input.
There's a couple problems though. First is that the player might not be first in the turn order when the World starts, and second is that I'm not sure I can multithread it. Oh I just thought of a third problem. I've still got that infinite loop going if there aren't any actors under player control.
Let's start with the starting problem. I could have it so that when we load in a new World we run a starting loop of turn processing until we get to a player controlled actor.
Oh one aside; I guess because of the hour? they've got infomercials showing on one of the TVs in the McDonalds and it's really distracting. XD Infomercials always make their products seem really great and show you all sorts of weird use cases, or not so weird. In this case it's a kind of non-stick frying pan and they keep cooking stuff and showing off food you can make/make better with it.
Anyways back to work.
So that starting solution sounds good, but ideally I want to be only processing Actor behaviors one way.
Ah, here's an idea that's just coming to me. We have a 'ProcessCurrentActor' function, that runs in the background/on another thread and we wait for it to finish processing that actor before continuing. But the trick is, the Update loop keeps going, and checks if the current actor is done yet each frame. If it is, we check if the next actor is under player control, and if it is then we check the current input... Hmmm.....
But we're not checking input, we're receiving input directly as a cross class method call. The InputController calls the WorldController's OnInput method, or the MenuController's OnInput method, depending on which one has context at the current time.
At this point I'm wondering if I want the AI controlled actors to keep moving when the UI is up and the player actor isn't capable of recieving input?
Well anyways I've got an idea that might work. Instead of having WorldController's OnInput method directly initiate control of the current actor, if that actor is player controlled, instead I make it so that it sets a property on WorldController, so WorldController always has a Command waiting, or no-Command.
Basically, the OnInput method will change the parameter to whatever Command the user is currently inputting.
When a player controlled Actor comes along in the turn order, instead of being directly commanded, it checks the WorldController's new inputCommand property, and if it has a command, then it executes it. And if it doesn't have a command, it waits.
Hmm...
So I guess I'll put it in the Update function after all, since we'll either need to be regularly checking if the Actor has finished being processed or if the User has input a command.
Still, this should be much better than what I've currently got.
5:46am - I should open up HackNPlan and make tasks for all this.
Implement the Command Enum
Implement the inputCommand Property
Implement the ProcessActors Method
That should do! <3
5:59am - I guess now I'll get started on the first task.
6:47am - Alright! I've implemented the Command Enum without breaking anything. Next up I need to implement the inputCommand property on the WorldController object.
But first, toilet, and more food. I hunger!
7:49am - Okay I did those things and also had a filling come out (FACK) and watched a video while I ate and for a while after. Now it's back to work again.
8:03am - Okay so this is kind of weird. I'm looking at the code for the InputController and I'm realizing that the way it's written, as a bunch of if statements, it'll pour down the list changing the inputCommand value over and over again until it reaches the last command, for each command that was true.
So, I can either restructure it so that it posts multiple simultaneous command values, maybe by building up a bitwise ANDed value, or I can put them in order of importance... I could also seperate out directional inputs, which the Actor consumes, from other inputs that would be for GUI or other player centeric things.
Geez. This is a tough decision.
9:07am - Alright so I decided to go with the combination route, and spent a while re-writing the input handlers for the menu to use the bitwise ActorCommand options. Now I just have to do the same thing to the WorldController's input handlers.
9:15am - That went a lot faster than the other one. Let's see if it works!
9:36am - It didn't but it does now. I had to implement some Menu controls to get the menu to show up but that seems to work fine now. So I officially have the groundwork set up for the last of this three stage programming program.
Next up is implementing the ProcessActors method.
How it should work is that it checks if the CurrentActor is an NPC. If it's an NPC it runs the ProcessActor method in a seperate thread, and while that's running in the background, a check in the Update function will be checking if it's done. When it is done, it runs ProcessActors again.
Basically in the Update function, I'll just be checking a property on the WorldController to see if there's an Actor being processed or not. If there isn't, I'll process one. NPCs will be straightforward, but when it comes to a PC it'll only process that PC if there's a Command waiting in the inputCommand property that the actor can handle.
And that's about it.
9:51am - Now, it's about ten am and that means I'm pretty close to my goal of six hour shifts. I don't want to overwork myself, so I'm going to stop working now, get some groceries, and head home. But I've made a lot of progress today and I'm happy with myself, and I can see this all working right soon!
