next »

[Nitro Crate]

So I'm in the planning stages of a new creation that I'm working on, and after fleshing out a carefully made first area, a sudden question bursts into my head: "Is this paced well?"

And it boggles my mind how I'm supposed to test this without actually making it.
All I could think of doing is playing existing games that are known to be great, and jotting down notes on what's introduced and when.

But then I thought that perhaps the world of Tigland could give me some wonderful advice.

So to all you tiggers out there, how do you properly pace a game?

(Also if you have any reccomendation on exceptionally well-paced games, I'd be happy to take those as well.)
 

[moi]

Have you tried playing the game?

[mewse]

My rough rule of thumb is to introduce a new "interest element" once every five minutes of active gameplay.  An "interest element" can be a new level with a different tileset, can be a new ability for the player (or a new application of an old ability), can be a new type of enemy, etc.  Basically, something that the player hasn't seen before in this game.

That rule of thumb is usually enough to get you to a first draft of the game, at which point you need to get it to focus testers to make finer timing and gameplay adjustments.  (And note that this rule of thumb only applies to plays-the-same-every-time linear games.  Doesn't apply at all to procedurally generated games such as Spelunkey or Dwarf Fortress)

[Nitro Crate]

Have you tried playing the game?

Well I'm trying to see if I can create a proper first draft as mewse describes.

My rough rule of thumb is to introduce a new "interest element" once every five minutes of active gameplay.  An "interest element" can be a new level with a different tileset, can be a new ability for the player (or a new application of an old ability), can be a new type of enemy, etc.  Basically, something that the player hasn't seen before in this game.

My main concern actually is that I'm introducing too much too quickly. Does this five minute rule apply in that sense as well? Should I refrain from introducing too many new elements in-between each 5 minute segment? How many elements should I be adding every five elements? How much content is considered overloading a player?

Haha so many questions. Anyways, this topic isn't meant as an aid just for myself. It's meant as an aid for all aspiring game developers, in case they stumble amongst this question themselves.

Edit: Also, another question to explore: How would you implement pacing in a procedurally generated game? I think spelunky did a good job with this by cutting up what type of content you get until you get to the next zone. But what are some other ways of handling it?

[___]

Well, five minutes entirely depends on the structure of your game.  If it were a slow paced exploration game, or some action intense game where a level could only last 5 minutes... there's no exact time, it's something that has to be felt out.

Perhaps think of a graph of intensity or interest vs. time.  Overall think about how you want that shape to be.  Do you want a player experience that starts out high, slowly drops down, spikes up in the middle, drifts off and calmly ends the level?  Do you want it to start off low and climb upwards to one central climax and then drop off?  There are a lot of different ways you can do it.

You can then sort of think of all the details of what you want the player experience to be.  Then imagine yourself playing!  And start charting out the graph.  I start walking right in my platformer, pretty low on the intensity level.  Oh shit, a short spike pit, interest rising a little bit, I jump over it, now theres a big pit, and the interest/intensity is rising higher.  Throw in some enemies, introduce some unique element, use the unique element, now combine that element with the danger parts from before, enemies spike pits... charting this all out on the graph.

I usually try to only introduce the player to one thing at a time, and then eventually combine those things.  Sometimes if you try to introduce multiple things at once, or just too much at once, those things can lose their significance and the player will be more likely to forget them.  Things standing on their own are more memorable for the player, I think.  But I'm not going to tell you there's any set way to do things.  Experiement, prototype.  There's only so much you can do on paper.

[mewse]

My main concern actually is that I'm introducing too much too quickly. Does this five minute rule apply in that sense as well? Should I refrain from introducing too many new elements in-between each 5 minute segment? How many elements should I be adding every five elements? How much content is considered overloading a player?

Sorry, I should have specified!  Five minutes is the maximum time between adding new elements, to prevent the player from becoming bored.

On the other end of the scale, I'd say to introduce no more than two concepts at once, and there should be at least a minute per concept, to let the ideas be practised and sink in.

But again, these are just rough guidelines;  there are always exceptions, and you should try to avoid locking anything in absolutely, until after you've had some focus testers play your game to get actual reactions.

[yesfish]

The only way to test it is to make a prototype.

[Alec S.]

Well, I guess it really depends on the game and what you mean by pacing.

I generally think that you should have large amounts of variety in environments and challenges, while introducing mechanics at a slower pace.  Don't overburden the player with mechanics, give them a lot of situations to use the ones they have.

Also, make sure not to have a lot of downtime.  Don't make the player travel through uninteresting places to get to interesting places, for example.  Either make everywhere interesting, or don't include the uninteresting areas.

I guess the question you should keep asking yourself is "is the player having fun here, or is the player bored."  If you think the player has nothing to do, give them something to do.  If you think they'd get tired of doing the same thing, give them something different to do.

[hatu]

Right now I'm making a game that has short, almost puzzle-like levels so I just made 25 levels every now and then and then played through them and put them in a order from easiest to hardest.
Some didn't fit or work very well so I'll scrap them and try to make 25 more and then re-arrange again. Also I tried to arrange them so that the levels that introduce new stuff have about the same amount of levels between them.
Then I try to add one or two levels that make use of the new element that bring the difficulty down a bit and then start climbing back up.
Pretty obvious stuff. When you get a heavy story dependency then it can get a bit tougher. But arranging by gameplay difficulty is pretty good for alot of games.

[Cevo70]

There are some good books about pacing a video game.

Of course, I can't tell if you're talking about pacing the PLOT of a video game (like an RPG, or dungeon crawler, adventure, etc).  Or if you mean opening up new mechanics in a puzzler, etc.    It can mean many things. 

The general rule of thumb is not introduce too much upfront - leave some mystery and time for things to unravel.  Many games follow the standard, "start at an insignifcant level, and then quickly spiral upwards towards saving the world!!"

Personally, I think it's best to focus a TON of energy on just your opening.  Nail that perfectly, immerse the players, and they will be more forgiving the pace slows.   Because honestly, pace will differ from player to player - you have less control there. 

Like I am the guy that wanders around every hallway, alleyway, corner, mountain side - even in an FPS.  I don't care if I can see the shotgun in the locked room, I still take my time because I figure that everything will be revealed at some point anyhow.   Other players want that new shiny shotgun at a certain point, so developers carefully plan it's availability.

[Epitaph64]

One of my favorite techniques for pacing is when things are introduced, but aren't usable until a later time, giving reason to re-explore past areas. That's why I think I loved the Zelda franchise so much, especially the 2D ones, because there was reason to return to old areas to get new rewards.

[Montoli]

Personally, I find pacing to be one of the hardest things to figure out on my own, for the simple fact that by the time I have anything even remotely resembling a playable game, I am INCREDIBLY far away from any kind of objectivity.

I know EVERYTHING about the game, or at least everything in regard to pacing.  This, as it turns out, makes me terribly unqualified to play it myself to see.  Since I DON'T need to wander around and look at the scenery and wonder what's over the next mountain.  Since I put all the mountains there, and know which ones have things behind them, etc.  I don't need to play with a new weapon or mechanic to figure out what neat things it can do, since as the designer, I already know in advance all the ways it can be used that will be relevant to the game.

So personally, for any kind of question like "is this paced well", or "is this having the effect on the user I want it to", I strongly strongly strongly recommend roping some friends into playtesting while you watch and take notes.  Watch the parts where they get bored.  Watch the parts where they look overwhelmed.  Watch the parts where they don't explore everything you expected them to explore because you distracted them with a shiny new toy too soon.  Watch the parts where you give them a new mechanic, and they don't bother using it because an old one is still sufficient and is more fun.  Watch the parts where they don't figure something out that you thought would be obvious.  Take many, many notes.

Really, I feel like finely tuned games don't just come from the creator's mind fully formed.  Tuning things like pacing takes active work.  If you want something paced well, track down some fresh eyes (the more the better) and take notes while they play.

Valve Software, btw, takes this to an absurd extreme.  And I guess they have the games to show for it.  I got to attend a lecture at GDC by their on-staff neuropsychologist, and he was describing some of their methods.  They range from normal (observation, gameplay log analysis) to truly mad-scientist-level.  (Cameras recording player eye movement on the screen, sensors on the person's skin measuring perspiration, and sensors on the person's head measuring various brain wave activity...)

[weasello]

For me, pacing is boredom. Get somebody who doesn't have a very good attention span and plunk them down in front of your game. If they get bored, your pacing is too slow.

There are a lot of games out there that I never got around to finishing simply because.. there's no hook; there's nothing keeping me interested. You want to avoid this

[travisdunn]

Civilization had the surprisingly good pacing trick of ensuring that the player was always waiting for something to happen. The rollover progress of various game tasks from one turn to the next is almost rhythmic. It's a great answer to the question: how do you pace a turn-based game?

[Epitaph64]

I think another good pacing idea, is that if you give minor rewards constantly, people may drag their feet through some of the slower parts of your game. Although, ideally, it would be great to have NO slow parts, that's generally not the case. When I think of playing games like Bioshock and Call of Duty 4, some of the main reasons I pushed forward were because of the constant rewards like the upgrades in Bioshock and the experience gain / achievements in Cod4.

[Razz]

pacing is really hard to nail on your own. have other people you know test your game, see when they get bored, and try to work from there.

however, I do think that pacing is much more satisfying when it is executed in a systematic manner. what I mean by this, is that you don't want to introduce new elements at random moments. although this may be FUN for YOU (the developer), it may also ruin the flow of the game. I do agree that it is okay to surprise the player every once in a while, but if you don't have a specific plan then the player might be put off a tiny bit.

here's a good example, it's made up of course, but who knows there could be a game that actually follows this procedure. we're gonna make a little platforming adventure game called blok. in our little game, there will be a specific plan about the evolution of the gameplay. in blok the player collects rings, once he collects all the rings the player moves on to the next level. every four levels there is a boss, and after a boss you move onto the next world. a new gameplay element is introduced every 2 worlds, a new enemy every 4. every world the room size doubles ...

and so on. working on a game in this manner may be a tad bit boring, but it actually gives really satisfying results when it comes to pacing.

[Loren Schmidt]

Another thing that I always appreciate is when a game alternates between two or more types of gameplay. Moon Patrol is a great example of this. The constant switch between obstacle courses and anti-air combat makes the game feel very varied.

I'm not a very experienced designer, but here's the approach I used when making Star Guard:
(1) Write all the types of enemies, traps, and challenges on little index cards
(2) Arrange the cards in columns by the level in which they first appear
This establishes the curve of the game on a very large scale.

Then on a smaller scale:
(3) Come up with a theme or esthetic for each area. Pick a subset of those enemy and obstacle types that fits with the area's theme instead of just throwing everything in at once.
(4) Play around with the elements selected, and come up with a variety of fun ways of using them.
(5) Alternate between traps and combat more or less regularly.

Playtest constantly. People around here are really helpful when it comes to testing, and offer great feedback.