28 October 2014
Proposal in progress
This week there won't be any posts on this blog (apart from this one), as I'm currently working on the proposal draft which although needs to be filled up and submitted by the 7th of November, I decided to get it done a week earlier for the sake of getting it over with and not having to worry about it later. Once the lecturers will be happy with the final state of my proposal, I'll post it here.
25 October 2014
What makes a game hard to master?
Having found the elements which make a game easy to learn, I'm now undertaking research to find out the second principle - what makes a game hard to master.
Since:
'(...) we play games and enjoy the process because we are seeking to master the patter in the game. While mastering a pattern, players are having fun.' (Challenges for Game Designers page 83)
we can understand that games that are hard to master put players in the state called the flow which pushes them to carry on playing, and playing, and playing until they feel satisfied enough with their skill level. This is why it is so crucial for my prototypes to not only be easy to learn, but to also challenge the player encouraging them to work their way towards mastering the dynamics of the game.
What does it mean to master a game?
Being a master at a game means making the right decision every single time throughout gameplay. In tic tac toe, which is easily solvable, and so easy to master, the player, providing they've mastered the game, can at worst draw, but never lose. Having pointed that out, being a master at a game, doesn't mean having 100% certainty of winning the game, but having the certainty that at no point, will that player make the wrong decision.
Before I go into the main topic, let's first look at the type of game in which mastering isn't easy, nor is it medium or difficult - it is simply impossible.
Luck based games
Games which are purely based on luck are the ones that ignore player's decision making whatsoever, instead using random outside influences (dice, cards, number generators) as a form of progression. Games like this are self driven and players are only there to reveal the outcome hence it is impossible to master.
Since:
'(...) we play games and enjoy the process because we are seeking to master the patter in the game. While mastering a pattern, players are having fun.' (Challenges for Game Designers page 83)
we can understand that games that are hard to master put players in the state called the flow which pushes them to carry on playing, and playing, and playing until they feel satisfied enough with their skill level. This is why it is so crucial for my prototypes to not only be easy to learn, but to also challenge the player encouraging them to work their way towards mastering the dynamics of the game.
What does it mean to master a game?
Being a master at a game means making the right decision every single time throughout gameplay. In tic tac toe, which is easily solvable, and so easy to master, the player, providing they've mastered the game, can at worst draw, but never lose. Having pointed that out, being a master at a game, doesn't mean having 100% certainty of winning the game, but having the certainty that at no point, will that player make the wrong decision.
Before I go into the main topic, let's first look at the type of game in which mastering isn't easy, nor is it medium or difficult - it is simply impossible.
Luck based games
Games which are purely based on luck are the ones that ignore player's decision making whatsoever, instead using random outside influences (dice, cards, number generators) as a form of progression. Games like this are self driven and players are only there to reveal the outcome hence it is impossible to master.
Let's leave those, and jump into the type of games in which players can control the outcome, and get good at it. There are two skills that players can learn, develop and master. These are:
Strategy based games
Strategy based games are ones which require thoughtful decision making. One great example of a game which purely uses the element of strategic skill are chess - players have full control over the outcome of their turn, and from start to finish no outside elements, like luck are involved.
Examples of decision making in strategy based games:
The decisions a player makes in a twitch environment are of a different nature than those in a strategic game. Players still make decisions, but they are being made on more rapid basis that require fast thinking, dexterity and reaction speed. In an FPS for example, the decisions a player makes involve turning and firing.
The mechanics used for twitch type of games are:
With twitch skill based games, the 'hard to master' element is more straightforward:
'Human reaction time can continue improving over time forever' (Challenges for Game Designers, page 88)
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.
Considering target audience
Although purely luck based games seem like nonsense, they actually do have a target audience - children, since their level of strategic skill is not developed due to lack of interest (kids don't like games where they need to think), they will however enjoy playing something that requires very little input from them (throwing a dice) which provides an output which gives an equal chance of winning to all the people who participate A 4 year old girl from Newcastle can win against Stephen Hawking in a game of Snakes and Ladders.
Luck finds its target audience in the adult territory as well - gambling is one example. However given the fact that players don't make any impact on the game state, adults won't feel rewarded if they happen to win a luck based game, so games of this sort won't appeal to them.
Strategy based games as mentioned already, are not good for children, because kids brains aren't developed enough to analyse game play like adults do. Since I'm aiming at the mass market, and kids are the majority of mobile gamers, I'd be inconsiderate if I went to make a strategy based game.
Twitch based games appear to everybody. Kids like to play twitch games, because they enjoy looking at animations and interacting with them. Adults also like twitch games - otherwise there would be no sports.
Conclusion
I have found out the types of skill players can learn, and I know how to make those difficult to master. I have also considered the target audience, and what sort of games appeal to what people. Thanks to the undertaken research I know for sure that all my prototypes will be based on a twitch mechanic.
Bibliography:
Ernst, A., Dormans, J. (2012), Game mechanics : Advanced Game Design, Berkeley: New Riders
M. Tim Jones (2010), Game Design - Theory & Practice, Second Edition, Jones & Bartlett Learning
Brenda Brathwaite and Ian Shreiber (2008), Challenges For Game Designers, Delmar Publishing
Francois Dominic Laramee (2002), Game Design Perspectives, Charles River Media
Strategy based games
Strategy based games are ones which require thoughtful decision making. One great example of a game which purely uses the element of strategic skill are chess - players have full control over the outcome of their turn, and from start to finish no outside elements, like luck are involved.
Examples of decision making in strategy based games:
- Trade-offs - choosing one item, while sacrificing another. There is no right or wrong decision, but each has it's own advantages and disadvantages.
- Dilemmas - all choices will harm the player but the decision has to be made in order to progress.
- Risk versus reward trade-offs - the question that the player asks here isn't 'Which one of these right things do I want?' but rather: 'Will I risk it all for potentially huge payoff or losing the game?'. Players who are in the lead go for the safe options, while players who are behind are more courageous in their decisions, because they want to catch up.
What makes chess so difficult to master?
Emergence
As opposed to progressive games which 'offer many pre-designed challenges that the designer has ordered sequentially, usually through sophisticated level design' (Advanced Game Design, page 24), games of emergence are difficult to predict, because challenges and flow of events are not planned in advance but emerge during play. This increases space of possibility, and the chances of choosing the wrong decision. In chess players get to choose very few decisions at the beginning, but as the game progresses, the amount of decisions vastly increase each move starts to make a significant impact on the final result.
The table above shows that a game that's using emergence could be perfect for my prototypes, since they require small number of rules making them easy to learn, and their space of possibility is large, giving players so many choices to make, that mastering is very difficult to achieve.
Adding a luck mechanic
Another way of making strategy based games more difficult to solve is by adding a luck mechanic to the game.
When random elements exist in a strategic game, there is no longer a strategy that is always right. Some moves have a high chance of failure, but also a potential pay off making them a risky choice, while others are safe, but with a small gain. Since there is uncertainty about the outcome, the decisions become more complicated and thus more compelling. The mix of both, makes the game dramatic, because the player carefully crafts a strategy, but then has to depend on luck to see if the plan succeeds. Having said that, adding luck carefully, can make decision making less predictable and therefore the game will be hard to master.
Twitch based gamesEmergence
As opposed to progressive games which 'offer many pre-designed challenges that the designer has ordered sequentially, usually through sophisticated level design' (Advanced Game Design, page 24), games of emergence are difficult to predict, because challenges and flow of events are not planned in advance but emerge during play. This increases space of possibility, and the chances of choosing the wrong decision. In chess players get to choose very few decisions at the beginning, but as the game progresses, the amount of decisions vastly increase each move starts to make a significant impact on the final result.
The table above shows that a game that's using emergence could be perfect for my prototypes, since they require small number of rules making them easy to learn, and their space of possibility is large, giving players so many choices to make, that mastering is very difficult to achieve.
Adding a luck mechanic
Another way of making strategy based games more difficult to solve is by adding a luck mechanic to the game.
When random elements exist in a strategic game, there is no longer a strategy that is always right. Some moves have a high chance of failure, but also a potential pay off making them a risky choice, while others are safe, but with a small gain. Since there is uncertainty about the outcome, the decisions become more complicated and thus more compelling. The mix of both, makes the game dramatic, because the player carefully crafts a strategy, but then has to depend on luck to see if the plan succeeds. Having said that, adding luck carefully, can make decision making less predictable and therefore the game will be hard to master.
The decisions a player makes in a twitch environment are of a different nature than those in a strategic game. Players still make decisions, but they are being made on more rapid basis that require fast thinking, dexterity and reaction speed. In an FPS for example, the decisions a player makes involve turning and firing.
The mechanics used for twitch type of games are:
- Pure speed - the point is to complete a task as quickly as possible. For example in the Olympics it would be 100 metres sprint.
- Timing - tapping the screen at the right time
- Precision - in Angry Birds, depending on the angle and power of the shot, different outcomes take place, so precision matters
- Avoidance - making sure the character does not touch incoming obstacles such as enemy bullets
- Time pressure - as opposed to pure speed, time pressure doesn't necessarily force the player to complete the task as quickly as possible (although it might), but instead do it within a time limit.
With twitch skill based games, the 'hard to master' element is more straightforward:
'Human reaction time can continue improving over time forever' (Challenges for Game Designers, page 88)
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.
The flow diagram above shows that if you make the game too difficult too quickly, it'll frustrate the player. On the other hand if you take too much time with increasing game's difficulty, players become bored. Keeping balance between both is what's putting them in the - what every designer wants - flow state.
Some tuning are:
- 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
Considering target audience
Although purely luck based games seem like nonsense, they actually do have a target audience - children, since their level of strategic skill is not developed due to lack of interest (kids don't like games where they need to think), they will however enjoy playing something that requires very little input from them (throwing a dice) which provides an output which gives an equal chance of winning to all the people who participate A 4 year old girl from Newcastle can win against Stephen Hawking in a game of Snakes and Ladders.
Luck finds its target audience in the adult territory as well - gambling is one example. However given the fact that players don't make any impact on the game state, adults won't feel rewarded if they happen to win a luck based game, so games of this sort won't appeal to them.
Strategy based games as mentioned already, are not good for children, because kids brains aren't developed enough to analyse game play like adults do. Since I'm aiming at the mass market, and kids are the majority of mobile gamers, I'd be inconsiderate if I went to make a strategy based game.
Twitch based games appear to everybody. Kids like to play twitch games, because they enjoy looking at animations and interacting with them. Adults also like twitch games - otherwise there would be no sports.
Conclusion
I have found out the types of skill players can learn, and I know how to make those difficult to master. I have also considered the target audience, and what sort of games appeal to what people. Thanks to the undertaken research I know for sure that all my prototypes will be based on a twitch mechanic.
Bibliography:
Ernst, A., Dormans, J. (2012), Game mechanics : Advanced Game Design, Berkeley: New Riders
M. Tim Jones (2010), Game Design - Theory & Practice, Second Edition, Jones & Bartlett Learning
Brenda Brathwaite and Ian Shreiber (2008), Challenges For Game Designers, Delmar Publishing
Francois Dominic Laramee (2002), Game Design Perspectives, Charles River Media
18 October 2014
Marking criteria
Having provided a flexible timeline, there is one more task I need to complete, and that is to decide under what criteria do I want my dissertation to be marked on.
First let's conclude one more time what my dissertation is about:
I'm learning about Bushnell's law which states "All best games are the ones that are easy to learn and hard to master" by providing academic research from books and online resources. After learning all the theory, my next step is to start designing, developing (in Unity), and playtesting a number of simple playable prototypes, to prove that I have understood Bushnell's philosophy. The amount of prototypes will vary between one to three, depending on how fast my development process will be progressing. I will transfer my prototypes onto mobile platforms, and I'll aim to have them optimised and bug free, to prove that I have also learnt to use C# effectively.
Since my dissertation puts a particular focus on coding, I want to be marked based on how much of it I will learn throughout this year, and whether, through my prototypes I will prove that I can indeed program a mobile game.
First let's conclude one more time what my dissertation is about:
I'm learning about Bushnell's law which states "All best games are the ones that are easy to learn and hard to master" by providing academic research from books and online resources. After learning all the theory, my next step is to start designing, developing (in Unity), and playtesting a number of simple playable prototypes, to prove that I have understood Bushnell's philosophy. The amount of prototypes will vary between one to three, depending on how fast my development process will be progressing. I will transfer my prototypes onto mobile platforms, and I'll aim to have them optimised and bug free, to prove that I have also learnt to use C# effectively.
Since my dissertation puts a particular focus on coding, I want to be marked based on how much of it I will learn throughout this year, and whether, through my prototypes I will prove that I can indeed program a mobile game.
16 October 2014
Timelines for completion
Having met the following criteria:
Know your dissertation
Provide academic research on the topic
Find matching job offers
Highlight what you're capable of, and what you want to learn throughout the dissertation
it is now time to figure out a realistic timeline for all tasks I'll be facing this academic year and work out how many prototypes I'll be aiming to create.
Timelines are of complicated nature, because it is rarely possible to predict how long each development process is going to take. Being a beginner in C# it is especially difficult to guess the right amount of time which will take me to produce a game even one that's very simple. The design process as well as iterating the game is also very easy to under, or overestimate.
Having shared my worries with my lecturer Rob, I was told that I don't have to follow one timeline. I can set up three time scales, one being what I think would be an underestimation, second being what seems to be too much of a challenge, so an overestimation, and the third, that I think is neither, so the perfectly balanced timeline.
Having three timelines provides flexibility, as I can move back and forth between them, depending on how my project progresses throughout, leaving me not worrying about not having enough time to complete all tasks on time if I've overestimated it, or avoid being lazy if I realise I'm ahead of time.
So here are my three timelines:
Timeline 1 (in case I take longer with development than I thought):
Timeline 2 (in case I take quicker with development than I thought):
As the timelines show, the only differences between them are the amount of prototype development and iteration processes. If I end up following timeline 1, I'll complete one prototype (although since I'll spend so much time on it, it'll probably be a working game more than a prototype), following the - what seems like an overestimating timeline 2 will mean completing three prototypes, and the balanced third timeline, which is most likely how my dissertation will progress throughout, will provide me with two prototypes.
it is now time to figure out a realistic timeline for all tasks I'll be facing this academic year and work out how many prototypes I'll be aiming to create.
Timelines are of complicated nature, because it is rarely possible to predict how long each development process is going to take. Being a beginner in C# it is especially difficult to guess the right amount of time which will take me to produce a game even one that's very simple. The design process as well as iterating the game is also very easy to under, or overestimate.
Having shared my worries with my lecturer Rob, I was told that I don't have to follow one timeline. I can set up three time scales, one being what I think would be an underestimation, second being what seems to be too much of a challenge, so an overestimation, and the third, that I think is neither, so the perfectly balanced timeline.
Having three timelines provides flexibility, as I can move back and forth between them, depending on how my project progresses throughout, leaving me not worrying about not having enough time to complete all tasks on time if I've overestimated it, or avoid being lazy if I realise I'm ahead of time.
So here are my three timelines:
Timeline 1 (in case I take longer with development than I thought):
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
|
Uni Task
|
Post
about the dissertation timeline and marking criteria
|
20th
|
4
|
Theory
|
Post
about what makes a game hard to master
|
27th
|
5
|
Uni Task
|
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
|
Theory
|
Start designing prototype #1
|
24th
|
9
|
Theory
|
Prototype #1 designing process
|
1st Dec
|
10
|
Practice
|
Start developing prototype #1
|
8th
|
11
|
Practice
|
Prototype #1 development process
|
15th
|
12
|
Practice
|
Prototype #1 development process
|
Semester 2
|
Week
|
Category
|
To do
|
19th Jan
|
13
|
Practice
Uni Task
|
Prototype
#1 development process
Seminar
presentation
|
26th
|
14
|
Practice
|
Prototype #1 development process
|
2nd Feb
|
15
|
Theory &
Practice (T&P) |
Publish
prototype #1 on a smartphone
Get
people to playtest prototype #1
Start
iterating prototype #1
|
9th
|
16
|
T&P
|
Prototype
#1 iteration process
|
16th
|
17
|
T&P
|
Prototype
#1 iteration process
|
23th
|
18
|
T&P
|
Prototype
#1 iteration process
|
2nd Mar
|
19
|
T&P
|
Prototype
#1 iteration process
|
9th
|
20
|
T&P
|
Prototype
#1 iteration process
|
16th
|
21
|
T&P
|
Prototype
#1 iteration process
|
23th
|
22
|
T&P
|
Prototype
#1 iteration process
|
Easter holidays
|
|||
20th Apr
|
23
|
T&P
|
Prototype
#1 iteration process
Finish
with prototype #1
|
27th
|
24
|
Thoughts
|
Post
a summary
|
8th May
|
25
|
Uni Task
|
Final presentation
|
Timeline 2 (in case I take quicker with development than I thought):
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
|
Uni Task
|
Post
about the dissertation timeline and marking criteria
|
20th
|
4
|
Theory
|
Post
about what makes a game hard to master
|
27th
|
5
|
Uni Task
|
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
|
Theory
|
Start designing prototype #1
|
24th
|
9
|
Practice
|
Start developing prototype #1
|
1st Dec
|
10
|
Practice
|
Prototype #1 development process
|
8th
|
11
|
Theory & Practice (T&P)
|
Publish
prototype #1 on a smartphone
Get
people to playtest prototype #1
Start
iterating prototype #1
|
15th
|
12
|
T&P
|
Prototype
#1 iteration process
|
Semester 2
|
Week
|
Category
|
To do
|
19th Jan
|
13
|
T&P
Uni Task
|
Prototype
#1 iteration process
Finish
with prototype #1
Seminar
presentation
|
26th
|
14
|
Theory
|
Start designing prototype #2
|
2nd Feb
|
15
|
Practice
|
Start developing prototype #2
|
9th
|
16
|
Practice
|
Prototype #2 development process
|
16th
|
17
|
T&P
|
Publish
prototype #2 on a smartphone
Get
people to playtest prototype #2
Start
iterating prototype #2
|
23th
|
18
|
T&P
|
Prototype
#2 iteration process
Finish
with prototype #2
|
2nd Mar
|
19
|
Theory
|
Start designing prototype #3
|
9th
|
20
|
Practice
|
Start developing prototype #3
|
16th
|
21
|
Practice
|
Prototype #3 development process
|
23th
|
22
|
T&P
|
Publish
prototype #3 on a smartphone
Get
people to playtest prototype #3
Start
iterating prototype #3
|
Easter holidays
|
|||
20th Apr
|
23
|
T&P
|
Prototype
#3 iteration process
Finish
with prototype #3
|
27th
|
24
|
Thoughts
|
Post
a summary
|
8th May
|
25
|
Uni Task
|
Final presentation
|
Timeline 3 (balanced timeline):
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
|
Uni Task
|
Post about the dissertation timeline and marking
criteria
|
20th
|
4
|
Theory
|
Post about what makes a game hard to master
|
27th
|
5
|
Uni Task
|
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
|
Theory
|
Start
designing prototype #1
|
24th
|
9
|
Practice
|
Start
developing prototype #1
|
1st Dec
|
10
|
Practice
|
Prototype #1
development process
|
8th
|
11
|
Practice
|
Prototype #1
development process
|
15th
|
12
|
Theory & Practice (T&P)
|
Publish prototype #1 on a smartphone
Get people to playtest prototype #1
Start iterating prototype #1
|
Semester
2
|
Week
|
Category
|
To do
|
19th Jan
|
13
|
T&P
Uni Task
|
Prototype #1 iteration process
Seminar presentation
|
26th
|
14
|
T&P
|
Prototype #1 iteration process
|
2nd Feb
|
15
|
T&P
|
Prototype #1 iteration process
Finish with prototype #1 |
9th
|
16
|
Theory
|
Start
designing prototype #2
|
16th
|
17
|
Practice
|
Start
developing prototype #2
|
23th
|
18
|
Practice
|
Prototype #2
development process
|
2nd Mar
|
19
|
Practice
|
Prototype #2
development process
|
9th
|
20
|
T&P
|
Publish prototype #2 on a smartphone
Get people to playtest prototype #2
Start iterating prototype #2
|
16th
|
21
|
T&P
|
Prototype #2 iteration process
|
23th
|
22
|
T&P
|
Prototype #2 iteration process
|
Easter holidays
|
|||
20th Apr
|
23
|
T&P
|
Prototype #2 iteration process
Finish with prototype #2 |
27th
|
24
|
Thoughts
|
Post a summary
|
8th May
|
25
|
Uni Task
|
Final
presentation
|
As the timelines show, the only differences between them are the amount of prototype development and iteration processes. If I end up following timeline 1, I'll complete one prototype (although since I'll spend so much time on it, it'll probably be a working game more than a prototype), following the - what seems like an overestimating timeline 2 will mean completing three prototypes, and the balanced third timeline, which is most likely how my dissertation will progress throughout, will provide me with two prototypes.
Subscribe to:
Posts (Atom)