INDIVIDUAL MID-SEMESTER PROJECT
BENCHMARK 1
There will be no programming involved in this benchmark. Here you will design your game. As part of this process, you will create a game design document & storyboards and setup your personal Web page where you will post your work this semester. In this individual project, you will make your own side scrolling 2D game with gravity and jumping where you are the star. That's right, you will be the main character, and you will in some way name the game after yourself (i.e. The Legend of Richard McKenna), and you will give yourself all of the special powers that you've always wanted if you were ever to be turned into a little 2D sprite.
This is an original game creation, but of course it may be strongly influenced by the 2D games you've played over the years. And so you are encouraged to be creative. Think out of the 2D box. Make it memorable, make it unusual. Make it your own. Oh, and be sure to make it fun to play.
You should probably start the design process by thinking small. Try to make your design interesting, but within reason. I understand that it is the start of the semester, and so you are not yet fully aware of what we will be capable of creating, but do your best of estimating the difficulty of implementing different features.
END GAME REQUIREMENTS
So where are we going? Well, by the time you present your finished project on Friday, March 20th, you should have a fun and exciting 2D game. This game will require:
- A user interface for welcoming the user, for starting the game, controlling the game, exiting the game, and for getting information about the game.
- One quality game level that uses side scrolling and has both gravity and character jumpging
- A minimum game world size of 40,000 square pixels for the level, we'll talk more about this in the weeks to come.
- An originally drawn, animated main character named after the game author. That main character must have some objective. There must be a way to clear the level, the more interesting, fun, and creative, the better.
- A game world that uses artwork taken from any source the author desires. Note, I'm telling you that you can steal artwork for this assignment.
- Enemies that use basic AI techniques (like patterns or tracking). Again, you can steal artwork for these guys.
- Collision detection to keep the sprites from going through walls and likely to advance the game state (perhaps when they collide with each other)
- Interactions between the main character and the game environment.
- A victory condition for clearing each level with feedback to the user to let the player know of success or failure.
BENCHMARK REQUIREMENTS
Part 1: Author a game design document - This document should be a blueprint for your program and should include information about all game elements that will go into its construction. It should be professional looking & should specify what you will implement and how the game will look and be played. This does not mean UML, but rather more like a user's manual. Gamedev.net has a page devoted to different formats for such a document. You may use any format you like as long as it is professional looking, well organized, and complete. This does not mean UML, but rather more like a user's manual. Below is an example of what a design document might look for. You may use this format if you like
Many of the elements in this and other templates you may find may not be relevant to your project. You may simply exclude those elements. For example, this game does not require sound or music, so don't include a design for it in your document. There is no one way to create such a document but it must outline what your program is to be.
Note that your design document is a living document. You may make design decisions along the way that differ from your original proposal. You should update your design document as you go, adding new ideas and removing those things that you don't have time to complete such that at the end of the process, after all the benchmarks, your design document describes the completed game as a game manual would.
Part 2: Storyboard your game - Draw a series of diagrams of what your game is going to look like. This should include any characters, background, & important objects. Since I'll assume you are programmers and not artists (though some of you may be both), I'll also assume your drawings are going to be pretty rudimentary. To make these drawings, you may use Paint, Word, or another program. Again, don't go nuts with this, I don't expect drawings like that of Age of Mythology, this is really to get you in practice for storyboarding your group projects, where storyboards will be part of an agreement between you and your partner.
Part 3: Create a projects Web site - I would like students to share their work in this class with the broader game development community, so each student should create a Web site where all project progress will be posted. Understand that code-sharing is strictly forbidden among students, so never post source code to your site while this semester is going on. You may do so once it is over, however. The point of your page is for you to get ideas from each other as well as for you to point prospective employers to a page that showcases your work. Your page should be neat and attractive and should have the following:
- Link to your Individual Project Page - this is where you will post all your benchmarked progress for your mid-semester project. As part of this step you must post your design document and storyboards on this page. As you continue to develop your projects, you'll post your game development LOGs and bug databases here as well.
- Link to your Group Project Page - this is where you will post all your benchmarked progress for your group project later in the semester.
- List of your 10 favorite games of all time - briefly explain what you like about each game. Please include the game maker's name.
- Game Reviews (part of future benchmarks) - write your game reviews here
SUBMISSION
Post the URL of your main project page (from Part 3) on the Blackboard message board forum for benchmark 1 before the due date and time.
A LOOK AHEAD
For the next benchmark students will code the game graphical user interface (GUI).
GO AHEAD TO BENCHMARK 2
Web page created and maintained
by Richard McKenna