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.