Communication Lab 7
Architecture & Design Exercise

Due: Friday, February 28th at 10:10 am

The focus of today's lab is to start thinking about the architecture and design specifications that are due before technical prototype. These may seem a long way off (so far off that we do not have links to the instructions yet). However, it is helpful to start thinking about them right away. This is particularly true for the programmers, as it gives you a chance to try out the techniques that we just talked about in lecture.

In the past, this lab has only been about the programmers, giving them a chance to finalize their architecture. However, we have recently added an exercise for the designers which is just as important: specifying an art style. This is only the second year for this document, but our design TAs are all very familiar with what we are looking for. Please ask for help if you do not know what to do.

The key thing about this lab is to look at the deliverables. You are expected to present your work to the class for critique on the following day (Friday). This is the first of several critique sessions. These are informal presentations where you get immediate feedback on what you did in lab. We will make heavy use of these when it is time to think about level design.

Programmers: CRC Cards

This lab is the CRC Card exercise that was described in the architecture design lecture. You can do this either with actual index cards, or with sheets of paper that are torn up. However, we really do want you to lay out the cards on the floor, or the table, or whatnot. We want this to be an active exercise.

Remember, that the goal of the exercise is to have each card touching all of the other cards that it collaborates with. If you cannot do that, it is time to refactor your design into more (or less) cards. Also, make sure that you have all of the major elements of your game that you can think of.

In designing your CRC cards, you should take the following all into consideration:

Respect the Model-View-Controller Pattern

Each card should be categorized as either model, view, or controller. No card should ever straddle multiple categories. This means, of course, that you will need a minium of three cards.

Respect Your Milestone Document

You should separate the cards so that they represent the order in which you plan to implement technical features. Each card should either be implemented all at once or not at all. For example, if you are implementing character AI by alpha release, but are going to delay pathfinding to beta, then these need to be on separate cards.

Modularize Responsibility

Each card should be assigned to exactly one programmer in the group. That programmer should be able to implement every responsibility listed on the card. If this is too difficult for that programmer, or one programmer has too many responsibilities, then you need to reorganize the cards.

Designers: Style Inspiration

The design document is a relatively new one that we added a few years ago. It was a smashing success and has now become part of the course. It also gives designers something to do during this time. However, we are not going to give you the instructions just yet. We just want to get you to start thinking about your influences.

The design document itself is a slide deck that outlines your inspiration, as well as the technical choices that you are going to make regarding your assets. We like you to use slides for this document because the layout is easy to manipulate. Keep in mind that this is not a set of slides for a talk. Instead, you are using them as storyboards or "mood boards," with chapters. Think of them as a "deck doc" (slides instead of pages for the document's layout). A great example of what we are talking about is the design document for Underhand.

This document is going to take a quite a bit of work to assemble. So we just want you to spend this class focusing on your inspiration. In particular, we want you to gather assets (from others, not your own) that address the following issues.

Artwork

We want you to gather artwork that represents the mood of your game. Think about the art-style you want, your choice of lighting, and so on. Sometimes an inspiration may be good in one area, but not another. For example, you might find an art asset that has the lines you are looking for, but not the color palette. Take all this into account when assembling the art.

Photos

In addition to the artwork, we would like you to assemble reference photos for your future art assets. These can include photos of animals, environments, poses, and objects. It is highly suggested that these be real images rather than drawings because with drawings, as sketches from other artists (not you) insert a design or interpretation layer between the real thing and your game. For assets, it will be best that you interpret subjects yourselves, within the team, rather than creating an interpretation of an interpretation.

Sound

Another major portion that influences the feel of a game is sound. Find some sound clips that you think best support your game. This can be music, or even just simple sound effects. Think about how this sound reflects the mood that you established from the artwork.