Get the latest Education e-news
  • A Method for Pacing Analysis

    - Filip Coulianos

  • How Do I Use It?

    Break Down Gameplay

    The idea behind the method is simple. Break down the core gameplay of your game to a handful of different game play elements. Let's take Half-Life 2 as an example. I think it has the following game play elements:

    Puzzles. Non-combat sections where the player has to solve a logical puzzle to pro¬ceed. (very low stress)

    Dialogue. Non-combat sections where either pieces of the story is being revealed, or player gets new weapons. (no stress)

    Arena. Enclosed and heavily scripted areas in which the player faces multiple enemies and/or a big boss and must kill them all in order to proceed. (high stress)

    Soft resistance. Areas in which the player simply travels through from with enemies scattered around to keep the player somewhat busy. (low stress)

    Vehicle ride. Areas in which the player drives through with either the airboat or the buggy. (low/medium stress)

    You then let someone play through your game/mod and time the tester. For each new game play element, take a note and set a time stamp. You then use the timestamps and create a chart to illustrate how the player progressed through the different areas and can easily see if the player spends too much time doing the same thing, which is something you want to avoid.

    Project 25 Example

    When designing Project 25 I had a couple of goals. Project 25 had to be at least 25 minutes of game play for the average player, it also had to be doable in 2.5 months.

    What I basically did was to come up with an abstract similar to the one in the Duke Nukem Forever example. I then designed my own chart, putting game play elements into it and an estimated completion time for each element. The basic abstract of Project 25 was like this:

    "The player gets introduced to game and her goal (reach station 25) in a rebel base located in a tunnel. The player then progresses through the tunnel, and gets up to street level. There the player battles through combine forces until she finds and saves a couple of rebels. The rebels lead the player to station 25 where the player gets ambushed, survives and finds Alyx."

    I then made a breakdown with timestamps of what should happen in my mod. This is a breakdown of the pacing for the episode, each cell in the chart represents one minute of playtime, the chart is supposed to be read from left to right:

    1. First. One minute of dialogue (blue) in which the player is introduced to the game and the goal. This followed by a couple of minutes with just basic exploration and sporadic encounters of zombies (red). Then a puzzle (green) to get the player relaxed and not threatened. When the puzzle is solved the player quickly gets attacked by zombies and an arena follows with combine soldiers breaking into the tunnel (orange).

    2. The player gets through the tough fight and now continues into a sewer system with little to none enemies to get the stress down (red). Finally the player gets up from the sewers and fights her way through a backyard (red).

    3. The player saves rebels who were held hostage in one of the houses at the backyard. After a short dialogue the player is being shown where station 25 is. The player now has to solve a puzzle to get through (green). The pacing is very low as the player solves the puzzle and opens a gate, only to be surprised by an ambush by the combine. A final battle takes place in station 25's ruins.


    After I was done with the abstract and had timing in place I now knew I had to come up with two puzzles, write and design dialogue for two occasions, a long arena event in the end (the boss fight) as well as one in the middle of the game. This was of course all subject to change, but now I had a very clear picture about what to implement and a rough idea about how big each area should be. Next stop was to get the first iteration up and running as soon as I possibly could.

    When first iteration was done, it was time to do the most important thing in the development process; test the product. To get most out of my method one has to do this as early as possible. I had a fully working prototype about three weeks into the project. It was very rough, buggy and all that, but the project was fully playable from the beginning to the end. From this time and on I had regular play tests once or twice a week with friends who played it through.

    Below are a few handy tips and tricks that you could use when conducting your own playtests:

    Always be present during the tests and take notes about what the testers had difficulty with and what they didn't understand. Also time the players to get a feeling of how well your target time compare to the average player.

    Have an interview after the playtest. Ask the playtester what she liked and what she didn't like. Ask things based on your observations such as if the player behaved strangely during a specific challenge.

    The playtester will always ask questions regarding the game and the challenges that are presented when she plays; don't answer these questions. Instead, take notes about the questions and answer them after the playtest. Pay close attention to what the tester asks about, this is vital information that will help you create a smoother experience!

    Try to avoid "the scientist effect" at all costs. The playtester will most probably feel more or less uncomfortable about having you sitting behind her back taking notes about every move she does, and because of that will play differently than she would otherwise. Do everything you can to make the playtester feel comfortable. If you can, conduct the test at the playtester's home.

    If you can, try to avoid showing the tester that you actually time her. This will only stress her and make her play faster or slower than she would otherwise. You also could record a demo of the playsession and time it later to avoid this issue.


comments powered by Disqus