GAME IDEA NO. 4Â PROTOTYPE
Saturday, November 23rd [Version 1.0]
So yesterday, we discussed what we wanted to do for our third game idea prototypes. We decided it would be good if we had some interactive prototype, that would show what we mean by rhythmic game and how we want to do this: the player would be in sync with the beat of the sound, or it can set the beat during the first move.
​
Here is what I need to do in the prototype: nothing happens before the player jumps first. Then, when this happens, there is a countdown to the next beat (which can either be set beforehand, or it will be set by the time between the first and second jump - two prototypes). Then, at the next beat, the player has a certain time in which they can jump again if they want to be in sync with the beat. You can see below a timeline of the prototype:
It is a bit confusing, but Daryl's Mario double jump example helped a lot. After the first jump, you have a certain time to press space again to double jump. Our prototype is very much like this mechanic. You have to keep jumping during the time that is allocated for the beat.
​
As we decided yesterday, today I made the prototype for the last game idea.
​
To do this, I started with some squares. The big red/green square is to show when the the player should jump, having a 2.5f time in-between beats. The timer resets after that time has passed, whether the player has jumped or not. If they have, the square instantly turns red and the player has to wait for the next green square (the next beat).
To make it more like our vision of the game, but without getting overly complicated, I added a force to the right, when the player jumps, to act as gravity, and turned the camera 90° to the left, so it would appear like the player is moving down, instead of to the right. This works well for the prototype, as I don't want to make it unnecessarily complicated by adding forces to stick to the wall and other stuff. It shows what we want to say and that's what is important.
Next, I drew some images and changed the sprites of the player, green/red light and cliff. I think it helps give a better idea and expresses our vision better than some squares. Also, I added a score system. You are rewarded a point each time you jump on the beat (green light), but the score resets if you jump when you shouldn't. This also helps understand what you have to do, and if you are doing it right.
The code is pretty basic: if the player jumps, the computer checks if it's the first time it does, and if so, it starts doing the beat countdown, so the player has to follow that when jumping; then it adds force up and to the right (or left and down, if you look through the camera whose rotation has been change).
​
If this isn't the first jump, so the countdowns have started already, then it adds Time.deltaTime to the timer. If the time is within a certain interval, smaller than 0.7f (the delay time), then the player should jump. If it's between 0.7f and 2.5f, then the player should not jump, and should wait for the next beat.
​
And, lastly, the colour of the light changes depending on whether the player should jump or not. This is a visual instruction, since we don't have the beat yet.
Saturday, November 23rd [Version 2.0]
The only change in this version is the beatTime. In the previous version, the beat was set beforehand by the designer/developer. In this version, however, the player sets the beat by jumping the second time. The time between the two jumps will give the beats for the rest of the game. There are two limits however, as we decided yesterday: 0.8f <= beatTime <= 2.2f.
This will allow for a more personal experience and immersion, the player being able to influence the sound within the game.
In the code, not much changed. I only added a few lines of code. Now, the computer checks if the player has jumped once, in which case, starts a timer;Â then also the second time. If it has, then saves the value of the beatTime, if it's lower than the lowest, 0.8f, then it sets the beatTime to 0.8f, and if it's higher than 2.2f, then sets it to 2.2f. If it's in between, then sets the beatTime to what the player wanted. We set these limits because we don't want the game to be ruined by too long or too short beats.
