Iterating Square Wobble - Part 2

The main issue with Square Wobble that my playtesters pointed out, was the annoyance of having to swipe left and right repeatedly throughout gameplay. The problem with constant quick flicking was that it was not always responsive due to players not being accurate with them, and also the fact that player's fingers started to hurt after a while of playing, taking away the focus of the fun this game provides.

The reason I introduced the swipe mechanic, was to push the game closer to it being difficult to master, as swiping takes a fraction of a second longer than a simple tap, making the control of the square a tiny bit harder. However the fact it annoys players more than challenges them, is the reason why I have decided to remove the swipe mechanic, and have the square move left and right with the good old tap input.

Here's the updated code:

Next week (providing other assignments won't eat my time away) I'll get the playtesters again to hear what they have to say about the new version of Square Wobble.

Improving game balance

The point of playtesting, is to see if the game appeals to my target audience. In order to push the game towards fun, I need to know what the playtesters didn't like in my prototypes, and find solutions to their negative feedback. Then comes the iterative process, where some mechanics are modified, some added, and others simply removed.

During the iterative process, the aim is to balance the game out, so that it feels right for the majority of my audience meaning that the gameplay is not too easy, but then again not ridiculously difficult.

There are a couple of ways in which balance in games can be understood. There is balance in single player games, balance in multiplayer games, balance between strategies in games and balance between game objects.

I will focus on the ones that I can relate to with my prototypes, so balance in single player games, and balance between strategies.

Balance in single player games
From the Game Design Concepts blog, that I'm basing this entire post on, we can read that:
"In single-player games, we use “balance” to describe whether the challenge level is appropriate to the audience."

The reason why most games get harder as we beat more levels, is because our mastery level rises, and as we get better we want a bigger challenge. The change in difficulty over time in a single game is called pacing. Because my prototypes aim to be difficult to master from the start, I don't necessarily need to add pacing to increase the challenge, because mastering is the challenge itself.

I, being the creator of my games, find my prototypes relatively difficult. Every time I get asked by people what's my highest score however, they think I'm joking, or cheating because they are so high compared to what they achieved. It's a problem, because what I may find slightly challenging, can prove frustratingly difficult for my players, which can end up with their smartphone flying through the window or worse (well, for me, not for the smartphone) with them not wanting to play my game because it's too hard. Alternatively I can think that my game will be way too challenging, whereas proving too easy to my audience. This is why letting other people play my prototypes, and judging the game based on their feedback is so crucial, because it is them who are meant to be playing my game at the end of the day, not me.

The problem with playtesting is - everybody's skill is different, and where for one person the game proves too difficult to even get one point, for another getting a good score is a matter of a few tries.

The solution here is to get lots of playtesters (I get 20 which I think is a high enough number) to get a good idea of what the overall ranges are. Obviously these playtesters have to fall into the same demographic as who I'm aiming at with my prototypes, so that these ranges don't give me the wrong idea. This is why I always ask my playtesters whether they play twitch based mobile games.

No matter how much I'll try to balance my prototypes, it will be too easy for some, and too difficult for others. There's no way of making everybody happy so one trick I can do is to aim for the middle of the curve, as I will get the widest possible audience that way. I could also introduce difficulty levels to please even more people with different level of skill.

Balance between strategies
"Within a game, if there are multiple strategies or paths to victory that can be followed within the game, we use “balance” to describe whether following one strategy is better or worse than following another."

In Square Drop, there is no strategy involved. You tap when you have to tap and that is it. Things are more complex with Square Wobble. In Square Wobble players can decide to either move the square away from the incoming gap, to then squeeze it through by swiping at the right moment, or try to stay in front of the gap at all times, while controlling the trajectory of the square by quickly swiping left and right. One strategy does not have the advantage over the other.

That's good because there must not be a dominant strategy in my prototypes. The reason why is because "if the dominant strategy is discovered, astute players will ignore all suboptimal strategies. Everything in the game that is not part of the dominant strategy becomes extraneous noise."

Whereas it's ok having multiple strategies that are balanced out, as it encourages players to find the one they'll be mostly effective at, designing a game with one particularly powerful strategy makes all the other ones useless, giving players false decisions which wastes their time, making them feel deceived when they realise they've been playing my game the wrong way all that time.

When playtesting, I need to monitor what the player is exactly doing - what strategy is being used most often, which ones are performed least frequently and which ones give higher scores to make sure that there is no way of cheating.

Ways to balance games
So I've talked about discovering unbalanced mechanics, but how about fixing them? According to Game Design Concepts, in general there are three ways of balancing games:

• Maths - controlling the system through balancing in game variables
• Using my game designer instincts - changing the balance in the game until it feels right to me
• Playtesting - adjusting the game based on the results of playtests, where the players are experienced gamers who have been instructed to play to exploit and win

As with anything, each approach has their flaws - not all game elements can be balanced out using maths; my instinct is vulnerable to human error plus other game designers may not agree with me; and playtesters may not find the flaws of my prototype even though they exist.

Either way providing I use one, two, or all three of these balancing techniques, I will be iterating my game in a more reliable way as opposed to just guessing and hoping for luck.

Additional advice worth mentioning:

• Keep the prototype easy to learn and difficult to master - at no point will I want my iteration to change this core idea, that I'm following through the entire dissertation
• Make one change at a time - if something breaks after making a change, I know exactly why. If something breaks after making ten changes, I won’t know which change (or combination of changes) caused it.
• Don't mistake a confusing mechanic with a bad mechaic - there is an entire article about the importance of not removing a mechanic that is just confusing for the player, and instead explaining how it works better either by text, or preferably - visually. This is because the confusing mechanic, can actually be the core reason why the game is fun in the first place, however because of lack of information, the players are left scratching their heads. If the mechanic is fully understood by players, and they still don't like it - then it should be removed.

References:
Making Better Games Through Iteration [ONLINE] Available at: http://www.gamasutra.com/view/feature/132554/making_better_games_through_.php?print=1 [Accessed 26th February 2015]

When Design Iteration Goes Wrong [ONLINE] Available at: http://www.gamasutra.com/blogs/PeterAngstadt/20150211/236158/When_Design_Iteration_Goes_Wrong.php [Accessed 26th February 2015]

Game Design Concepts [ONLINE] Available at: https://gamedesignconcepts.wordpress.com/2009/08/20/level-16-game-balance/ [Accessed 26th February 2015]

Timeline update

Back in October, I came up with three timelines, one showing what my dissertation will look like when things go slower than expected; one when quicker than expected; and a balanced timeline which was what I believed I'd be following all year long.

The pesimistic timeline expected that I'll finish my dissertation with one prototype, the optymistic timeline - with three, and the balanced one - with two.

I'm happy to announce that as for now, three quarters through my dissertation, I am following the optymistic timeline, meaning that soon I'll be done with my second prototype, and I'll have enough time to design and develop one more.

So here's the optymistic timeline that hopefully I'll follow all the way until my dissertation project reaches its end:

(the highlighted column shows the current week)

Semester 1	Week	Category	To do
29th Sep	1	Thoughts Research	Post dissertation thoughts Post about Game mechanics used for touch screen devices
6th Oct	2	Theory Research	Post about what makes a game easy to learn Post job offers
13th	3	Technical	Post about the dissertation timeline and marking criteria
20th	4	Theory	Post about what makes a game hard to master
27th	5	Technical	Post the proposal
3th Nov	6	Theory	Post about four types of games
10th	7	Practice	Learn the basics of C# by following the Pong guide
17th	8	Practice	Start designing prototype #1
24th	9	Practice	Start developing prototype #1
1st Dec	10	Practice	Prototype #1 development process
8th	11	Practice	Publish prototype #1 on a smartphone Get people to playtest prototype #1 Start iterating prototype #1
15th	12	Practice	Prototype #1 iteration process

Semester 2	Week	Category	To do
19th Jan	13	Practice Technical	Prototype #1 iteration process Finish prototype #1 Seminar presentation
26th	14	Practice	Start designing prototype #2
2nd Feb	15	Practice	Start developing prototype #2
9th	16	Practice	Prototype #2 development process
16th	17	Practice	Publish prototype #2 on a smartphone Get people to playtest prototype #2 Start iterating prototype #2
23th	18	Practice	Prototype #2 iteration process Finish prototype #2
2nd Mar	19	Practice	Start designing prototype #3
9th	20	Practice	Start developing prototype #3
16th	21	Practice	Prototype #3 development process
23th	22	Practice	Publish prototype #3 on a smartphone Get people to playtest prototype #3 Start iterating prototype #3
Easter holidays
20th Apr	23	Practice	Prototype #3 iteration process Finish prototype #3
27th	24	Thoughts	Post a summary
8th May	25	Technical	Final presentation

Playtesting Square Wobble

Once again I got 20 people who meet my target audience requirements, to play my prototype - this time Square Wobble, and give me a constructive feedback. I've asked the same questions as I did with Square Drop, and here are the results:

If I thought Square Drop has provided me with good feedback, then Square Wobble's one is almost perfect. The game has proven to be very easy to learn to 18 people, and easy to learn to 2 people, and very difficult to master to 19 (!) playtesters, and difficult to 1.

In fact some players stated that the game is too difficult to master, and that they want bigger gaps, or slower gameplay in order to have a higher chance of succeding with squeezing the square through. Looking at the high scores, it's clear that some people struggled getting a single point after 2 minutes of gameplay, which shows a much bigger challenge compared to Square Drop, where the results averaged between 10 to 20.

One issue I stumbled across multiple times, was the annoyance of the swipe mechanic. Even after performing an improvement with this input, players still complained that sometimes they feel that the square reacts to the swipe slightly later, and that it affects gameplay. In fact the problem laid with the fact that players were performing such quick and innacurate swipes, that sometimes the game wasn't picking up on them, delaying, or not letting the square move in the opposite direction at all.

Now that I have the results, I'll be able to perform iterations, and make Square Wobble a better game.

Five Tips for Better Playtesting

Having gone through the process of getting 20 people to playtest my first prototype, I have gained a bit of experience in this area. Since I received sceptical feedback from one of the lecturers which stated that I might be a little too subjective with playtesting and iterating, I decided to make some research in these areas. Let's start with playtesting.

Having gone on the Gamasutra article called Best Practices - 5 Tips for Better Playtesting I found some valuable points that I'll share here.

Point #1 - Recruit Your Target Player
I need to find playtesters that match my target audience, or I will get feedback that may throw me off track. If my game is made for young adults who play mobile games, I shouldn't expect good advice from elderly people who've never used a smartphone before, because at the end of the day it isn't them who will play my game.

Some of the crucial questions to ask before playtesting are:

• How old is my intended audience?
• Is the intended audience predominantly male, female, or split?
• What device or platform is my game targeting? (Don't recruit players if they've never played a game on that platform before).
• Does my game assume any prior knowledge from the player?

Asking my playtesters whether they have any experience in playing twitch based games is very important, because that way I can take their high scores seriously, knowing they are familiar with this type of games, helping me identify better whether the game is difficult to master, or whether the player is just not experienced.

Another important thing is to not stick to the same playtesters all the time, but trying out those, who've never seen the game before. That way I'm increasing my chances of receiving some fresh ideas and views as of whether the game is fun to play or if it's lacking something.

Another good reason to recruit a new playtester is because as Gamasutra states:

'If you only collect feedback from your biggest fans, you're much less likely to hear about the problems that new players face on Level 1, and much more likely to hear about how great Level 10 is'

Point #2 - Test Your Test Before You Test!
Before letting people play my game, I need to make sure that it doesn't contain any bugs that could affect gameplay. I also need to prepare comfortable seats for my playtesters so that they can fully enjoy the experience.

Point #3 Take the Pressure Off
I need to let my playtesters know that I'm testing the game, and not them, so that if they get confused during gameplay, the blame goes on the game only. The playtester should also be left uninterupted, and should be encouraged to think out loud during their experience, to help understand their point of view.

It is also crucial to ask playtesters for honest opinions, because they'll do more harm saying they like the game for the sake of not sounding personal, as opposed to giving constructive criticism, and helping me push the game forward later on when iterating.

Point #4 Rock the Survey
Questions that identify certain information about gameplay (in my case it would be whether it's easy to learn and difficult to master) should be more detailed than a vague 'Was the game hard?'. Instead asking particular things such as 'From 1 to 5 how much did you struggle squeezing the square in between the obstacles' and 'Were the obstacles spawning too frequently' will provide more detailed information, making it easier to draw conclusions later on.

Point #5 Analyze
Compiling data from many people will objectively show me whether my prototype is easy to learn and difficult to master, as opposed to having one or two players telling me something, that the other 18 would have said otherwise, which at a later stage when iterating, would push the game in the wrong direction.

The issues contained in the feedback that the playtesters brought to light need to be considered and fixed, whether it's a button that doesn't always respond to a click, or a mechanic that only annoys the player. That way I will have evidence that the game is being iterated in the right area and not because 'I felt like it'.

References:
Best Practices: Five Tips for Better Playtesting [ONLINE] Available at: http://www.gamasutra.com/view/feature/185258/best_practices_five_tips_for_.php?print=1 [Accessed 18th February 2015]

Playtesting delayed

Unfortunately my plan to get playtesters for Square Wobble has been cancelled this week due to catching a flu.

By next week however I should be able to get feedback and go with conclusions from there.

Iterating Square Wobble - Part 1

Before getting my target audience to play Square Wobble, I already let my close friends give it a go.

Their feedback has been the same - the game is very difficult to master, however not so straightforward when it comes to learning (or rather getting the hang of the mechanic properly).

They've pointed out that the swiping mechanic was not responsive quickly enough, ending up frustrating them, because as they tried to move the square left and right, the game listened to them a fraction of a second later, making them feel as if they haven't got much control over the outcome and need to rely on luck more than anything.

That is obviously not what I want - I want my twitch games to be based fully on player skill, and no luck, especially if all it does is annoys the player.

So what was the reason of a delayed swipe response?

The red label shows the line of code where things go wrong:

The reason why players were getting a delayed response, was because the square would only move when not only the swipe itself took place (which is putting the finger on the screen, and moving it across), but also when the finger was released off the screen thereafter.

Because players anticipate to see the square move as soon as they swipe, and not swipe and release, they were getting the illusion of a delayed response.

Solution

Thankfully the solution is very straightforward - all I need to do is change

if(t.phase == TouchPhase.Ended)

to

if(t.phase == TouchPhase.Moved)

That way the game will listen to the swipe as soon as the finger moves across the screen, not when it releases.

References:
Unity Documentation: TouchPhase.Moved [ONLINE] Available at: http://docs.unity3d.com/ScriptReference/TouchPhase.Moved.html [Accessed 9th February 2015]

Developing Square Wobble

This week I came back to Unity, to start developing my newly designed mobile twitch game Square Wobble.

In fact it only took me this one week, to almost fully finish coding it up, along with transfering it onto a smartphone and trying it out. The reason it took me so quick, is because Square Drop had all the important code I needed to use for Square Wobble already, so it was a matter of just replacing, and upgrading certain sections of code.

It doesn't mean that I haven't learnt anything - having went onto this forum I've learnt how to do the swipe command which was necessary to use for my new prototype.

This is the stage:

That's the code:

And here comes the swipe class, that contains the new code I've learnt:

And that's the game:

The obstacles show up as soon as I make my first swipe:

I swipe right to avoid hitting the edge of the screen:

Then I perform a number of quick left-right swipes to squeeze through the first obstacle gap

Once I managed to do that successfully I receive a point, and carry on swiping in order to beat the new incoming obstacles:

Eventually when I hit either the edge of the screen, or the obstacle, the game ends, and let's me restart if swiped again.

I still need to update the obstacle spawn code, however that should take very little to no time, so I'll be pretty much ready to start getting playtesters next week already!

References:
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]