Technical Workshop

The purpose of this class is to help you improve your architecture and design specifications, which are due this weekend. These are difficult documents, and the initial scores on them are often quite low. So make the best use of this discussion. In fact, to maximize your performance on these documents, we are going to have a critique session on Friday checking in on your progress.

Note that the critique means we expect you to have some part of these documents finished by Friday. You do not need anything polished enough to turn in. But it should be coherent enough for discussion.

Architecture Specification

The primary thing that we want you to to work on in this session are your CRC tables and your dependency diagram. In fact, on Friday, we will ask you to present your dependency diagram as part of the critique session.

In working on these two activities, you should be able to answer all of the questions below. If you do not know the answer to a question, it means that part of your architecture is unclear, and you need to improve it.

CRC Tables

  • Can you identify the main controller class, the one that starts up the game?
  • Do any of the classes violate the model-view-controller pattern? Why or why not?
  • How does saved information get from the data files to the models?
  • How does information get from the models to the scene graph (or your custom render pipeline)?
  • How are you abstracting input so that it works on both desktop and mobile?
  • Are there too many classes? Too few? (This is a very hard question to answer)

Dependency Diagram

  • Is every element from the CRC tables represented in the dependency diagram
  • Is every collaborator in the CRC tables represented by a link (and vice versa)?
  • Is the graph planar? If not, can reorganize the diagram?
  • Does the diagram show how to break up tasks while minimizing meetings?

Design Specification

A lot of your work on the design specification was actually completed in your presentation for the gameplay prototype. But there are still some very important things to think about. Today we want you to think about the more technical aspects of your design specification. Thins like your exactly choice of perspective, your brush styles, and so on.

But the most important thing we want you to think about are your file formats. This is the one thing we find that designers do not take seriously enough. So we want you to spend a good amount of time on this topic, and that is what will be part of your critique session.

File Formats

Programmers must be able to put in your assets into the game, and they cannot do this without knowing some specific details. Make sure you can answer the following questions:

  • How should the programmers use this file in the game?
  • What is the file type and extension?
  • What are the sizes (pixel) for the most common art assets? Is there a standard size?
  • What are the layouts of spritesheets? Is each animation its own image or are they combined?
  • Do certain color channels mean anything specific in image files?
  • Are audio tracks meant to crossfade or loop? How do you differentiate?
  • How is the volume level of individual audio tracks normalized?

Once again, if there is any doubt on these questions, confer with your programmers during section.

Art Style

Many of you have already started to think about your influences. We saw this in the design presentation for the gameplay prototype. So you you should think about how you would describe the art of your actual game. You should address the following questions:

  • What perspective will your game use?
  • How will the color palettes distinguish different features of your game?
  • What types of brush styles will your art use?
  • Will your art style be retro pixel art? Realistic? Cartoonish?
  • What types of animations will your game include?
  • Are there any programmatic art features, like shadow or fog effects?

Critique

While you are turning in these documents this week, we want to give you some early feedback on how you are doing. So you are going to bring as much of the document as you have finished so far. Bring two copies, one for you and one for another group (your version can be on a computer, but the one you give the other group to look at should be on paper). You will present what you have to another group and they will critique it.

Programmers

The key thing we want you to focus on in your critique is the dependency diagram. For those of you from the intro course, this session is a lot like the CRC critique from that course. Each team should look at the dependency diagram provided by the other group and determine if they can answer all of the questions above. If not, they should check to see if the CRC tables (if they are there) give more information.

Designers

For designers, we want you to focus on the file formats section. Each team should look at those specific slides and determine if they can answer all of the questions posed above. In the case of images/sprites remember the file size limitations (4096x4096) but also remember what we said about texture switching in the graphics lecture. In the case of audio, think about the things we said in class on Monday.