Week 8 - Checkpoint 2 - Basic Level Blocking
Hi everyone, welcome to my second devlog about the building process of Blue In Town. In this post, I will summarise how I partly improved the movement's drawback mentioned in the previous post, some new points that I added to the game, and what I should do to fix problems happening so far.
In the last post, I showed you some simple movements of Blue. She would reach the cursor position in the game scene whenever the left mouse button was clicked by players. I also pointed out the downside that my Blue could not go to the destination when facing any obstacles.
To upgrade those movements to something smarter, I put some new C# scripts (borrowed from my teacher as the algorithm in it was somewhat challenging to a newbie like me) in the game. The scripts generate a 25x10 grid composed of nodes in the game scene, which allowed the character to move via connections between them.
The interesting point was the A star algorithm implemented. In general, this algorithm has 'intelligences' that help us to find the shortest paths from the start position to the target position without meeting any obstacles [1]. It calculates and compares the movement cost among nodes (begins from the start position), and then picks the ones with the lowest value respectively. Our character will move following a series of those lowest costing nodes to the target. In our game, the start position will be where Blue is standing (can be a node or near a node), and the target will be a new invisible game object which is parallel with the mouse cursor.
Also, I changed the scripts a bit to delete diagonal connections between nodes to make sure that my characters' four-way movement will be more realistic.
Regarding new stuff put in the game, besides the tilework, I introduced the first two customers of Blue's restaurant who were Rin and Will. Small introductions about their career and features would pop up on the screen at their first appearance. 
Players can also drag them to anywhere in the game scene, but they cannot drop Rin and Will at a table yet. 
I also gave Blue and Alice an inventory displaying ingredients/ items that they grabbed. Players would be allowed to discard any unnecessary things in it.
(Sorry for the ugly circle :D)
Simple recipes with my favorite sushi (salmon for life!!!) was created as well. 
When it comes to comments from other players in my class, it was so glad when I received compliments on the artwork (I did put a great effort into it!) and how fun the game was so far. There was also one feedback that noticed a sorting layer error where one ingredient was covered by Alice's shoes. The owner also kindly sent me a capture of it. 
I will arrange the layer order of those sprites and update the result later on.
At this time, the player movement is not perfect yet since the paths from Blue to her target are not the most effective ones (containing weird-looking zigzag turns). However, I am still at the stage looking for a solution for it. Further improvements and updates will be announced in the next post. Also, there are some other issues which are needed to be solved:
Firstly, my Blue approaches her target immediately after the game starts while she should be idle and should begin her movement when receiving triggers (the mouse clicks). Secondly, Blue continues moving even when being at the target position. One solution for both of these two problems I think can be used is setting the speed of her movement equal to zero at the beginning of the game level and when she is at the target. The speed will be greater than zero if players click the left mouse button on the game scene.
Finally, when touching some obstacles in the game scene, Blue is randomly stuck at either the edges or the corners. Therefore, I will putting connected nodes in the game scene manually, ensuring the distances between nodes and colliders are rational to avoid the possibility that my Blue will touch any furniture in her restaurant and stay still.
Reference