| Deadline | Day and Date Due |
|---|---|
| Plan | Thursday, February 22nd (6:00pm) |
| Alpha | Sunday, February 25th (11:59pm) |
| Final playable | Wednesday, February 28th (11:59pm) |
| Promotional material | Friday, March 1st (2:59pm) |
| Presentation | Friday, March 1st (in class) |
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. The ones for this project are: plan, alpha and final. The intent of the milestones are to yield a robust, complete, playable game built with your own game engine. Each milestone is submitted and graded separately, while all apply towards the total Project 3 grade.
You 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 work on and be knowledgeable (in terms of how the game code executes) for all parts of the game.
Development must be in C++, preferably using your game engine from Project 2. Under certain circumstances (e.g., no teammates having completed Project 2c), you will be allowed to use the Dragonfly engine from Project 1. Permission to do so must be obtained from the instructor in advance, with reasoning provided. In all cases, we must have the ability to compile and run your game (and engine) in order to do the grading.
You provide a documented plan within the first week of the project. Your plan document should provide a detailed description of the game you intend to build, including the technical challenges it entails, a bit about any significant artistic aspects of the game, and the timeline to successfully complete development within the time allotted. In planning, you should draw upon your experiences from other classes (e.g., game development process, programming, project management, and game design) 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 detail.
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 each illustrating a kind of weapon or a specific opponent).
Your game is likely not yet finally balanced nor the levels designed for all levels (beginning player to advanced player) of gameplay.
Your game may contain some 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.
In addition to the design and implementation of your game, you 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, logo or some other graphic you deem suitable.
Description. Along with the image, 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 trailer illustrating your gameplay. You can provide a music sound-track to your video and/or provide voice narration, as you see fit. You do not actually submit the video when you turn in your project, but instead provide a link to where it may be found online (e.g., YouTube).
Stand-alone Game. A downloadable, packaged version of your game that can run without the source code or engine. See below for details on how to create this.
You may make use of these materials during your presentation, as appropriate.
Each project team presents their game in class.
Presentations should begin with an introduction of the team 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 a team should talk. Arrangements should be made in advance as to which parts of the presentation will be given by each team member.
Laptops can be brought to class with presentation materials already pre-loaded, and used with the in-class projector. Or materials can be brought in on on a USB drive 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 is approximately 4 minutes max! Please plan your presentations accordingly. Most important is to practice, many times, to be sure you have the content, timing and transitions down.
Tip! Check out the grading guide for some criteria used to assess your presentation.
For inspiration, you might check out trailers of games from past classes:
The above are for ideas only. You do not have to make games of the size and/or scope - more important is a polished game within your team’s capabilities!
Make full use of the in-depth knowledge on the game engine in designing your game:
The book.
The class slides
The game engine API documentation.
You are encouraged to use a source code management system for sharing and managing your game code and engine code. Please do not make your engine source code public - just share it privately between the team members.
For live capture, Microsoft Windows has a built-in method of capturing video - hit “Windows-G” simultaneously to launch. For Linux, you might try xvidcap or simplescreenrecorder.
For large, banner-type text (e.g., GAME OVER) 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. A Web-based version called “Text to ASCII Art Generator” that might work is at http://patorjk.com/.
Some advice on how to proceed in your development:
Form group. Setup group in Canvas.
Do a quick brainstorm about ideas.
Produce asset list (should be small!).
Design software (e.g., C++ classes).
Construct milestones.
Use iterative development. Incrementally produce features. Meet often (daily) to update each other on progress, talk about blockers, etc.
Produce final report: plan, class design, asset list, video.
Since each group is a team of 2, consider using pair programming. Not sure what that is? Check out the informative (and rather entertaining) video Introduction to Pair Programming (version 2).
If you find you are unable to work with your partner, 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 with the full team. 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. If a team is dissolved, both team members must complete the class as a soloist. Soloists are expected to submit assignments that meet the same standards of quantity, quality and timeliness as those created by a partnership.
Your assignment is to be submitted electronically.
Only ONE person from each team should submit for the group.
Before submitting, “clean” your project:
make cleanBuild ->
Clean solutionIn addition:
1. In the solution folder delete all bin, obj,
ipch, Debug and Release
directories.
2. Delete any .suo files.
3. Delete any .ncb files.
4. Delete any .sbr files.
5. Delete any .*log files.
6. Delete the .vs directory.
Note! These are good candidates to add to a .gitignore
file, too.
Use zip to archive your files. For example (adjust the
below instructions, as appropriate):
mkdir lastname-proj3__cp * lastname-proj3// copy all the files you want to submit
zip -r proj3-lastname.zip lastname-proj3// package and compress
To submit your assignment (proj3-teamname.zip):
Open: IMGD3000-C24-C01 Navigate to:
Assignments->Project 3
Click:Submit Assignment
Click:Choose File
Select the zip file:proj3-teamname.zip
Click:Submit Assignment
Important - you must click the
Submit Assignment button at the end or your file will not
be submitted!
When successfully submitted, you should see a message similar to:
SUBMITTED on Mar 1, 2024 9:50pm
For your plan submission, you hand in the following:
For your alpha submission, you hand in the following:
A source code package:
All code necessary to build your game engine, including
.h files.
A Makefile or project file for building your game engine.
A game code package:
All code necessary to build your game. Note! Make sure your code is well-structured and commented.
Any other support files, including .h
files.
A Makefile or project file for building your game.
A README file explaining: platform, files, code structure, how to compile, and anything else needed to understand (and grade) your game. Important! Make sure your names and email addresses are included in the README file.
For your final submission, you hand in the following:
A source code package:
All code necessary to build your game engine, including
.h files.
A Makefile or project file for building your game engine.
A game code package:
All code necessary to build your game. Note! Make sure your code is well-structured and commented.
Any other support files, including .h
files.
A Makefile or project file for building your game.
A README file explaining: platform, files, code structure, how to compile, and anything else needed to understand (and grade) your game. Important! Make sure your names and email addresses are included in the README file.
A DESIGN document providing all the details in your plan, but updated to reflect the game as actually built. For example, the functionality, milestones and work responsibilities should be updated to reflect the development. Major deviations from the original plan should be noted. In all cases, this document should be complete, well-organized and clearly written. Acceptable formats for this document are Word, PDF or text.
The team hands in the promotional materials in a separate submission (one submission per group) including:
Team name, Game name, Team member names.
Representative image, scaled to 200x150 pixels.
One paragraph description of game.
A link to an online (e.g., YouTube) video of your game.
See Promotional Materials above for additional details on what is required.
In addition, when your final game is complete, make a stand-alone version of your game. This is a zipped folder that, when extracted, will let the player run your compiled game. As such, it includes all the necessary libraries (e.g.,sfml-system.lib and
libdragonfly-x64-release.lib) and game engine files (e.g.,
df-font.ttf) and game files (e.g., sprites/
and sounds/).
Build a Release version of your game using the release version of
the SFML libraries (e.g., sfml-graphics.lib versus
sfml-graphics-d.lib) and a release version of Dragonfly, as
appropriate.
Make a new, empty folder and copy in the needed files.
SFML/bin)The SFML libraries are usually in
/usr/lib/libsfml*.
The remote host (where installing) needs to set
LD_LIBRARY_PATH=.
Make sure to test the installation by extracting on another computer and verifying it can run!
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: For the final release, you will be graded on the version of your project submitted online by the due date, not on the version you present in class.
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.
