Dragonfly - Project 3

Project 3

Dragonfly Spawn

Top | Plan | Alpha | Final | Promo | Resources | Submission | Grading

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.


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:

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.


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.


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:

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


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.


See the class materials for technical details on game implementation.


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.


Some advice on how to proceed in your development:

  1. Form group
  2. Quick brainstorm
  3. Produce asset list (should be small!)
  4. Design (software classes)
  5. Construct milestones
  6. Use iterative development (see class slides)
  7. Final report will have plan, class design, asset list, video



For your plan submission, you must hand in the following:


For your alpha submission, you must hand in the following:


For your final submission, you must hand in the following:


Under most circumstances, both team members will receive the same grade. You will, however, be given the chance to provide your own feedback (e.g. a grade) on your project and on your partner privately to your professor when the project is complete.

NOTE: You will be graded on the version of your project submitted online by the due date, not on the version you present in class.

Grading Guidelines
Plan 10%
Alpha 25%
Final 40%
Design 10%
Presentation 10%
Promotional materials 5%

Below is a general grading rubric:

100-90. The submission clearly exceeds requirements. The game is fully implemented, playable from start to finish in a robust, bug-free fashion. Gameplay is balanced throughout, providing appropriate difficulty for beginners while getting more challenging as the game progresses and/or the player obtains skills. Instructions are provided in-game for how to play. The required documentation (plan and design) is thorough and clear. The group presentation is well-organized, well-rehearsed and introduces the team and game in a fun, yet professional manner. The promotional material is clear, complete, and very presentable.

89-80. The submission meets requirements. The game is implemented and playable from start to finish, in a mostly bug-free fashion. Gameplay is mostly balanced, providing adjusted difficulty for beginners and more advanced players Instructions are provided in-game for how to play. The required documentation (plan and design) is complete. The group presentation is organized, rehearsed and effectively introduces the team and game. The promotional material is clear, complete, and presentable.

79-70. The submission barely meets requirements. The game is implemented and playable but may have some minor bugs or glitches. Gameplay is balanced, but may have some aspects that are too easy or too hard for either beginners or advanced players. The required documentation (plan and design) is intact, but may be unclear and/or missing some sections. The group presentation introduces the team and game, but may suffer from lack of preparation or organization. The promotional material is presentable, but may have shortcomings in appearance or substance.

69-60. The project fails to meet requirements in some places. The game is playable, but has minor to moderate bugs or glitches. Levels are incomplete or gameplay is unbalanced, and there are aspects that are too easy or too hard for either beginners or advanced players. The required documentation (plan and design) is unclear and incomplete or missing sections. The group presentation is not well-organized and suffers from lack of preparation. The promotional material is incomplete or not very presentable.

59-0. The project does not meet core requirements. The game may not compile cleanly or has major bugs. Levels are incomplete or not even playable. The required documentation (plan and design) is incomplete or missing. The group presentation is poorly organized and suffers greatly from lack of preparation. The promotional material is missing, or incomplete and of low quality.

Top | Plan | Alpha | Final | Promo | Resources | Submission | Grading