This is mark Joseph “young” blog entry #167, on the subject of Cybergame Timing.

I’ve played a few games which I am calling “cybergames”.  “Computer games” would suggest they are considerably bigger than they are.  These are “Facebook games” and cellphone games.  What usually happens is a close friend or family member will be playing a game and will “need” another player in order to get certain in-game benefits (a recruitment tool used by the game designers to get people who are playing to coerce their friends to play), so I will join the game and become involved, and then they will stop playing and I’ll realize, gradually, that I’m the only one I know playing this game, and eventually will realize that I’m wasting a lot of time on something that was supposed to be a way of interacting, in some small way, with this other person, and now is about interacting with a central processing unit somewhere.  However, along the way, being a game designer and gamer from way back, I notice things about these games, and one of them has begun to bother me.

Many of these games have timed processes.  That is, for example, you’ll say “build this here”, and it will tell you that it has started building it and the building will be complete in exactly this period of time, a countdown timer beginning.  That sometimes limits what else you can do (or requires you to spend resources to do some other things you normally would be able to do “free”), but its primary function seems to be to induce you to return to continue playing the game later.  The time units are often intuitively logical–for example, it is often the case that these will be twenty-four hours, or twelve or eight or six, fractions of a day.  With the twenty-four hour unit, you think that means you can play the game once a day and hit the button to restart this for the next day–but therein lies the rub.

Assume that you are playing such a game, and there is one task that can be done every twenty-four hours–collect a specific resource.  Let’s assume you are playing this game every morning before work and again twelve hours later in the evening after supper.  Both of those times are going to have a bit of fluctuation to them, of course, and that’s part–but not all–of the problem.  So at seven o’clock Monday evening you collect the resource, and that restarts the clock.  Of course, there are other things to do in the game–you don’t just collect the resource, you do other game play things at the same time.  So on Tuesday at seven the flag pops up to say that you can collect the resource.  Odds are against the notion that you are simply waiting for that flag to appear and immediately hit the button, so it will be at least a few seconds–let’s say a minute–before you do.  Sure, some days you are going to hit that resource in the same second, but those are the very rare ones.  By the end of a week, you are going to have shifted the time that the twenty-four hour resource renews by several minutes–so the next Monday you come to play at seven, but the flag doesn’t appear until five after, or ten after, or some time after the hour.  That’s not a problem–presumably you are playing the game for more than ten minutes at a shot, or it wouldn’t be much of a game.  However, you can’t make that clock go backwards–by the next week it will be quarter after, or possibly half past, before the flag appears.

Probably it’s not a game that you play for half an hour, at least not every night.  At some point, you give up waiting for that flag, and it “appears” in the program after you’ve shut down the game.  When you restart the game at seven in the morning, there it is.  And now you repeat the same process in the morning, until you have to quit the game and leave for work before the flag appears.  You lose a day of resource generation, and it returns to an evening task.

Not a big deal?  However, this same problem affects all tasks of length, whether twelve, eight, six, four, or even three hours:  no matter how frequently you play the game during the day, eventually the task will be unfinished twenty minutes before you are going to bed, and you will have to choose whether to stay up and hit the button late or go to bed and pick it up in the morning.  What seems like a game mechanic that pushes you toward a regular play schedule actually prevents a regular play schedule, because it shifts against the clock slightly each time.

The obvious solution to this problem is a game design correction:  replace those seemingly intuitive chunks of turnover time with rather unintuitive shorter ones.  Have the resource renew in twenty-three hours, eleven and a half, eight and two thirds, six and a three quarters, four and five sixths, three and seven eighths hours.  This lets the player show at a regular time and find the task complete and waiting for replay.  It avoids the frustration of having to wait until tomorrow morning simply because it’s not worth waiting another twenty minutes tonight.  It’s a better game design.

Anyway, that’s my suggestion.  I would probably find these games a bit less frustrating (and really, do you want your game to be frustrating?) if that were fixed.

[contact-form subject='[mark Joseph %26quot;young%26quot;’][contact-field label=’Name’ type=’name’ required=’1’/][contact-field label=’Email’ type=’email’ required=’1’/][contact-field label=’Website’ type=’url’/][contact-field label=’Comment: Note that this form will contact the author by e-mail; to post comments to the article, see below.’ type=’textarea’ required=’1’/][/contact-form]