You Got Turn-Based Chocolate In My Real-Time Peanut Butter

The whole idea behind this Vespers project thingy is to take a rich textual world created in interactive fiction and extrude it, so to speak, into three visual dimensions. As I've discovered, a whole mess of issues arise when moving from the predominantly discrete world of IF to the largely continuous world of 3D. That applies, of course, to space: in IF, space is divided into discrete locations, with little to no functional representation of spacial relationships within those locations, while in 3D, space is represented on a more familiar continuous scale. Likewise, it applies to time: rare exceptions aside, IF is turn-based with discrete time steps, while first-person 3D games are real-time and continuous.

The question is, can a game really be both at the same time?

In terms of space, that's not really a difficult stretch. Most locations in IF are just discrete representations of a location in 3D; a kitchen, a bedroom, a church can all be defined by walls and doorways in 3D to produce the same effect as in IF. Outdoor or more abstract locations can be a little trickier, but through the use of invisible, arbitrary borders one can functionally define locations such as "outside the calefactory", "base of the bell tower", or "garden", to produce the same effect. Dealing with spatial relationships within locations has its implementation challenges, but nothing that can't be addressed by a few ground rules that can be tweaked based on playtesting and feedback.

Time, however, is a bit less straightforward.

The turn-based nature of IF is something that is tightly integrated into game design and gameplay mechanics. It's probably fair to say that this is, at least in part, a reflection of the history of the genre, going to back to the command-line interface and early computational limitations. It's also probably related to the nature of the medium and interface; reading and typing text, and thinking through sometimes complex puzzles, is better suited to a more relaxed, turn-based interface. It creates a challenge for authors trying to model time-limited situations in their IF games, with the typical solution being a turn counter and forcing the player to resolve an issue within X number of turns. This can work to create a sense of urgency in players, although in some cases it can come across as an artificial limitation.

Some authors have tried using IF systems that operate in real-time; although I don't recall trying any of these myself, my sense is that the scarcity of these games is a reflection of the popularity of this approach.

Which leads, I guess, to the next question: if that's the case, why try to do something like that with Vespers?

The answer is that I'm not. Instead of being truly turn-based or truly real-time, Vespers will actually be something of a hybrid, although in practice it will play closer to a turn-based game. The player can move in real-time, but for the most part it will resemble moving about within a world where time is essentially in an idle loop, advancing predominantly (but not entirely) upon player input. That input could be the entry of a command (like in traditional IF), or it could be the result of movement (such as entry into a new location).

As an example, take the interaction with NPCs. When the player first encounters Lucca, for instance, he is on the floor in Matteo's room, scratching at a flagstone in the floor. If the player does not interact with Lucca, he will just continue to do what he is doing, maintaining his "idle" state of scratching at the stone. We've created a series of animations for Lucca during these "idle" times -- scratching at the floor, sitting up to rub his sore hands, wiping the tears in his eyes, and so on. These animations play at random intervals to give the appearance of a living, active character, even though he is essentially just waiting for either (a) the player to interact with him, or (b) some other game event to trigger his next action or task. If the player does interact with him, once the interaction is finished he simply goes back to doing what he was doing, scratching at the floor.

The result is a game world that is predominantly reactive, but it remains to be seen if this comes across as a little too passive. Note, however, that the world won't be 100% reactive in this sense; there are still some situations where we cannot always wait for the player before advancing time.

The most obvious example of this is an action sequence; in Vespers, for instance, there is the tense scene with the wolves in the garden. In the IF game, the player is given a handful of turns to work out a solution to the mess -- but how to implement this in pseudo-real-time? Forcing players to think and type fast would not be an ideal solution. Instead, the solution will be to implement a surrogate for the "turn". The surrogate will take into account all possible actions (and inactions) of the player, including the typing of commands and any movement.

There are a couple of tricky situations with this approach. For instance, with respect to player movement, how much movement should represent a "turn"? Then there is the command line entry window: should the advancement of time be suspended while waiting for the player to finish typing? Should a time limit be placed on text entry? Or should text entry be cancelled if no keys are pressed after a certain period of time? Finally, there is the issue of player inaction, and whether time should advance or loop continuously while the player sits idle.

These are all issues that need to be worked out through playtesting and then tweaked as needed. In the end, however, the result will be a game that has elements of both turn-based and real-time gameplay, although functionally it will probably be closer to the former than the latter.

The most interesting part of the experiment will be to see which parts of the system work and which do not, and then using that information to refine the mechanics once we move beyond Vespers and on to the next project.