Game Manual

Your final (formal) document for this class is the game manual. The manual is intended to provide a quick tutorial of the game, so that the player can get started immediately.
For this first draft of the manual, we are not requiring that you finalize all artwork (in fact, it is common for artwork to still be in flux up until Showcase.

Table of Contents

Manual Requirements

While printed manuals are certainly going away, most games still have a some form of manual. It may be an interactive set of instructions in the game, or a PDF file that ships with the game. Despite trends towards interactive instructions, we are going to stick with the latter format. You need to be able to design a classic game manual before you move on to a something more complicated, like an interactive manual.

The format of your game manual is largely up to you. One of the design TAs can help you with layout suggestions if you need help. You should also look at many of the examples below for inspiration.

With that said, there are some “minimum requirements” for your game manual. Your manual should contain (at a bare minimum) the following information.

System Requirements

What are the minimum system requirements for your game? While you have probably not tested it out on all systems, you should try to make a reasonable guess. OS requirements are particularly important.

Installation

Even though this game is in Java, not everyone has the same Java VM or the appropriate OpenGL libraries. Therefore we require that you use PACKR to create an installer for your game.

Basic Objectives

You should provided an overview of your game and identity the basic objectives. This is a really good place to put some backstory if you wish.

Gameplay and Controls

You should outline the primary actions and show how the user activates them (e.g. keyboard, mouse, gamepad, etc.). While interactions are less important, it is a good idea to highlight the major game entities, and describe how the player interacts with them.

Credits

The last page of your manual should be the credits. List everyone on your team and their role (to the best approximation). In addition, if you used any third party assets or libraries that require attribution, you should list them here as well. This is particularly important for audio assets; most of the Newgrounds audio library requires that you acknowledge the music in the credits.

Examples

Manuals have not changed too much in this class, and so we have plenty of examples to show you. All of the manuals below have a very different style, and illustrate the amount of freedom that you have in designing your manual.

Felongeist

The most innovative game at the the 2017 Showcase, Felongeist has one of the most well-rounded manuals in recent years. The document is well-formated, the installation instructions are clear and well-formated, and the controls are particularly well described. There were a lot of unique mechanics in this game, so the manual worked as an excellent alternative tutorial.

Prism Break

Another recent example, the 2019 game Prism Break is notable because of how it credits its sound effeects at the end of the document. If you have any 3rd party assets, this is extremely important. The manual also does an excellent job of illustrating its objectives and game elements. However, we felt like they could have done more with their controls. They just show us the keys, and do not show the character in actions (like we saw in Felongeist).

Janiterror

The 2018 game Janiterror is another entry that does an excellent job of illustrating is objectives and game elements. Once again, the controls are fairly simplified. But since they are shown in the context of their usage (e.g. the various weapon types), this works a little better.

Dash

You should be very familiar with the 2014 Showcase Winner Dash by now. The artist for that game was really into graphic design, and the result is one of the most beautiful manuals ever designed for this class. However, this game predates the use of lb

Undetected

The 2019 game Undetected is very different from a lot of the other examples here. It is very text heavy and has minimal art assets. However, it clearly conveys all of the required information and gets the job done. If your artists are under pressure for the final sprints, this is an acceptable alternative (though we do not know how it will fit with the video format.

Arc-en-Ciel

Arc-en-Ciel was the audience favorite at the 2015 Showcase. This is a much more flowery manual than the one for Dash; you should not be compelled to have this much art. But it shows off the types of things that you can do with your manual, should you wish.

Dodgeball Damnation

Dodgeball Damnation was another popular game at the 2015 Showcase. While we are not a fan of the messy links in the installation section, the description of the controls is excellent. Notice how well the images work together with the text.

ChronoBot

The manual for ChronoBot is one favorite manuals from the “old days” (back when this class was called CIS 3000). It is a very minimal manual, combined with some elegant graphic design. It shows that you can have a high quality manual without a lot of text or art.

Submission

Due: Sat, Apr 23 at 11:59 PM

You should submit a PDF file called manual.pdf representing your game manual. As usual, 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. More importantly, we are expecting some art assets in this manual, so you will need to use PDF for that reason as well.

As with every other document in this course, this is not the final draft of your manual.
You will get another chance to revise this manual for final document portfolio. However, because we are so close to that assignment, there is no chance for intermediate revisions before that assignment. Therefore, this assignment is different from the rest.
For the game manual “final” document portfolio is actually just another draft. The final, final version of your game manual is to be submitted at Showcase.