CS/INFO 3152: Introduction to Computer Game Development

Communication Lab 6
Architecture & Design Exercise

Due: Thursday, March 9th at 11:59 pm

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.


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 laying 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 Guidelines

The design document is a brand new document that we are still finalizing at this time. But we have enough of an idea about what we want for you to participate in an exercise while the programs work on their architecture.

As designers, your job is to create a slide deck of inspiration and style pieces for this assignment. We encourage you to use slides because the layout is easy to manipulate. This is not a set of slides as for a talk; use them as storyboards or "mood boards," with chapters, for this assignment. Think of them as a "deck doc" (slides instead of pages for the document's layout).

The first slide should list contains the team name, the game's name, and a list of all team members. After that, we want slides that address three main features.


High Thematic Statement

We want a cohesive statement describing how the team wants the game to look and feel. Do not write an essay; rather, write enough so that anyone who reads the statement will have a good understanding of what you aim to achieve as designers. Include in your statement the general vibe of the world (e.g. "the game Dash is portrayed in a mystical, Oriental-themed universe") and the feelings you want to evoke (nostalgia, adventure, comedy, etc.). Of course, this may have changed somewhat since earlier documents; this is expected and welcomed because it demonstrates a maturity of the team's vision of the game.


Inspiration and References

Art styles hardly ever evolve form from nothing. They are influenced by other art or games. We want you to put words to those influences. The final version of this document (due in over two weeks) will have you expand on these influences to full define your vision. For this communication lab, we just want you to focus on gathering (and crediting) your external sources

The document that you submit will be a slide deck, written in PowerPoint, Keynote, or similar piece of software. The desk you submit should have slides that address the following.

Mood

Create several slides that will include collages of pieces from different art styles you think will best portray the game. These slides will be inspiration slides, setting the mood and tone for the team to work from. We recommend you put multiple images on one slide so you can compare styles and see how they can fit together. We do not want to see just pictures, so explain your points. For example, you may like the lineart from one artist yet the coloring of another, so you could put both of them on the same slide to do a side-by-side comparison.

Group these slides by themes that you find appropriate; for example, you may have a couple of slides that show what "dreary" means (because "dreary" in Call of Duty is different than "dreary" in Cursed Ghost).

Sound

Another major portion that influences the feel of a game is sound. In this part of the slide deck, link clips of soundtracks that best support the game. Try to find royalty free music or have someone create a soundtrack; this is important, because when it is time to put sound in your game, any copyrighted material used in Showcase is a breach of academic integrity. For now, however, feel free to collect and link any music and sound effects that serve as inspiration. Copyrighted material can be placed here for reference but make sure to not use it in-game.

Photos

In the last set of inspiration slides, include include slides that reference photos for your art assets. These 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. We also suggest you group images together by subject such as feet references, cloud references, etc.


Citing or Referencing Sources

It is unacceptable and against Cornell policy for students to use outside sources and not give proper credit. (This will also be true for future employers, too.) For the Design Spec, there are several ways to cite sources, as the document will be make in a slide deck and be highly visual.

Use a "regular" citation system, such as IEEE. This would mean that for an image, a number would be associated with that image and a full reference entry would be on a back page for each one.

Use hotlinks for each image or sound to the original. You can create a link around the image so that the reader is taken to the original source upon clicking it. Be warned, however, that you cannot hotlink back to a Google search; you have to track back to the original page where the image or sound file exists for this to be a valid method.

Insert URLs into the page design. In this case, you place the URLs as text in the document (which might or might not be clickable). The link can go to a parent page with the image, instead of the image itself. However, it must be completely clear how to find the image from the given link.


Putting it All Together

This is a lot of work to ask of you to do in a single lab. Therefore, we want you to spend the majority of the lab time brainstorming references from materials online. For each of the sections outlines above, right down a list of references that you are thinking of. Then, as time permits, you can fill everything in.

With that said, since you have a week to work on this, we do want a proper slide deck submitted by the deadline. Expand your notes into slides. Please include the elements below in your slide deck, in order. Understand that each "chapter" does not have to be called that, but it should be clearly labeled. Each chapter may also contain more than one slide/page.

  • Opening slide/page
  • High Thematic Statement
  • Chapter 1: Mood
  • Chapter 2: Sound
  • Chapter 3: Photos

Submission

Due: Thursday, March 9th at 11:59 pm

The architecture specifications are never perfect the first time, so we would like to see what you have done as a rough draft. This way we can give you comments before we look at your official specification in two weeks. The same goes for the art style activity, as the design specification is still a relatively new document.

With that said, you already have a lot to do this week with gameplay specification and the upcoming gameplay prototypes. Therefore, you will notice that we are asking for this document much later -- after gameplay prototype. For programmers, it is going to take some time to assemble your cards into a single document. For designers, it may take a while to assemble all of the collages and references.

When you do submit this document in a week's time we want two submissions put in CMS. From the programmers we want an overview of your CRC cards. You can submit this as the text file crc.txt or the PDF crc.pdf, which ever is easiest for you. Since the designers are submitting a slide deck, it should be the PDF style.pdf. You only need to submit one of each file for the entire group.