IMGD 4000

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.

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 cs.wpi.edu 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.

• Each individual (art and tech) student should look over the design constraints.

• Each art student thinks about the genre and art style of game s/he would like to make.

• Tech students meet (in person or by email) to talk about the genre of game s/he would like to make.

• Each art student and each tech group print out seven hardcopies of the "elevator speech" for your game and bring to speed dating session (see below).

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:

• Game Genre Interest
  • What is your favorite game genre(s) to play?
  • In your view, what game genre has the most impressive art and/or Tech?
  • What genre(s) of game are you most interested in working on this term?
• Game Dev Role
  • What roles do you usually play in teams you are part of? (visionary/detail person/community builder/get-stuff-done-er/other)
  • What game development role(s) are you most interested in taking on this term?
  • What are your strongest game development skills?
• Type of Student
  • When you have an assignment due, are you more likely to get it done a week early, stay up all night before it is due, or something else?
  • How important is this class to you and how does it fit in with your other commitments this term?

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:

• Choose a team leader. The team leader is the administrative point of contact for the faculty and also responsible for setting meeting times and other coordination.
• Submit a text (only!) file to InstructAssist under "Game-Team-Name" assignment containing:
  • Team number (i.e., 1001, 1002, etc.)
  • Team leader
  • List of all team members and email addresses

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:

• 1 fully-animated biped or quadruped main character. This character must be player controlled!
• At least 4 secondary animated non-player characters or interactive objects that the main character interacts with.

• A single environment/level with at least 20 static objects.

• At least 25 unique triggerable sound effects.

• The main character shall be modeled, optimized, textured (diffuse, metalness and glossiness, normal map), rigged, and animated with at least the following animations: walk, run, idle, jump, and two additional game-specific actions.

• The secondary characters and interactive objects shall be modeled, optimized, textured (diffuse, metalness and glossiness, normal map), rigged and animated with at least 2 unique animations. Two models with two texture variants can be used.

• The game environment, with texture and lighting, shall contain at least 20 static objects, all of which must have full texture sets (diffuse, metalness and glossiness, normal map).

• At least 25 unique sound effects (all triggerable/interactive).

• 1 ambient stage sound track.

• At least 5 particle effects (associated with specific gameplay actions or ambient)

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    smith.zip    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:

• Team Number (i.e., 1001, 1002, etc.)
• Game Title
• Team Leader (include email)
• IMGD 4000 Students (including emails)
• IMGD 4500 Student (including email)
• Elevator Pitch (maximum 3 sentences describing the game)
• Detailed Description (see below)
• Technical Element List (numbered for tech milestone)
• Art Asset Spreadsheet (following art requirements)

The detailed description should include:

• Where and when does the game take place?
• Who/what are the protagonist and adversary (which one is the player)?
• Explain the primary objective of the player and how the player wins.
• Explain the general game narrative (if any) in 1-2 paragraphs
• What is the basic game mechanic? (use figures, as appropriate)
• What will the art style be? (support with appropriate sketches, images, and concept art)

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.

Website

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:

• Team Information (members, roles, contact information)
• Design documents (game treatment and subsequent design materials)
• Slides for Tech, Alpha and Beta presentation
• Downloadable zip files containing packaged games for Tech, Alpha, and Beta versions
• Demonstration video (for Beta version only)
• Daily art blog (obtain further guidance from Professor Sutter)
• Art portfolio (obtain further guidance from Professor Sutter)

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

• A simple overview slide containing the game title, elevator pitch and a numbered list of the key technical elements corresponding to your game treatment document..
• One or two slides for each technical element explaining how it works, with a picture, if possible.

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.

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.

Playtesting

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:

• Playtesters - play the game, providing feedback, both verbal and via a final survey. Verbal feedback is in the form of thinking out loud while playing - not providing a critique of the game, but rather thinking about play choices (e.g., "I am going to try to jump this gap" and not "this color is ugly").

• Facilitators - facilitate the test. Before starting, familiarize themselves with the game by talking to the developers. Give playtesters the game instructions, help get the game loaded and started. Do not get involved in conversations about the game. May answer questions or occasionally "urge" the playtesters towards a solution they get stuck (e.g., "Maybe check the directions for the controls again?"). When done, give developer-made survey (see below), collecting the results.

• Developers - prepare survey ahead of time. Before testing, confer with facilitators about how to play the game. During testing, watch and take notes. Do not interact with playtesters. Developers should assume they are behind a "one-way mirror".

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:

• Facilitators give instructions.
• Playtesters play, thinking out loud. Facilitators help as needed. Developers take notes (no help, no talking).
• When done, facilitators hand out survey and collect when filled out.

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:

• The specific goals of their playtesting.
• The original survey form and the playtesters' responses.
• Developer notes from the playtest session
• Summary of main take-aways from playtesters
• Changes made to the game (if any) based on the playtesting

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:

• Do:
  • project your voice
  • speak with confidence
  • make eye contact with the audience
  • clearly describe tech
  • rehearse who says what
  • have clear visuals that show what you want audience to see
• Don't:
  • mumble
  • have an "oops" moment
  • apologize for any part of your presentation or game
  • use foul language
  • assume audience understands tech (or the game)
  • forget to introduce yourself
  • talk too long without supporting visual

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.

Hints

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:

• Build this in "Debug" mode to preserve the console messages you may have.
• Test that the .exe created runs outside of your UE4 editor.
• If the game runs but you get a "black screen" with a red reticule in it, try one (or both) of the following:
  • In your [project]/Config folder, open DefaultEditor.ini, find the line "bDontLoadBlueprintOutsideEditor=true" and change it to "bDontLoadBlueprintOutsideEditor=false".
  • In project settings, select "Maps and Modes". There are two dropdown menus for setting a map, so set both to the map for your game game. In particular, do not have one set to the starter map, which is all black.

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:

• All of your source code (*.cpp and *.h) files for your game. Make sure your code is well-structured and commented; failure to do so will result in a loss of points.
• Screen shots of any significant Blueprints you implemented.
• A README.txt file providing:
  • The URL of your website (where the package game has been uploaded).
  • Directions on how to play your game.

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    smith.zip    3718 KB  On Time   Delete

Grading

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
Treatment	5%
Website	5%
Tech Demo	20%
Alpha Presentation	20%
Beta Presentation	40%
Final Submission Quality	10%

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.

Return to the IMGD 4000 Home Page

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