CS/INFO 4152: Advanced Topics in Computer Game Development

Communication Lab 1
Team Workflow and Brainstorming

At the start of this lab, you should get together according to your assigned groups. For many of you, this will be your first official meeting with your group. The lab today will be focused on two important topics: starting your Team Workflow Document and brainstorming ideas for your game.

When you meet with your group, check to make sure that everyone is there. If anyone is missing, let us know immediately. If someone is missing group meetings this early, it does not bode well for the future. If a team member must be replaced, we need to know early while we can still add new people to the class.

As with all discussion sections in ENGRC 4152, there is nothing to turn in for this lab. All of your work will be turned in as an assignment in CS/INFO 4152.


Team Workflow

At the very beginning of class, Traci will talk to you all about group dynamics and what is expected of you this semester. She will go over the purpose of the team workflow. She will also talk about what to do if you think you need to revise your workflow document.

We do not want you to finish the team workflow in lab time. That should be completed outside of class, and we want you to spend the majority of the time brainstorming. However, you should spend some class time thinking about team roles. Everyone should have some sort of role. However, there are three roles that are very important:

Project Leader

This person is in charge of assigning tasks and keeping the group on top of deadlines. They are also responsible for gathering together the information for the bi-weekly reports (though everyone is expected to contribute). This should be someone who can get along with everyone on the team.

Software Lead

This person is in charge of the architecture decisions on the project. They lead the design of the architecture specification, and have final say on all class interfaces. They also assign programming tasks to the other members of the team. This should not be the same person as the Project Leader.

Design Lead

In the case of multiple designers, this is the person who sets the visual aesthetic of the game. They have final say on the artistic style of the game, and the other designers are expected to conform to this style.


Game Ideas

You should only spend 10-15 on the team workflow document. The majority of this lab should be spent brainstorming the kind of game you want to make. For this lab you will use some, but not all, of the formal design elements that we talked about in the introductory course. If you did not take the introductory course, this is okay, but you should listen closely to your team mates.

When you develop your ideas, you should focus on your core gameplay mechanics, but do it by framing them in terms of the player experience. This is the approach favored by Ernest Adams, who uses it in his game design tutorials. We have also found that it is one of the most successful approaches for beginners.

As you work, write down answers to the questions below. You should use these to prepare you for the pitch session next week.

It is possible that you will not answer all of the questions. Answer as many as you can. In addition, you do not need to answer them in order. Different designers find it easier to begin with different starting points. Some people like to begin with verb brainstorming from the very beginning. Others need to understand all the goals and challenges before they understand the verbs. As with everything else in this course, treat this as an iterative exercise. Answers to some parts may cause you to go back and revise other parts.

While you work, several TAs will be moving about the room. They will listen in on your groups and occasionally give you some feedback (though they will not directly give you ideas). If you have any questions about this activity, please ask the TAs. The are all alums of this course, and have been through this process before.


Thematic Focus

Before you formulate your core gamplay, you will first define the thematic focus of your game. This is not the same as genre. Unlike a book, a game genre does not define a setting or theme; instead it implies a common set of gameplay mechanics. You will not worry about mechanics until you have defined your theme.

Defining your theme consists of answering the following questions:

What dream are you satisfying?

As we discussed in class, many games are about wish fulfillment. That is, they are a response to a statement of the form "I want to ______." This can be a role (e.g. "I want to a be a crime-fighting zombie"). It can be be an activity or experience (e.g. "I want to explore a land where I do not know the language"). It can even be an emotion (e.g. "I want to feel lonely, but content"), though these are, by far, the hardest to achieve.

What statement are you responding to? Choose carefully, as the rest of this activity will be critiqued according to how well it supports this theme.

What is your setting?

The setting is what your player sees. Is your game a virtual (albeit 2D and primitive) world, or is it some mathematically abstract landscape? If it is a world, what kind of world is it? This should expand on your dream mentioned above.

It is possible to get too carried away in this step. Keep your description short and limited to a few sentences. We are not looking for an unabridged history of your game world.

What is your perspective?

The perspective is how your player sees the game world. If your game is set in a virtual world, is the perspective top-down, side-scrolling, or isometric? If it is an abstract mathematical world, how is the abstraction represented visually to the user?

Player mode diagrams are particularly useful for explaining perspective. You may wish to draw a picture to answer this question. However, we are not requiring any pictures at this stage of the design.


Gameplay Mechanics

Now that you have some ideas for the theme of your game, you can start work on your core gameplay mechanics. This is a process that does not end with this communication lab; you will be refining and redefining your mechanics over the course of the semester through your various prototypes. However, to get you started, you should answer the following questions:

What are the player's goals?

You have provided us with a theme. Now try to distill this theme into concrete goals. In doing so, you should certainly keep in mind the formal types of goals mentioned in class or in the assigned reading. However, you should always start with informal goals that directly match your theme, and then figure out how they correspond to more formal design elements. Never start with with the formal elements.

You do not need to limit yourself to a single goal. Secondary or optional goals are also okay. However, try to keep this list relatively short, as too many goals will make the rest of the exercise complicated and unfocused. In particular, limit yourself only to goals that are mandatory for the player to complete a "level" in your game.

What are the player actions?

As we discussed in class, games are an interactive medium, and that means that players can do something other than watch the game. Actions (or "verbs") indicate what the player can do. These actions may be tied directly to an avatar, or they can be the result of a disembodied entity (e.g. as in many "God games").

For this step, tell us your most important actions. Follow our guidelines below. Focus on the outcomes of the actions, and not the user input or how it is animated. Furthermore, if your game fits within a genre, you should simply mention that (e.g. "we have standard platformer movement") rather than describe each verb individually. You should only spend time describing a verb if it is relatively unique.

In describing your verbs you should try to indicate, for each verb, whether it is primary or secondary. Remember that a primary action is one that is necessary to achieve (one of) the goals that you listed in the previous step. For example, if your goal is to reach a location, then your primary actions consist of the movement verbs. Your game may also involve some form of combat, but unless destruction of enemies is a goal (e.g. you cannot complete a level without destroying so many enemies), the combat verbs are secondary, not primary.

Do not worry if not all your actions are primary. As we discuss below, many indie games concentrate their innovation in their secondary verbs. But this step is important because it helps you prioritize the important verbs from the less important ones. Indeed, you may find that you want to change your goals to make a secondary verb into a primary one. Furthermore, you should avoid having more than one or two secondary verbs.

What challenges does the player face?

Challenges prevent the player from achieving the goal(s). Describe some of the challenges that you expect to have in your game. You are not expected to come up with all of your challenges right now, but you should describe at least 2.

In describing your challenges, you need to be aware of the type of challenge. We have talked about challenge taxonomies in the introductory course. For this activity, we want you to focus on classifying your challenges as one of two types.

Extrinsic Challenges: An extrinsic challenge is one that does not depend on the actions themselves, but instead depends on how well the player performs the actions. Timing, rhythm, or hand-eye coordination are the primary types of challenges in this category.

While these types of challenges can be fun, it is important that these are not your only type of challenge. Games limited to these types of challenges tend to get old very, very quickly. They can also be frustrating for players not committed to your game (e.g. pixel-sensitive platformers).

Intrinsic Challenges: An intrinisic challenge is one that the player overcomes via game mechanics, or the combination of a verb (or verbs) and interactions. This can include enemies, where the associate mechanic is either combat or stealth. It can also include spatial obstacles. Lock-and-key or resource challenges also fall into this category.

When you have finished describing your challenges, you are done with the exercise. Feel free to go back and revise your answers to any of the previous questions.


Describing Actions

One of the biggest challenges that students have with game design is properly defining actions. If you do not understand your core actions (both primary and secondary) from the beginning, your gameplay will be very shallow. And then you will be tempted to compensate with this by adding even more features and actions. This "verb bloat" is a guaranteed way to get a lower grade on your game.

There are several things that you should keep in mind when defining your actions.


Be Outcome-Oriented

You should avoid the "verb proxies" that we talked about in class. "Use an item" is never a core verb, as each item can have a different effect, and thus represent a different kind of activity. To ensure that your verb is suitable, we find it is best to describe the outcome. For example "hurt an enemy" or "hurt an enemy from a distance" is often much better than "shoot."

As a general rule, a verb should correspond to a single outcome. For example, if your game has weapons with different types of ammunition — such as freezing ammunition or fire ammunition — the effects of each one of these corresponds to a different verb. However, these lines are not always clear-cut. If you have ammunition types, but the only difference is the amount of damage that each types causes, or the defenses that each type can overcome, this is just one verb.

In addition to being more descriptive, this approach to actions allows you to be more flexible in your artistic design. Whether you are attacking with a gun, a magic wand, a bow-and-arrow, or throwing stars, the attacks all create projectiles that cause damage and so are essentially the exact same action. Yes, there may be differences in attack speed, damage, or resource usage, but these are additional mechanics that you do not worry about during the initial design process.

Another important feature of being outcome-oriented is that you do not define actions in terms of input control. In most platformers jump and double jump are not the same action, even though they use the same action button. However, determining what is actually a separate action can be a bit of an art form. For example, in platformers, a long jump is a combination of a jump with forward movement. Is this actually a different verb, or is it just what you naturally get when you combine the upward movement of a jump with forward movement? This is not immediately clear. Make your best guess when deciding what needs to be its own verb.

One of the greatest resources for understanding outcome-oriented actions is the Hero System. This is a pen-and-paper RPG that is famous for its flexibility in designing character abilities. Absolutely everything is described in terms of what it can do. Want a fireball spell? That is just a 10d6 ranged killing attack with area effect and no normal defense. The fire aspect is a "special effect" that describes what the attack looks like, but has no significant effect on the game mechanics.

If you are interested in learning more about this approach, we have provided a copy on reserve in Uris Library. Chapter 5 (Powers) is the important chapter to read.


Leverage Genres

A game genre is a set of actions and challenges that are common to games of that type. For example, most platformers have side-to-side movement and jumping (though some replace jumping with wall-running or other forms of vertical movement). If your actions are those from a recognized genre, feel free to say that (e.g. "our game uses standard platformer movement"). This is concise, and it allows you to focus on the different elements of your game.

If you are leveraging an existing genre, we recommend that you pick one with a relatively small number of actions. Lots of verbs means lots of controls to implement. This is difficult for you, as a developer, to implement, and difficult for the player to learn. There is a reason why a large number of indie games are platformers plus an additional (often secondary) action.

Another option with genres is to start with a genre and "strip it down", removing actions so that you get a smaller mini game. Many of the deconstructive games that we talked about in class fit into this category. For example, Help the Hero takes an RPG and removes everything except for inventory management, while My Pet Protector concentrates entirely on leveling.