Due: Saturday, March 18th 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 your 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 to your game so that we have a good idea about
how your game is going to look. In addition, it is where you specify 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
(particularly regarding bullets). Other information, such as how to cite your outside
sources, is included below. If you are confused about what we are looking for, please
talk to a design TA or Traci.
The Design Specification
The design specification is a document that describes a vision of the details of the
final product, much like the
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 design specification focuses on art style, sound, and other
This document should rely heavily on visual imagery. Some of the imagery should be
your own, but much of it will be from other sources. We want to know what influences
are impacting the game, 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
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
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.
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).
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.
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.
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.
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.
Since foreground elements have to stand apart from background elements, what colors
palettes do you plan on using to differentiate the two? Will there be different color
schemes for different worlds, if there are any? Use a well constructed set of
sentences, along with images, to showcase the team’s ideas.
Is there a type of brush that all characters will be created with? Or is the style you
are going with going to be flat or 8-bit? Will you have 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 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, but you
should always give credit for outside work.
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.
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 identify which additional features (if any) will be present in your game.
For each feature, identify whether or not it is purely cosmetic or whether it
will affect gameplay. You should also identify the division of labor between programmers
and artists to complete this feature.
These slides should be largely text (not bullets) describing the additional features,
though you are welcome to add illustrations (either yours or inspiration) if you like.
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.
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.
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
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.
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
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 your 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, you should 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, we want this material to be created using slide, but then saved as a PDF for submission. 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
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 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 18th 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.