INDIVIDUAL MID-SEMESTER PROJECT
BENCHMARK 2
Requirements: In this benchmark we will actually begin coding the GUI and setting up the game architecture. You should use the Empty Game example project as your starting point. In addition, you will create your own artwork for your main character.
Part 1 - Code your GUI: We will start making our games by building a splash screen/game menu that will provide an entry point into your game. In future benchmarks, we'll add the actual game. Your GUI should include the following:
- Game Icon (.ico) - Draw a logo for your game and make it your application's icon. This is your official game icon, so I hope you like it. When you create a new project in Visual Studio, a defaul icon is created, so simply change this one. You'll then have to use it to set the window's icon.
- Windowed Mode - This semester we'll do everything in windowed mode, so simply leave it like that.
- Welcome Screen/Game Menu - Create a simple welcome screen for your game that loads when the program starts. This splash screen should state the name of the game, have a large image of some sort (ex: a giant main character), and have any other creative elements that you think might attract a user to your game (think of it sitting in an arcade). In addition, it should provide a game menu of buttons named and displayed as you like that do the following:
- Start a new game - When selected, your game will begin. Since we haven't coded the game yet, instead your program should display a timed slideshow of the storyboard images you defined in Benchmark 1. After looping through all of your storyboard images, it should simply display GAME OVER, which oddly enough should represent game over. At this time, the player may press a button to return to the splash screen/main menu.
- Game Controls - When selected, a new GUI screen should appear that would specify the keys to be used for playing your game. You should have already mentioned this in your game design document, so this is an extension of that. This screen should also have a button option to return the user to the menu, i.e. "Go Back to Menu".
- Help screen - When selected, it should display a screen that briefly explains what the game is about. Who is the main character? What is the point of the game? Etc. Again, this information should come directly from your design document. This screen should also have a button option to return the user to the menu.
- About - When selected, it should display the game author's name, the Stony Brook Computer Science Department, our class name & number, and the semester. This screen should also have a button option to return the user to the menu.
- Exit the program - When selected, your program should close.
A NOTE ON BUTTONS: Many games use buttons that simply look like hypertext. By this I mean they have no outline (no rectangle or oval). Making such buttons is perfectly acceptable, as is using traditional looking buttons. You may be as creative as you like to create your own game look, just make sure the GUI is user friendly, easy to navigate, and bug-free. This is a standard feedback that users expect.
In addition to providing the options, in order to provide a menu that looks and feels professional, it should adhere to the following rules:
- Options in the menu must be selectable by mouse clicks (like buttons).
- Your game should have its own unique mouse cursor. Draw it such that it fits in with the theme of your game, of course.
- Options in the menu should provide mouse-over feedback. Simply changing the color of the button text is an easy way to do this.
Part 2: Game Pause/Resume and the In-Game Menu - Once a game, or your slideshow, has started (but is not over), players should be able to pause the game by pressing the ESCAPE key. When pressed, an in-game menu should appear. This menu should be overlayed on top of the graphics of the frozen game. This menu should contain all of the options of the main menu (Start New Game, Controls, Help, About, Exit), as well as a new option to Resume the game. Pressing this option should close this in-game menu and continue the game.
Be careful with this in-game menu, because if I pause the game and then select Help, I should be brought to the Help screen. But then if one hits ESCAPE in the Help screen, or selects the "Go Back to Menu" button, now one should be brought back to the In-Game Menu (where the current frozen game is visible and resume game is an option), not the splash screen/main menu (where resume game is not an option). This should be true of all the menu options (like game controls or about). Understand that pressing ESCAPE should not close the application on any of the screens. Rather, ESCAPE is used to return to previous menus. This is a common game GUI setup and you should use it.
Part 3: Catastrophe prevention dialogs - Dramatically changing the current game condition via a single accidental mouse click is something every GUI programmer must be concerned with. So, anytime the player has chosen to exit the application (whether in game or not), you should pop up a little dialog window that verifies this decision with the user. In addition, if one pauses the game and then presses Start New Game from the in-game menu, pop up a similar little dialog to verify this decision. This is a consideration to the user who may have accidentally seleced a menu option, and should be given a second chance to undo this mistake.
Use DirectX to draw these little dialogs over whatever GUI and/or game screen is currently displayed. And make sure that when one of these little dialogs is visible, the menu it is overlayed onto is not selectable.
Part 4: Your main character sprite - You are the main character of your game, for this you'll need a series of images of your character in order to animate it. Produce a series of images that together may be used for a single animation state (ex: running right).
SETTING UP YOUR PROGRAM: Student projects should start from the Empty Game example project we talked about in lecture. I expect you to use object-oriented principles. Please be aware that students may not share code directly. This is an issue that I take very seriously. This is an individual project, and so students must do their coding individually. I want to make sure that each student learns to code games in this course, and the only way to do that is to verify that everyone is doing their own work. Incidents of academic dishonesty will be taken very seriously, so please, don't be tempted this late in your academic career.
SUBMITTING YOUR HW: This should be done in two stages:
- Generate an .EXE file, then ZIP it with whatever resources it needs to run (i.e. images) and post it on your project Web page. Do not post your source code there. The TA or anyone else should be able to simply download and play your game without any hassles (setup, bugs, crashes, etc.).
- Hand-in your full Visual Studio project with all source code and other components necessary to build and run your game by zipping it up into a single ZIP file and posting it to the class' Digital Dropbox on Blackboard. Call your submission "X Y's Benchmark 2", where "X Y" is your name. You'll use a similar style for future Benchmarks
A LOOK AHEAD
For the next benchmark students will organize all game artwork and will create a game prototype with a fully tiled, partially complete game world. In addition students will add an animated main character.
GO AHEAD TO BENCHMARK 3
Web page created and maintained
by Richard McKenna