Specifications for 2D Games

3. All games must be accompanied by a Game Manual in PDF format. The game manual must include: • Title page. Name for the game, your name(s), student number(s), class number, quarter, instructor’s name. • Back story for the game (if any). If you have different kinds of NPCs (non-player characters), give each of them their story. • User’s guide. This includes how to play, what the objective of the game is, how scoring is decided, different play modes, etc.. Most important: how to locate the in-game help screen (ususally F1), and how to quit the game (usually ESC). Another common pattern is to have ESC bring up a menu, and two of the items on the menu are always Quit and Help. • Module documentation. A brief summary of each module in your code, what functions and classes are found there, which modules they import. Also, a brief overview of how the code fits together. • Cheats. I don’t have time to solve all your puzzles, or acquire the skill to defeat your game. A good game should take hours to finish, but I want to see everything you did in a few minutes. Please provide walkthroughs for your puzzles, and genuine cheats (keys to press to get to the next level without earning it, an immortality mode, unlimited ammo, the BFG, etc.), so I can see your whole game in just a few minutes. • Acknowledgement of credit for any artwork, sounds, or code that is not your own. Failure to acknowledge such is plagiarism and grounds for academic disciplinary action. Even if the stuff you use is public domain, it is always nice to credit the place you got it. Whenever you grab something off the internet, just save the URL with the file and list all these in your acknowledgements. • Autobiographical info on the programmer. There is a wide skill range in this class in programming, and in game knowledge. Games will be judged individually, and based on what the student brings to the game. Some students may focus on the artwork, some on the game physics, some on the puzzles, some on trying out a completely novel game idea, etc. Needless to say, grading will be very subjective. However, I will attempt to discern how much effort went into the project. To that end, it is not inappropriate here to give some autobiographical information in the Game Manual about your history, what you found challenging, what was easy, how this differs from games you’ve done in the past, etc.
4. All games must have in-game documentation. Usually this takes the form of a help screen, traditionally accessed by pressing F1 or by choosing a Help menu item. The help screen should give much of what is in the user’s guide, but more succinctly.
1
5. Grading criteria. Notwithstanding the range of games I expect to see, here are some of the things I look for in evaluating a game (based on John Laird’s criteria).
(a) Is the game functional? (b) Manual and in-game documentation. Things to consider: • Is the documentation clear? • Is it entertaining and inviting? • Is there a back story to the game? • Does the game have in game instructions on keys and controls? (c) Non-trivial implementation. Things to consider: • Sound effects • Music • Different difficulty levels • Multiple opponents with different behavior • Multiple levels • Tutorial level • Complex interactions between player and enemies • Complex properties of game pieces (health, shields, ...) • Two player game mode • Graphics unusual and engaging • Physics complex • Universe bigger than screen • Deep story • Network support (d) Bugs/Design Flaws. Things to consider: • Game crashes • Game locks up • Long load time • Bad controls • No ability to stay in game after one turn • Only one life • Difficult to tell if you’re making progress • Collision detection problems (walking through walls, getting stuck in walls, etc.) (e) Game Play. Things to consider: • Impossible to win • Too easy to win • Just a move and shoot game • Rate of feedback and achievement not good • Only single level of goals • Not fun • Good mechanics for gameplay • Originality of game • Goals are well integrated and are appropriately rewarding • Feedback appropriately informs players of what is important • Dynamic difficulty adjustment • Judge gets hooked on playing the game • Judge shouts, screams, or laughs out loud while playing