Bring Back The Party Spirit! (The Trouble With Sharing.)

Without doubt, the most fun games I have ever played have to be when I have shared the experience with a fellow gamer in a co-operative style multi-player game: where players play out the same story and work together towards the same end, as opposed to a "capture the flag" style MP game where the players are usually pitted against each other and do not normally take place in the original story. While I am sure many players share individual gaming experiences with their fellow gamers, it is not the same as actually playing the same game and discovering the story at the same time. I also believe this is what made/makes PnP D&D the success it once was/is. I am vague on the tense I use here, as I am not sure the D&D game has the same appeal to modern day players as it once had when its attraction and success was based very much on the imaginations of the players compared to the senses-driven CRPG environment that players are so used to today. Before computer graphics, players had to rely solely on DM descriptions of their environment, with a few drawings and paintings to help inspire everybody's imaginations at best. Nowadays, an argument could be raised that says, "What is the point of a description when you can see and hear all the action onscreen!"

I believe, however, we are in danger of throwing the proverbial baby out with the bathwater if we are not careful when designing an adventure in such an environment that NWN provides the computer aided D&D world. Why? Simply because while we are drawn in with the fantastic ability to have our creations come to life through computer technology, at the same time we are losing the importance of creating something that can be shared by others. I am not talking about the experience of the game itself, but the experience of playing the game and sharing the experience with another player at the same time. The baby in this sense is the shared experience, and ultimately means providing a game that can be played as a multi-player (MP) experience as much as single-player (SP). I want to quickly add that by multi-player, I do not mean creating a persistent world (PW), but, instead, a module where two or more players can enter and then enjoy the same story and experience together. I make the distinction between a PW and a MP one, because the former tends to only offer an environment with varying paths for advancement according to a preferred style of play, whereas the latter tends to be a more focused story with a distinctive final objective or ending. By their very definitions, a persistent world is persistent, whereas a module is a complete/closed environment. However, a module can be created to allow more than one player to play at the same time if the builder designs the module with MP in mind. The problem with designing a module to be MP is that it can change what at first appears to be a reasonably simple idea into an exceedingly complicated one. My aim in this post is to help remove some of the bigger obstacles that may have prevented a MP design from fellow builders in the past. By sharing two of the more important problems I had to overcome, I hope to present the solutions to them in such a way that will both encourage and inspire builders to take steps towards designing a MP module that might rekindle some of the party spirit in the style of a good old-fashioned D&D adventure where friends would gather around the table and play together. I hope to bring back the baby, hopefully not kicking and screaming, to be enjoyed as much as it once was by a group rather than just an individual.

To support my own belief in encouraging releases of co-operative MP modules, "Better The Demon" will be released supporting MP play as well as SP. In the past, I have often mentioned the added difficulties of catering for a MP environment, and again, only this week, I found myself having to revise two fundamental aspects of the module to ensure both rigidity and logical flow remain intact: transitions and conversations. It is these two aspects of module design I wish to cover now, which if handled correctly from the start of the design, will go a long way to ensuring a stable MP module. While, I have experimented with many different approaches to these problems over the last couple of years, I believe I have finally settled on a solution. Although I have divided this topic into two, you will see that I refer to both subjects within their own topic. This is because the two are closely related.

Transitions (Setting The Boundaries)

When playing PnP (pen and paper) D&D, it is very easy for one player to ask the DM to do something in one area, while another player may be doing something else in another. When translating this concept to a CRPG environment, it is very easy to be misled into trying to come up with a kind of "autonomous" design for each player, by allowing the players to venture into their own "areas" independent of each other. I will tell you of some of my own (failed) ideas before sharing the final solution I settled with and the reasons why.

DESIGN 1: At the very start, I was sorely tempted to set the module property to allow more than one party at a time. This had the advantages of appearing to solve both of the problems I am talking about in one go. By having separate parties, the different players could create their own individual "party" and all transitions and conversations would be handled for each party individually.

DESIGN 1 PROBLEM: The design reflected more of a persistent world (PW) approach, in that each party was too independent and each would quickly end up following their own individual path through the module. Different variables would be set for each player, causing a breakdown of consistency of a single story. As the module was designed to be a co-operative MP experience following a single storyline, then this multi-party approach failed.

DESIGN 2: My second approach (using a single party module setting) was to allow players to visit their own "area" with the PCs they controlled, as long as it did not involve long distance travel, which would separate the players significantly. E.g. Allow one player to go inside a tavern within a village, while another spoke to the man at the local market in the same village.

DESIGN 2 PROBLEM: I thought I had this working for a long period of time. Initially, I had encountered a number of NWN engine issues that caused game crashes when one player was trying to change areas while another player possessed a shared companion. However, even after I solved this problem, I came up against a problem with another design idea I had in place: In "Better The Demon", players control their own PCs. In other words, although players are within the same single party, each player is responsible for their own PCs within the party. E.g. The PCs will only rest when the player who controls them rests; the PCs follow the player that controls them and not the party leader (unless the player is the leader); and the PCs will only respond to the commands and shouts of the player that controls them. Unfortunately, however, whenever the party leader leaves an area, all companions, whether associated with another player or not, will leave the area with the leader. As I mention above, I resolved the crash this would cause if another player possessed a companion at the time by ensuring the said player was forced back to their main PC prior to the companion being zoned. However, it later became obvious that this could have dire consequences if the second player's main PC was dead, or if a player was in the middle of a conversation while using the possessed companion that was trying to be zoned via the party leader exiting.

DESIGN 3 (FINAL): Eventually, I reconsidered the original game design of allowing this autonomy for players to travel between different areas to each other and concluded that the idea was not actually required. For instance, even when playing PnP D&D, each player had to wait their turn before the DM could address their situation, irrespective of where they were in the game world. And in every situation, all players would have to sit through the discourse of the DM with another player until it was their own turn to speak of what actions they wanted their PCs carry out. In other words, all players were present at all events, regardless of where the PCs were and what events actually took place. Most of the time, every player was privy to their fellow players actions for their PCs and any events that came from the play was shared as an experience for the party as a whole.

To translate this idea into NWN (of being present in spirit even if not actually), we have to ensure that each player is actually present at each other's activities, which means ensuring every player's actions for their PCs take place in the same area as every other players. If this was not done, then even if we did manage to allow players to visit areas independently of each other, the players would have to stop play every now and then to keep each other updated of the events that they had done independently of each other. In this sense, the working together as a party experience would have been lost to individual information gathering. And although I do recognise there are times when being able to speak to different vendors in different areas could be useful, the potential loss to "surprise events" possibly encountered along the way is too great a risk to allow such autonomy to take place. In brief, the likelihood for players actually needing to be in two different places at once was too insignificant (or even potentially game spoiling) to allow. (See also Different Locations, Same Area below.)

To ensure the party do stick together, I have employed the Gather Your Party GUI for all area transitions. This GUI only shows in a multi-player game where more than one player could be involved in another activity within the same area as another player. Basically, if there is any risk of a player breaking an event of another player, this simple GUI ensures that all players are basically ready to leave together before the transition is accessible. For example, nobody likes to be zoned in the middle of a conversation.

Different Locations, Same Area

I should point out that an area can be designed with more than one location within it. E.g. A tavern may have an upstairs location and a downstairs location, which are designed within the same area. In such a situation, one player can easily control their own PCs to travel to one location independently of another player. This use of different locations within the same area allows the builder to offer some interesting situations to players who may then have to think tactically about which PCs to use and when.

Conversations (Sharing The Knowledge)

Knowing when to allow players to have conversations independently from each other is another difficult design area to get right when considering multi-player gaming. Many of the arguments about area transitions above can be used about conversations and, in particular, noting the point about ensuring every player in a MP game shares the same gaming experience. This is especially important with respect to the main story or other pertinent game background that is divulged through conversations. In my experience, there are two types of conversation: plot and casual. The main problems come when you have plot conversations that may also contain casual elements.

Plot Conversations

In my experience, I would say that it is essential that conversations divulging story background are set with the Multiplayer Cutscene property as TRUE so that every player gets to see the conversation taking place, even if they do not actually take part by clicking an option. A Multiplayer Cutscene conversation starts for every player in the same area, wherever they are and whatever they are doing, and can be displayed either as a NWN2 cutscene style conversation or the older NWN 1 conversation GUI. (This is the main reason why it is important for all players to be in the same area when playing, so they do not miss out on an important conversation.) All players are then able to see and discuss the choices available, even though only one player controls the input. (NB: The Party Chat property set as TRUE overrides the Multiplayer Cutscene setting. It prevents PCs beyond a certain range taking part in the conversation as determined by a setting in the Campaign Editor at build time. Those that are included in the conversation, however, can all have an input. UPDATE: The Party Chat will not be escapable with Multiplayer Cutscene enabled.) It is important to recognise that starting a Multiplayer Cutscene will abruptly end all other conversations going on elsewhere. E.g. If somebody is speaking to a vendor about something, the player will suddenly be dropped out of that conversation and brought into the cutscene one. As long as the abruptly ended conversation did not contain any unfinished "once only" nodes (especially with important variable settings on them), then it should not be an issue, apart from forcing the player to have to "replay" the original conversation after the cutscene one has ended.

Other examples of when to use Multiplayer Cutscene set as TRUE include:

1) Companion atmosphere speeches, where a member of the party addresses other members (i.e. all the players) about something they have observed. (Use sparingly, especially in areas that use different locations, as players may be separated and so logical flow could appear off.)

2) NPC triggered atmosphere speeches to give extra information to all players, while preventing the players from bypassing the speaker. (Force the players back.) Note the same issue as mentioned above.

3) When we want a Party Chat conversation to not be escapable at any time during its conversation.

Casual Conversations

By contrast, casual conversations are those that do not offer much to advance the story and better serve the individual needs of the player/PC speaking to the character with the conversation. Such conversations include those with vendors that give access to a store or allow a player's PC to do something that does not have to involve the whole party of players. Judging when to allow this is not easy, but there is a good way to handle it if in doubt. In every instance of any type of casual conversation, however, the Multiplayer Cutscene is always set to FALSE. UPDATE: Unless set as TRUE with Party Chat to prevent the player from escaping the conversation.

If a conversation is obviously casual, with absolutely nothing to be gained from a party perspective, then feel free to leave all properties as FALSE and only setting TRUE the one that determine if you want the conversation to be in a NWN1 (old conversation GUI) or FALSE if a NWN2 (cutscene) style.

If, however, there may be something useful to be gained by the party as a whole, but does not warrant a full-blown use of a party Multiplayer Cutscene setting, then make use of the Party Chat option by setting it to TRUE. Then, when a player starts a conversation with the NPC with the Party Chat enabled, all nearby players will be involved with the conversation, but also allows players further afield (maybe doing their own thing) to not become involved and/or forced out of a conversation they are already having. NB: If a player is within range of a Party Chat conversation, they will still be forced out of any conversation they are in to take part in the Party Chat one.

The order of priority for setting multi-player conversations is as follows:

1) Plot: Multiplayer Cutscene = TRUE. Party Chat = FALSE. (TRUE overrides Multiplayer Cutscene, but allows a Party Chat to not be escaped from.)

2) Casual (Important): Multiplayer Cutscene = FALSE. Party Chat = TRUE. (All nearby PCs involved.)

3) Casual (Unimportant): Multiplayer Cutscene = FALSE. Party Chat = FALSE. (One speaker only.)

The golden rule is: if in doubt about the casual conversation, set it with Party Chat as TRUE.

Useful Multi-Player Conversation Tips

1) Avoid using PLOT Multiplayer Cutscene = TRUE with NPCs who also have stores. Instead, consider implementing an alternative means to access the NPC's store while they are present. The latter made accessible after having given the first conversation.

2) Only use the "once only" option on a node of casual conversations if you are sure you can afford to lose the information and accompanying variables it may alter. This is because a plot conversation that employs the Multiplayer Cutscene property will cut short any other conversations running at the time if started. If you have any critical "actions" or "quests" in the paths that follow the "once only" node and you cannot get to them again, then you MUST make sure this conversation CANNOT be interrupted, either by upping its priority to a Multiplayer Cutscene or setting check variables, or even ensuring important variables are set if the conversation is "aborted" due to another conversation of higher priority being started. Doing this, however, could confuse the player who had their conversation aborted.

3) If you want to make even the Party Chat option include every PC in the area (like the Multiplayer Cutscene mode), then increase the value in the Campaign Editor to cover even the furthest distance apart. (I have not tested this myself yet, but it should work.)

Final Questions

BUILDERS: I believe I have covered the two most important issues when it comes to module builders considering designing a module to cater for MP play. However, if there are other reasons why you prefer not to design a module with MP in mind, then please let me know. Maybe I am missing something I should know about. :)

PLAYERS: Am I a dying breed? Does not a co-operative gaming style appeal to you more than a SP game only? Let me know what have been your most exciting gaming experiences and why? Do you prefer to play a D&D game in a party of real players or are you content with a party of your own?