IMGD 4000

D-Term 2017 Game Project

Due Dates
Form Art/Tech TeamsMarch 15
TreatmentMarch 19
WebsiteApril 2
Tech milestoneApril 13
AlphaApril 18
PlaytestApril 24
BetaMay 1

The goal of this project is to build a game, of your own choosing but with some design constraints, in a team of artists and programmers. The team will brainstorm ideas and then produce a treatment document. Technical implementation will be done in UE4, with the artists providing original assets. Milestones include a technical milestone, alpha release, playtesting, and beta release. All milestones will be done/presented in class.

Top | Teams | Design | Treatment | Website | Tech | Alpha | Playtest | Beta | Hints | Submission | Grading

Form Teams

As of the time of this writing, there are 23 tech students enrolled in IMGD 4000 and 7 art students enrolled in IMGD 4500. For the joint game project, we will therefore have a total of seven teams, with 1 artist per team; five of those teams with 3 tech and two teams with 4 tech.

The faculty will inform the tech students of their initial assignments by email before the first day of class. This is good professional practice, since in most future employment situations you will not be able to choose your teammates. We will, however, accept mutually voluntary swaps between tech groups if both participants inform us using imgd4000-staff at by 11:59pm on Tuesday, March 15.

To form final art-tech teams, there are three phases: Preparation for Speed Dating, Speed Dating, and Form Teams, as described below.

Preparation for Art-Tech Speed Dating

Must be done before lab on Weds, March 15, 2pm.

Speed Dating

All students go to FL 222 at 2pm (regular lab time).

Art students assume fixed locations around room.

Tech groups each start with a randomly chosen art student.

Art and tech exchange elevator speech hardcopies (see above) and talk for 5 minutes, refining game interest, and brainstorming. Also, taking notes and looking for good matches for future reference. Possible questions that may be helpful:

After 5 minutes, tech groups rotate to the next art student. Art students stay in place.

Repeat until all tech groups have met with all art students.

Form Teams

Must be done by Wednesday, March 15, 11:59pm.

After "speed dating", art and tech students communicate to commit to an art/tech team by email or in person.

Once an art/tech team has committed to each other:

N.B. As soon as the team is formed, the tech group should immediately set up a source control repository for the game project!

Warning! Any art-tech students not committed to a team by Wednesday, 11:59pm, will be randomly assigned.

A Note about Teams

The final game created is a team effort and everyone on the team should view it as such. This means being professional and responsible in all aspects of development. All team members have a stake in the final game produced. That is not to say that team members will not have roles (they will and should), but every team member must look beyond their individual roles to see how to help the team complete their best game possible. For example, the entire team is responsible for game design and playtesting. Ask yourself "What else needs to be done?" and "How can I help?"

The art student creates the game assets and then tests and assembles them in UE4, but ultimately the tech students are implementing the finished artwork into the game. The art students test their animations and put together the level to see that it all is functioning, but the actual hand off is just the assets.

Tech team members usually, but not always, get the same grade for the project.

Dealing with Problem Teams

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 the faculty 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 Rich for a team meeting. All 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 a 0 for the project.

During the team meeting, all team members will explain and defend their positions. Professor Rich 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, all team members must complete the class as solos.

Solos are expected to submit assignments that meet the same standards of quantity, quality and timeliness as those created by a partnership. There is absolutely no deadline extensions or other accommodations. This means a solo has to work much harder to get the same grade. Think very carefully before you decide to break up a team!

Design Constraints

The following are required constraints on your game design and implementation. The reasons for these constraints are pedagogical, but almost all game projects have some significant constraints, whether they come from technical, financial, legal or market (or pedagogical) sources. Note that when constraints below say "at least", that means you may exceed the requirement, but we strongly recommend against it, since it is better to do a more polished job with limited scope than to only partially accomplish overly ambitious goals.

Notice that the setting, narrative, character personality and game mechanic aspects of your project are not constrained. The game design will be a collaboration with art students in IMGD 4500, who will also be responsible for producing the art assets, including models, animations and sounds.

The 3D game design must include:

The following are additional art-specific requirements for each IMGD 4500 student, which are included here for the shared knowledge of the entire team:

No stock art assets are to be used in this project, except for sounds, which may be downloaded from websites with proper licensing.

Treatment Document

Review the design constraints before working on this treatment!

Submit ZIP file (only!) containing PDF document (approx 5 pages) and asset spreadsheet (see below) by due date at InstructAssist under "Game-Treatment" assignment.

N.B. Don't forget to press "Upload File" as the last step of uploading! If successful, you should see a line similar to:

 Creator     Upload Time    File Name      Size     Status    Removal
 Smith 2016-04-25 11:12:23    3718 KB  On Time   Delete

Note, the treatment is not a contract, but rather a chance for the team to think through most aspects of the game before starting. You may, and likely will, change your mind about details as you work on the project--that is fine.

Keep a copy of this document and add it to your game website, as soon as it is created (see the timeline for when the website needs to be up).

The elevator pitch below should be a maximum of three sentences, e.g., "A top-down shooter using rotten vegetables that takes place in the supermarket produce section. You win the game by hitting your opponent with a complete salad."

Treatment document sections should include:

Please make sure your team number is also on the spreadsheet and any other separate documents!

The detailed description should include:

The technical element list should draw from the general topics covered in the course, such as physics, AI, pathfinding, camera control, etc., but with specific reference to your proposed game(see example tech milestone slides).

The faculty will provide feedback in the first lab after the treatment due date regarding the proposed art and tech scope, and may suggest changes.


The team will collaborate to make a website that will serve as a repository for both art and tech students. It should include information on all team members, their roles, the game title and links to relevant information.

The website will eventually have links to content including:

The initial website will have at least the first two elements above.

The hosting and implementation choice for the website is up to you, but it should provide a professional, outward-focused representation of your game development effort.We recommend you look at websites from game projects from past offerings for ideas: d12, b12, d16.

By the due date, upload a text (only!) file with the URL of your website to InstructAssist under the "Game-Website" assignment.

N.B. The final website grade (see Grading) will be assigned at the end of the course, but late submission of this assignment will result in a maximum of half or zero credit for the website.

Technical Milestone

See Submission section below for Technical submission instructions.

Every tech group will do a short (~5 minute) presentation in class, which includes a live demonstration using a packaged game downloaded from their website. Make sure you test this before class! If your demo does not work, you will get zero on this portion of your grade. This is a real-world check; if you have a meeting with your publisher or funder, you only get one shot.

For your presentation, start with the following prepared slides (also downloaded from your website):

See example slides here. (Note however that this example is for a 2D game; we are building 3D games this year.)

Note that unlike the beta presentation, in which all members of the team must participate, due to the short time for this presentation, it is not necessary for all team members to participate in the presentation (of course, all members should have contributed to the technical elements).

Finally, run the packaged game from your website and point out each element as it works in the running game. It is not expected that the elements are tuned/balanced or even fully debugged. Many or all of the art assets may be placeholders (e.g., a simple cube). However, each technical element should be somehow working and observable in the game.

Make sure you can do all of this in no more than 5 minutes!

N.B. Your grade on the technical demo will be based entirely on your class presentation.

Alpha Release

See Submission section below for Alpha submission instructions.

Every team (art and tech together) will do a short (~5 minute) presentation in class, which includes a live demonstration using an packaged game downloaded from their website. Make sure you test this ahead of time!

Presentation slides are optional for the Alpha presentation, but plan your time regardless. If you use slides, download them from your website.

At Alpha stage, your game should have all of your planned functionality 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. You may have separate levels for demonstrating different game aspects, if that is convenient for development at this point.

Your game should compile cleanly and be runnable, and separate features of the game demonstrable.

Your game is most likely not yet finally balanced.

Your game may a few placeholder art assets. For example, in the Alpha release, a simple square may be used for an object not yet fully created. Or a static object can be shown where in the final version it would be animated.

Note that unlike the beta presentation, in which all members of the team must participate, due to the short time for this presentation, it is not necessary for all team members to participate in the presentation (of course, all members should have contributed to the alpha).


By playtest time, your game should be playable by users outside of the development team. This means near-final versions of all art assets, and decently balanced, suitable for players of various skill levels.

During playtesting, your intent should be getting feedback on your game to make it more playable and/or more fun for the Beta version. After this point, you should not add any more new features to your game nor make any major game or code changes!

There are three roles for playtesting. During the playtesting session, you will rotate between all three of these roles for your own and other games:

In preparation for playtesting, each team (art and tech together) creates a short survey for their game. The survey should include questions that focus on aspects of the game the developers want feedback on. Keep the survey short. Print out copies ahead of time (at least 5) so playtesters can fill them out and return them. This must be done before class begins!

Before class, there will be a roster (see here on playtesting day) with multiple rounds, with teams divided assigned one of three roles in each round, e.g.,

  Round 1: 
  Playtesters - Team 1001
  Facilitators - Team 1002
  Developers - Team 1003

At the beginning of the round, the Facilitators meet with the Developers about their game first so as to understand the basics. This can include a quick walkthrough and should also include play instructions and the survey. Facilitators do not need to completely understand or completely play the game, but need enough to facilitate playtesting.

When playtesting starts, the facilitators make sure each playtester is set up to play the game on a separate computer, with one facilitator and one developer per machine (with adjustments for smaller teams---one facilitator or developer can be shared between two adjacent computers). Developers should quietly observe and take notes. To summarize:

Once complete, repeat for further rounds as scheduled.

When submitting its Beta, each team will provide a report on the playtesting. This report in PDF (only!) must include:

Beta Release

See Submission section below for Beta submission instructions. Submission of the Beta must include the playtesting report.

The final version of your game in this course is a "beta" release. It should have most bugs fixed, and have reasonable game balance. All art assets should be in place and functional and all the tech features should be functional.

Don't forget the opening/splash screen.

Don't forget credits.

Don't forget directions to play (in game, not just in the documentation).

The presentations for the Beta release will be a full rehearsal for your MQP presentation on WPI project presentation day. You will have 10 minutes for presentation plus two minutes for questions from class and professors. You will start by clicking on your website link for your presentation slides (PDF, Google or PowerPoint) and for your demonstration video (see below).

Presentations should begin with an introduction of the team and members, then provide a high concept of the game, and a summary of the major art and technical features.

Presentations should include an approximately 3-minute demonstration video played from a link on your website, which demonstrates all of the technical and gameplay aspects of the game. It will probably be useful to combine multiple gameplay cuts. Do not try to demonstrate your game live!

Screen capture videos can be easily created using any one of a number of free tools. (This is a good skill to learn, if you don't already know how to do so.) The video can be narrated or you can provide the narration live. Make sure ahead of time that your video is playable on a public WPI machine (such as in the library), which have the same software configuration as the classroom podium machine.

Every member of your team should talk. Arrangements should be made in advance as to which parts of the presentation will be given by each team member.

Your presentation will be ended after 10 minutes, regardless of whether you have covered everything or not (and your grade may therefore suffer). Plan your presentations accordingly. Most important is to practice, many times, to be sure you have the content, timing and transitions down.

Here is some additional presentation guidance:

N.B. To determine your final grade, the faculty will also play your game themselves by clicking on the link you provide on your website.


Think about scope as you plan your game. Look at the design constraints, understand what you know (and don't know) about UE4 from the Quickstart project, know your size (2 person tech team) and time budget (7 weeks, about 10 hours/week on average of programming), and your own personal constraints (ability and time). Use all this in planning.

There are many, many UE4 tutorials, documents and videos online, but be aware that most are made for different versions of UE4. That's not to say that a tutorial made for a different version of UE4 is worthless, but it does mean you are responsible for figuring out the differences between the UE4 version you are using.

Refer to the UE4 resources that we have collected.

Packaged Game Submission

For the Technical, Alpha and Beta milestones, package your game according to the Unreal Engine instructions and upload the zipped folder to your website. Also note the following:

For the Technical Milestone, only the packaged game on your website is required.

For Alpha and Beta milestones, also submit a ZIP (only!) file via InstructAssist by 11:59pm on the day due under the "game-alpha" or "game-beta" assignment containing the following:

N.B. Don't forget to press "Upload File" as the last step of uploading! If successful, you should see a line similar to:

 Creator     Upload Time    File Name      Size     Status    Removal
 Smith 2016-04-25 11:12:23    3718 KB  On Time   Delete


The grades should be expected be the same for all tech students on team, barring exceptional circumstances. The grading breakdown is as follows:
Grading Breakdown
Tech Demo20%
Alpha Presentation20%
Beta Presentation40%
Final Submission Quality10%

Below is a general grading rubric:

100-90. The submission clearly exceeds requirements. The game works without problems. The demonstration went smoothly, well-prepared and executed. All technical components exhibit an unusually high degree of effort and technical ability. Accompanying documentation is complete and clearly written, and website is complete, well-organized and professional.

89-80. The submission meets requirements. The game works without significant problems. The demonstration went fairly smoothly, showing preparation. Most technical components exhibit an high degree of effort and technical ability, although some may have minor issues. Accompanying documentation is complete and fairly clearly written, and website is complete, and fairly well-organized and professional.

79-70. The submission barely meets requirements. The game works, but with some problems. The demonstration has some difficulty showing functionality. Some technical components exhibit a high degree of effort and technical ability, but others have issues, possibly significant. Accompanying documentation is partially incomplete and somewhat unclear. website is mostly complete, with some minor organizational or presentation issues.

69-60. The submission fails to meet requirements in some places. The game may only somewhat work and has significant problems. The demonstration has difficulty showing functionality. Many technical components have issues, some significant. Accompanying documentation is unclear (or missing) and unclearly written. Website is incomplete, with some organizational and/or presentation issues.

59-0. The project does not meet requirements. The game does not work or crashes frequently. The demonstration did not show adequate functionality. Most technical components had issues, some significant. Accompanying documentation is unclear, missing and poorly written. Website is missing or incomplete, with organizational and presentation problems.

Top | Teams | Design | Treatment | Website | Tech | Alpha | Beta | Submission | Grading

Return to the IMGD 4000 Home Page

Send all questions to the staff mailing list (imgd4000-staff at