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

All teams will be 2 Art and 2 Tech.

To form teams, there are three phases: Form Pairs, Speed Dating, and Form Teams.

Form Pairs

Must be done by Tuesday, 11:59pm.

Students form pairs, meaning Tech students pair up and Art students pair up.

Each individual student should look over the design constraints.

Then, each pair meets and talks about the kinds of 2d game s/he would like to make.

By Tuesday evening (11:59pm), send professor Claypool (claypool@cs.wpi.edu):

1. Classification of Art or Tech pair
2. Pair names and email addresses
3. A 1-sentence description of the kind(s) of 2d game(s) the pair would like to make

Speed Dating

Must be done by Wednesday, 3pm.

All pairs go to FL 222 at 2pm.

Each person takes 1 printed handout of pair info (Artists take Tech pair sheets and vice versa).

Art pairs assume fixed locations around room.

Tech pairs randomly group up with an Art pair, one Art pair to Tech pair.

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

• 2d Game Interest
  • What is your favorite 2d game(s) to play?
  • In your view, what 2d game has the most impressive art and/or tech?
  • What genre(s) of 2d 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 pairs rotate to the next Art pair. Art pairs stay in place.

Repeat until all Tech pairs have met with all Art pairs.

Form Teams

Must be done by Wednesday, 11:59pm.

After "speed dating", Art and Tech pairs communicate to try to commit to a team of 4 (two Art and two Tech), by email or in person.

Once two pairs have committed to each other:

1. Choose a team name
2. Send both professors Claypool (claypool@cs.wpi.edu) and professor Synder (bsnyder@wpi.edu):
   1. Team name
   2. List of all team members and email addresses

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

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 students create the game assets and then test and assemble 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.

One Art student acts as the point person on each team to take on the Technical Art role. This role overlaps with game design, including level design. The Technical Art student interfaces with the Tech students and takes on some of the role of assembling the level with the assets that have been made.

Tech team members often, but not always, get the same grade for the project. However, there will be an opportunity for each partner to "grade" his/her teammate for work done on the project.

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 group. 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 group meeting. Both group members must attend this meeting. If any member of the group 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 group is automatically dissolved, and the uncooperative group member(s) will receive a 0 for the project.

During the group meeting, both group members will explain and defend their positions. Professor Claypool will then negotiate an agreement to either continue or dissolve the group. If no agreement can be reached, the Professor will decide based on the evidence presented. The verdict of the Professor is final. If a group is dissolved, both group 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. There is absolutely no deadline extensions or other accommodations. This means a soloist has to work three times as hard to get the same grade. Think very carefully before you decide to break up a group!

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 sources (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 game must:

• Include at least one fully-animated biped or quadruped character. This character can be used as either a player avatar or a non-player character (NPC).
• Include at least three non-character objects.
• Include at least five sounds, two of which are ambient and three of which are triggered.

Note, the IMGD 4500 artists produce:

• 2 animated characters or objects (1 per student)
• 2 static 2d assets (1 per student)
• 1 environment
• 5+ sound files, at least 2 triggerable and the rest environmental

No stock art assets are to be used in the project.

Treatment Document

Review the design constraints before working on this treatment!

When done, send a PDF as an email attachment. Send the email to both Professor Claypool (claypool@cs.wpi.edu) and Professor Snyder (bsnyder@wpi.edu). Include the art work in the PDF. If the file is too large for email, use your WPI Filer account or DropBox to share the document. In the subject of the email, put "IMGD 4/500 Treatment".

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

Information/Sections include:

• Game Title
• Group Leader (include email)
• IMGD 4000 Group Members (including emails)
• IMGD 4500 Group Members (including emails)
• Elevator Pitch (maximum 3 sentences describing the game)
• Detailed Description

The detailed description should include:

1. Where and when does the game take place?
2. Who/what are the protagonist and adversary (which one is the player)?
3. Explain the primary objective of the player and how the player wins.
4. Explain the general game narrative (if any) in 1-2 paragraphs
5. What is the basic game mechanic? (Use visuals, as appropraite)
6. Include asset list (with brief description, as needed).
7. Briefly describe the technical requirements that will be used in the game (e.g., physics, pathfinding, networking, AI, ...)
8. Include style guide, with all sketches, images, and concept art.

Website

You will make a development Website for your game. It should include information on the team members, their roles, the game title and links to relevant development information.

The Website should have links to content including:

• Team (e.g., members, roles, contact information)
• Documents (e.g., Game treatment)
• Artistic content (e.g., Concept Art, Model Renders)
• Releases (Tech, Alpha, Beta)
• Promotional materials (e.g., Trailer)
• Final game

The actual implementation (and hosting) of the Website is up to you, but it should provide a professional, outward representation of your game development effort.

We recommend you look at Websites from game projects from past offerings (e.g., d12 and b12).

When the initial version of the Web site is setup, send an email with the URL to both professor Claypool professor Snyder. In the subject of the email, put "IMGD 4/500 Web page".

Technical Milestone

For an overview, and an example, see the Technical Demonstration slides.

Every Tech group will do a short (~5 minute) demo in class by either downloading their game on the podium computer, or running it on their laptops.

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!

You will:

1. First describe a high-level concept of the game.
2. Then, you will describe and demonstrate the technical elements required for your game. Be sure to point out each element as it is shown in the running game.

Note, it is not expected that the elements are tuned/balanced to the game nor even working with game art assets, but they should be working and observable.

Include a README.txt in your project describing the technical components.

Alpha Release

For an overview see the Alpha Release slides.

Every team will do a short (~5 minute) demo in class by either downloading their game on the podium machine, or running it on their laptop.

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, and separate features of the game demonstrable.

Your game is most likely not yet to be 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 frame a can be shown where in the final version it would be animated.

See the Alpha Release slides for a summary and guidance on the presentation.

Playtest

For an overview see the Playtesting slides.

For the day of playtesting, see the Playtesting Assignments slides.

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 with the short (and possibly long) term intent to make your game more playable and/or more fun. At this point, you should add no more new features to your game nor make and major game or code changes.

There are three roles for playtesting. You will assume each role as a developer of your own game, playtester of another game and facilitator of a third game.

• 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?"). Give developer-made survey when done, 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, the development teams 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!

During class, there will be a roster (created by the professors) with three rounds, with teams divided evenly into the three roles.

  Round 1: 
  Playtesters - Team A
  Facilitators - Team B
  Developers - Team C

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. Developers should quietly observe and take notes.

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

Once complete, repeat for Round 2 and Round 3, with each team playing the role of playtester, facilitator and developer one time and all games being playtested.

When submitting its Beta, each team will provide a report on the playtesting. This report 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

Reports must use 12 point font, 1.5 line spacing and be provided in PDF format.

Beta

The final version of your game is a "beta" release. It should have most bugs fixed, and have reasonable game balance. All art assets should be in place, and, along with the tech features, 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).

As for the previous milestones, every group will do a short (~5 minute) demo in class by visiting their game Web page on the podium machine and clicking on a link.

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. Arrangements should be made in advance as to which parts of the presentation will be given by each team member.

Total presentation time is limited! Plan your presentations accordingly. Most important is to practice, many times, to be sure you have the content, timing and transitions down.

Submission of the Beta must including the playtesting report.

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.

Submission

Your assignment is to be submitted electronically via turnin by 11:59pm on the day due, unless otherwise noted. For submissions about technical elements (e.g., Technical, Alpha, Beta), you must include the following:

• A Windows executable (.exe).
  1. Build this in "Debug" mode to preserve the console messages you may have.
  2. Test that the .exe created runs outside of your UE4 editor.

  Important! Upload the .exe to your Web site where we can download it.

• A source code package:
  • All your source code (*.cpp and *.h) files for your game. Important! 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 where the .exe has been uploaded.
  • Directions on how to play your game.

To submit:

1. Upload your .exe (see above).
2. Place the README and Source code in a folder with your last name (e.g., "claypool").
3. Zip up the folder.
4. Log into the Instruct Assist website:

   https://ia.wpi.edu/imgd4000/

   Use your WPI username and password for access. Visit:

   Tools → File Submission

   Select "Project-Alpha" from the dropdown and then "Browse" and select your assignment (claypool.zip).

   Make sure to hit "Upload File" after selecting it!

   If successful, you should see a line similar to:

    Creator    Upload Time           File Name      Size     Status    Removal
    Claypool 2016-04-25 11:12:23    claypool.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%
Web	2.5%
Tech Demo	15%
Alpha	30%
Playtest	2.5%
Beta	35%
Game 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 TA mailing list (imgd4000-staff at cs.wpi.edu).