CS/INFO 4152: Advanced Topics in Computer Game Development

Assignment 8
Design Specification

Due: Saturday, March 11th at 11:59 pm

A good game should have a well-defined visual style. The visual style should not conflict with the gameplay; this is a form of ludonarrative dissonance. In addition, if the team has more than one designer, they should not be creating designs that conflict with one another.

This is the motivation for the design specification. This is a specification that gathers together all of the influences for the game so that we have a good idea about how the game is going to look. In addition, it is where the team specifies some important rules with regards to presentation and file formats. That way, the programmers will know what they will be working with long before they receive the assets.

Teams should follow the writing guidelines (particularly regarding bullets). Other information, such as how to cite your outside sources, is included below.

The Design Specification

The design specification is a document that describes a vision of the details of the final product, much like the gameplay specification. Indeed, these documents are very similar because they have the same audience; they are both internal documents written to allow team members to break-up and work in isolation. The primary difference is focus. The gameplay specification focused on game elements like mechanics and challenges. The visual specification focuses on art style, sound, and other non-gameplay elements.

This document should be full of visual imagery. Some of the imagery should be created by the designers on their own, but a good portion of it will be from other sources. We want to know what influences you, so be honest.

Because this document is visual, teams should use slides to create it (PowerPoint or otherwise). This is very similar to what we asked for in the concept document. As with that document, it will be created with slides for layout agility, but teams will not be presenting the assignment.

This document should be significantly longer than the concept document. Therefore, we want you to use chapters to organize this document. A chapter is a collection of one or more slides/pages that all address the same topic. For example, in the concept document, some teams used more than one slide to talk about game mechanics. This was a chapter. There is no need to explicitly call them chapters; it is just a way to think about organization.

Title Slide

The first slide should list the team name, the game's name, and a list of all team members. It should clearly indicate that this is the design specification (not the concept document).

Example: The linked slide is an excellent example of a title slide taken from a 4152 group from last year. Notice that it is clean and simple, but has an image that invokes the style of the document.

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 the team wants to achieve as designers. Include in a statement about the general vibe of the world (e.g. "the game Dash is portrayed in a mystical, Oriental-themed universe") and the feelings that the team wants 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.

This statement should be a single slide with a single paragraph of text. Do not use bullets for this slide.

Inspiration and References

Art styles hardly ever evolve form from nothing. They are influenced by other art or games. We want you to identify to those influences. These slides are meant to be largely visual collages. Teams must identify the source of each image, and we will show via the linked examples different ways to do this. Create slides that address the following:


Include several slides that show collages of pieces from different art styles that 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 for ease of comparing styles. We do not want to see just pictures, so explain the main 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. Again, we reiterate the need to cite where images are from, and examples of methods to do this are outlined in the examples section.

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).

Example 1: The linked slide is an excellent example of a mood slide taken from a 4152 from last year. There are only two images, but they clearly represent the idea. In addition, there is a lot of text explaining how to interpret the images.

Example 2: The linked slide is an another example of a mood slide taken from another 4152 group last year. Note the descriptive text to one side and the images cleanly arranged to the right.


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.

Example: The linked slide is an excellent example of a sound slide taken from a 4152 group last year. Note that there is a lot of text explaining how to interpret the sounds. In addition, each image is a hyperlink that we can follow.


In the last set of inspiration slides, include include slides that reference photos for any 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 the game. For assets, it will be best that you interpret subjects within the team members, rather than creating an interpretation of an interpretation. We also suggest that the team group images together by subject such as feet references, cloud references, etc.

Art Style

This next section is all about outlining the development of the art style for this game. These slides should describe the specific tools needed for developing the game's style. These slides should be bulleted text. The team will have a chance to show off some of this style in the next section.

Color Palette

Since foreground elements have to stand apart from background elements, what colors palettes will differentiate the two? Will there be different color schemes for different worlds, if there are any?


Is there a type of brush that all characters will be created with? Or is the style going to be flat or 8-bit? Will there be hard borders with no alias or soft borders? Making sure all artists have the same photoshop brush, for example, can help make the game's style feel more consistent.

Animation Style

Animation styles can vary widely, too, in the level. Some animations styles are very exaggerated and cartoon-like while others strive to be more realistic. For this section, please provide some gifs or frames that inspire you as you move forward with the animation process. Again, these can be taken from others and do not have to be your own.

Example: The linked slide is an excellent example of an animation slide taken from a 4152 group last year. Instead of using gifs, they composite several frames together to make the animation visible in a static image. This works a lot better in a PDF format.

Additional Elements

There are only so many things that games have in common with each other. Games need to differentiate themselves in some way more than just through the gameplay alone. Games rely on the combined ability of programmers and artists to add extra bells and whistles that will augment the vision of the game or give players a "wow factor" that they have not seen or heard before.

Due to the importance of these features, team members should be thinking of all the additional elements that will be added to the game. Some examples are as follows:

  • Parallax backgrounds
  • Lighting and shadows
  • Electricity arcing throughout the environment
  • Rain and wind effects
  • Music (if it is not a core feature)

In this chapter of slides, identify which additional features (if any) will be present in the game. For each feature, identify whether or not it is purely cosmetic or whether it will affect gameplay. Please also identify the division of labor between programmers and artists to complete this feature.

These slides should be largely text describing the additional features, though teams are welcome to add illustrations (either new or inspiration) if you like.

Example: The linked slide is an excellent example of an additional art style slide taken from last year. In this slide, they talk about their style for layering and composing images.

Concept Art

In order to plan out designs, characters, and worlds, designers will create early throw-away concept art to convey ideas and designs quickly without putting in the same effort as a final design. Although this type art may include early sketches, it still should be polished; early concept art is often used to persuade others (or maybe the team itself) the world/character/direction is attractive and feasible. Concept art should be a detailed exploration of two or three possible directions the game can go in.

Please include any early concept art for character/background/elements that have been developed at this time. Concept art does not have to be, and really should not, be used in-game. This slide or slides should be a mixture of images and text. The text should note any special details of characters/backgrounds/elements, as this will help with consistency within the game.

Example: The linked slide is an good example of concept art taken from a 4152 group last year. Notice how they have a variety of images, with text discussing how they related to each other.

User Interface Design

Concept art does not need to be limited to character or environmental assets. Understanding the user interface is equally important. A user interface is anything that is not within the “game world” that players must interact with. This is any HUD element, such as a health bar, map, or menu screen (such as level select or pause).

The user interface should have a similar art style to the game; however, it stands apart from any in-game element. It can be weird to have an 8-bit menu in a photorealistic game, so it should keep to the overall style and feel of the game. However, menu elements must be clearly defined from avatars and monsters. The user interface is important for the overall experience of the game, since players will almost always interact with interfaces before playing (e.g. the main menu).

As part of the concept art, please include mock-ups of what the team expects the user interface to look like.

Example: The linked slide is an good example of a user interface slide taken from last year. This is a just a simple loading screen, but the text makes clear why this slide is so important.

File Formats

Creating art and sound is fine and dandy, but unless it can be used by the game, it is meaningless. Programmers must be able to put in the assets into the game, and they cannot do this without knowing some specific details.

For each type of art asset, give the technical specifications of that file or group of files. Types of art assets include but are not limited to animations, tessellating tiles, backgrounds, sounds, and UI elements. Please do not go more specific than this for now. Remember, more restrictions placed on art asset formats actually make it easier for programmers to be able to use them.

The technical specification slides should be entirely text, arranged as bulleted lists for each file type. In describing the file format, 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?

Putting it All Together

As we said before, create this document using slides. The chapters should be arranged in the following 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
  • Chapter 4: Art Style (Color Scheme)
  • Chapter 5: Art Style (Lines)
  • Chapter 6: Art Style (Animation Style)
  • Chapter 7: Additional Elements
  • Chapter 8: Concept Art (including User Interface)
  • Chapter 9: File Formats

This means that there should be a minimum of 11 slides. However, teams are encouraged to submit more.

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 approach 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. The document for Aiden in the examples section is sort-of an example of this (though they did not number).

Use hotlinks for each image or sound to the original.

In this style you 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. We provided an example of this in the Sound section above.

Insert URLs into the page design.

In this style, you place the URLs as text in the document (which may or may 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. This style is clearly carried out by Aphelion in the examples below.


This is a relatively new document. Last year is the first time that we ever assigned this document. While we were very happy with the results last year, this means that we do have only a few examples to show you. Throughout the instructions we gave you examples of isolated chapters. Here are a few examples of complete documents.


The game Aiden was designed for the introductory class last year. This document is a great example of how to put together a cohesive, thorough design spec. Notice the clean design for each major element. All throughout the visual organization and methodology is strong. For example, look at the Fuel Bar page. Notice that there is a general description to start, and then there are three images that each have their own explanation.

We also want to emphasize how the team gave credit the sources for each image, citing each along the way. For example, in the first collage under Mood, each image has a number imposed upon it. At the end of the document, the image is given full credit in the References section. Our only complaint was that they did not number the citations on the Citation page.


Aphelion is the only example in this section developed for 4152. Once again, we see several great practices play. The layout is clean, thoughtful, and very descriptive while not being overwhelming. Each image and sound taken from an outside source has a URL associated with it (avoiding issues of plagiarism and intellectual property theft). This approach to documenting sources is different than the one shown in Aiden, but it works just as well.

Brought to Light

Brought to Light is another game developed for the introductory course, and this document has some nice elements to it. Look over this team’s uncluttered approach and its strong captioning/short descriptions on each page. Each element that needs a citation has one (see the end of the document). However, this could have worked a bit better if each image in Chapter 3, for example, had been numbered and then its citation had a number at the end of the document. The team’s move of listing clockwise for every page (see page 27 at the top) is fine, but not great for organizing so many referenced cites.


Due: Saturday, March 11th at 11:59 pm

We highly recommend that you submit as close to a finished document as you possible can. Not only will that guarantee the most amount of feedback, but it will also help each group understand the vision very early on.

Submit a PDF file called design.pdf containing all of the information above. We ask that the file be a PDF so that we can annotate it in order to return it to you with feedback for possible revision. It is fine if you create the document in a program like Microsoft PowerPoint, but you should convert it to PDF before submission.