Project 3 Dragonfly Spawn

The goal of Project 3 is to use the Dragonfly game engine you built in Project 2 to make your own, original game from scratch. The end result should be robust (bug-free), playable, and balanced - it may even be fun. ;-)

Like a typical large game development effort, this project is broken into several milestones: plan, alpha and final. Each milestone will be submitted and graded separately, while all apply towards your total Project 3 grade. The intent of the milestones are to yield a fully-functional, complete, playable game built with your own game engine.

You will work in teams for this project. The number of students on a team shall be two, no more, no less. If one student is left over after everyone else has formed two person teams, one (and only one) team will have three members (and their game will be expected to be a little bit bigger). You can partition the work among the team as you see fit, but all team members are encouraged to help (say, with design and debugging) and be knowledgeable (in terms of how the game code executes) for all parts of the game.

Development must be in C++ using your game engine from Project 2. Under exceptional circumstances (e.g. both partners not completing Project 2), you may be allowed to use the Dragonfly engine from Project 1. However, permission to do so must be obtained from the instructor in advance. In all cases, the TA must have the ability to compile and run your game (and engine) in order to do the grading.

Plan

You will provide a plan within the first week of the project. The plan document should provide a detailed description of the game you plan to build, including the technical challenges it entails, a bit about the significant artistic aspects of the game, and your plan to successfully complete development in the time provided. In planning, you should draw upon all your experiences from other classes (e.g. programming, project management, game design, and game development process) to inform the creation of the plan document.

Your plan documentation must include the following sections:

• Game Name - a catchy, descriptive name for your game.
• Team - the names and email of both team members, including a team name.
• Genre - a brief, one sentence/phrase of the game genre.
• Game Description - a short, one paragraph description of your game.
• Technical Features - a list of the specific, significant technical features that your game will include.
• Artistic Assets - a list of the significant artistic assets that that your game will include. Sizes and frames of animation should be estimated.
• Implementation Plan - A short description of how you plan to implement the technical features of your game. While the entire game should be original, in the event you are using code or artwork from elsewhere this should be clearly indicated and attributed.
• Distribution of Work - broadly, what team member is responsible for what aspects of the project. Joint responsibility can be indicated, if appropriate.
• Schedule - milestones and when they will be met for your game development. While the major milestones (plan, alpha, final, presentation) are fixed, smaller milestones should be specified for your project.

While the actual length of the plan is not a requirement, as a guideline the plan should be approximately 2-3 pages - much less and you probably have not supplied enough details.

Alpha

At Alpha stage, your game should have all of the required features implemented, but not necessarily working completely correctly. Your game code should be tested thoroughly enough to eliminate any critical gameplay flaws, but minor bugs or glitches may be present.

Your game should compile cleanly and be runnable, even if all aspects of the gameplay are not available from one program. Separate features of the game may be demonstrable from separate game code programs (e.g. separate game programs illustrating a kind of weapon or a specific opponent).

Your game is likely not yet be finally balanced nor the levels designed for all levels (beginning to advanced) of game play.

Your game may contain a certain amount of placeholder art assets. For example, in the alpha release, a simple square may be used for an opponent with the goal of creating a figure and providing frames of animation for the final version.

Final

The final version of your game should have all content complete - design, code and art.

It should be tested thoroughly for bugs, both major and minor, removing all visual and gameplay glitches.

Your game code should compile cleanly and be easily runnable.

Upon startup, instructions for the player on how to play your game should be readily available, and with clear indications on how to begin gameplay.

Gameplay should be balanced, providing appropriate difficulty for beginners and/or early gameplay, with increased difficulty as the game progresses.

Your game should have a clear ending condition and the ability for the player to exit the game easily and cleanly.

Promotional Materials

In addition to the design and implementation of your game, you will produce some promotional materials suitable for display during a presentation or via a Web page or project portfolio. These include:

• Image. You should create/select an image that when scaled to 200x150 pixels provides a suitable representation of your game. This can be a screenshot, or logo or some other graphic suitable for your game.
• Description. To accompany the image, please include the title, development team and a short (about 100 words) description of the game. This description should include the game features and can include significant technical features.
• Video. You must create a short, 1-2 minute video illustrating your gameplay. You can provide a music sound-track to your video and/or provide voice narration, as you see fit. You will not actually submit the video when you turn in your project, but instead will give a link to where it may be found online (e.g. YouTube).

You may make use of these materials during your presentation, as appropriate.

Presentation

Each project team will present their game in class.

Presentations should begin with an introduction of the team and members, then provide a high concept of the game, including a quick summary of the major features and core ideas.

Most of the presentation time should then be spent on demonstrating the game itself, highlighting technical aspects of the game that needed to be programmed wherever appropriate.

Every member of your team should talk. Arrange in advance which parts of the presentation will be given by each team member.

You can, if you wish, bring a laptop to class with your presentation materials already pre-loaded, and you can hook your machine into the projector. Or you can bring your materials on a USB key for installation on the podium computer. In any case, thoroughly test your prototype and presentation materials in advance to make sure they work properly. Embarrassing things can happen when you don't rehearse!

Total presentation time will be approximately 5 minutes! Please plan your presentations accordingly. Most important is to practice, many times, to be sure you have the content, timing and transitions down.

Resources

See the class materials for technical details on game implementation.

Utilities

You are encouraged to use a source code management system for sharing and managing your game code and engine code. See your professor for details on how to get started.

For large, banner-type text you might try FIGlet, a program for making large letters out of ordinary text. You can download versions of FIGlet for Unix, Windows and Macs.

Advice

Some advice on how to proceed in your development:

1. Form group
2. Quick brainstorm
   • Be aware of the limits of your engine! Especially for the game mechanics (e.g. using the mouse for core gameplay may be problematic).
3. Produce asset list (should be small!)
   • Decide on "unit height" before starting - critical for speed, size of other assets, etc.
4. Design (software classes)
5. Construct milestones
   • With names attached to each.
   • Still meet/check in frequently! You need to be a team.
   • Remember, everyone should help (as needed) with everything.
6. Use iterative development (see class slides)
7. Final report will have plan, class design, asset list, video