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, beta release, final release and final presentation.

Form Teams

On the first Wednesday of the term, all IMGD 4000 and IMGD 4500 students will meet in FL222 and form game project teams. IMGD 4000 students should pair up before this meeting. Their goal will be to find a pair of artists that generally is interested in making the same kind of game.

Note, artists will be supporting 2 teams! (There is a 2-1 ratio of IMGD 4000 students to IMGD 4500 students)

Before attending, all students should fill out the following questions on a half-sheet of paper. This will help to characterize game interests and expertise, as well as their working style.

• What is your favorite game(s) to play?
• In your view, what game has the most impressive art and/or tech?
• What game development role(s) are you most interested in taking on this term?
• What are your strongest game development skills?
• What genre(s) of game are you most interested in working on this term?
• What roles do you usually play in teams you are part of? (visionary/detail person/community builder/get-stuff-done-er/other)
• 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?

Students rotate amongst each other, looking for compatible groups. Staff will be on hand to help facilitate the matchmaking process.

The outcome should be a team of 2 artists and 2 tech for each tech pair (again, the artists are part of 2 different groups - their art assets will be the same for both groups, however). Students must email:

• Team name
• Team members and email addresses

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 mechanics aspects of your project are not constrained. The game design will be a collaboration with art-track 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).
• Use either first-person (if animated character is an NPC) or third-person (if animated character is player avatar) perspective.
• Have only one level, which is either indoor or outdoor, and includes one central or "hero" object.
• Include at least three non-character objects, at least one of which will be moving (such as bird that flaps its wings or a vehicle that turns its wheels when it moves, etc.).
• Use all of the following technical features (see Technical Milestone for more details):
  1. Physics
  2. Autonomous, Force-based Steering
  3. Pathfinding
  4. State-based AI
• Include at least five sounds, two of which are ambient and three of which are triggered.

Note, the IMGD 4500 artists produce:

• 2 rigged and animated characters (1 per student)
• 2 static models (1 per student)
• 2 static models with simple animations (1 per student)
• 1 environment, either interior or terrain
• 1 hero object (large, detailed static model that students work on together)
• 4-8 sound files, at least 2 triggerable and the rest environmental

Art assets beyond this need to come from "stock" or other art found on the Web. All external art (and tech) sources must be attributed.

Optional Tech

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 claypool@cs.wpi.edu and farbrook@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 two sentences, e.g., "A first-person 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
• 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?
6. Is the game first or third person?
7. Briefly describe each game asset:
   • Animated Character:
   • Environment (indoor or outdoor?):
   • "Hero" object in environment:
   • Mobile/animated object in environment:
   • Other (2) objects in environment:
   • Ambient sounds (2):
   • Triggerable sounds (3):
8. Briefly describe how each of the following minimum technical requirements will be used in the game:
   • Physics:
   • Autonomous force-based Steering:
   • Simple Pathfinding:
   • State-based AI:
9. What are you currently planning as the optional technical element(s), if any?
10. Include all sketches, images, and concept art.

Source Control

As you did for the UE4 Quickstart, setup source control (git or svn). For the art work, you should create the following directory structure:

• concept-art
  • text
  • images
• character-sculpt
• character-complete
  • animations
• static-models
  • static
  • movable
• hero-object
  • environment
  • audio
    • environmental
    • triggerable
• final-game

The tech members of the team should teach the art team members how to submit their art assets to the repository, as needed. You may setup additional directories for the tech/code, as you see fit.

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 Farbrook. In the subject of the email, put "IMGD 4/500 Web page".

Technical Milestone

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

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 be expected to demonstrate at least partial implementation of the following required technical elements (all of these will have been covered in lecture):

• Basic physics (Rigid Body, Simple and Complex Collisions)
• Autonomous steering using at least two forces (see lecture)
• Pathfinding using basic A* (see IMGD 3000 lectures)
• State based AI using state machines (see lecture)

The demo should 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 for which you are claiming credit (include class names).

Alpha Release

As for the Technical Milestone, every group 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 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.

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

Beta Release

At Beta stage, your game should be playable by users outside of the development team. Your focus should be on fixing bugs to reduce their impact for players, making 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.

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

Your game should have near-final versions of all art assets (with any exceptions noted in class).

Your game should be fairly balanced, suitable for players of various skill levels, with only tweaks needed to make the game more fair/fun.

Final Release

Your final release is like your Beta release, but with more bugs fixed, more balance. Polish, polish, polish!

Don't forget the opening/splash screen.

Don't forget credits.

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

If you have completed any optional tech requirements, make sure you include in your documentation (e.g., README.txt):

• The type of element
• Who implemented it
• How it is clearly observable in the game

Final Presentation

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! Please plan your presentations accordingly. Most important is to practice, many times, to be sure you have the content, timing and transitions down.

Hints

Think about scope as you plan your game. Look ahead at the tech requirements in 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.

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 a 0 for the project.

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

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 Milestone, Alpha, Beta, Final), 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.
  • For each technical element:
    1. A brief description of its design and functionality
    2. Who implemented it (give proportion of contribution, if not equal)

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 Turnin using your WPI user id and the password you were mailed.
5. Select the IMGD 4000 area of turnin (if necessary) and submit the zip file under "quickstart". (If your submission times out, try again.)

Grading

The grades will be the same for all tech students on team, barring exceptional circumstances. The grading breakdown is as follows:

Grading Breakdown
Treatment	2.5%
Web	2.5%
Tech Milestone	10%
Alpha	20%
Beta	20%
Final	35%
Final 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).