When it comes to game design, there can be several different meanings: the story of a game and the technical aspects that supports the needs of the story. Let's start by looking at the first view.
Why do people play computer games, especially networked games? A short answer is it is fun. Knowing that different people define fun in drastically different ways, maybe there is something else. How about "in search of an identitiy"? In a loose way, what you enter college and choose a major because that's the major you like, a similar process has taken place. Just that in the virtula world of multiplayer games, the physical tangibles are far removed.
It is then helpful to ask the question of how many different kinds of "identities" there are? At the risk of stereotyping, let's look at a few. Achievers are those who usually likes to act on the world, and play to "win". (Kind of like playing god) Explorers like interacting with the world and enjoy discovering. (How many of you like watching Discovery channel or National Geography?) Killers like dominating other players, be it via bullying or politicking. Socializers enjoy spending lots of time chatting with other players. With such a paradigm, the idea is to develop stories of games catered to different player type.
Later research found that more is involved. For instance, when a player changes from a explorer to an achiever (like a outdoor adventurer wanting to build a water dam), what might the reasons be? In addition, some killers are less aggressive than others. So how can the degree be characterized? Latest literature often uses a three-dimensional model of players, with the three dimensions being: players (0) vs. world (1), interacting (0) vs. acting (1) , and implicit (0) vs. explicit (1). The previous 4-type model only considers the first two dimensions.
Now things become interesting. Maybe we can tell more about ourselves too.
After years of research, here is how the community of multiplayer game development views the users (i.e. everyone of us who plays, :-). All paths in the following graph, directed from left to right, is possible, for reasons enough to write a brick-heavy book.
griefer -- networker -- politician -- friend
\/ \ /
/\ \ /
opportunist -- scientist -- planner -- hacker
So players start out in a virtual world as an implicit, turns explicit and finally become implicit again. The overall path is then "locate to discover to apply to internalize". This is indeed how every human being would learn, including babies. Note that a scientist can never become a politician, while a politician would never want to deal with the world. (:o)
Immersion is a sense of being in a virtual world. There are different levels of it, however: unimmersed, avatar, character and persona. Naturally, a player would progress through the levels and during the process affirms the player's identity. The big deal of virtual world is allowing everyone, with as much unfortunate entanglement of reality as we have, to embark on a journey in a quest for the self. To most of us, this virtual self would be a hero. Maybe this explains in part of the immense popularity of online multiplayer games.
As discovered by Joseph Campbell, the hero's journey is pretty the same in all cultures. The thread starts with departure, followed by initiatiation and finally a return. In virtual world, for departure, it starts with a call to adventure (call to spend money), you refuse (to play), a supernatural aid came along (a friend of yours convinced you) and cross the first threshold (you got the software running), and created a character (rebirth).
Initiation starts from the lefthand side of the path of player evolution. You start trials, meeting the goddess (know the big picture), going from learning to doing (networker/scientist), and then starting to know what the virtual world is about (politician/planner) and be recognized by the virtual world, finally winding up as hackers/friends. The end of initiation is acquring a token of achievement. In many ways, this is the reason for the hero to visit the different world to begin with.
The return can be summarized as the unpleasant but real process of realizing (with help or arm-twisting by other people) that virtual is not real and come back to the mundane life. All fictional stories in various cultures follows the same overall process, so do most online games. The question is how good a story you can come up with. Since this semester we will mostly focus on the technical side of networked games, don't spend an overly long time on this. You have one week from today to finalize the story of your game and let that be it.
Most multiplayer games encounter the common three thiries. Knowing about these, you can quickly sketch out several key components in your overall technical framework, i.e. some must-have functionalities.
The first 30 minutes. This is the most important for a gameplay. The player sees the controls, the systems and the story (fictional fabric) for the first time. You need to focus on three major tasks: control tutorial, character creating and fictional context.
The control scheme is the way for a player to interact with the virtual world. Keep the controls simple, most important customizable (yeah, how?). No surprises. If there is a standard way of providing a control, just use that. Reveal controls in your tutorial slowly and simply (i.e. need-to-know basis). Most importantly, let a player learn about the control set privately, not seen by others in the game environment. For each game design, this part must be documented with a formal control tutorial, as well as detailed interface spec of all needed modules, to be developed by the entire team.
When creating a character, mature games often have subtle but versatile ways for players to specify their path of advancement. For instance, in a certain game, by picking a different profession, family and race, one choose to become a opportunist and then a networker. For your project, keep this part as simple as possible, as long as implicit path of advancement is supported. For character appearance, also important in character creation, please try to stay as modest as possible.
Within your overall story line, there needs to be a set of small (5 to 10 minutes) tasks for each new characcter to make a sequence of small quests. The goal is to prvoide clear directions early in the game to establish the overal story, and further strengthen control tutorial. Accordingly, in your software design, the overall story line is not a "line", but instead should be composed of a hierarchical graph. Make sure there is a capable component to handle graph operations. Each team must provide a detailed set of header files describing a class hierarchy for handling the switching among small story lines, more appropriatedly referred to as "story arcs".
The main theme is character advancement in this stage, and the basic utility here is a compelling and logical quest-flow to transition the player from shorter paths in the first 30 minutes to more group-friendly fame with more quest options and longer term goals for both the group and the individual. This is the time when the players first enter the main game world.
Some mature games make the transition natural with environmental changes (an abandoned city after enemy invasion, for instance). We have little time, so don't focus too much on the "natural" requirement. A key technical element here is to start keeping "score", make frequent rewards, and provide choices (3 to 8) at each step. As a player progresses, just like when we graduate high school, enter college and then graduate college, start limiting the number of choices and hence better define their path of advancement. How do you maintain so many choices, note different player coming to the same scenario may have different numbers of choices? Why don't we all think about it?
Now the next important thing is to develop a player's ego, as defining its role within a group. It is preferrable to have larger groups as opposed to small ones, because a 6-player group losing one key member is a much bigger problem than that for a 100-player group. Your story line should encourage established groups to recruit new players, and encourage new players to join groups (no loners). Make grouping the better (fast, safe and efficient) way to advance. Your system must support group-wide attribute or skill benefits, and fundamental skill enhancements by being part of a group. Award group plays hansomely. Technically, how do you plan to support groups with the above functionalities?
At this stage, individual projects will last longer and require more investment of time, effort and/or resources, provides regular feedbacks but not necessarily affect the player's score. Examples are item collection or building a house. First you might need gold. Then you exchange that for equipment or blueprint. This process goes on and on.
The game also needs to provide projects for group times or the friendship to grow stronger, and to expand their influence to other players. A few possible examples are: to win prestige for a guild by winning other smaller guilds, to advance a city via group efforts, and regional conquest (conquering the world).
In the meantime, the software, especially the server part, must be constantly running with little downtime. As players' needs/wishes evolve overtime, the developers make have to make changes post launch of a game. From this aspect, it is a critical task for the developers to distinguish mechanism vs. policy, and truly understand what makes a server and what makes a client. The core part of the software must be able to incorporate dynamic libraries, etc. This list goes on and on.
In closing, please consider this lecture as an overview of general user requirement. Let me emphasize again. You most often will write code to be connected with a module different from you originally thought.