top of page

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.

Final Game Idea Prototype 1.x: Bio

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.

Final Game Idea Prototype 1.x: Welcome

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.

Final Game Idea Prototype 1.x: Welcome
Final Game Idea Prototype 1.x: Video

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.

PlayerMovement1.png
Final Game Idea Prototype 1.x: Welcome
Final Game Idea Prototype 1.x: Video

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.

PlayerMovement2.png
Final Game Idea Prototype 1.x: Welcome
Final Game Idea Prototype 1.x: Video

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.

Final Game Idea Prototype 1.x: Welcome

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.

ComboTable.png
Final Game Idea Prototype 1.x: Bio

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.

KeyPermutations.jpg
Final Game Idea Prototype 1.x: Bio

After I finished with calculating the eventual possibilities the game could have when it comes to the number of keys and combos, I wanted to see how other games have tackled the combo system, and I found some tutorials:

Final Game Idea Prototype 1.x: Bio
Final Game Idea Prototype 1.x: Video
Final Game Idea Prototype 1.x: Video

Both of these look rather complex to me, and I don't think we need our system to be this complicated. One thing I like and I think is going to be useful is the way they have "a list of input that you should be going through. Grab an input and test it." This seems to me interesting and exciting.
I also asked Jamie how he went about creating a combo system last year, and he showed me a link to his blog. That was much more clear and useful.

So, after reading his blog post, I figured out what I need to do: set up a few predetermined strings, and when the player presses a key, the program transform it into a char, and compares whether they are filling in any combo.

Even though it seems pretty simple, I can see where I'm going to run into problems: if there are different length combos, and one is similar to the other (e.g. M + O + N, with M + O + N +P), will the computer automatically instantiate the three key combination sound/object, or how much time does the player have to press the fourth key? Will this affect immersion by delaying the sound? I think I'll need to talk to Rylan to see how this should work, since he has more experience with music. In highschool I have worked with char arrays and did different operations on them, but then, it was a one time operation, not in a game, and this is going to make it harder to code.

Next, I want to see of I can develop this system, but I'm pretty sure I'm going to need help.

Final Game Idea Prototype 1.x: Bio
bottom of page