[Dragonfly]

IMGD 3000 Project 3

Dragonfly Spawn

Due dates:

  • Plan: Friday, September 28th
  • Alpha: Thursday, October 4th
  • Final playable: Tuesday, October 9th
  • Presentation: Thursday, October 11th


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.


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:

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:

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 engine implementation.

Utilities

You are encouraged to use WPI's FusionForge source code management system for sharing and managing your game code and engine code. At the website, login with your WPI credentials to get an account. There is a link in the upper right with the WPI fusion user guide.

For live capture on Windows, WPI allows you to install and use Camtasia Studio. Many of the labs have Camtasia installed, too. For Linux, you might try xvidcap.

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
  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

Dealing with Problem Groups

If you find yourself stuck with a partner who you think is not carrying his/her weight or is unreasonably difficult or scary to work with, you can petition your Professor to dissolve your team. This serious action should be taken only as a last resort and will be vigorously discouraged.

Set up an appointment with Professor Claypool for a team meeting. Both team members must attend this meeting. If any member of the team fails to cooperate in setting up the meeting, or fails to attend the meeting at the agreed-upon time and place without a very serious excuse, the team is automatically dissolved, and the uncooperative team member(s) will receive an NR for the course.

During the team meeting, both team members will explain and defend their positions. Professor Claypool will then negotiate an agreement to either continue or dissolve the team. If no agreement can be reached, the Professor will decide based on the evidence presented. The verdict of the Professor is final. If a team is dissolved, both team members must complete the class as a soloist.

Soloists will expected to submit assignments that meet the same standards of quantity, quality and timeliness as those created by a partnership. There will be absolutely no deadline extensions or other accommodations. This means you will have to work three times as hard to get the same grade. Your Professor will enforce this standard without mercy. Think very carefully before you decide to break up a team!


Submission

Your assignment is to be submitted electronically via turnin by 11:59pm on the day due.

If you do not have your files on the CCC machines, then copy your entire working directory to your CCC account. Then, login to the CCC machines (using slogin or putty). Use tar with gzip to archive your files. Adjust the below instructions, substituting KEY with "plan" and "alpha" and "final", as appropriate:

    mkdir lastname-proj3-KEY
    cp * lastname-proj3-KEY  /* copy all the files you want to submit */
    tar czvf proj3-KEY-lastname.tgz proj3-KEY-lastname  /* compress */
Submit your assignment (proj3-KEY-lastname.tgz):
    /cs/bin/turnin submit imgd3000 projectKEY proj3-KEY-lastname.tgz

Following this, you should verify that your files have been entered into turnin by executing the following command:

    /cs/bin/turnin verify imgd3000 projectKEY

If you need more information, see Using the turnin Program for additional help with turnin.

Plan

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

Alpha

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

Final

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


Grading

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

Return to the IMGD 3000 Home Page

Send all questions to the TA mailing list (imgd3000-staff at cs.wpi.edu).