Adding tuning to Square Follow

In my previous post I found that for some, Square Follow is too easy and not really challenging, whilst for others so difficult, it discourages them from playing.

How can I satisfy both types of players?

The solution has been mentioned on this blog in the October post What makes a game hard to master.

Back then I said:

'Since I'm planning on having one mechanic in my prototypes, there's a high chance that with a twitch mechanic the game will either quickly become boring, or it'll be so difficult to master, that players will be left frustrated. This is when I should use tuning as a way of keeping a healthy balance within the gameplay.'

So here are the three tuning techniques I could use:

• Difficulty levels - having an easy, medium, and hard difficulty options, allows players of different skill to play the game
• Dynamic difficulty adjustment - the difficulty changes during gameplay depending on how skilled the player is
• Difficulty curves - games which get progressively harder as they carry on

Difficulty levels - I don't like having difficulty levels, because I want people to say 'I just scored 250 points!' without the additional 'on easy/medium/hard difficulty!'. I want to keep my game as straightforward as I can, and by having difficulty levels that will not be the case anymore.

Dynamic difficulty adjustment - My game isn't complex enough to put dynamic difficulty adjustment in place. Players either catch the collectable or they don't. Because of only having that one crucial true-false variable, there is too little involved to allow the game to adjust the difficulty during gameplay. Even if I have somehow put it in place however, players could pretend to be bad at the game, only to make it easier for them to get better scores which would be an obvious way to exploit it Square Follow.

Difficulty curves - this seems like the best solution to my issue. I need to find a way to make the game easy for everyone at the beginning, but progressively more difficult throughout gameplay so that eventually even high skilled players miss a collectable. That way Square Follow will be playable for low as well as high skilled players whilst keeping them both challenged and entertained throughout gameplay.

One way I could make the game more difficult over time, is increase the speed of the collectables. The problem with that though, is that if they move really fast, frames may not catch up effecting in either the game slowing down (ironically), or the collectables lagging, and skipping frames, which would obviously frustrate the player.

I could also not do anything to the collectables and instead gradually decrease the speed of the player as opposed to having him stick to wherever their finger is. That would force players to act in advance, and drag their finger earlier to catch the collectable on time. Having gained the experience from Square Wobble however, and the fact that players hate when their action is delayed on the screen, automatically makes me restrain from this idea.

One final difficulty curve idea, which would neither cause technical or gameplay issues, would be to control the spawn rate of the collectables depending on player progress. At the beginning the collectable's spawn rate would be low enough for even the worst players to handle. Overtime, when the score would get higher however, the game would increase the collectable spawn rate progresively so that even the highest skilled players would eventually find it challenging to keep up with catching them. I think doing so will fix my current issue with Square Follow.

In conclusion to fix the issue that came out the playtesting process, I have decided to add a difficulty curve to the game by progressively increasing the collectable spawn rate.

Playtesting Square Follow

I managed to get 20 playtesters to try out Square Follow. I'm really glad because with Easter Holidays approaching next week, I wouldn't have had the chance to complete the playtesting process anytime soon have I not done it this week.

Here are the results:

The game proved to be very easy to learn. Whether it's difficult to master is another story - to some people the collectables were falling way too fast discouraging them from playing after only a couple of tries, whereas to others they were falling slow enough to carry on catching them and getting insanely high scores very quickly. Widely spread out player scores clearly prove that.

Having said that while to ones the game is too difficult to master, to others it's not much of a challenge.

This is definitely a problem because instead of having one group of players frustrated because they just cannot physically keep up with the collectables as soon as the game starts, and the other group not feeling challenged as they can get any high score they like, I want everyone to find the game both managable to play, yet difficult to master.

In my next post I'll try to find a solution to this problem.

Developing Square Follow

Throughout the weekend I managed to successfully program and put Square Follow on my tablet. I learnt how to code the drag input control, and I've performed some tweaks to spawning (which has proven a lot more reliable, so I'm going to use it for the other two prototypes as well).

Without further ado here's the stage:

Here are the scripts (with the new drag input code):

And this is the gameplay:
1. Players see the square that they're taking control of by dragging it left and right

2. Collectables start falling from the top of the screen

3. Before the first collectable reaches the bottom, others start falling too. Besides spawning repeatedly, they also move really fast (pure speed mechanic), so the player needs to be fully focused to react quickly and catch them

4. The player has cought their first collectable. They received a point.

5. They didn't drag the square to the right quickly enough to catch the second collectable. It is now too low to be caught, so the game is over. The player finished the game with one point. Once the screen is retouched, the game restarts.

My last job is naming the scripts and prefabs appropriately (for instance instead of obstacles, that I'm not using anymore, call the falling squares collectables).

This week I'll try getting playtesters to as usual see if they think the game is easy to learn and hard to master and ask about their iteration suggestions.

Designing prototype #3

In my previous post - What do I want from my third prototype, I made it clear that for my last game, I should avoid having tap and swipe inputs, as I've already coded them in before meaning I won't learn anything new; and preferably not use timing or precision elements, instead going for either pure speed, avoidance or time pressure.

My third and final game idea is called Square Follow. Player's job is to move their character left and right using the drag input. Whilst they do that they must not miss touching any of the squares that fall down from the top of the screen. Each caught square gives 1 point. The goal is to catch as many squares as possible. The illusion of the player constantly having to change position of their character, based on where the squares are dropping from, gives the illusion of the player following their path, hence I called the game Square Follow.

Because the squares will be falling down really fast, the game will make use of the pure speed twitch mechanic, forcing the player to react quickly and accurately (meaning it'll make use of precision too).

To make it easier to understand, below I'm visually representing the gameplay of Square Follow:

Red square: player
Black squares: the squares that the player needs to touch as they fall

The last screen shows the player missing the black square meaning they lost. When the screen is touched thereafter, the game restarts.

From next week onwards I'll start developing Square Follow. As usual I'll be showing my progress in here.

What do I want from my third prototype

I'm really glad that I have come to the point where I can comfortably think about my third prototype. My progress is getting along very nicely considering that at the beginning of the academic year, I was prepared that I may only create one prototype in the entire dissertation.

As I mentioned in my post What do I want from my second prototype, when thinking of a new game, I want to follow particular rules to avoid creating something which's gameplay could resemble my previous prototypes.

Those rules can be read in the mentioned post, so I'm just going to list down what I have used in my previous prototypes and what's left over for me to possibly use in my next prototype:

Touch screen inputs:

Used:

• Tapping - used in Square Drop and later in Square Wobble
• Swiping - used at the beginning in Square Wobble

Not used:

• Double tapping - quickly touching the screen twice
• Pressing and holding - touching the screen in one spot for a longer duration of time
• Dragging - moving the finger across the screen
• Pinching - putting two fingers together, and spreading them out
• Rotating - putting two fingers close to each other, and rotating them

Twitch elements:

Used:

• Timing - used in Square Drop
• Precision - used in Square Wobble

Not used:

• Pure speed - performing a routine task in a minimum amount of time / performing a repetitive task as many times as possible within a set time limit
• Avoidance - staying away from harmful enemies or projectiles
• Time pressure - adding a time limit / doing something before the opponent

Of course on top of those, I need to remember to follow Bushnell's philosophy as well.

Next week I'll come up with the design for my last dissertation game. Lately, I'm taking things slowly on this blog, because of the wave of other assignments that have taken a considerate amount of my time, however I'll remain steady and reach my goal over Easter when I should get a lot more time.

C# I've learnt from Square Wobble

After the iterative process, Square Wobble turned out to be a fun, easy to learn, and difficult to master type of game (arguably more difficult than Square Drop). It took me much quicker to develop than Square Drop, however I still learned some things:

The swipe input
Swiping is probably the second most popular input after tapping. Since I want to be creating more casual mobile games in the future, learning the following piece of code has been very valuable to me:

if(Input.touches.Length > 0){
Touch t = Input.GetTouch(0);
if(t.phase == TouchPhase.Began){
//save began touch 2d point
firstPressPos = new Vector2(t.position.x,t.position.y);
}
if(t.phase == TouchPhase.Moved){ //use .Ended for slower response time
//save ended touch 2d point
secondPressPos = new Vector2(Input.mousePosition.x,Input.mousePosition.y);

//create vector from the two points
currentSwipe = new Vector2(secondPressPos.x - firstPressPos.x, secondPressPos.y - firstPressPos.y);

//normalize the 2d vector
currentSwipe.Normalize();

//swipe left
if(currentSwipe.x < 0 && currentSwipe.y > -0.5f && currentSwipe.y < 0.5f){
rightSwipe = false;
leftSwipe = true;
}
//swipe right
if(currentSwipe.x > 0 && currentSwipe.y > -0.5f && currentSwipe.y < 0.5f){
leftSwipe = false;
rightSwipe = true;
if (!audio.playOnAwake){
audio.Play();
}
}
}
}

Adding sounds
Besides swiping, I've also learnt how to add sounds to the game. All that's needed to be done, is select the prefab which will activate the sound through code, add the Audio Source component to it, select the sound we want to be using, and deselect the play on awake variable (unless we want to hear the sound when the game starts).

Then we just need to add the following code to a line when we want the sound to trigger:

if (!audio.playOnAwake){
audio.Play();
}
I placed it inside the swipe code (tap code after performing the iteration) and it works fine.

Swipe code source:
Swipe in all directions Touch and Mouse [ONLINE] Available at: http://forum.unity3d.com/threads/swipe-in-all-directions-touch-and-mouse.165416/ [Accessed 8th February 2015]

Playtesting Square Wobble - Part 2

This week I got the same people as last time to play Square Wobble. This time round, the only two questions I asked them, was whether they find the game better with a tap mechanic, and whether the game is still difficult to master.

Here are the results:

It is unquestionable that players prefer the tap mechanic. It's reliable, less annoying and provides a more comforting experience. Looking at their high scores and opinions about how difficult they found my prototype, we can see that it has become slightly easier to master, but still challenging enough for it to be addicting.

In conclusion, after performing the iteration of replacing the swipe input with a tap mechanic, Square Wobble has remained easy to learn and difficult to master. What has changed for the better is the gameplay experience, which is not annoying anymore, allowing players to focus on the fun only.

Soon I'll start designing and developing my 3rd and last prototype.