Redesigning and Reordering Levels

In response to my survey data, I've decided to take a bold move and do a lot less hand-holding during the opening levels of my puzzle game. This means scrapping Levels 1 and 2, which were particularly un-puzzling and showed the least interest/difficulty to new players. Instead, I'm combining the tutorial value of both levels into a new Intro level. Note that this flies in the face of what I've been told about tutorship; teach your player one thing at a time, one level at a time. Take it slowly. Don't risk overwhelming your player. I'd like to see just how true this principle holds by discarding it for now.

The new Intro level essentially does what Levels 1 and 2 used to do separately:

The major risk here is overwhelming the player, but I'm hoping to see if spending less time boring the player with tutorial levels will improve the game's overall quality.

Following this, I've added a more complex puzzle involving a single gem

As with many of my other puzzles, the key to completing this puzzle is order. First, the central lock must be correctly primed to carry the red gem across the grid. Then, the very same slices that allowed this movement need to be relocated to actually move the gem. To complete this puzzle, (I think) the red gem always needs to make its way to the rightmost open slot on that central piece - the one between two other open slots.

After sufficiently challenging the player with one type of gem, I move onto a puzzle with two. For this, I'll use the pre-existing Level 3 "TwoGemsWithLocks".

This level scored the highest enjoyment on my previous iteration, and actually had a difficulty rivalling the final puzzle. But I'm not convinced that this is due to genuine complexity; the puzzle isn't all that complex. In fact, I'm wondering if it'll now be ranked as a less enjoyable and challenging puzzle, due to the player being exposed to more complex puzzles beforehand. Nonetheless, it contains two gems, so it seems fair to use it as the level that introduced multiple gems.

This is followed by last iteration's Level 5:

.. which introduces multiple gems in a more complex puzzle system.

I'm going to try following this with another new puzzle.

I'm not entirely confident that my players will find this puzzle the most difficult to solve, but I certainly did. It took a lot of trial and error before I finally worked out the correct strategy. Again, this puzzle is about correctly priming your puzzle pieces, drawing on skills practised in previous levels.

With these new 5 levels, I'm ready to collect data for my second iteration. Questions I'd like to answer include:

Does toning down the hand-holding improve the game's reception? We'll be able to see this impact in the interest curve that emerges, and, in particular, in whether or not that dip in challenge at Level 2 disappears. However, I should also be watching to see if the lack of careful tutoring harms the game's quality, as players may now be being introduced to concepts too quickly.

Do I now have an interest curve with a climax? This is the hope, since I've tried to order my puzzles according to their difficulty. But my last iteration had surprising data here; where I was sure that Level 5 was the hardest, Level 3 (which I thought was too easy) showed slightly more difficulty).

All of these changes can be evaluated as my players rate the overall quality of my game.

It's quite important that I find players who haven't played the game before, as I'm testing experience uptake in a puzzle game. Any previous players will have already been exposed to the game, and their results might not be very reliable.

Data from First Survey

I've sent out my game and survey to be completed by fellow students. I've received 9 responses. This isn't a spectacular sample of data, but it's enough for me to start reviewing my game's progression.

Google Forms can be exported into a handy excel sheet, where I'm able to compile the data into graphs.

Here are the graphs I've compiled.

 (Level difficulty, enjoyment of the level, and the level requiring skills taught in a previous level, rated 1-5 by players)

This graph is very valuable. It illustrates the kind of experience curve I've created with the way I've lined up my game. The most important factors here are difficulty and enjoyment, with skill preparation being difficult to make sense of. In previous posts, I've talked about how the ideal difficulty progression of a game should be a gradual increase. More specifically, a game should start by matching the player's skill level, then gradually approach a "test" level, where the skill level somewhat exceeds what the player can easily accomplish. This level of challenge should push the player out of their comfort zone, but not out of flow; the player should still feel up to the task, and any challenges should be ones that they have a fair chance of overcoming. Immediately after a test, the game should return to the low-end of flow.

In the above graph, we don't see this pattern. Where difficulty should be steady (due to the player being roughly capable of completing each new level), but should have a slight rise towards the final levels, we instead see the 4th level being considered the most difficult (by a fraction of an integer, however). Levels 1 and 2 are considered exceedingly easy - these are the levels that introduce mechanics rather than challenge the player with puzzles - and Level 2 is the least enjoyed. This indicates that having two congruent levels with poor puzzle quality is a shortcoming of the game's quality. It risks losing the player's attention early in the game. But at the same time, it's important to make sure that the player understands the mechanics taught in these levels.

Level 3 is the most enjoyed level. I think this is because it's the first level featuring a real puzzle element, and it does this at a comfortable pace that still challenges the player. In fact, it's my first real "crest", where this was supposed to be Level 5. After that, difficulty and enjoyment plateau.

(Types of skill required to complete each level, and time taken to complete levels)

These graphs show less interesting data. Once again, however, Level 3 shows a surprisingly high reception and quality among players (where planning can be considered an important attribute of any puzzle), while the previous two levels are disturbingly low, requiring "not much effort". The scaling of completion time, however, shows the general uniformity that I'd expect.

As I prepare for my second round of tests, I'll need to focus on:

- Making the first two levels less boring, without getting rid of their tutorial quality.

- Moving the 'crest' to where I need it to be, and following it with another crest if possible.

Creating the Survey

To gather data from the players who play my game, I'm using Google Forms to design a survey.

This survey will ask for general impressions on the game, and will also ask if the player feels that a level required skills from previous levels. Likely the most important fields in the survey, however, are ratings for difficulty and enjoyment. These are rated on a scale of 1-5 (5 being highest enjoyment, and highest difficulty. Also note that, arguably, ideal difficulty ratings are between 3 and 4 ('moderate' and 'difficult', where 5 is 'too difficult').

To remind players of the level I'm asking about in each section, I've provided an image. I hope this will be sufficient, and that players won't have trouble remembering 5 levels. Ideally, though, players would be rating each level immediately after they've completed a level.

With average difficulty and enjoyment ratings for each level, I'll be able to build an experience curve of my game.

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.