FINALÂ GAME IDEA PROTOTYPE
Monday, December 2nd [Version 1.0]
Today, as Adam advised us on Friday, I started working on the first prototype for the game. My goal for the day is to work out how I can change the gravity of the world, make the player move to the right along the circle, and make it jump.
While I was researching about how to change the gravity point, I found this useful tutorial which helped me understand what I need to do and how to think about the concept. The game built in the tutorial is 3D, and the tutorial is 5 years old, so I had to change quite a lot of things. The good part is, the thinking is the same.
So, here is what I did: there is a force that is attracting something (the circle/floor in this case), from the centre point; and there is a body that is being attracted by this force. The way this is done, is my determining in which direction from the centre of the circle the body is. Then, I added a force to attract this object. To make sure the player is rotating, and not facing the initial direction, I used a Quaternion that told the object which position to rotate from to which it should rotate. This was pretty easy to understand, but figuring out the language to do it took me more time than I wished. Now, the player is attracted to the floor.



The next step was getting the player to move. I thought I would get away with using the horizontal axis for input, but that turned out to be wrong, as the horizontal axis doesn't move, even if the player's rotation changes. As you can see in the video below, the player stop after reaching 90 degrees, as it would wish to go to the right side of the screen, but the Attractor force won't let it.

That makes sense, now that I think about it. So. Instead, I decided to add force to the player, using the physics engine. This went a bit better, as the player could actually complete the circle, but the new problem I ran into was physics. It never works the way I want. As in real life, constantly adding a force to an object will make it accelerate. This happened, to the point where the Attractor couldn't keep the player close to the floor and the object flew into space. It's like having a stone tied to the end of a shoe lace, if you keep rotating the other end, the stine will get furter and further away (in a nice wave effect) from the original point. This is nice, but we don't need this in our game. We need to player to always return to the floor.

I am happy with this, the player is constantly moving, so it keeps the music going, and it can also jump. I think this is good for the first day of prototyping for this game. Tomorrow I want to see how I can make the obstacles pop up, and test if we want them to pop up behind the player, or under it, and the player can just jump off of them and do other stuff.
Tuesday, December 3rd [Version 1.1]
Today I wanted to get started with the objects that pop up when the first player does different elements of parkour. As we imagine it, it is a combo system. Different keys make different sounds and objects, and different key combinations make more complex sounds and objects. I decided to set up a new scene in Unity, so I wouldn't need to bother with the new objects' gravity attraction point or so, the way I did yesterday with the player's, since I firstly wanted to see how I'd even go about the combo system.
Since we are still developing and designing the game, I wasn't able to create a proper table with what keys and combinations would trigger what objects or sounds, so I quickly made this table that shows how the complexity of a combo gives the player a 'better' obstacle, with some random keys a chose. I will try to work with these combinations for the prototype phase, until we figure out the actual design.

As you can see, from only three keys, {M, N, O}, there can be more than 7 objects instantiated (depending whether we take into consideration the order in which the player presses the keys, M + NÂ may not have the same sound and object as N + M, case in which we could have a number of 15 sounds with objects if we start with three initial keys). To see how many possibilities there would be if we started with four keys {M, N, O, P}, I used the same formula, adding 4Â permute 1, 4 permute 2, 4 permute 3 and 4 permute 4. This resulted in 64 possibilities, if the order matters, 15 if not.
