CS/INFO 3152: Introduction to Computer Game Development

ENGRC Lab 1
Idea Formation

Due: Thursday, February 4th at 11:59 pm

At the start of this lab, you should get together according to your assigned groups. For some of you, this will be your first official meeting with your group. The lab today will be focused on two important topics: starting your group charter 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.


Group Charter

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 group charter. She will also talk about what to do if you think you need to revise your charter.

We do not want you to finish the group charter 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.


Activity: Brainstorming Ideas

You should only spend 10-15 on the group charter. 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 lecture. You will focus on your core gameplay mechanics, but you will do so by framing it 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 will turn in your answers, and we will critique them for you. You will use this critique to form your concept document 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 coming up with your verbs, you do not need to separate actions and interactions. It is okay for you to think of composite mechanics, like stomping a Goomba, as a single verb. That can make your design a lot easier. We will worry about actions and interactions in a later exercise.

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 or 3.

In describing your challenges, you need to be aware of the type of challenge. We have talked about challenge taxonomies in class. 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 (e.g. actions 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.


Suggestions: 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 two important 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.


Submission

Due: Thursday, February 4th at 11:59 pm

You do not need to submit anything about the group roles. We will see that as part of your group charter at the end of the week. The only thing that you need to turn in for this lab is the result of your brainstorming. We will critique your ideas so that you know what to put in your concept document next week.

We will also grade this submission, though the grade will be pass/fail based solely upon whether your group was present and took the assignment seriously. This lab will be part of your documentation grade.

To submit your answers, create a file called ideas.txt which answers all of the questions above. If you drew a picture, scan the picture and submit the document as a PDF instead. You only need to submit this file once for the entire group.