Tuesday, July 29, 2008
Game Design: Mixing Turn-Based and Real Time
Indies aren't always more open about their current projects in development than mainstream developers, who usually have a veil of secrecy enforced by publisher contracts and non-disclosure agreements. But sometimes, members of the indie game development community open up with current challenges facing development. Sometimes they solicit the opinion of other developers or their own customers for suggestions for dealing with the quandary-of-the-month.
This can be a little bit like offering tours around the sausage factory. In general, gamers really don't want to know how the products of their hobby are made. But a few of us do. Even before I was a game developer, I was fascinated with the nuts-and-bolts of how games get made. I loved looking behind the curtain.
Now that I am a developer, I have another reason for appreciating these looks into design and development. Often, I am dealing with similar problems. Even if the solution suggested isn't applicable to my particular issues, I just appreciate knowing that I'm not the only one struggling with these kinds of things.
Such is the case for me with Mike Rubin, in his latest chapter about the difficulties moving from the text-interface world of Interactive Fiction to the more fully-detailed "virtual" 3D world of Vespers 3D. In this installment, he deals with the issues of integrating a real-time interface and movement system into what is, at its heart, a turn-based game.
You Got Turn-Based Chocolate In My Real-Time Peanut Butter
Time in the text-based game was largely literary or turn-based. The world patiently awaited the player's next action via a text parser. Distances in text adventures are abstract - crossing a large garden might take exactly the same amount of time as crossing a tiny room. Text is inherently static - we would balk if words changed as we read them.
But you take a game designed around that paradigm, and translate it to a visual world where players expect real-time motion and action... and it gets weird. Rubin notes that even something simple like an idle animation can get weird when the AI does nothing but repeat their actions while waiting to react to player input.
I've run into exactly the same issues with Frayed Knights. I do not want time to progress while the player is just standing there, doing nothing. I'm deliberately trying to maintain a more leisurely pace with the game. But one of many 'resources' of the game is time - which I calculate in abstract "turns." How do you reconcile that with movement? My solution was simply to progress time by fractions of a turn for distance traveled. Not an optimum solution, but it worked.
Another noteworthy comment is how a design decision on one element of the game can impact so many others.
I recommend giving the article a gander!
Labels: Game Design
- posted by The Rampant Coyote @ 5:00 AM (Permalink)
Comments:
Links to this post:
<< Home
After 30 seconds of just standing around you could have a narrative and pause the timer (not the game). "It's as if time stopped as our intrepid adventures synchronized into a flurry of day dreams that will eventually lead to Dirk getting a Fireball in his noble backend." :)
I personally don't see a problem with having time pass normally while the player is standing around or moving from place to place. And I don't see a reason to quantify distance into turns unless turns is somehow a metric used in game-play or scoring, e.g.
"I won the game in 142 turns!"
"Haha, I did it in only 98 turns! You suxxor!"
"....!"
A few points:
1) If the gameplay consists solely of random or scripted encounters, then time has very little meaning anyway. You see this all the time in games like Half-Life: No matter how long you wait -- minutes, hours, days, weeks -- the soldiers are still going to be there to ambush you and throw you in a trash compactor! =P
2) If time is important (e.g. the player needs to accomplish some task or arrive at a certain destination by a certain time) then keep the player informed as to the time limits; if he chooses to stand around wasting time, then he'll have to deal with the consequences, whether that's missing out on some element of the game, or having to reload a previous save-game.
3) In the case of where characters in the game need to react realistically based on time, provide some sort of "idle" or "pause" state.
To use the monk scratching at the floor as an example; eventually if we wait around long enough, the monk -- no matter how manic he is -- will likely take a break from scratching at the floor, whether from excessive pain or from sheer exhaustion. In this case, provide some alternate action that "pauses" the character; e.g. the monk curls up on the floor and falls asleep, waking either when the player interacts with him or at some later time, at which he returns to scratching at the floor.
4) Back in the day, Alternate Reality mixed real-time with turn-based rather well. Most of the time it was real-time: Whether wandering or standing around, food and water were consumed, the sun rose and set, storms came, etc. It was only during encounters that it became some-what turn-based. (I say "some-what" since the players turn was limited to 5 seconds, so if he didn't do anything, the NPC would automatically take their turn after 5 seconds.) And seems like a lot of Japanese RPGs take a similar approach.
5) I always thought that the time management of Baldur's Gate and its ilk was a good compromise -- letting the game flow in real-time unless the player felt overwhelmed; then the player could control the "turns" by pausing/unpausing.
"I won the game in 142 turns!"
"Haha, I did it in only 98 turns! You suxxor!"
"....!"
A few points:
1) If the gameplay consists solely of random or scripted encounters, then time has very little meaning anyway. You see this all the time in games like Half-Life: No matter how long you wait -- minutes, hours, days, weeks -- the soldiers are still going to be there to ambush you and throw you in a trash compactor! =P
2) If time is important (e.g. the player needs to accomplish some task or arrive at a certain destination by a certain time) then keep the player informed as to the time limits; if he chooses to stand around wasting time, then he'll have to deal with the consequences, whether that's missing out on some element of the game, or having to reload a previous save-game.
3) In the case of where characters in the game need to react realistically based on time, provide some sort of "idle" or "pause" state.
To use the monk scratching at the floor as an example; eventually if we wait around long enough, the monk -- no matter how manic he is -- will likely take a break from scratching at the floor, whether from excessive pain or from sheer exhaustion. In this case, provide some alternate action that "pauses" the character; e.g. the monk curls up on the floor and falls asleep, waking either when the player interacts with him or at some later time, at which he returns to scratching at the floor.
4) Back in the day, Alternate Reality mixed real-time with turn-based rather well. Most of the time it was real-time: Whether wandering or standing around, food and water were consumed, the sun rose and set, storms came, etc. It was only during encounters that it became some-what turn-based. (I say "some-what" since the players turn was limited to 5 seconds, so if he didn't do anything, the NPC would automatically take their turn after 5 seconds.) And seems like a lot of Japanese RPGs take a similar approach.
5) I always thought that the time management of Baldur's Gate and its ilk was a good compromise -- letting the game flow in real-time unless the player felt overwhelmed; then the player could control the "turns" by pausing/unpausing.
Sorry I'm late to the party, and thanks for the props, Jay.
I think xenovore makes some good comments, although I don't have the time to go into them in detail. Suffice it to say that the game does not consist entirely of scripted encounters or events, which makes things a little complicated. Time and space just need to be fit together in a way that preserves the nature of the original game.
And as to your comment #3, that's actually exactly the way I've implemented the NPCs.
Post a Comment
I think xenovore makes some good comments, although I don't have the time to go into them in detail. Suffice it to say that the game does not consist entirely of scripted encounters or events, which makes things a little complicated. Time and space just need to be fit together in a way that preserves the nature of the original game.
And as to your comment #3, that's actually exactly the way I've implemented the NPCs.
Links to this post:
<< Home
