Creating Levels

Now that I've coded the tools and framework to help me quickly make new levels, I can actually begin setting up the game. The levels I design, and the order that I chose to present them in, will lend to the central concern of my research; how should you pace your game's difficulty? How do you keep your player in 'flow'? Do concepts such as 'the hook' (the exciting entry for your game) which, according to Jesse Schell, serves to immediately draw in your audience, remain valid when trying to start the player off gently, or is it actually a bad design decision that will only frustrate your player?

The premise of my puzzle game is that it's a self-influencing geometry game, much like a Rubik's Cube. More specifically, the puzzles can always be solved with a certain order of moves, and the actual game is figuring out which moves to make.

It's fairly obvious that a game's difficulty should start out relatively easy, and end with a very challenging 'test'. Kremers - in his book Level Design - cites this as a major concern for the level designer. Kremers places a lot of focus on all games as being about mastery - that is, the real fun in most games is becoming skilled at controlling a system and achieving objectives. He stresses the importance of teaching your player new aspects of playing the game in each level, and then testing their skills, be that with a boss-fight, a difficult puzzle, or a particularly dangerous level.

Generally, it seems that a level should teach one new concept at a time. A level should never demand multiple concepts and skills that the player has not yet learned; it should only demand learning a single new skill. But that's a general guideline.

(Will Wright's demonstration of progression in The Sims. Source: https://youtu.be/CdgQyq3hEPo)

In one of his lectures on game design, Will Write - creator of The Sims - pointed out that the first hurdle for a player to overcome is the game's interface. So, for example, in The Sims, the first action a player will try to perform is moving a character, or interacting with an object. Similarly, the first level in my game simply teaches the player how to move slices to their goals:

Level 1 (seen above) includes no complications, such as locked slices or multiple gem colors. It simply allows the player to try moving a gem-slice by rotating circles - the key principle of the game. After briefly showing this to my module tutor - who hasn't played many puzzle games and was unfamiliar with the interface - it became clear that I'd also need to somehow indicate the input itself (clicking) to a new player.

Moving on to more complex levels, here's Level 2:

The concern of Level 2 is to introduce the player to 'locked' slices, which prevent circular pieces from rotating. To solve this puzzle, the player needs to rotate the blocking piece. This is another example of levels serving as a test-barrier, where players cannot progress unless they understand a key concept, thus preventing them from moving on to levels they're not ready for, and falling into the anxiety' side of the flow channel.

When creating and ordering my levels, I generally give them a solid purpose; a lesson that they need to teach the player. Each level introduces two things. Sometimes, several levels can be dedicated to one concept, especially if that concept is difficult, or needs to be tried in different scenarios (locked pieces with one gem, locked pieces with two gems, locked pieces with three gems ...).

Level 3 introduced multiple gems. It also maintains locked pieces, and features a more complex lock-conundrum, resulting in the player having to focus on ordering their moves (Does this level introduce too much? There are two new concepts and one freshly understood one. However, players seem to manage the level fine. These are the questions that I hope to gather data on).

Level 4 once again introduces an order puzzle, but this time it's more central and more concise. This may actually be a better order-puzzle demonstrator than the previous level. I may want to swap Level 3 and 4 around.

Level 5 pushes order-priming into full swing. It requires one of a few very specific solutions, requiring much experimentation. The few play-testers so far have managed to solve the puzzle in around 15 minutes, after much experimentation. They start to figure out the steps they should take one at a time. It's actually become clear that a puzzle-reset button would be great.

Note that the structure of these puzzles is, roughly:

1. Interface.

2. Difficulty-inducing mechanic and key concept (locked slices).

3. Order puzzle (intermediate).

4. Order puzzle (intermediate/easy?).

5. Order puzzle (hard).

Ignoring the possible error with how I've ordered 3 and 4; the final three puzzles represent a culmination of understanding order solutions. This is the teach-test structure. You teach the player a concept, and culminate with a test. From what I've read, it seems that this final text corresponds to the crest of an oscillating game pace:

Following the crest of the curve (The test, in this case Level 5), the game's pace drops back to a slow one, as a new skill is introduced. Schell has discussed rewarding your player's crest-test-passes with a new mechanic, or an empowerment. For example, once you've mastered the grenade pickup, you'll always have 5 grenades each level. However, I can't imagine how my puzzle game could support this technique. Instead, each new dip-and-crest would represent a new style of puzzle; more gems, more complexity, or new auxiliary mechanics (which I haven't yet added).

My next step will be to polish the game with a tutorial, and construct a survey for participants to fill out. Then I'll gather my first batch of data.

Creating level-building tools in Unity to allow speedy level creation

When I send out my game to gather user data, I intend to be able to quickly create and adjust levels. Faster level creation saves time at the beginning of the project when creating the initial setup, and subsequently, as I start to gather feedback and make adjustments to the design of my puzzle's progression, difficulty curve, and pacing.

To elaborate; when building my circle-rotation puzzle game in Unity, there are two main approaches:

The normal 'messy' way: This would involve me placing puzzle pieces to create my levels, one by one. I'd have to set which pieces are locked, and texture accordingly. This would work out fine eventually, but it would also A) take more time to create each level, and B) Make it difficult to make changes without messing something up, applying the wrong texture, etc.

The custom-editor 'elegant' way: Unity supports a large degree of customization. That is, if you want to make a button in the engine's editor that resets the position of all enemies in the game - rather than selecting each enemy and doing it yourself - you can do that without too much difficulty. And, in my case, say I want to ask the engine to look at all the data for the circle-pieces, which slices they're locked to, etc. and apply the appropriate texture (because it needs to be clear to the player which pieces can and can't rotate), I can do that.

(Left) Screenshot of how editing puzzle pieces would work in Unity with the 'messy' option. Locking slots can be done by ticking the boxes under 'Slots Locked', but the effect on the textures of the slice pieces won't appear until either the game starts, or until I assign it manually. This would be time consuming with complex puzzles.






So, by creating a custom editor class, I can override Unity's (already quite useful) editor features, and automate the process of assigning textures based on data, such as which slots are locked.

This is easier said than done. Creating the control system required a fair amount of debugging, and took two weeks. But the basic control structure is quite simple. Again, keep in mind that my main objective here is to allow textures to be assigned automatically. I want locked puzzle pieces to be easily picked out ...

1. Locked slots are counted up. There can be either 1, 2, 3, or 4 locked positions on a given circle piece.

2. In the case of 1 locked slot, a single-lock texture is applied to the circle piece. For 3 and 4 locked slots, it works the same way. However, if a circle piece has 2 locks, it could be either 'L' shaped, or with the two locks opposing each other.

3. The locked circle piece textures are rotated appropriately.

4. Locked textures are also applied to the slice pieces.

Using placeholder textures where the red arrows indicate locks, and to which direction the piece is being locked, here's the result:

These four circle pieces had their 'lock' indexes assigned with the clock of a button. Then by pressing the 'Update Graphics' button (that's my custom-inspector work), all of these red-arrow textures can be assigned automatically, vastly reducing the workload.

So if I ever wanted to make an adjustment to a level, the changes should be easy to implement. This will allow me to respond quickly to the feedback I gather.

Designing a Puzzle Game

To continue investigating how to design progression, difficulty, and tutorialship into a video game, I've decided to take my creative research into practice; I'm going to design and program a game, then send it out to testers, where back-end scripts can gather some data. I can use this data to look at areas such as flow, interest curves, and learning curves.

Creating a Game

In any case, creating a game isn't easy. But I've created a few small prototypes over the last few years, and I think I'm capable of quickly designing a game that's fun, simple, and ideal for my research. Note that, rather than simply designing a fun game and then programming it, my actual area of research is using this game to learn more about difficulty progression.

What kind of game should I make? Whatever I make, it needs to be;

- Simple, and easy to build (time is limited).

- Easy to create new levels or content with. Making new levels will be my primary way of improving the game as I gather data. I'll need to look at how hard each level is, and what systems it introduces.

- Easy to extend. The game may require new features.

Given these criteria, a Puzzle game seems ideal. Puzzle games already heavily incorporate the principles of difficulty progression. They represent very logical, definite examples of problem solving. In The Art of Game Design, Jesse Schell defines puzzles as a game where the objective is to find the dominant strategy, whereas in most games a dominant strategy should be avoided. For this reason, puzzle games generally have a one-time replay value, since once the solution is known, the puzzle is no longer fun.

And, of course, Portal, mentioned in the previous post, is a great example of a puzzle game.

Puzzle Game Design

Puzzle games are abstract, and often involve mechanics that depend on problem solving, hidden information, and sequences. Quiet often, they can be (and are) solved by applied mathematics.

After doing some sketches and brainstorming, I came to a concept where overlapping circles - with moving 'slices' on the overlap areas - can be rotated, in order to move the slices to the correct location.

The principle is quite similar to a Rubik's cube; it's a self-influencing geometry problem. Solving the puzzle is difficult because trying to move one slice often moves other slices. The puzzles aren't always automatically fun; they need to be designed to be fun. I need to create the levels manually. But it seems to be a pretty easy process.

Programming and Building

I used Unity to create the game. I'm very familiar with Unity, and with programming in C#. I hoped that creating this game would be quite easy; it features simple, easily defined mechanics. However, writing the scripts to handle the puzzle pieces and the game's logic actually proved to be pretty difficult.

The first time I scripted everything, I was met with dozens and dozens of errors - I'd solve one and face another. It started to become clear that a lot of these errors were down to script-execution. I was attempting to keep my game's programming neat and concise by keeping everything modular; puzzle pieces were their own classes, they inherited from a parent class, etc. I thought this was good practice, but it seems I've misunderstood how to properly use Object Oriented Programming.

In the end, I had to overhaul everything twice, and the endeavor took me more than a week of non-stop tinkering. I'm an aspiring designer, but I also love to code and want to get better at it. It's becoming pretty clear that I need to read some of the literature on the issues surrounding manageable code. Code Complete seems like a good place to start.

But, finally, I got the game to work. My final architecture looked something like this;

There's probably a name for this kind of design pattern; I've seen it in Civilization V's map generation script. Anyway, in the end, it wasn't very Object Oriented, and probably terribly inefficient, but it's neat and it works.

So, with this game, I'm ready to start building levels, setting up back-end scripts to gather data, and sending it out to test players.

Feedback On Presentation 2

After presenting my plans for a second time to the class, I received feedback. This feedback addressed my plans towards the conclusion of this project. Currently, I hope to address ideas about tutorials - such as the ideal shape of an excitement or learning curve, whether it requires a "hook" at the start, or whether covert/overt tutorials are preferred by the player. I can draw conclusions in these areas by releasing my game, and reviewing user data scientifically.

However, my tutors reminded me that this would be a difficult task, and that my game only represents a single type of game. Findings from this game might be highly contextual, and not applicable as general rules. With this in mind, I should focus my research on understanding my game in particular, rather than all games and how a designer should approach their tutorials.

The Oscillating Flow Model

Mihaly Csikszentmihalyi proposed the 'flow' model as a psychological explanation of an extreme state of joy/focus. He developed the model by studying the work process of painters, many of whom did not expect their art to be profitable, and many of whom lost interest in their work once they were done with it. This raised the question: what was motivating the painters to paint? To answer this question, Csikszentmihalyi developed his flow model, which assumes that human attention is a sort of limited resource, and that people enter the state of flow when their attention is entirely focused on achieving a task (Csikszentmihalyi, 1988)

Csikszentmihalyi's model has a lot to say about human consciousness, and the concept of the self, and how these agents may have evolved. But of the greatest interest to game designers is his assertion that ...

"The universal precondition for flow is that a person should percieve that there is something for him or her to do, and that he or she is capable of doing it." (Csikszentmihalyi, 1988, p.30)

... and, furthermore, that there must be a balance between the skills of a person, and the challenge of the task they're facing, for flow to occur. Too much challenge, and the person is anxious. Too little, and the person is bored. He goes on to explain that flow will cease when an activity's challenge is exhausted. Thus, tic-tac-toe is easily mastered and discarded, but chess remains interesting for centuries.

Flow can be expressed in a graph, like this:



Jesse Schell - mentioning this model - takes it a step further. He argues that, though acceptable, a linear increase in difficulty will be less interesting that an oscillating one. This sinusoidal relationship between challenge and skill - such that the flow's trajectory is punctuated by moments coasting anxiety and moments coasting boredom - can be seen in many games, and will feel more satisfying to the player. Schell gives the example of a shooter where the player is given a weapon. The player must use this weapon to fight an increasing number of enemies, and overcome increasingly difficult challenges, until they eventually pass the most difficult challenge and the 'crest' of the flow oscillation. Following this, the player is given a new, more powerful gun, providing momentary relief of challenge, which rewards the player's efforts. This relief is soon met with increasing challenge again (Schell, 2015, p.141).

This version of flow can also be expressed as a graph:



With this in mind, I'm hoping to create a game that emulates at least one oscillation in the flow channel. The game should begin easy, then ascend to a more difficult level.


References
- Csikszentmihalyi, M. Csikszentmihalyi, I. S. 1988. Optimal Experience: Psychological Studies of Flow. Cambridge: Cambridge University Press.
- Schell, J. 2015. The Art of Game Design: A Book of Lenses. 2nd ed. Boca Raton: CRC Press.

Csikszentmihalyi's Flow Model

The flow model is a psychological model about motivation and learning. It's a recurring tenant of my creative research. Developed by Mihaly Csikszentmihalyi, it describes a mental state of extreme focus and joy, called 'flow'. For Csikszentmihalyi, flow is a very central and important emotional component of our lives, but I'm more interested in how it applies to learning, and skill. Below is a graphical representation of flow seen in Csikszentmihalyi's book.

The graph's axes represent the skill of a person performing a task, and the challenge of that task. If the person's skill far exceeds the requirements of the challenge, i.e. if the person finds the task very easy, the resulting emotional state is boredom. Conversely, if the challenge is beyond the participant's skill level, this person will be anxious, or frustrated, with the task. Neither are preferable emotional states, but between these areas is the 'flow channel', where the degree of challenge in the task matches the person's ability to complete it; the challenge is difficult enough to demand the application of their skill, but not so difficult that it is beyond their abilities. Just as a low-skill individual would be happy to complete low-skill tasks, a high-skill individual could perform high-skill tasks and still be in flow.

The implications for video game design can be simply stated as this: at any given time in your game, the challenge given to your player must be neither too easy, nor too difficult for their skill level. In order for the player to actually enjoy solving the problem, the game must match them with an adequate challenge. Examples in video games of all kinds are ubiquitous. Skyrim is often criticized for having dungeons and monsters that do not increase in complexity or skill. The player may find Skyrim's dungeons a lot of fun at the start of the game, but as they level up and unlock new abilities, in addition to just becoming better at handling the game's combat encounters strategically and reflexively, the skill-to-challenge ratio quickly falls into the boredom zone. But in Crusader Kings II (CKII), a grand strategy game set in medieval Europe, the player is advised by the game to begin a session as the Duke of Normandy, or as King Harold of England, right in the heat of the English war of succession. Navigating this event skillfully requires a good understanding of Crusader Kings's war mechanics, city building, complex political gameplay, and many more elements that a new player - or even a seasoned one - will not be ready to employ. Such an experience easily falls into the anxiety section of the graph, and will likely result in a frustrating and confusing first game of CKII, possibly resulting in the player never trying to play again. All this happens because the game actually suggests that a new player should try to play as these characters, rather than a much easier, much slower-paced and smaller scale start as a duke of Ireland, or vassal of a larger kingdom. In addition, as the game is tailored around historical accuracy, CKII quickly employs gameplay surrounding the crusades and papal politics, long before a novice player has even had a chance to learn some of the basic mechanics.

The game I often cite as a masterpiece of well-paced challenge is Portal. Portal's core mechanic centers around jumping through portals to complete spatial puzzles. With such an unintuitive and unheard of task, employed to solve difficult logic puzzles no less, you would expect the game to suffer from an even less ideal learning curve than Skyrim or Crusader Kings II, as the designers may attempt and fail to predict the player's progressive understanding of a complicated mechanic. But in fact, Portal progresses quite smoothly and quite comfortably for most of its players. It begins with some simple levels that exhibit the basic concept of wall-mounted portals, before handing the player a portal gun that can fire just one portal, then two portals, moving on to introduce momentum and jumping puzzles, weighted cubes, and hostile turrets. Portal finally tests the player's skills in all of these areas, with a series of complicated tasks that include all previous aspects, before one final 'boss' puzzle. These final challenges only occupy the last quarter of the game, thus the common observation that Portal is 90% tutorial. In my experience, most players manage with each puzzle just fine. The game rarely dips into boredom or anxiety. It remains in the flow channel, adjusting the required challenge at roughly an equal rate to the player's progressively increasing skill.

How does Portal manage to stay in the flow channel, where Skyrim falls into boredom, and CKII into anxiety, along with so many other games? Csikszentmihalyi provides some functional guidance to encouraging flow. First, he identifies attention as the primary resource of a person performing a difficult task. He literally analyses it as if it were a resource; the psychological equivalent to physical energy. If several things are on a person's mind, that person is not applying themselves fully to the task at hand; Csikszentmihalyi calls this a state of 'psychic entropy'. If most or all of someone's attention is being applied to just one challenge, however, then the inverse emotional state is achieved - that state being flow. In this somewhat drawn out analysis, Csikszentmihalyi is basically summarizing one of his eight identified characteristics of flow. Four of these characteristics are actually conditions for flow, so I'll talk about these.

1. The task must be possible to complete.
2. We must be able to concentrate on what we are doing (as elaborated on above).
3. The task's objectives must be clear.
4. Immediate feedback must be provided.

It is interesting how closely these correlate with some principles I'm already familiar with in game design. Principle one, for example, is essentially a rephrasing of the 'options principle', 'counter-play', or the law of feasibility. The player must have a chance of actually succeeding at the task you give them. An impossible task is absolutely no fun, and an improbable one is also quite frustrating. This seems simple enough, but I've found that the lack of the options principle appears in unexpected places. For example, in a competitive multiplayer game. If one player is losing, and nothing can be done to actually turn the game in their favour (i.e. there are no options), the result is an extremely frustrated player. A game designer needs to ensure that in almost all situations, the player has the ability to achieve their task.

Principle two is very encompassing and quite abstract. Csikszentmihalyi means it in the sense that an untroubled personal life leaves someone free to focus on their professional work. Game designers don't have much control over their players personal lives, so this principle can only be applied to the game itself. Clean graphical user interface, and avoiding flooding your player with side-quests, are possible examples of this principle.

I find principle three extremely relevant to tutorial design. Nothing can shut down a player faster than not knowing what they're supposed to be doing, or not understanding how to do it. I experienced a good example of this only a few days ago, playing a horror game called Monstrum for the first time. Monstrum is reminiscent of Amnesia; you navigate corridors and rooms, searching for items and avoiding a frightening monster. However, during my first game it was never made clear to me how I was supposed to finish the level. What was I looking for? What were the win conditions? Without a target to actually aim for, my gameplay was much less engaging. At the same time, this principle crumbles a little when we consider that the challenge in many games, puzzle games in particular, lies in not knowing exactly what to do. In Portal, it is clear that you need to reach the end of the level. What is not clear is the specific steps needed to achieve this goal. The whole fun of the game is figuring out these steps. So I believe the third principle is a balancing act; the player needs an objective, but an unclear path between them and the objective. And again, going pack to principle one, it actually needs to be possible to figure out what this path is.

Finally, principle four is a classic game design imperative. Reward your player for achievement, punish them for failure (but don't punish them too hard). What constitutes a reward, and why a reward might be enjoyable, is an entirely different issue, so I'll just leave it at that for now.

Flow has been employed and investigated by a few game designers, to my knowledge. An excellent example of this is the game flOw, created by Jenova Chen and Nicholas Clark, and I can only assume named after the theory itself. flOw features a microbial snake/worm character swimming around and eating smaller creatures. The game does have levels, each one progressively more difficult, but the player is given the freedom to move between these levels as they see fit. To ensure that the player does actually progress, a level can be cleared, in which case there is no reason to stay, and being killed by a larger creature will knock the player back a level, so the game ensures the player will remain in the flow channel. flOw is available to play online. A link is provided at the end of this post.

Links
http://www.jenovachen.com/flowingames/flowing.htm - flOw

Bibliography
Csikszentmihalyi, M. 2002. Flow: The Classic Work On How To Achieve Happiness. London: Rider.

Feedback On Presentation 1

Following my presentation that introduced my research subject to the class and my tutors, it seemed that my tutor wasn't entirely clear on what I intend to research. This may be because game design is often overlooked, and little-known to most people outside of the field. It's clear that my following presentations will have to introduce the subject more carefully.

To clarify; game design is the practice of handling a game's behavior, rules, composition, and experiential quality. As a discipline, it has fuzzy boundaries and widely varying roles throughout different game studios, but game design is very necessary for the creation of a good game. I normally like to explain the role of the game designer using Chess as an example.

Chess is a folk game; it's been "designed" by thousands-millions of people throughout the ages. But let's imagine for a second that it was created in a modern board-game studio, from scratch. A lot of people assume that just making the game makes you its designer. Carving the pieces, painting the board, designing the box art, they're often confused with the role of the game designer (given that "game designer" is often shortened to "designer" which, in almost all other fields, is an artistic role, this isn't surprising). These tasks would not, however, be the work of the game designer. Especially in the context of a video game, this kind of thing is handled by the game artist. In the case of Chess, the designer decides how many pieces there are, what they all do, how many squares are on the board (and even if they're going to use a square grid at all). These decisions may seem mundane, but they're often extremely weighted responsibilities that shape the game's quality.

In my case, I'm looking closely at the design of progression, and tutorials. Many video games are so complicated that they need to convey lots of instructions to the player, without boring them. Lots of games still aren't doing a very good job, and I'd like to investigate why this is the case, and how you can do a good job.

When I talk about tutorship, I don't necessarily mean solidly tutorial levels. This method of tutorship is arguably inferior to more integrated, seamless tutorials. Furthermore, even after your player has been taught basic controls and objectives, many games require continuous mastery of new situations and mechanics, so teaching the player should rarely stop at an early point of the game.

My research could focus on several individual topics. Designing overt tutorials and effectively conveying information, experience/difficulty curves, and 'flow'.