![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
4:51pm - Well here's a blast from the past; I'm working at the Coffee Culture in Sarnia today. My Dad's sweet but I don't want to spend all afternoon at his place, and I brought my whole kit with me, so I thought hey, why don't I go work on my projects at the Coffee Culture? Well here I am.
It's been a while since I worked last. It doesn't seem that long ago I was chiding myself for working on Labour Day and here I am working on Thanksgiving. But, I've already had my first thanksgiving dinner/lunch and I think that means I'm in the clear.
Now, last time I worked I basically spent my time figuring out what to do next, and I did! The next step is step 6 on the 15 step guide, adding monsters and the timing system. I think I already have the timing system implemented, and some testing NPCs, but I have a lot more to do. Ah but I feel the anxiety working its way up; calm down, me, it's not that bad.
Let's see where we are right now in the code.
5:27pm - Whoops I got distracted while I was waiting for Visual Studio to load. ^.^;;
*read read* Boy I made a complicated thing. Hah!
5:59pm - Okay so I'm making a random brain right now. It'll be hardcoded in at this stage, but it gives me a place to start from. It'll take a step in a random direction or stand still each turn. I'm thinking one third of the time it'll stand still.
6:30pm - Alright! I switched out the CivilianBrain for the RandomBrain and now I've got two guys who move around or wait at random.
6:49pm - Then I got a little distracted again! Also oops I forgot about HackNPlan until just now.
6:56pm - Oh brilliant, they mixed up the HackNPlan format and design. Now I'll have to learn it all over again. ^.^;;
7:34pm - Geez, time flies. Anyways I've got the HackNPlan organized again with clear tasks for me to do, and the first one is to implement collisions. That is to say, make it so that the game processes an event when an actor tries to move into a space where another actor already is.
This may be trickier than it sounds, since I think I coded the movement processes in such a way that... hmm... hard to find the words. I'll just open up the movement code and see for myself.
7:53pm - Alright this is a bit tricky. Let me try and spell out how the movement system works right now, so I can see where I need to make changes.
First off there are two ways the movement functions are called, either by the OnInput event handler or by the Update function, for AI controlled actors.
Either way calls the same method, the WorldController's "AttemptToMoveActor" method. This method takes the actor to move, and a pair of integers for the offset from the starting position that the actor should move.
The AttemptToMoveActor method gathers references to the Tile that the actor is in and the tile it wants to move to, and makes sure the target tile exists and is free to be moved into. Then it runs the actor's MoveActorTo method.
I think this is a key spot! Because it only runs MoveActorTo if the movement is valid, if it's invalid I can have it do something else, without worrying about the result of MoveActorTo... Except that only MoveActorTo would be aware of limiting factors on the Actor's movement, like if they were frozen in place or slowed or otherwise couldn't make the move.
Alright I'll have to push forward...
The Actor's MoveActorTo method basically just moves the actor to the tile passed as an argument, and returns true if it works or false if it doesn't. So that's a thing. I can expand the function later to include those limiting factors when I add them, but since it returns a boolean, I can have the AttemptToMoveActor method return the bool as well, and handle what happens when the movement doesn't go according to plan back in the initial movement function call.
That should work!
Hmm... I'm implementing it now, and it occurs to me I could also do a check before the call of AttemptToMoveActor to see if there is a wall or whatever in the next tile before trying to move or otherwise acting. But then, I think it's best to do it this way, so that if you can't move, you can't attack either.
8:35pm - Okay now I've got it so that it only adds to the log that it moved if it successfully moved. But I still have to make a method to react when the boolean is false.
8:44pm - I was working on that when I realized that if I put a check for a collision after the move has returned false, then it will result in that 'attack when frozen' behavior I want to avoid. So I'm thinking I'll put it in the AttemptToMoveActor method after all. It'll happen when the check to see if the space is clear fails.
Or wait, would that have the same problem?
Yeah it seems like if I check before the Actor's method, or after the Actor's method, it'll result in that behavior. It has to be during the Actor's method, somehow.
8:56pm - Okay so let's walk through this.
If the tile doesn't contain an actor and is not blocking and doesn't contain an installedObject, then move the actor.
Else, If the tile doesn't contain an actor and is not blocking and contains an installedObject which is not blocking, then move the actor.
Else, If the tile contains an actor, ...
Else, if the tile doesn't contain an actor, and is blocking, and doesn't contain an installedObject, ...
Else, if the tile doesn't contain an actor, and is not blocking, and contains an installedObject which is blocking, ...
Else, if the tile doesn't contain an actor, and is blocking, and contains an installedObject which is blocking, ...
9:04pm - I'm out of time, so I'll have to fill in those "..." next time. Good night everyone!
It's been a while since I worked last. It doesn't seem that long ago I was chiding myself for working on Labour Day and here I am working on Thanksgiving. But, I've already had my first thanksgiving dinner/lunch and I think that means I'm in the clear.
Now, last time I worked I basically spent my time figuring out what to do next, and I did! The next step is step 6 on the 15 step guide, adding monsters and the timing system. I think I already have the timing system implemented, and some testing NPCs, but I have a lot more to do. Ah but I feel the anxiety working its way up; calm down, me, it's not that bad.
Let's see where we are right now in the code.
5:27pm - Whoops I got distracted while I was waiting for Visual Studio to load. ^.^;;
*read read* Boy I made a complicated thing. Hah!
5:59pm - Okay so I'm making a random brain right now. It'll be hardcoded in at this stage, but it gives me a place to start from. It'll take a step in a random direction or stand still each turn. I'm thinking one third of the time it'll stand still.
6:30pm - Alright! I switched out the CivilianBrain for the RandomBrain and now I've got two guys who move around or wait at random.
6:49pm - Then I got a little distracted again! Also oops I forgot about HackNPlan until just now.
6:56pm - Oh brilliant, they mixed up the HackNPlan format and design. Now I'll have to learn it all over again. ^.^;;
7:34pm - Geez, time flies. Anyways I've got the HackNPlan organized again with clear tasks for me to do, and the first one is to implement collisions. That is to say, make it so that the game processes an event when an actor tries to move into a space where another actor already is.
This may be trickier than it sounds, since I think I coded the movement processes in such a way that... hmm... hard to find the words. I'll just open up the movement code and see for myself.
7:53pm - Alright this is a bit tricky. Let me try and spell out how the movement system works right now, so I can see where I need to make changes.
First off there are two ways the movement functions are called, either by the OnInput event handler or by the Update function, for AI controlled actors.
Either way calls the same method, the WorldController's "AttemptToMoveActor" method. This method takes the actor to move, and a pair of integers for the offset from the starting position that the actor should move.
The AttemptToMoveActor method gathers references to the Tile that the actor is in and the tile it wants to move to, and makes sure the target tile exists and is free to be moved into. Then it runs the actor's MoveActorTo method.
I think this is a key spot! Because it only runs MoveActorTo if the movement is valid, if it's invalid I can have it do something else, without worrying about the result of MoveActorTo... Except that only MoveActorTo would be aware of limiting factors on the Actor's movement, like if they were frozen in place or slowed or otherwise couldn't make the move.
Alright I'll have to push forward...
The Actor's MoveActorTo method basically just moves the actor to the tile passed as an argument, and returns true if it works or false if it doesn't. So that's a thing. I can expand the function later to include those limiting factors when I add them, but since it returns a boolean, I can have the AttemptToMoveActor method return the bool as well, and handle what happens when the movement doesn't go according to plan back in the initial movement function call.
That should work!
Hmm... I'm implementing it now, and it occurs to me I could also do a check before the call of AttemptToMoveActor to see if there is a wall or whatever in the next tile before trying to move or otherwise acting. But then, I think it's best to do it this way, so that if you can't move, you can't attack either.
8:35pm - Okay now I've got it so that it only adds to the log that it moved if it successfully moved. But I still have to make a method to react when the boolean is false.
8:44pm - I was working on that when I realized that if I put a check for a collision after the move has returned false, then it will result in that 'attack when frozen' behavior I want to avoid. So I'm thinking I'll put it in the AttemptToMoveActor method after all. It'll happen when the check to see if the space is clear fails.
Or wait, would that have the same problem?
Yeah it seems like if I check before the Actor's method, or after the Actor's method, it'll result in that behavior. It has to be during the Actor's method, somehow.
8:56pm - Okay so let's walk through this.
If the tile doesn't contain an actor and is not blocking and doesn't contain an installedObject, then move the actor.
Else, If the tile doesn't contain an actor and is not blocking and contains an installedObject which is not blocking, then move the actor.
Else, If the tile contains an actor, ...
Else, if the tile doesn't contain an actor, and is blocking, and doesn't contain an installedObject, ...
Else, if the tile doesn't contain an actor, and is not blocking, and contains an installedObject which is blocking, ...
Else, if the tile doesn't contain an actor, and is blocking, and contains an installedObject which is blocking, ...
9:04pm - I'm out of time, so I'll have to fill in those "..." next time. Good night everyone!
