CS/INFO 3152: Introduction to Computer Game Development

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.


Critique

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

Even though both of these documents (Architecture and Design Specification) are a ways off, we want to give you immediate feedback on how you are doing. Therefore, the lecture immediately following this lab is a critique session. We will pair you off with another group, and you will present what you have done so far for them to critique and give feedback. In addition, the instructor and TAs will be available for feedback as well.

You have a lot to do this week with gameplay specification and the upcoming gameplay prototypes. Therefore, we are not expecting you to do any work outside of lab. Finish what you can in lab today. On the day of critique, bring whatever you finished. If the design (architecture or visual) is incomplete, that is okay. But please make an effort to complete as much as possible during class.

Programmers

We want you to bring your CRC cards for the critique. You will lay down these cards during the critique and explain your justification for your design. Be prepared to answer questions about classes that you may not have gotten around to thinking about yet.

Designers

Bring a collection of the most important inspiration assets (artwork, photos, and sound) that you have gathered so far. You do not need to assemble them into a document yet; we do not want to see any slides. We just want to see your initial ideas.