ChasePlayerStrategy

[cproctor]

I propose ChasePlayerStrategy, a subclass of Strategy which causes the sprite to move toward the player. There are two possible levels of complexity here.

1. Just have the sprite try to move toward the player. This is pretty easy to implement because you can get the x and y positions of the NPC and the player, and use them to compute the vector from the sprite to the player.

This is an OK strategy, but it's not great. The problem with moving directly toward the player is that it's not always the best way to get there. You have probably seen games where the enemies walk into a wall and just get stuck there, trying over and over to walk into the wall. One simple way to deal with this problem is to use a DividedStrategy to make the NPC sometimes walk toward the player and sometimes wander around randomly. A better, more advanced strategy is to use an algorithm which plans routes around obstacles.

2. Implement the A* algorithm (Warning: Advanced! This algorithm is not too hard to understand, but will be a somewhat tricky challenge to implement. Teachers can support a group that wants to take on the challenge.) This algorithm considers all possible paths, going from really short to really long, until it finds a path from the sprite to the player. Since we went from short to long, the first path that connects them must be the shortest one, so it's the best way to go. After a step along that path, it's time to plan again...

[wolfj95]

@the-isf-academy/peach Start by just trying to make the grandma character chase the player in a copy of the grandma's soup example game. Where does the NPC make a decision to move? Update this based on the first suggestion above.

[wolfj95]

The first strategy outlined above is complete! Great work @the-isf-academy/peach ! I moved your code to the quest/contrib/ directory. You can find an example game that uses it in quest/examples/contrib.

I will leave this issue open in case anyone wants to implement the more elaborate chase strategy.

[0010074]

Something that went well during this feature lab was the discussions between the group. Through these discussions, we were able to figure out how to go around accomplishing this lab. Something that was different than what I had expected was how we needed to start the code from scratch. Normally we would have some sort of starting point however, we weren't given that this time. Something I'd do differently in other projects is to contribute some more ideas on how the code would work.

[0010040]

The things that went well was that we were able to grasp the main idea of what we were doing and figured how to implement our ideas into actual working code(kind of working code). At first, I thought that we were going to make the NPC "smart"(NPC find the most direct route to the player, however, we were forced to switch the NPC to a state where it would just follow the player. If we were to do this project again, I would also try to contribute to more ideas, as I thought that my teammates were thinking of most of them.

[jet8858]

I think what went well was the fact that we managed to somewhat make some progress on the feature before the deadline, in terms of having our basic code and ideas. What was different from expected was probably the amount of work we had to do because I guess we had thought it would be easier. Next time in the game project we would probably try to work in a python file in atom instead of google drive.