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

    - Filip Coulianos

  • Changes Due To Testing

    In total I did 10 play tests of Project 25 before release. Project 25 was fully playable from beginning to end when I had been developing about one third into the project. I then continually tested throughout the development once or twice a week improving the game each time. I also took notes about completion time for each gameplay element and compared the data between experienced and inexperienced players. Below are the changes that I did as Project 25 was being playtested, this chart is based upon the completion time for the average player:

    1. The first area got slightly bigger to make sure the player spent a bit longer in-game time before the first puzzle emerged.

    2. A small puzzle was added in the sewers to make sure pacing was low before the fight at the backyard. I added this puzzle because players would otherwise do nothing but kill stuff for 13 minutes straight -- which is bad variation.

    3. I also added a small puzzle right before the dialogue to lower the stress on the player prior to the dialogue.

    4. The final battle was interesting but some testers got a bit fatigued by the intense fighting. Because of this I changed the final battle in such a way that the combine forces attacks in two waves and new rebel characters shows up and helps out in the fight, hence the one minute dialogue in the middle of two arenas.

    As you can see the average player actually gets to a new gameplay element at roughly every five minutes.

    I found that the sweet spot is about eight play tests (or iterations if you will) is about enough to collect information you need, after that information starts to get redundant. Interestingly enough I found that the game studio Rebellion uses a minimum of seven iterations before giving a section of the game green light for shipping. However really big projects most probably have a lot more than eight playtests.


    As I used this method for analysis of an existing game and used it to plan my own project I also found a couple of flaws with it. There simply isn't enough information being presented in the chart to make it easy to communicate with other teammates, leads etc. I suggest that one adds notes and comments around the cart and also adds a stress curve to illustrate the amount of stress the games puts on the player.


    To think about what should happen in your project is of course essential, but don't forget to think about how much time everything should take as well. How long should each game play moment be? Work with target completion time for each event and think about how it will relate to what will happen after!

    Get first prototype up and running as early as possible. Being able to play from start to finish one third into the project proved to be extremely successful from a feedback and quality perspective. (This is perhaps not possible if new game play mechanics are to be implemented in the project, but I do think you should aim for this goal).

    Play test often and with different people. Seven to 10 play tests proved to be a good target to aim for, but you can never get too much. Don't forget to take notes and interview the tester afterwards.

    Time the testers! How long did it take for them to get through the experience? Did the average players experience correspond to your estimates? Do you shift pace of¬ten enough to avoid fatigue?

    A shift in pace every 5-10 minutes proved to be a good recipe to keep the players feel immersed and find the game play experience varied and interesting.

    Pacing is just a piece of the puzzle. Don't forget to think about the quality at each event as well! Make every puzzle, scripted sequence or whatever the challenge really awesome! Think about what you want the player to feel at each event and how that feeling will be in relation to text event.

    This method can also be used by quality assurance teams to show actual numbers on sections of the game in development that doesn't have good variation or pacing. Simply time the testers, if the pace of the average player doesn't shift very often you can easily prove this to whoever is in charge and ask for a improvement.


comments powered by Disqus