Designing prototype #2

As I mentioned in the post What do I want from my next prototype my second prototype should not be controlled by tapping, and should make use of a different twitch mechanic than timing.

After days and days of brainstorming, I came up with a game idea that I'll explain in this post.

The first thing I need to address, is that art wise the new prototype will look like Square drop - the player will be in control of a square, and the obstacles will look the same as Square Drop's platforms, however first of all I'm making prototypes, not actual games, so the artwork will naturally look similar as I'm using place holder art; and on top of that the actual gameplay will feel totally different to the one experienced in Square Drop, so my second prototype is by no means a recreation of the first one.

The game is called Square Wobble, and the point of it is to move the square, by swiping left and right (left swipe - the square moves left; right swipe - the square moves right), and squeeze it inbetween the incoming obstacles. Each beaten obstacle gives one point. Touching the obstacle, or the side of the screen will result in game over. The higher the score, the better the player has done.

The game makes use of swiping, as a form of control, and precision as a form of twitch mechanic. Below you can see an illustration that shows gameplay:

The game should be easy to learn, considering there's nothing else involved in terms of mechanics other than left swipe, and right swipe, and difficult to master, considering the square will be in constant movement, forcing the player to keep swiping left and right to avoid touching the sides of the incoming obstacles. The need of repeatedly moving the square one way or another, makes it look wobbly, and hence I called the game Square Wobble.

All this is theory - we'll see how things stand next week, when I'll start developing Square Wobble.

Seminar presentation feedback

On the 19th of January this year, I presented my dissertation progress in front of my lecturers. Just over a week later I received the mark, and the following comments:

First Marker Comments:-

This dissertation is going very well and promises much. I remain a touch sceptical about the veracity of your feedback and your methods, and would advise you to be absolutely clear on the distinction between subjectivity and objectivity. Given that your dissertation pivots around the definitions of ‘easy to learn’ and also ‘hard to master’, you should give a little more thought to how you intend to analyse your work in your post-mortems, and how you intend to integrate your conclusions in an iterative manner. Words like ‘annoying’ and ‘addicting’ can have different meanings to different people and you should attempt to retain control over your meanings, especially when conducting usability tests. Nonetheless, your presentation was excellent and your work is very encouraging so far.

Second Marker Comments:-

I am enjoying this dissertation. You are making very good efforts at integrating theory with practice. You blog consistently so it is easy to follow your progress and you have made a very simple but addictive little android game ‘Square Drop’ which attempts to hit the criteria you have set for yourself. I am looking forward to seeing what you come up with next. Keep up this good work.

Overall the feedback is positive and states that my dissertation is going in the right direction so there's not much more I can do, but carry on the way I was. The only concern is the way I deal with player feedback, so I'll improve upon that with my second prototype.

What do I want from my second prototype?

Square Drop has taught me a lot of useful features that C# consists of such as object spawning, object movement, object collision, and object destroying. The full list of syntax I learnt can be found here. My aim now, is to design and create a new twitch prototype, based on following particular rules, rather than designing one of the top of my head, because that way I could recreate something which's gameplay is similar to the one of Square Drop, and I don't want that.

What particular rules do I want to follow?

Use a different touch screen input
First of all I want to learn code for a different touch screen gesture. Square Drop was all about tapping the screen, however there are other ways in which we can interact with touch screens.

Having went on the Wireframes and Microsoft websites (links at the bottom), I found that touch screens provide the following input possibilities:

• Tapping - quickly touching the screen once
• 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
• Swiping - flipping 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

I could also make use of the motion sensor, where tilting the entire device has an effect on gameplay (Temple Run and Fall have used it for instance).

Use a different twitch element

What I also want from my second prototype is a different twitch mechanic to the one I used in Square Drop. In challenges for Game Designers, we can find out that five different types of twitch mechanics are:

• 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
• Timing - pressing the right button at the right time
• Precision - performing accurate actions
• Avoidance - staying away from harmful enemies or projectiles
• Time pressure - adding a time limit / doing something before the opponent

Square Drop focused purely on timing, so I'll avoid it and make use of one of the other four twitch elements.

On top of that, I obviously want to make sure that my second prototype easy to learn and difficult to master. What these mean, can be found under the following two blog posts:

What makes a game easy to learn
What makes a game hard to master

Conclusion:
For my second twitch based prototype, I will not use tapping, as a form of input, instead probably going for swiping, as it's popular amongst games plus would teach me some valuable code; and I will not use timing as a form of gameplay, instead going for either pure speed, precision, avoidance or time pressure (maybe merging some of them together).

References:

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]

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

Summarising player feedback and deciding what next

Last week I asked 20 people to play Square Drop and answer a few questions to help me decide whether the game needs iterations, and improving upon the easy to learn and hard to master elements. The questions were about player's age, gender, experience of playing twitch based mobile games, and opinion whether in their eyes Square Drop is easy to learn and difficult to master. These questions weren't made up off the top of my head - beforehand I read an article on Gamasutra called Best Practices - 5 Tips for Better Playtesting.

As seen in the previous post which shows the final results the vast majority of playtesters were within the target age, and do play twitch mobile games, which means that I can comfortably say that they were the target audience I'm aiming at from the beginning.

The two crucial questions I asked were:

• From 1 to 5 how quickly did you know how to play Square Drop? 
• From 1 to 5 how difficult do you think the game is to master?

The results showed that the game is very easy to learn (eighteen players voted 5/5, two voted 4/5), and relatively hard to master (three voted 2/5, five voted 3/5, seven voted 4/5, five voted 5/5).

The most interesting iteration suggestions I received were:

• Have different gap sizes - would increase randomness and unpredictability, making it more difficult to master

• Change the speed of the square every time it drops - another way of increasing randomness and unpredictability, and making the player never be certain about when should they tap

• Put a delay on the tap so that the square reacts a fraction of a second later - would make the twitch mechanic more tricky for the player, and so the game more difficult to master as well

What do I do next?
Certainly the easy to learn element is no worry of mine since the results were very positive. My slight concern however is the fact that some players haven't found the game too difficult. A vast majority were not reaching 20 points after 3 minutes of gameplay, which is ok, however there were individuals who were getting 30 and 40 points.

When we compare this to Flappy Bird, where reaching 2 points after 3 minutes is an achievement, my game doesn't look like much of a challenge.

On the other hand, more than having Square Drop very difficult to master, I value its already shining addictiveness. Every playtester was in the state of flow, glued to the screen, wanting to try one more time no matter of the score.

So should I iterate Square Drop, or move on to designing a new prototype?
Since it's a difficult decision to make at this stage of my dissertation (I'm right in the middle of it, and time is ticking away!), I'm going to list down the pros and cons of each outcome, and go from there:

The Pros of iterating Square Drop:

• Will push Square Drop towards being more difficult to master than it currently is

The cons of iterating Square Drop:

• I won't learn any new code, considering that the core mechanics are already there, and the iteration suggestions do not change them radically enough for me to learn any new C#.

The pros of starting a new prototype:

• Will have more time to design and develop a new prototype, possibly giving me the chance of creating a third prototype

The cons of starting a new prototype:

• Square Drop will be left the way it is without performing any iterations

Decision:
Square Drop is good the way it is. It's addicting, it's fun, it's difficult for most of players, and still relatively tricky for hardcore gamers (like my lecturer Chris who pulled of 47 points on his 10th try). I could iterate it, however considering my dissertation priority - which is to learn C#; the fact that my game already is easy to learn, and (relatively) hard to master; and the fact that the suggested iterations won't teach me any more code, I have decided to spend the next week designing a new prototype, and start developing it at the beginning of February. That way I'll have a lot more time and less stress working and iterating a new game, and possibly, as suggested by Dave, it'll give me enough time to create one more prototype.

Playtesting Square Drop - Part 2

On Thursday I managed to find my lecturers Rob and Dave, and let them playtest Square Drop. They were very happy with how simple the game is to pick up and play, and how difficult when it comes to getting good at it. The day after, on Friday, I let my close friends play it as well. Knowing they are all within the target age, as well as interests of my target audience, their feedback was very valuable.

Below I'm presenting the updated feedback including the 13 playtests I've done on Wednesday:

Playtesting Square Drop - Part 1

Today has been a productive day - I turned up to the University labs, and managed to get 13 people to playtest Square Drop. What that means is that for the rest of the week I just need 7 more playtesters to start summarizing their feedback and perform iterations.

This is my current feedback (the numbers in brackets show the amount of people that have selected each answer):

Having done my market research I know that the people who playtested my game, belong to the target audience I'm aiming at. Everyone apart from my lecturer Chris, were within the age range of between 18 to 25, and most of the playtesters play or have played twitch based smartphone games before.

Generally players really liked the game, they loved the idea of gaps spawning randomly, making it difficult to get into the rhythm, and overall even though most of them haven't found the game extremely difficult, they thought it was tricky enough to be challenging and addicting.

Some of the iteration suggestions were predictable, while others very interesting. As for the easy to learn element, almost all players knew how to play the game straight away, so there was no need for feedback there.

Overall I'm very happy with the results, and once I get the remaining playtesters, I'll start improving Square Drop.

Playtesting to take place next week

Next week I'll be asking twenty people to playtest Square Drop, and fill out a questionnaire asking how easy to learn, and how hard to master they thought the prototype was, and also whether they suggest any iterations. I will be also preparing for the seminar presentation which is coming in less than two weeks time.

This week my full focus goes onto the group project however, so until next week, there'll be no updates here.

C# I've learnt from Square Drop

The point of my dissertation is to learn C# at a level which will allow me to create my own simple 2D mobile phone games, as well as become an employable person in the coding industry (the list of job adverts I looked at can be found here). I'm aiming to do so by creating two prototypes which will be easy to learn and hard to master. Here's a list of C# commands that I've learned after creating the first prototype - Square Drop:

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(); }

This adds up to 16 pieces of code I have learned and used throughout the production of Square Drop. I have also used plenty of boolean, GameObject, and int variables, however having learnt how to use those already before the dissertation, I didn't include them in this list dedicated particularly to C#.

After possible Square Drop iterations due to feedback from my playtesters, I'm hoping to then create another prototype, and learn more code.