charlieroberts / imgd4000-2024

Course repo for IMGD 4000, Technical Game Development II, 2024 @ WPI

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

IMGD 4000 Technical Game Development II D24

Classroom: Remote + FL222

(REMOTE) Tuesdays and Fridays 2:00 to 3:50 pm

(IN PERSON) Lab Sessions on Wednesdays from 2 to 3:50 pm

Instructor: Charlie Roberts
Email: cdroberts@wpi.edu
Office Hours: by appointment (arrange via Discord DM)

Student Assistant: Jiangwen Nong
Email: jnong@wpi.edu
Office Hours:

  • Monday - By appointment
  • Tuesday - 4-5PM
  • Wednesday - 4-6PM
  • Thursday - 2-5PM
  • Friday - By appointment
  • All office hours will be in either FL 222 or the ZooLab; this will be announced beforehand in the course Discord server

IMGD 4000 will explore concepts related to technical development using game engines. Game engines are used in a wide range of fields including games, simulations, and architecture, and are an important part of any developer's toolbox, regardles of whether or not a developer is working on a "game".

Topics discussed in this course include:

  • Modern game development engines (primarily Unreal) and game engine design patterns
  • Game-specific algorithms (path finding, agent-based AI etc.)
  • Source control / asset management for game engine

Wednesday Labs

IMGD 4000 and 4500 are not scheduled to run at the same time (IMGD 4500 is scheduled for Tuesdays and Fridays, from 12 to 1:50pm). However, in addition to these days, 4000 and 4500 have Wednesday labs in FL222 at 2pm. ALL 4000 and 4500 students are required to attend these Wednesday labs. All major presentations and milestones are scheduled to take place on these Wednesdays, with the exception of the Beta – which will consist of a pre-recorded presentation and deliverable of your game's executable.

Deadlines at a Glance

Group Deadlines

Form Teams - Wednesday, March 13th (before that sub-teams should be formed by Tuesday, March 12th)

Treatment Document – Sunday, March 17th

Website – Wednesday, March 20nd

Alpha – Wednesday, April 10th

Playtesting - Wednesday, April 17th (runs for one week until Wednesday, April 24th)

Beta – Wednesday, May 1st (Friday schedule – but the Beta build and presentations need to be uploaded by then).

Forming Teams

Team Forming Process (3 steps)

A significant portion of your grade this term involves your final project, which you will work on from the first day of the term to the last. An important first task is the creation of your team for this project. There are 28 IMGD 4000/Tech students and 14 IMGD 4500/Art students. This will result in a grand total of 7 teams.

  • 7 teams with 4 Tech and 2 Art students (6 students total per team)

Your full/final (Art + Tech) teams are expected to be in place by Wednesday, March 13th.

Step 1. The team formation process for IMGD 4000 will begin on Tuesday, March 12th. During class, you will be forming your development sub-teams.The same thing will occur on the Art side during the first class of IMGD 4500. As you form your sub-team, think about each other's strengths. Your natural tendency will be to pair up with people you know, but focus on what your abilities are instead. A good development team needs people interested in physics, AI, graphics, and audio. Having a well-rounded base pool of knowledge in your team is incredibly important. In other words, look past the fact that you may not know the people you could possibly be working with, but look at how you can find people whose strengths compliment yours.

Step 2. After selecting the other members of your sub-teams, you will create a meta-document describing the background of your sub-team and their final project interests. In effect, you are pitching what you'd be interested in creating to your technical / artistic counterparts, to find other students to work with. Try to be somewhat flexible and generic in your goals. For example, "We'd like to create a 3D open-world game with a heavy resource farming mechanic" is reasonable. "We'd like to create a game set in 18th century France where aliens invade and stop the French Revolution" is way too specific in terms of plot, and actually reveals nothing about the type of development work that would need to be done, nor much about the type of assets that would be required. Each sub-team will post their meta-document to the course Discord #team-forming channel, no later than Tuesday, March 12th 11:59pm. All sub-teams should take the time to read all of the tech sub-team meta-documents (and vice versa for IMGD 4500 students) before the first Wednesday lab session (which is on the following day, March 13th). This will help the final step of the team formation process, since you will be aware of what each Tech sub-team is hoping to produce. Your sub-team meta document should also contain the development roles you intend to take on... these are not set in stone but you should have a sense of who will be responsible for what.

Step 3. On Wednesday, March 13th, all of the art sub-teams will meet all of the tech sub-teams during the lab session in FL222. This is an important step, come prepared! Bounce ideas around, see if things gel – and if you could see yourselves working with any of the specific sub-teams. At the end of this lab session, each art sub-team will need to find a tech sub-team to form their respective final team with. All teams must be formed before Friday, March 15th! Once a team is formed, you must post your Team Document in the #team-formation channel of our course Discord. Your Team Document should contain the following:

  • Your team name
  • A primary contact person for your team for communication purposes with course staff
  • Your team member's individual roles

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. The Tech Artist then tests and assembles them in UE5, so 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 Professors Roberts and Sutter 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. Your Professors 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 Professors is final.

Group Evaluations

As this class centers on creating a group project, teamwork is an important consideration. You will be asked to provide anonymous feedback on your teammates twice during the term. We reserve the right lower your final grade if your teammates are unsatisfied with your work at midterms and there isn't significant improvement by the time the final projects are submitted, or, if you fail to meet your deliverables for the final project. That said, it is our hope that this doesn't happen to anyone in the class, and we will work with everyone to make sure that deliverables are distributed equitably and that the scope of projects is reasonable.

Scoping and Hints

Think about scope as you plan your game. Look at the design constraints, understand what you know (and don't know) about UE. Know your team size, limitations, and time budget (7 weeks, about 10 hours/week on average of programming), and your own personal constraints (ability and time). Above anything else, take into account that everyone is working remotely. Use all of this in planning.

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

Game 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 must include:

  • A solid gameplay mechanic which makes your game enjoyable and fun to play set in a 3D environment using 3D assets. Note, this does not mean that the camera cannot be locked to a single angle. 2D gameplay mechanics are thus allowed, but should use 3D assets.
  • 1 fully-animated, bipedal, main character. This character can be used as either a player avatar (third person game) or a featured non-player character (NPC).
  • 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 level objects (buildings, foliage, etc.).
  • A fully featured sound design. This should include, at minimum, a soundtrack, a variety of sound effects, and (as appropriate) a soundscape. The soundtrack and sound effects can be sourced from any creative commons licensed asset (look at freesound.org!), but many projects in the past have also featured custom music and sound design. The arrival of Metasounds in UE5 makes interesting procedural audio effects easier than ever... if you have a team member interested in this we highly encourage you to explore!

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

  • 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.
  • 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)
  • The majority of your game should consist of assets that you've created yourself – however, the use of complimentary assets (models, textures, shaders, sounds, etc.) is allowed. Provided that your own content still outweighs these additional assets.

Important Dates, Milestones, Deliverables and Presentations

Below you will find the descriptions of all deliverables and presentations required for 4000/4500. Please

note that if a deliverable is listed as GROUP both 4000/4500 are to contribute, if it's listed as ART only 4500 students must submit.

Team Document – GROUP Wednesday, March 13th

Your Team Document should be submitted in the #team-formation channel of our course Discord and needs to contain the information below:

  • Your team name
  • Your team leader (for communication purposes)
  • Your team member's individual roles

Treatment Document – GROUP Sunday, March 17th

Review the design constraints before working on this treatment! Submit PDF file (only!) by due the date through Discord. 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 Information/Sections include:

  • Game Title
  • Team Contact (include email)
  • IMGD 4000 Students (including emails)
  • IMGD 4500 Students (including email)
  • Elevator Pitch (maximum 3 sentences describing the game)
  • Detailed Description

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 visuals, as appropriate)
  • Include asset list (with brief description, as needed). Your asset list should list everything you anticipate having to create for the game from both a tech and art standpoint.
  • Briefly describe the technical requirements that will be used in the game (e.g., physics, pathfinding, networking, AI).
  • Include style guide, with all sketches, images, and concept art. artists will need to have come up with one concept sketch for their main character, 5 NPC characters/objects, and environment.

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 – GROUP Wednesday, March 20th

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 should have links to content including (some of which you obviously cannot add until Alpha and Beta Presentations have taken place, but add what you can when you can):

  • Team Information (members, roles, contact information)
  • Design documents (game treatment and subsequent design materials)
  • Downloadable executables for your game's Alpha and Beta versions
  • Demonstration video (for final Beta version)
  • Slides for final Beta presentation
  • Art Progress Imagery (obtain further guidance from Professor Sutter)
  • Art portfolio (obtain further guidance from Professor Sutter)

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.

By the due date, upload a text (only!) file with the URL of your website to your Discord channel.

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.

Alpha Presentation and Release – GROUP Wednesday, April 10th

The Alpha presentations will be held in person in FL222. Every team will give a short (~8 minute) presentation, which includes a demonstration that starts by visiting their website and clicking on the download link to your executable to show that your game is downloadable and playable. Make sure you test this ahead of time!

Presentation slides for your Alpha presentation should focus on the current state of your game, and should include tech and art processes. Note that both Tech and Art students are required to present on their technical and creative methods during this presentation! Everyone in your team should be speaking at some point.

At the 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 finally balanced.

Playtesting – GROUP Wednesday, April 17th

Your Alpha build should be playable by users outside of the development team. This means Working 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.

Playtesting will occur from April 17th until April 24th. Throughout this period each time will play each other's games. You will be submitting your Alpha builds and playtesting surveys via your team's Discord channel. At the end of this period, each team member of each team should have played every game other than their own. This will result in your Beta product being that much better. You are in charge of the questions being asked, but ask yourselves what is of value for you to know at this stage. Are the gameplay objectives clear? Is the game fun to play? Etc.

When submitting your Beta materials, 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 Presentation and Release – GROUP– Wednesday, May 1st

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

Final presentations will be done in Zoom. You will be submitting your final Beta presentation in video format via your group's Discord thread. 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 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; I recommend OBS. (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.

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.

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

Grading

Outside of individual assignments (described below) gradesshould be expected be the same for all of the students on a team, barring exceptional circumstances. The grading breakdown is as follows:

Grading Breakdown

  • Treatment Document 5%
  • Website 5%
  • Alpha Presentation 30%
  • Beta Presentation 30%
  • Tech Assignments 30%

Assignments (30% Total)

For the additional assignments in this class, you must complete at least one of the two programming assignments (Agent-based simulation or Pathfinding / A*) and then one other choice from the following list:

If you'd like to focus on C++ in Unreal, completing both programming assignments is great! More information about these individual options will be given as the course progresses.

Discord

All course communication will occur via Discord. Please see Canvas for a link to the course Discord server.

Group meetings outside of class

Your team should meet more than just the one obligatory Wednesday lab session per week. It is highly recommended that you set up your own Discord or Slack to keep track of each other's progress and to make time to work alongside one another as best as you can whilst working remotely. Teams who work together often times produce far better work. It is easy enough to alienate yourself from a group, even when physically on campus. So make every attempt to counteract this by scheduling days and times outside of class, where you all hang out via remote conferencing to do work together as a team. This will make all aspects of development more efficient, you will feel more as though you are functioning as a team, and everyone will be aware of what the greater group is consistently working on.

About

Course repo for IMGD 4000, Technical Game Development II, 2024 @ WPI