========= CHANGELOG =========
Week of 2014-01-13: - Created the action code for the EXIT verb (actionExit) - Implemented code to put the player in bed, and to get the player out of bed - Created new verb mappings for entering and exiting the bed - Created a new keymap for the bed & chairs - Began to implement code to SIT the player in a chair, and to get up from the chair - Explored tweaking Cecilia animations for Act I - Began implementing new animation controls for Constantin (NR)
========= CHANGELOG =========
Week of 2014-01-06: - Implemented a GET IN (mapping to ENTER) and PUT IN (mapping to PUTON) feature for all beds - Added info and credits for the splash screen artwork (Triumph of Death) to the HELP files - Added FIRE as a noun (floating) in the calefactory - N.R.: Finished all new animation controls for Ignatius
A long, long time ago—it looks like over five years ago, actually, which makes me wince—I posted a blog article here about an analysis of verb use in some well-known IF games. These were based not on actual player transcripts, but rather on the published walkthroughs of these games. The walkthroughs weren’t necessarily the quickest solutions to the games—they included commands that were technically unnecessary for solving the game, but which provided a more complete experience of the game for players who followed them. Still, they were by no means game transcripts, so they didn’t truly reflect the typical use of verbs that one might expect from players. The idea was to get a sense of the breadth and depth of verb usage in these games, and one of the things I found was a surprising range of verbs required, with one game requiring a total of 65 different actions. I also looked at Vespers, which required fewer verbs in its walkthrough than some of the other games, and was dominated by movement, talking, and examination.
But that, again, was an analysis of the verbs specified in the walkthoughs for those games, so it doesn’t represent an accurate verb frequency distribution for players who actually play the games. That would require a series of game transcripts, along with some effort to extract out and analyze the commands used.
As it so happens, our version of Vespers generates text files of game transcripts each time it is played which, when examined, have the same appearance as a transcript from an IF game. There are a few modifications; since movement is not represented textually but rather through mouse input, I insert notifications in the text files when the player moves from one location to another. I also insert notifications when the player clicks on an object, since this can help in the interpretation of the transcript. But overall, it looks much like a transcript from a text IF game. To wit:
***** Your room is small; it is the same as all the others, but it seems smaller of late. With so many of your brothers gone, there has been little for you to do but wait. Wait for the spots to appear in this tiny, dark room.
Six crisp chimes mark Vespers. Your heart flutters for a moment.
** Player moved to: Your Bedroom
(The player selected your blanket.)
>> pick up blanket Taken. (The player selected your desk.)
>> pick up desk You're far too weak to carry something heavy like that around.
Thunder rumbles overhead, shaking the monastery to its foundations.
(The player selected the window.)
>> open (the window) The window cannot be opened or closed. *****
When I went through a period of testing earlier this year in preparation for submission to the two game comps last month, I asked my testers to send me all of their game logs so I could look them over and find trouble spots, verb or noun synonyms that would be useful to implement, or newbie-like situations that would benefit from additional information or guidance. But this also gave me the opportunity to extract out all of the commands to look specifically at the verbs players were using, just to get a sense of what people were trying. For this report I didn’t use every game transcript, since it takes a good deal of processing with each file to identify and extract the commands, so what you see here is the analysis of seven transcripts of reasonable length and more extensive playing. But while the sample size is small, the results were nevertheless interesting:
Click on the image to “examine” more closely. Get it? “Examine”?
This graphic shows the 20 most frequently used verbs in the game. Overall, in these transcripts, there were 82 different commands used, although some of those represent typos or attempts at abbreviations, such as typing T for TALK (which I haven’t implemented). Note, of course, that movement commands, typically near the top of the most commonly used verbs, are not represented here, since movement in our game is performed with the mouse. I’ve also removed any game meta-commands, such as commands that adjust preferences (like SET RIGHT MOUSE BUTTON and so forth).
Some interesting observations:
This is potentially some really useful information, although it’s limited to the top 20 commands. What about the rarely used commands? That’s where some really interesting things can be found, as people try things either because of misunderstanding, confusion, or merely to test the limits of the system. What I found from a review of the commands tried only once, twice, or three times among all of the transcripts:
In all, the rarely used commands (those tried three times or less across all transcripts) accounted for 52 different types of commands, and most of those gave no particularly informative response. That’s something to look more closely at, although to be honest, I don’t have the full set of verbs implemented at this point.
One thing to bear in mind is that these were transcripts from testers, not random players, so these could certainly be people who were trying to push the limits of the game rather than simply playing through. They may also have restricted themselves from doing the types of things they might ordinarily do when someone isn’t “watching,” per se, through submitted transcripts. But all in all, I thought it was very helpful to see the kinds of things people were trying. Not only does it help identify gaps in my verb implementations, but it also helps to debug, locate areas or objects that give people trouble, and improve the responsiveness of the game for less experienced players. Overall, it’s a really great tool for testing.
In the last post, I talked a bit about my game design documents for Vespers, although technically they’re really more like level design documents. Vespers doesn’t have levels, of course, but it does have Acts that are organized chronologically, so design docs for each Act help to organize the content and action into discrete compartments. I thought this would be an interesting look at how the game is structured, where the action takes place, and how the docs have helped in the design and development of the game.
Previously, I showed the design docs for Acts I and II, which represent the first day of the game. Most of the action involves talking with the various NPCs to understand the backstory and current context, and to set the stage for the rest of the game, although there is also a little bit of puzzle solving. If the player makes it past the first day, then the game proceeds to Acts III and IV, which represent the second day of the game. That’s when most of the heavy action takes place—truths are learned, plots are uncovered, lives are endangered, and several puzzles need to be solved along the way.
Plenty of spoilers ahead. You are hereby warned.
The design doc for Act II got a little complicated, because some of the action is ordered chronologically, and some characters appear in different places at different times during the Act. It starts with the player waking in his bedroom and confronting Constantin, and from there it’s a bit of a free-for-all. One thing I have to review more carefully in the original code is if any of the events that take place are required before others can occur. For instance, I know that the player can’t encounter Drogo in the Cloister until after he converses with Constantin outside the Calefactory, but can all of the activity beyond the front entrance—which is now accessible in Act III—occur without first confronting Constantin? What about encountering Drogo in the briars behind the stables? There is a good deal of openness in the game world, but not always, as I’ve learned.
Click for a larger view.
Although I have most of the content for Act III already in hand, there are some aspects here that I’ve always known would be a challenge, and those are still yet to be resolved. There are three scenes in particular that will be extremely difficult to organize and implement: Drogo dragging the player into the Church, animating and riding the horse, and, worst of all, the avalanche scene in the mountain pass. I don’t know what kind of creative magic it will take to develop and animate an avalanche.
Act III ends if the player can survive the avalanche and make it back to the main gate, which triggers the start of Act IV, which is the real climax of the game. By now, you certainly know about the spoilers coming.
Click for a larger view.
Like Act III, Act IV has a number of scenes that don’t necessarily have to occur in a particular order, or in some cases don’t have to be encountered at all, and many of them are technically challenging. For instance, the scene at and behind the stables when the player encounters the hungry wolves is one that could be bypassed altogether (I think), while at the same time it will involve a lot of complicated animation and coordination. Then there is the cellar scene, which is not optional, but also quite complex to orchestrate. The fire in the monastery and the final struggle at the top of the bell tower won’t exactly be walks in the park, either. But hey, that’s why they pay us the big bucks.
Act IV ends after the encounter at the top of the bell tower, transitioning immediately to the third day, or Act V. Little action happens in Act V, as it takes place entirely in the Church, but it dictates the final outcome of the game, based primarily on the choices and actions that led to this point. It is essentially a denouement for the game.
Click for a larger view.
So those are the design documents for the different Acts of the game. As you can see, even after finishing Act I and the first cutscene as the demo (submitted to the two different comps last month), there is still a great deal of work left to do on this game. Again, most of the content for this work is already done, such as the modeling, voice work, and so on, but what still remains is the more complicated stuff: the animation and the orchestration of the different scenes. We’ll just keep pecking away at it until it’s done.
Since Vespers has mostly been a one-man operation, I haven’t spent too much time on formal game design documents. Some detailed information can be helpful for collaborators, particularly on the art side with N.R., but I’ve mostly dealt with those issues as they’ve arisen. But one area that I’ve found helpful for myself has been mapping out the locations and activity in the game, so I can keep track of what happens in a particular Act and where it happens.
Since I’m using the text version of Vespers as the basis for the game, I’ve had to play through the text game and read through the source code countless times, making sure to account for all different kinds of approaches to game play. Jason wrote the original game in such a way that most activity occurs in distinct locations around the map; rarely does an event occur that spans multiple locations, and rarely does an NPC move from one location to another during an Act. That made it relatively simple to lay things out for each Act on a map of the game, which I can refer to at times to make sure I’m accounting for everything.
I started out by mapping the entire text game onto a location map, with each box representing a location in the game, and lines representing the pathways between locations according to compass direction.
Click for larger version.
The first day of the game comprises Acts I and II, although the text game doesn’t split things up into separate Acts—that’s something of my own creation. During Day One, the action is restricted to only about half of the game map, as the player is not allowed to leave the monastery due to the weather. The rest of the activity was mapped out on this template. So, for Act I, the design doc looked as such—and note, there are, of course, spoilers here:
Click for larger version.
For those familiar with the text game, the only departure here is that the “cutscene”—that is, the scene where the first dead body is discovered—occurs in the Cloister per se, rather than in the location specified as “Base of the Belltower” to the northeast of the Cloister. This was mostly for 3D reasons; the way the monastery (and the Cloister in particular) was created in 3D didn’t really allow for a distinct space for the base of the belltower that is not covered by the Cloister colonnade (which, for spoilerly reasons, would not accomodate the dead guy very well.)
(Actually, that’s not entirely true: in the 3D game, I’ve actually reversed the locations of the infirmary and stables, such that the infirmary is on the east side of the monastery and the stables are on the west side. I can’t remember now why I did that, but I don’t think it impacts anything.)
As for Act II, that begins right after the first cutscene ends, with the player standing in the Cloister. Interestingly, Act II has less action than Act I, and can even be totally bypassed by the player if desired. The Act ends when the player goes to sleep for the night, which of course triggers a new scene and/or cutscene, before proceeding to Day Two (and Act III). Again, spoiler warning.
Click for larger version.
Arguably, these are not true game design documents per se, since these really only provide a glimpse at the basic map of the game and the briefest of descriptions of the action in the game, without going into all of the other aspects of game design and play that these documents usually describe (art style and concepts, sound and music description, user interface details, and so on). It’s probably better to describe these as “level design” documents, so to speak. Perhaps one day I’ll put all of the rest of the details together into a true GDD, since I actually have most of them already put together in one form or another.
More on Days Two and Three later.
