Dissertation Bibliography

A full list of reference materials I used in my dissertation:

Brenda Brathwaite and Ian Shreiber (2008), Challenges For Game Designers, Delmar Publishing

Claudio Scolastici (2013), Mobile Game Design, Packt Publishing Limited

Ernst, A., Dormans, J. (2012), Game mechanics : Advanced Game Design, Berkeley: New Riders

Francois Dominic Laramee (2002), Game Design Perspectives, Charles River Media

M. Tim Jones (2010), Game Design - Theory & Practice, Second Edition, Jones & Bartlett Learning

Thomas Finnegan (2013), Unity Android Game Development by Example - Beginner's Guide, Packt Publishing

The Keys For A Successful Mobile Game [ONLINE] Available at: http://greatpreneurs.com/keys-successful-mobile-game/ [Accessed 13th September 2014]

Youtube: androidtechman videos [ONLINE] Available at: https://www.youtube.com/user/androidtechman/videos [Accessed 19th September 2014]

Challenge and Consequence 2: The Reckoning [ONLINE] Available at: http://problemmachine.wordpress.com/2012/06/16/challenge-and-consequence-2-the-reckoning/ [Accessed 7th October 2014]

10 Games That Take Minutes to Learn and a Lifetime to Master [ONLINE] Available at: http://entertainment.howstuffworks.com/leisure/brain-games/10-games-minutes-to-learn-lifetime-to-master.htm#page=10 [Accessed 7th October 2014]

Gamasutra: Persuasive Games: Familiarity, Habituation, and Catchiness [ONLINE] Available at: http://www.gamasutra.com/view/feature  /132369/persuasive_games_familiarity_. php?page=1 [Accessed 7th October 2014]

Unity Scripts [ONLINE] Available at: https://unity3d.com/learn/tutorials/modu les/beginner/scripting. [Accessed 25 October 2014]

C# Scripting Tutorials for Unity [ONLINE] Available at: http://catlikecoding.com/unity/tutorials/r unner/. [Accessed 25th October 2014]

Finally, an interactive tutorial series that WILL teach you C# for Unity3D [ONLINE] Available at: http://forum.unity3d.com/threads/finally -an-interactive-tutorial-series-that-will- teach-you-c-for-unity3d.175410/.  [Accessed 25th October 2014]

Game Study #1: Bushnell's Law [ONLINE] Available at: http://www.teamliquid.net/blogs/155657-game-study-1-bushnells-law [Accessed 9th November 2014]

Make Pong game with Unity 2D [ONLINE] Available at: http://www.awesomeincu.com/tutorials/ unity-pong/. [Accessed 16th November 2014]

ESA EF 2014 [ONLINE] Available at: http://www.theesa.com/wp-content/uploads/2014/10/ESA_EF_2014.pdf [Accessed 1st December 2014]

Know Your Target Audience: Mobile App Development Tips [ONLINE] Available at: https://fbombmedia.com/know-target-audience-mobile-app-development-tips/#prettyPhoto [Accessed 1st December 2014]

Gamer Demographics that Every Developer Should Know [ONLINE] Available at: http://blog.apptopia.com/game-demographics-that-every-developer-should-know/ [Accessed 1st December 2014]

Mobile Social Gamers: The New Mass-Market Powerhouse [ONLINE] Available at: http://www.flurry.com/bid/57219/Mobile-Social-Gamers-The-New-Mass-Market-Powerhouse#.VKYQfYdGZjI [Accessed 1st December 2014]

Define your target audience [ONLINE] Available at: http://www.eldergame.com/2008/05/define-your-target-audience/ [Accessed 1st December 2014]

5 WAYS TO EMULATE FLAPPY BIRD'S SUCCESS—AND AVOID ITS FAILURE
 [ONLINE] Available at: http://www.fastcompany.com/3028295/lessons-learned/5-ways-to-emulate-flappy-birds-success-and-avoid-its-failure [Accessed 1st December 2014]

6 Lessons Every Entrepreneur Can Learn From Flappy Bird (R.I.P.) [ONLINE] Available at: http://www.shopify.co.uk/blog/12221109-6-lessons-every-entrepreneur-can-learn-from-flappy-bird-r-i-p [Accessed 1st December 2014]

Demographic Breakdown of Casual, Mid-Core and Hard-Core Mobile Gamers [ONLINE] Available at: http://developers.magmic.com/demographic-breakdown-casual-mid-core-hard-core-mobile-gamers/ [Accessed 1st December 2014]

2013 Gamers Survey Results: Demographics, Platforms and Smartphone Use [ONLINE] Available at: http://www.bigfishgames.com/blog/2013-gamers-survey-results-demographics-platforms-and-smartphone-use/ [Accessed 1st December 2014]

Tutorial: How to Make Flappy Bird in Unity3D [ONLINE] Available at: http://anwell.me/articles/unity3d-flappy-bird/ [Accessed 25th December 2014]

Touch: swipe, tap and beyond [ONLINE] Available at: http://windows.microsoft.com/en-GB/windows-8/touch-swipe-tap-beyond [Accessed 27th January 2015]

Touchscreen Gesture Icons [ONLINE] Available at: http://wireframes.linowski.ca/2009/04/touchscreen-gesture-icons/ [Accessed 27th January 2015]

Touchscreen gestures list and names [ONLINE] Available at: http://stackoverflow.com/questions/10675359/touchscreen-gestures-list-and-names [Accessed 27th January 2015]

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]

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

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]

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]

How to save a progress by user with diferent users [ONLINE] Available at: http://answers.unity3d.com/questions/201731/how-to-save-a-progress-by-user-with-diferent-users.html [Accessed 12th April 2015]

Unity Documentation: PlayerPrefs.SetInt[ONLINE] Available at: http://docs.unity3d.com/ScriptReference/PlayerPrefs.SetInt.html [Accessed 12th April 2015]

Dissertation Summary

All in all thanks to this dissertation I achieved my long awaited goal. As Square Drop, Square Wobble and Square Follow prove - I can now comfortably create simple twitch based mobile games in C#.

Just to show how eventful this dissertation was, here's a breakdown of what happened each month:

September 2014: Coming up with the best dissertation for me
As this post shows, long before my dissertation started, I knew exactly what I wanted to achieve with it. I wanted to learn C# through creating a number of simple prototypes for mobile devices. Initially my plan was to replicate already existing mechanics from a selection games. As pointed out by Dave however, a dissertation which revolves around re-doing games would not have enough depth to be considered a good dissertation.

What makes a dissertation stand out is when a student researches and learns about the topic of their choice, and then proves they have gained that knowledge by producing their own piece of work that follows the theory they've learned about. Depth is what really matters, not the amount of prototypes I can replicate in 8 months.

Hence I changed my plan:

It still focuses on me learning C# as I'll still be creating artefacts for mobile phones, however instead of reproducing prototypes of games that have already been created, I will design and make my own games, following the philosophy of Bushnell's law, one that states - 'All the best games are easy to learn and difficult to master.'

October 2014: Theory work
Having sorted out the structure of my dissertation, I spent the entire month researching Bushnell's philosophy. I found out the tools that'd help me make a game easy to learn and tools that'd help me make a game difficult to master. I then decided that I want to make twitch based games, as there's a high market for them (especially for mobile devices). By making twitch games I'd also learn more code due to having to code in physics such as movement or object collision.

I then looked at job adverts to find out what coding qualities companies are looking for, and then I created three timelines - one that was structured around me creating one prototype by the end of the year, one with two prototypes, and one with three. Not knowing what's ahead of me, I had to create three differently scoped timelines, to later adjust to one that suits my abilities and time management best.

November 2014: Learning C# for the first time and designing my first prototype
In November I took my first steps with C# by going through a Pong tutorial. It helped me a lot in getting the hang of syntax and the way in which physics work in Unity. I then designed my first prototype for what turned out to be Square Drop.

December 2014: Developing my first game in C#
At the beginning of December I went through a detailed market research, to make sure that I know who I'm aiming at with my prototypes (which then helped me gather the right demographic of playtesters). Then it was all about developing Square Drop - my first ever game in Unity. Although I sacrificed most of Christmas holidays just to get the game working before 2015, it was totally worth it as I've learnt a lot of C# syntax at that time.

January 2015: Playtesting Square Drop and designing prototype #2
In January I got hold of 20 people to playtest Square Drop. Having received positive feedback about the game being is easy to learn and difficult to master, I decided to not iterate it and instead design a new prototype. That decision was reinforced by the fact that by iterating Square Drop, I wouldn't learn any new code anyway.

To get out of my comfort zone and avoid creating a similar prototype to Square Drop, I decided to design one which involves a different input than tapping, and a different twitch mechanic than timing (which is what Square Drop involved). That's when I designed Square Wobble - a precision game that is controlled by swiping.

February 2015: Developing, playtesting and iterating Square Wobble
February was all about focusing on Square Wobble. Having gained some programming experience from Square Drop, it took me a lot quicker to create my second prototype. As it turned out, players did not like the swipe mechanic, so I replaced it with the reliable tap one.

During that month I've also done some research on playtesting, and iterating, to improve in these areas, since Dave told me he was scepical about the way I dealt with them.

March 2015: Designing, developing and playtesting prototype #3 
March was a rush month, because I had to make sure I get my third and last prototype ready for playtesting before everybody leaves for Easter holidays (if I let playtesting happen after Easter I'd just have 2 weeks left for iterations). I designed a game called Square Follow which is controlled using a drag input and is based on a pure speed twitch mechanic. Once again, to learn more C#, I made sure that I created a prototype which differs from the other ones.

The game proved to be too easy to some and too difficult to others. That's when I made use of the knowledge gained from October and added tuning to the game.

April 2015: Iterating Square Follow and doing first polish work
In april I iterated Square Follow and, since I had completed more prototypes than I had even planned at the beginning, I could start concentrating on polish work. I added a high score, and a restart button, I named the files, prefabs and classes correctly, added comments to code, organised the folders and so on.

May 2015: Polishing all prototypes
At the beginning of May I improved the performance of all three prototypes. I tidied up their code, I got rid of the bugs and I made them work smoother than ever. Since, thanks to player feedback and iterations they are fun to play on top of that, there's nothing stopping me now from handing them in for marking, and celebrating for what has been a fulfilling year!

C# I've learned throughout dissertation

Here's a list of the C# syntax I learned throughout this dissertation:

Function purpose	Syntax
Spawning an object	Instantiate(object_name,transform.position, Quaternion.identity);
Removing an object	Destroy(gameObject);
Controlling the position of an object	object_name.transform.Translate (x position, y position, z position);
Moving an object	var vel = rigidbody2D.velocity; vel.x = object_speed;  rigidbody2D.velocity = vel;
Referring to a particular object	GameObject.Find("object_name");
Referring to a tag	CompareTag ("tag_name");
Collision detection	void OnTriggerEnter2D(Collider2D);
Returning a random number from a specified range	Random.Range(minNum, maxNum);
Accessing a variable from another class	GameObject variableName = GameObject.Find("object_name"); Class_Name classVariableName = variableName.GetComponent<Class_Name>();
Calling a function from another class	objectVariableName = GameObject.Find("object_name").transform; objectVariableName.gameObject.SendMessage ("Spawn",null,SendMessageOptions.RequireReceiver);
Calling a class every so seconds	InvokeRepeating("function_name", startTime, repeatitionTime);
Adding an OnClick listener	Input.GetMouseButtonDown(0);
Reloading a level	Application.LoadLevel(0);
Spawning text	GUI.Label(new Rect(x position, y position, x size, y size), "text");
Setting the game orientation to portrait	Screen.orientation = ScreenOrientation.Portrait;
Playing audio	if (!audio.playOnAwake){ audio.Play(); }
Adding a swipe input	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 a drag input	//when using mouse Vector3 touchPos = Camera.main.ScreenToWorldPoint(Input.mousePosition);    // get the current position of the player GameObject Vector3 originalPos = this.transform.position;    // replace the x coordinate with the x of touched pos. originalPos.x = touchPos.x;    // set the player position to the modified one this.transform.position = originalPos;
Adding a highscore	public int score; public int highscore; //retrieve highscore highscore = PlayerPrefs.GetInt("High Score"); //set new highscore if(score > highscore){  highscore = score;  PlayerPrefs.SetInt("High Score", highscore); }
Adding a restart button	if(GUI.Button(new Rect((Screen.width / 2) - 160,(Screen.height / 2) - 40, 320, 80), "Again?")) {  Application.LoadLevel(0); }

Polishing Square Follow

Since Square Follow already went through polishing throughout Easter holidays when I had a lot of time to work on it, only a few changes took place in it compared to the previous prototypes:

• Collectable spawn rate increases more gently
• The difficulty raises quicker than before so that high skilled players find the game challenging quicker than before and don't need to wait too long for the game to get hard. Lower skilled players can still easily catch the first few collectables
• Renamed classes and objects from obstacle to collectable
• Added more comments to the code
• Added sound when the player catches a collectable for feedback purposes, and to inform that they've gained a point

Here's the updated code:

Square Class:

CollectableClass:

CollectableGeneratorClass

GUIClass:

Now that I have polished all prototypes, there's not much else for me to do but to submit them on a CD for marking purposes.

In my next post I will write a summary where I will talk about what I've done throughout this dissertation and what I make of it.

Polishing Square Wobble

This weekend I carried on working on my prototypes, this time - Square Wobble. These are the things that I have polished:

• Just like in Square Drop, I removed the sensors and gap in the obstacle prefab, and instead simply created an empty gap between the left, and the right obstacle arms.
• Because I used to give a point during the gap onTriggerExit and now the gap object is no more existent, I put an object in front of each obstacle, so that when the square touches it, it gives a point instead
• Because of removed redundant objects, the code is now a lot shorter and cleaner than before, making the game should work smoothly.
• Added the highscore
• Added the restart button
• Added new skins making the score always appear in the middle, and highscore in the top right corner with smaller font
• Renamed some variables and objects so that they refer to clicking and not swiping as it used to be before the iteration
• Renamed ObstacleSpawnClass to ObstacleGeneratorClass and ClickClass to InputClass so they make more sense (will do the same in Square Drop)
• Learned how to have multiple sounds in one object by using variables to trigger them. Now the square has both - the point received sound, and the game over sound
• Updated obstacle spawning. Used the same way of coding as the one in Square Drop.
• Moved the spawn point from the position where I want the obstacles to start spawning as opposed to saying it through the code so that I don't need to remember know the y coordinates of the spawn point (will do the same in Square Drop)

As usual I'm posting the updated code:

SquareClass:

ObstacleClass:

ObstacleGeneratorClass:

InputClass:

GUIClass:

Polishing Square Drop

This week I've been working on Square Drop, and here are the things I've improved:

• The code for the platforms spawning has been improved so that a new platform spawns when the previous one is in a certain y position, as opposed to when it gets destroyed as it used to be. The distance between the platforms should be more equal now than what it used to be
• Added a highscore
• Added a restart button
• Used a skin to allign the score text so that it stays in the middle no matter how big the number is
• Used a skin to allign the score in the right hand corner of the screen, and made the font smaller than the actual score so that player's eyes are focused on their score
• Removed the gap and sensor objects attached to the platform, as they were redundandly taking up space and instead coded the game in a more reliable way without using them

There were possibly some more tweak ups I have done but forgot to note down, but nevertheless the most important ones I have mentioned.

Here are the screenshots of the updated code:

SquareClass:

PlatformClass:

PlatformSpawnClass:

GUIClass:

ClickClass:

Polish time

Having reached the point, where after having gone through iterations, all three prototypes have become easy to learn and difficult to master, I am going to start polishing them. Since my dissertation puts a high focus on coding (that's what I want to be marked on), polishing will be mostly code related. Polishing will include:

• Organising folders
• Naming objects in the scene appropriately
• Naming the classes appropriately
• Naming the variables and functions appropriately
• Improving the code so that the prototypes' performance is enhanced
• Adding comments to the code
• Building the prototypes for a PC so that they can be played using a computer

I will start with Square Drop, then over the weekend I'll work on Square Wobble and at the beginning of next week I'll polish Square Follow.

C# I've learned from Square Follow

Just like the previous prototypes - Square Follow has taught me some new C# commands.

Drag input:
//when using mouse
Vector3 touchPos = Camera.main.ScreenToWorldPoint(Input.mousePosition);

// get the current position of the player GameObject
Vector3 originalPos = this.transform.position;

// replace the x coordinate with the x of touched pos.
originalPos.x = touchPos.x;

// set the player position to the modified one
this.transform.position = originalPos;

Adding a highscore:
public int score;
public int highscore;

//retrieve highscore
highscore = PlayerPrefs.GetInt("High Score"); 

//set new highscore
if(score > highscore){
highscore = score;
PlayerPrefs.SetInt("High Score", highscore); 
}

Adding a restart button:
if(GUI.Button(new Rect((Screen.width / 2) - 160,(Screen.height / 2) - 40, 320, 80), "Again?")) {
Application.LoadLevel(0);
}

I also learnt more about controlling the font size, text allignment etc. through modifying skins:

Playtesting Square Follow - Part 2

This week once more I asked a number of people to playtest Square Follow and let me know if the game has improved since last time.

Here are the results:

Adding tuning was a very good iteration, as lower skilled players could finally play without being frustrated that the game is too difficult from the start, whereas higher skilled players after reaching a certain score were finding the game challenging enough that they were eventually getting defeated by it. This resulted in the game proving addicting to differently skilled players.

The feedback results prove that in player's eyes Square Follow is now easy to learn, and difficult to master.

This means that I have reached my goal and Square Follow needs no further iterations. Before I write any conclusions regarding this dissertation, I will be spending the remaining two weeks on improving the performance of all the prototypes I created by improving their code.

As usual I'll be posting about these improvements in here.

Adding a restart button

As mentioned in my previous post First Square Follow feedback adding a restart button will improve user friendliness in a way so that players won't accidentally skip their score when the game is over.

To add a working button quickly and easily all I had to do was return to the OnGui function, and add the following piece of code when the game is over:

The if statement automatically adds a click event listener which allows the button to trigger the function once the player presses it, and then there's the positioning and what text the button will say, in this case 'Again?'.

This is what the button (and the earlier this month mentioned highscore) look like in practice:

Tomorrow I'll get my first wave of playtesters to try the updated version of Square Follow.

First Square Follow feedback

I've been gathering a number of people lately to playtest Square Follow, but before I show the final results, I'll wait until I get more people next week when everybody's back from Easter holidays.

Anyway one feedback I received I thought I'm going to share here because I find it quite important.

It isn't related to the game itself, but it's more about user experience. The way the game works at the moment, is that when the player loses the game, they receive the 'Again?' message to encourage them to try again, and once they tap the screen the game restarts. As this happens the score resets back to zero so that the player can generate a new score again.

The problem with that is that in the heat of the moment, when players tap the screen repeatedly, they may miss out on the fact they lost and carry on tapping, resulting in restarting the game, without them seeing what their final score was. Although this was the case with only one of my playtesters, I can see it causing a lot of frustration if it happens to others, so I came up with a solution that should fix this.

I should add a restart button.

That way players will need to touch the screen in a specific place, in order to restart the game and reset the score, as opposed to click anywhere on stage to let it happen.

I will code this new feature in by this weekend.

Adding a highscore

It's a no brainer that every game involving a score should have a highscore to challenge the player to beat it. Particularly with my prototypes, where the score is the only way to tell how well the player has done, a highscore is indispensable.

Having said that I've done a bit of research to find out how to save a variable even after the application is closed and then re-opened which would enable to save a highscore.

PlayerPrefs.SetInt("variableName", variableName);

and:

PlayerPrefs.GetInt("variableName");

is what I needed. SetInt remembers a variable whereas GetInt retrieves it.

Here's the updated Square code where I put them:

Now it is only a matter of placing the highscore textfield in the top right corner and leave it there for players to compare with their score.

References:
How to save a progress by user with diferent users [ONLINE] Available at: http://answers.unity3d.com/questions/201731/how-to-save-a-progress-by-user-with-diferent-users.html [Accessed 12th April 2015]

Unity Documentation: PlayerPrefs.SetInt[ONLINE] Available at: http://docs.unity3d.com/ScriptReference/PlayerPrefs.SetInt.html [Accessed 12th April 2015]

Iterating Square Follow

To make Square Follow playable for lower skilled players, and challenging for those who are good at twitch based games, I decided to introduce a difficulty curve and increase the collectable spawn rate depending on the score. Here is the updated code:

I will be checking if this improvement has made my last prototype a better, more addicting to a wider audience game, by performing one more playtesting process. Because of Easter holidays, I will probably need to wait for 2 weeks before everyone's back in order to do so.

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.