Big Game Project Week 5
|
This week I have been working some more on menus, player movement and animation implementation. I have also added some feedback effects to the player.
Squash system fix and brokenLast week I created a system for squashing the player, it made him scale in the Y axis for example when he landed on the ground after performing a jump. This week I noticed that it was not functioning properly. It sometimes looked like the player was trying to have to scales at once, which made him flickering between these two scales. I tried to figure out why this was happening and find out that it probably was because I used coroutines. In the players usual update I reset a variable that needs to be reset in between the coroutine calls that is started. Like this.
resetVariable
updateCoroutine_1 updateCoroutine_2 resetVariable
updateCoroutine_1 updateCoroutine_2 But I noticed that it no longer updated in this order. The outcome could now instead be random and look something like this.
updateCoroutine_1 updateCoroutine_2 To avoid this I changed how the reset of the variable worked, it is now managed by the coroutines themselves.
I did not understand this at the time and I have not yet confirmed it, but now I think that the reason why the problem occurred was because I changed the players update loop to be a fixed update, instead of normal update. I am not sure if this change was made after I created the squash system or before. But if it was after it would explain why the order of the updates no longer are consistent.
I am still not 100 percent sure of how the coroutines work. Maybe they never are reliable to be in order whit the rest of the updates. So I am going to take a closer look at this next week to see how they work in that manner.
Sadly I saw this Friday that the problem still occurred. So my problem was not fixed as I thought. I have not yet looked in to it, so it could just be like a problem when files has merged.
MenusThe score screen is now done. But I noticed a bug when we had play testing this Friday that need to be fixed. It only occurs when the players finish time is zero, so I think it is quick fix. I have not yet checked it out but I think that a variable is trying to divide whit zero and therefore the variable gets the value NAN.
I implemented a pause menu to. I should probably done that earlier because it was really nice to have I noticed.
I started to work on the menu for the multiplayer lobby and how the connection are working. I never worked with network code before but I found that Unity’s system for it was very easy to pick up and get around.
Player FeedbackOur graphical artists made some particle effects that will show the player more easy when he loses or gain speed by using our pump feature (when the player make himself heavier). I implemented these effects so that when the player uses the pump feature in an uphill the particle effect will show red rings. When the player is in a downhill the effect turns blue instead. Because our player always is rotated as the normal of the ground triangle his currently stands on it was very ease to just use the player transforms forward vector to determine if he is in an uphill or downhill. If the forward vectors Y value is greater than zero he is in an uphill, if it is less than zero he is in an downhill.
Player movementWhen play testing during this week, we noticed that the behavior of unrideable walls that I made last week was not always working great. But on some places it did. So I added one more unrideable wall type. So now there is one that you can’t lose speed from, that just redirect your speed, and also one that you can lose speed from. |