Escape the Octagon Dev Blog #1: From Prototype to Vertical Slice

Scalar devblog Leave a Comment

A few weeks ago, I released a prototype game called Escape the Octagon for the 2015 Unreal Megajam.

The game is a first person puzzle game (and, in an unpopular feature, mouse flicking game) that focused on the manipulation of cubes and spheres to open a series of doors leading to escape.

While I am proud of the game for what it is and the time frame in which it was produced, moving forward with it has proven to be another challenge entirely.

I’ve spent the past two weeks reviewing the game and seeing what worked and what did not work, based on the feedback I’ve received from people who have been nice enough to talk to me after playing the game. I’ve broken this process out into three basic parts and the following questions:

  1. Concept: What is the general concept of the prototype? Did the prototype succeed in achieving this concept? What elements succeeded, and what elements failed?
  2. Design: What do the answers to the Concept questions mean for the design of the game? How must the design of the game change to improve?
  3. Scope: What do the new design requirements mean for the scope? How can we reduce the scope? How to increase development throughput to meet the new scope?


Concept

Question 1. What is the general concept of the prototype?

The general concept of the prototype was to build a puzzle game with some platforming/dexterity tests required to solve the puzzle.

Question 2: Did the prototype succeed in achieving this concept?

I would say that the prototype failed to meet the concept. The two elements did not play together well (save for, perhaps, the final room). The puzzle element and the physics based element work against each other more often than not.

Question 3: What elements succeeded, and what elements failed?

The general consensus was that the first floor was pretty fun, while the second floor was extremely frustrating.

Watching others play the prototype made this pretty obvious. When a player sits down to play a puzzle game, the mechanics must serve the puzzle element. Players who enjoy puzzle games like to know that once they figure out the puzzle, they can accomplish the steps needed to complete it with minimal issue.

If the mechanics do not allow for a relatively painless completion of the puzzle once the answer is known, the mechanics are not serving the puzzle and they are a needless frustration. During the design of the physics mechanics of the sphere game, I had it in my mind that the mechanics rules changing was itself a puzzle. I realized through watching my players that this type of game was akin to changing the rules every single puzzle, and generally wasn’t much fun.

The goal of the game is to be fun! So, we’ve identified a real problem with the mechanics introduced. The pure puzzle elements ARE fun, but that in itself presents a pretty significant design and scope problem.

Design:

Question 1: What do the answers to the Concept questions mean for the design of the game?

The first thing they tell me is that the prototype mechanics for the sphere slinging game aren’t fun, and they don’t fit well within the mechanics for the puzzle game. That feature will be axed entirely.

The second thing they tell me is that the puzzle elements are fun. People like solving puzzles, they enjoy the ‘Aha!’ moment, and they like having an intuitive answer be apparent within the confines of the game’s mechanics.

Question 2: How must the design of the game change to improve?

This question is simple, since we’ve done our homework thus far. We need more puzzles. And not just puzzles, we need more puzzles whose answer is intuitive, but not necessarily immediately apparent. We need mechanics that serve the puzzles we create and stay within the defined rules that we set. If we are to expand into a vertical slice and a complete game, we need a set of rules that scales well, and we need a decent amount of puzzles.

With this knowledge, we can look at our third point…

Scope

Question 1: What do our new design requirements mean for the scope?

Put simply, the scope balloons quickly. Creating intuitive puzzles is not simple. The majority of time spent on the prototype was not programming the game or developing assets, it was sitting with a pen and a piece of paper trying to figure out any mechanics that could provide provide 16 unique, intuitive puzzles. A week’s worth of exhausting work provided for approximately 2 hours of puzzle play, at least 1 hour of which will be scrapped because the mechanics were not fun.

It’s a given that moving from a prototype to a production-ready game will have it’s scope increase dramatically. Assets need to be sourced or created, the length of the game expands, and the bugs and glitches that were fine in a prototype need to be flushed out, as they aren’t acceptable in a retail release. In addition to assets and bugs, content has to be generated: Levels need to be built, puzzles need to be designed, a new set of rules and mechanics need to be thought out, fleshed out, and play tested, and the prototype needs to be reviewed constantly to ensure it’s staying close to it’s concept (mostly to prevent feature creep).

The scope for a production release for any game can be intimidating for any development team, from single developers to multinational giants.

Question 2: How can we reduce the scope?

Scope is an insidious thing. Collaborative and iterative design (either with players or other developers) can change everything about a game. You can start with Tetris and end up with Doom if you don’t keep scope in check.

There are many, many articles on scope creep who tackle this better than I ever could, so I simply a single question:

‘Can this game achieve its original concept without this feature?’

That’s it! Once you know the answer to that question, you can focus on what you need to accomplish your game concept, and what you can (if needed) go back to later on to improve upon.

Question 3: How to increase development throughput to meet the new scope?

The elephant in the room. Since we are building a puzzle game, one of the major ways to assist in scope issues (procedural generation) is off the table entirely. There isn’t a way to ensure an optimal play experience while leaving the level design to an algorithm. Level design is king, queen, and a few dukes in the realm of the puzzle game, and needs to be at the forefront of development priorities.

So how can we reduce the scope to be manageable?

Modular assets
Although we can’t use procedural generation, we can rely heavily on modular assets to assist in quick iteration of puzzle rooms. Building a room with modular assets is fast, allows for quick play testing to determine whether or not the puzzle is any fun, and gives a sense of progress constantly. The later point is imperative to remain motivated through the long slog to release.

Rules-based design
While the mechanics for my puzzle game are still in flux, testing new mechanics and design changes has been much easier since I’ve adopted a rules-based design process. What do I mean by this?

Basically, it’s assigning a difficulty to each combination of mechanics that a player could encounter. For instance, a moving platform that a player has to walk onto may be a difficulty 1, while a moving platform that a player has to jump to might be a 3 (and vary depending on speed).

While this kind of design is difficult to gauge, especially across different players, it does give a good idea of how to build a level. Constant high difficulty is draining, and constant low difficulty is droll. A fluid mix of difficult and easy parts (with a gradual progression of how difficult a particular puzzle/set of mechanics) is something I’ve been putting a lot of consideration into as I design my new levels.

Strong Metrics and Iterative design
Since I’ve placed each of these type of mechanics into a category, level design becomes easier to flesh out with less unintentional difficulty spikes. I know when and where I should have checkpoints, and I know which pieces work together well (and not well). Responding to play testing is as simple as re-categorizing difficult (or easy) puzzles and shifting levels containing them accordingly.

It’s imperative, therefore, to have strong metrics as to where players are failing, as well as play testers who are willing to die for you (metaphorically).

Escape the Octagon is at an evolutionary stage right now and by following these rules, I will be building a prototype that can be grown into a vertical slice and eventually a complete game.

Leave a Reply

Your email address will not be published. Required fields are marked *