# **GAM200: Project II** *Fall 2024* ### Course Information **Prerequisites:** GAM 150 and CS 230 plus either CS 170 or CS 175 ### Schedule | **Mondays** | 3:30pm-4:20pm | [[Plato]] | | | -------------- | ------------- | ----------------------------------- | --------------------------------------------------------- | | **Tuesdays** | 2:00pm-2:50pm | [[Plato]] | Producer / Tech Leads Meetings *and/or* Team Work Session | | **Wednesdays** | 3:30pm-4:20pm | [[Carr]] | Technical Leads, Newton for Producers | | **Fridays** | 1:00pm-5:50pm | [[Edison]], [[Tesla]], [[The Wing]] | | | **Fridays** | 1:00pm-2:00pm | | Reserved for team meetings *and/or* instructor meetings | | **Fridays** | 5:00pm-5:50pm | | | - Mondays: 3:30 pm—4:20 pm (1st lecture) in PLATO - Tuesdays, 2 to 2:50 pm (Producer/Tech Leads meetings and/or team work session) – Located in Carr for Technical Leads, Newton for producers - Wednesdays: 3:30 pm—4:20 pm (2nd lecture) – in PLATO - Fridays: 1 pm—5:50 pm (labs) – in EDISON, TESLA, and THE WING - Fridays: 1pm—2pm – First lab hour is reserved for team meetings, or at times a meeting with instructors - Fridays, 5 to 5:50 pm (supplemental lectures) – These will be announced if occurring Monday and Wednesdays are for on-campus lectures. Tuesdays are for the Producer and Tech Leads meetings, which are required for any students who volunteer for those team roles. We may also use these for instructor meetings with teams. If you are not a Producer or Tech Lead, please use this time to work on your team project. Fridays are for working with your team and for team meetings with your instructors. When you are not meeting with instructors, you are expected to be working with your team. Unless otherwise stated by college policy, Friday labs are when you must be onsite and working in your team space. **Class Participation:** You are expected to participate in every lecture and lab session. If called upon, you should be prepared to answer with a thoughtful, informed response that is relevant to the topic we are discussing. You are required to use a PC or laptop computer during labs for this course. **Professors:** - Ellen Beeman, Rachel Rutherford, Douglas Schilling are the instructors for this course. - Christopher Onorati is our Lab Manager. - Jeremy Holcomb teaches our sister course for BAGDs, GAM 205/255. **Contact Information:** Ellen Beeman: [[email protected]](mailto:[email protected]) Jeremy Holcomb: [[email protected]](mailto:[email protected]) Rachel Rutherford: [[email protected]](mailto:[email protected]) Douglas Schilling: [[email protected]](mailto:[email protected]) Christopher Onorati: [[email protected]](mailto:[email protected]) **All email correspondence must come from your DigiPen email address**. Please include the course name (GAM200) in the subject line for any correspondence. **Office Hours:** Ellen Beeman: Tuesdays, 3 pm to 5 pm or by appointment Jeremy Holcomb: By appointment Rachel Rutherford: By appointment Douglas Schilling: Tuesdays, 3:30 pm to 5:30 pm or by appointment Christopher Onorati: By appointment **Teaching Assistants:** The list of TAs for GAM 200 and their specialties will be posted on the course Moodle. **Class Web Page:** There are multiple locations you will need to go for information and check-ins: - **_Distance.digipen.edu (Moodle)_** for grading. Handouts and other materials will be posted in the GAM200-CSP200-combined Meta Moodle. - **_Microsoft Teams:_** The Files section of your student team’s private channel on Microsoft Teams is where you will submit your weekly work logs and check-in logs, milestone reports, playtests, code reports, and Team Milestone slides. Please note that you may also be required to submit work via Moodle. - **_Team Project Resources (on MS Teams)_** is a public Teams site with info about Team Registration and lab seating policies. Info on publishing on Game Gallery, Steam, and Itch.io can also be found here. Info about lab seating for teams is located here as well. _This site also includes_ the Allowed Software Library List, the font library, and other shared resources. Search for “Team Project Resources” in your Teams channels, or go to this URL: [https://shorturl.at/Vmzvo](https://shorturl.at/Vmzvo) If you cannot access the site, contact IT at [[email protected]](mailto:[email protected]). **Course Description** This course is the first semester of a two-semester project, which will be continued in GAM 250. You will work together on teams of three or more to create a simple real-time two-dimensional game or simulation. Techniques are explored for working effectively on a team, following a development process, using discipline-based best practices, and applying core discipline-based skills to game development. This first semester focuses on pre-production to ensure the technology, tools, and team are ready for full production in the following semester. **Course Objectives and Learning Outcomes** In this course, students will explore multiple aspects of game development, with outcomes in the following areas: - Apply discipline-specific skills and pre-production best practices in a team project. - Understand fundamental team dynamics including team formation, collaboration, and problem-solving. - Understand the iterative pre-production process for the prototyping of game design. - Understand conflict resolution and negotiation techniques within a team. - Practice communication techniques through presentations, team interactions, and giving and receiving feedback. - Practice project management techniques include scope and milestone planning, task definition, prioritization, and task tracking among a team. **Required Hardware and Software** - Laptop with college-required minimum specifications (min spec). Some lab PCs will be available when team space is assigned. - Unity and Unreal (only use the approved versions that is on campus PCs and in the labs. These are intended for optional prototyping only) - Visual Studio 2022 - Gimp/Krita/Inkscape (freeware) for designers and programmers - GitHub Classroom for source control - Microsoft Teams - Clickup, Trello, Excel, or other task tracking software - Internet connection **Textbooks** There are no required books for this class. **References** You can find the current list of recommended resources on the **Team Project Resources** site on MS Teams. Please note that the “Allowed Software Libraries” list is especially valuable and is located on **Team Project Resources.** **Academic Activity Documentation and Census** DigiPen Institute of Technology is a non-attendance taking institution. Federal regulations require our institute to document that each student has begun attendance in all enrolled courses. This documentation will be recorded in the course website, in Moodle.  Every course has required academic activities.  Required academic activities during the first two weeks will be used to form a census. A student with no recorded academic activity in a course at the end of the second week of the semester will be withdrawn from the course.   Note: Each student will have at least two (2) opportunities to provide documented proof of activity, but one (1) instance of academic activity is sufficient to prove academic activity and avoid withdrawal. Students who cannot submit any academic activity in the first two weeks of class cannot be excused by the instructor or the Office of Disability Support Services. Those students will have to work with the Office of the Registrar regarding their automatic withdrawal from the course.  **Academic Integrity Policy** Cheating, or academic dishonesty in any form, will not be tolerated in this course. Penalties for cheating may include receiving a zero on an assignment, or a failing grade in the course, or even expulsion from DigiPen. For further details, please consult the _DigiPen Academic Integrity Policy_. Note that in this team project class, working directly with your teammates, or even with other teams, is not cheating (and is highly encouraged). However, each student is required to accurately inform the instructors of the exact work they personally did on the project—any deception is cheating and will be punished accordingly. **Academic Support Lab** The Academic Support Lab offers free drop-in tutoring for specific 100 and 200 level courses. **Disability Support Services** If students have disabilities and will need formal accommodations in order to fully participate or effectively demonstrate learning in this class, they should contact the Disability Support Services Office at [(425) 629-5015](mailto:(425)%20629-5015) or [[email protected]](mailto:[email protected]). The DSS Office welcomes the opportunity to meet with students to discuss how the accommodation will be implemented. Also, if you may need assistance in the event of an evacuation, please let the instructor know. **Religious Accommodation** DigiPen Institute of Technology provides reasonable accommodations to students who may be absent from activities or incur significant hardship due to religious holidays or observances. These holidays or observances must be part of a religious denomination, church, or religious organization, and the course instructor must be notified in writing during the first two weeks of the course. The institute’s policy for grievances is published in the course catalog. **Last Day to Withdraw** To withdraw from a course, it is not sufficient simply to stop attending class or to inform the instructor. In accordance with the policy, contact your advisor or the Registrar to begin the withdrawal process. The last day for withdrawal from this course is cited in the official catalog. **Mechanisms and Procedures** There are a variety of procedures and mechanisms used in this class to make it run as smoothly as possible. Make sure you read each of these sections thoroughly so that you understand what the instructors expect. **In Class Use of Monitors and Devices** For lectures, unless you are using the computer to take notes, all screens and devices must be turned off. Working on homework or other work that relates to projects in other classes is not allowed. If you are on your phone or social media for any reason other than work that is specifically related to what is taking place in the lecture, you will be asked to leave and may incur a grade penalty. **Instructor Questions and Meetings** You will undoubtedly have many questions for the instructors and will often wish to have individual or team meetings as well. To make this work efficiently, you must email any questions (about any topics you wish) or meeting requests to one of the instructors. Make sure you start the subject of the email with “GAM 200”. In addition to asking questions through email, if you talk with an instructor via voice chat or in person (whether in class or otherwise) and there is some follow-up action the instructor has agreed to perform, you must email that instructor with a reminder. If you don’t send a follow-up email, whatever you talked about may be forgotten and not followed up on (regardless of what the instructor said at the time). Making follow-up emails a habit is excellent practice for the real-world of working with busy bosses, producers, executives, etc. **Assessment** **Grading Policy** GAM 200 and GAM 250 are Pass/No Pass courses. You will have a list of required personal contributions to the team and project, which includes weekly work logs, milestone reports, check-ins to the team source code repository, and other requirements. Each team has a list of required team contributions, which will be in the final rubric for the semester. The course rubrics will be posted on the course Moodle and in each team’s private MS Teams site. **Penalty Points System for Pass/No Pass** You begin with the presumption of a Passing grade in the course. If you acquire 26 or more Penalty Points, that will become a No Pass grade. Points of 25 or less still result in a Pass grade and otherwise have no effect on your grade. Please note that some points apply to both you and your team, especially relating to end of semester deadlines and requirements. | | | | |---|---|---| |**Penalty Point Types**|**Personal Penalties Points**|**Penalty Points for all Team Members**| |Failure to check in code or content into the build every week as of end of Week 2 (includes code, ASF lists, or other content). This is a permanent penalty and will not be removed if the student checks in after the deadline.|5|-| |Failure to satisfy milestone requirement: lines of code. This and the playtesting requirement cap at 10 points per each of the milestones. This is required in each of the three milestones.|10|| |Failure to satisfy milestone requirement: playtesting another team’s game. This and the Lines of Code requirement cap at 10 points per each of the milestones. This is required in each of the three milestones.|10|| |Missing weekly work log (until corrected)|10|-| |Below target weekly hours (8 hours unless excused)|3|-| |No Best Practices completed in the current milestone. Best Practices are required in each of the three milestones.|3|-| |No final build submitted. This penalty scales based on build submission date: Friday end of day is no penalty, Saturday end of day is -5, Sunday is -10, Monday is -26||5, 10, 26| |Build resubmission required at end of semester due to missing or incomplete Submission tab requirements. This penalty applies to each resubmission.||5| |Entire team misses a milestone meeting (until completed)||26| |Team is not using source control (until corrected)||26| |Missing or late to team milestone presentation (unless excused)|5|| |Not on a team (weekly penalty, only begins to apply after the Sunday night at end of the second week of not being on a team)|7|-| **Project Score** The Project Score is Pass/No Pass, with detailed checklists for project requirements. In addition, teams can earn “kudos”, which are recognition by the faculty that the team has gone above and beyond the basic requirements. Kudos do not affect the team or individual grade. The M1 Engine and Prototype Proof Milestone Presentation rubric is used to assess the team’s progress at the first milestone of the semester but does not apply to your team’s final grade. The M1 Engine and Prototype Proof Milestone Presentation rubric and M3 Pre-Production Milestone Project Submission rubric each are used to score that particular milestone. These will be stored in the Files section of your team’s MS Teams folder. You should read all these rubrics in advance. Do not wait until the milestone is actually due. **Attendance** Attendance sign-in is not required by our college. However, every student must submit GAM weekly work logs to their team’s Files site on Microsoft Teams by the Sunday evening deadline, as part of the regular weekly participation in the course. Student Affairs will be notified for students who fail to submit weekly work logs for two weeks, and this may have an impact on your enrollment at DigiPen or your Financial Aid. For any absence-related questions including a known upcoming absence of more than one lecture or lab session, please email Ellen Beeman at [email protected]. Do NOT email or cc instructors other than Ellen Beeman regarding absences. **Late Policy** Assignments that are turned in late will impact the student’s personal Pass/No Pass status in the course. Late penalties for the final team project of a semester will impact all students on that team. **Good Faith Petition** In some cases, you may find that you are on a team that may end up with a No Pass project grade due to circumstances that are outside of your reasonable control. If you believe you are, or might be, in this situation, you can petition Ellen Beeman ([[email protected]](mailto:[email protected])) and cc other instructors at any time during the final milestone (or before the end of finals week after you receive your project grade). For your petition to be accepted, the instructors must be certain that you have done everything reasonable to get the project to passing and may impose some additional requirements on you. If your petition is accepted, your project grade will be set to a Pass. Note that this is only allowed if you do not have Penalty Points from course requirements that would result in a No Pass grade. For more info or to request a Good Faith Petition, please contact instructor Ellen Beeman ([[email protected]](mailto:[email protected])) as soon as possible. **Team Guidelines** **Source Control** Every team is responsible for setting up and managing source control for their project. You will be using GitHub Classroom repositories for this course. Please note that personal or public-facing GitHub repos are never allowed. Use of source control is a course requirement. Failure to use DigiPen source control will result in a No Passing grade for the entire team. Instructions will be provided in lecture as to how to sign up for your team’s GitHub repository. Important: As of Week 2, you are required to check in code or content to the team’s source repository at least once every week. Penalty Points will apply if you do not check in code or content at least once every week. **Current Build Maintenance** Every team is responsible for maintaining a current working executable build of their game for their project. This build should be able to be run at any time. Keep a current working executable build in the appropriate folder in your Teams site and do not delete the previous working build until you know you have a viable build to replace it. **Team Names** Students can generally select any team name they wish, so long as it would be appropriate for an E-10 rated game. Please be aware that this team name will be displayed on public sites, potentially including Steam and Itch.io, in addition to listed on your resume and portfolio website, so please choose a name that is professionally appropriate. Note that using an inappropriate team name will result in an automatic No Pass grade for the class, even if the instructors do not initially catch the hidden meaning in your team’s name because they are not as aware of current pop culture or perhaps different cultural/linguistic meanings. **Team Size Requirements** GAM 200 teams must have at least three team members who are actively enrolled in the GAM 200 class. If you do not have three team members at any point during the semester, your team is automatically disbanded, and you must find a new team. Teams must have at least three students enrolled in GAM 200 and officially receiving course credit for the project. The instructors recommend having at least four team members. Volunteer team members who are not enrolled in GAM 200 are allowed on teams **only with written instructor approval**. Even if this person has previously volunteered for your team, you must still secure instructor approval. Please be aware that due to past issues with volunteers, your request is likely to be declined. If someone wishes to volunteer for your team, please ask them to contact Ellen Beeman as soon as possible at [[email protected]](mailto:[email protected]). **Changing Teams** You can leave, be requested to leave, or change teams within certain windows. Teams may only release a teammate in weeks 1 to 6, and weeks 9 and 10, and only in other weeks with written instructor approval. If you wish to voluntarily change teams outside of those weeks, you must have written instructor approval. If a team wishes to hold a vote on releasing a team member, the producer or another teammate must email all of the instructors as soon as possible, and this email must be sent at least one full week before the closing of a team roster change window. The email to the instructors must include why the team wishes to release this teammate. The instructors will advise the affected student(s) of the issue and then conduct an anonymous vote with the team. A team can ask for a release vote on one or two team members but requesting a vote for releasing more than two team members is only with instructor approval. Seceding or resigning from a team is allowed, but this must also be done with at least one week's notice to the instructors and the team before the conclusion of the team roster change timeframes. If there are other conditions that apply that would merit the immediate removal of a teammate (such as a Title IX incident), please contact the instructors immediately, regardless of the team roster change windows. Students who leave their team during the last week of a team roster change window may request additional time to find a new team and should contact the instructors immediately. If you do not stay on the same team for the entire semester, your grade will be based on the team you end up with at the end of the semester. If you only left the first team after half of the semester was completed, then your grade will be based on the average of the two teams’ project scores. If a student leaves a team, they are entitled to access to the entire team’s repository up to that point in the semester. Teams cannot lock out a former teammate without receiving actual notice that the former teammate has already copied the repository (that will result in an Academic Integrity Violation). A teammate who does any intentional damage to a current or former team’s repository will also be subject to Academic Integrity Violation. The instructors reserve the right to remove a student from a specific team or to assign them to a new team. **Project Guidelines** **Rules and Restrictions for GAM 200 and GAM 250** This is a 2D game course only. Your entire game must fit within a 5 to 10-minute gameplay window, beginning to end, including tutorials. This means you need to be very attentive to a core game loop and the visuals that provide engaging gameplay within a condensed play timeline. All teams are required to create a custom 2D engine. Additional info about the 2D custom engine game requirements is in the Pre-Production Rubric. **Creativity and Game Design GAM 200 and GAM 250** Within the constraints of course, you are encouraged to come up with creative and engaging game designs of your own team’s choice. The instructors will advise you as to the feasibility of your game design. Only in the likelihood that an entire team is going to fail the course will the instructors require changes to your creative game design. **Technical Restrictions** All teams must code everything themselves in C++ using only fairly low-level libraries (e.g. GDI, DirectX, OpenGL, OpenAL, FMOD low-level, STL, SDL, and XML parsers). Allowed software libraries are documented in the _Allowed Software Libraries List_ on the Project Teams Resources site on Teams. If you want to use anything else, you must receive written instructor approval in advance. You can use scripting languages (Lua, Python, C#, etc.) that you embed in your C++ engine. Physics, AI, and networking software libraries are not allowed. For review and approval of new software libraries, you must email Ellen Beeman (Ellen.Beeman) and Christopher Onorati (Onorati.C) with a link to the library and the type of software license. Your game cannot be 3D or networked. If your game is partially 3D in some way and you are not sure whether that counts, check with your instructor to see if it is allowed. **Game Content** DigiPen games must be able to get an EC, E, or E10+ ESRB rating. Anything that would require a T (13+) rating requires permission from an Assistant Dean. M (17+) and AO (18+) ratings are not allowed under any circumstances. For more info about ESRB ratings, please go to [https://www.esrb.org/ratings/ratings_guide.aspx](https://www.esrb.org/ratings/ratings_guide.aspx) - _Violence:_ only cartoon/fantasy violence is allowed—no overt violence, gore, body parts, realistic blood, dismemberment or burning of sentient beings or creatures, extreme or suggestive sound effects, etc. - _Social Issues:_ any references to real-world politics or alcohol/tobacco/drugs require approval. - _Sexual Content:_ nudity, sex, strongly suggestive sexual themes or references are not allowed. - _Language:_ profanity and disparaging/stereotyping of race/gender/culture/disability are not allowed. No content that is offensive in regard to race, color, religion, sex or sexual orientation, and disability. All art and audio must either be created by a current DigiPen student/instructor or be from the DigiPen approved art and audio libraries. You cannot use your friends, family members, public domain material, or any other students who are NOT enrolled in sophomore GAM project classes for any game code or content without written instructor permission. You are encouraged to use either abstract art or library artwork from the website Kenney.NL. Please note that if you use Kenney.NL assets, you need to be sure that the asset set is everything you need for your planned game. If it is not, you may need to personally create additional assets, which is not recommended. If you have questions about whether your game will qualify as EC, E, or E10+, contact Ellen Beeman and Christopher Onorati. **Game Publishing and Competitions** All student teams are encouraged to submit their game at the conclusion of GAM 250 to the DigiPen IP Committee to be published on DigiPen’s games website, Steam, and/or Itch.io. There are additional requirements for games to be approved for submission to Steam and Itch.io. DigiPen games can only be submitted to competitions by the DigiPen faculty—you cannot enter them yourself. If you think you have a game good enough to be entered into competitions (or that is the goal you are aiming for), make sure you inform your instructors as soon as possible, as they can give you advice directly targeted at making your game better for competitions. **Milestones** There are 4 important Milestones in GAM 200 that affect the entire team. - Week 1: Team Formation - Weeks 2 to 4 M0: “Kickoff” planning meetings with instructors and TAs - Week 5 M1: Engine and Prototype Proof Presentation and Milestone, each team presents to the entire class - Weeks 9-10 M2: Pre-Grading Milestone meeting with instructors and TAs - Week 14 M3: Pre-Production Milestone and game submission Each Milestone is handled differently. You are responsible for knowing what is required at each Milestone. **Milestone M0: Kickoff meetings** M0 is a planning meeting milestone. This is a required meeting with the entire team and instructors and TAs to review the team’s project. Your team producer will schedule this meeting for the team. **Milestone M1: Presentation** M1 is a formal Engine and Prototype Proof team presentation where you rehearse and present your game concept and engine according to strict guidelines to the faculty and TAs for feedback. The Engine/Concept Presentation guidelines will be provided to your team. You will have 10-12 minutes for presenting your project. Your score for the content of the presentation will not affect your final grade for the semester. This is entirely a checkpoint for your team’s progress. However, individual points penalties will be assessed if you fail to show up or prepare for the presentation, unless you have instructor approval for an exception. **Milestone M2: Pre-grading milestone** M2 is a mandatory, pre-scheduled Pre-Grading session with the faculty and TAs followed by feedback. This is a private team chat with instructors. You do not need to dress up for this meeting, but you MUST bring in a) a working build and b) a copy of the Pre-Production Rubric which you have ALREADY pre-filled-in to accurately represent your current status. **Pre-Grading is required**. This is an opportunity to find out exactly where you are and what you can do to improve your grade. Be prepared for individuals not on your team to play your prototype or game build. You will be scored against the semester’s final M3 Pre-Production rubric. Students tend to find this M2 Pre-Grading to be an enormous stress-reliever, as they leave with a clear explicit list of exactly what must be done to Pass, several weeks before the game is actually due. Additional optional pre-grading sessions will continue — and are highly recommended! — during Weeks 11 through 13. You will have an opportunity in these weeks to have your materials re-checked by the instructors and TAs. Please plan on scheduling at least two pre-grading sessions prior to the end of the semester. Please note that ALL TEAMS must have at least one Pre-Grading session with a TA or Instructor for the Submission tab requirements. Failure to do so is a No Pass for the entire team. Please see the following section (“Pre-Grading”) for additional information. **Milestone M3: Game Submission** M3 is the final milestone, in which you will submit your Pre-Production game and supporting materials, and your final reports. **Pre-Grading** Pre-grading is an opportunity to go through your project together with your instructors, grade the game based on its current, _demonstrable_ status, and receive advice and specific goals/requirements for achieving your team’s Pass grade on the project. This reduces stress for the students, gives them specific goals to work toward, and speeds up the final grading process. The first Pre-Grading session is a mandatory, pre-scheduled meeting between the team and the instructors in week 9 or 10. This session usually takes 60 minutes and all team members are expected to participate. Additional Pre-Grading sessions can be scheduled with individual instructors during weeks 11 through 14. While the first Pre-Grading session is mandatory, additional sessions are optional but strongly recommended. These sessions usually take 30 minutes and only one or two team members are expected to participate. Instructions for scheduling additional sessions with the instructors will be provided. The instructors for pre-grading sessions are: - Design: Ellen Beeman, Christopher Onorati - Tech: Technical requirements, Engine, Game Editor, Pipeline and Tools: Doug Schilling, Ellen Beeman - Submission (Submission tab requirements): TAs and Christopher Onorati Anything in the rubric spreadsheet that is already pre-graded as “completed’ will not be graded again **unless the project is severely broken or untestable.** Only those items that were incomplete or needed work will be looked at during final grading. All items in the latter category MUST be accompanied by student notes in the Comments column so the professor knows exactly what was updated. **If you do not participate in at least one pre-grading for your game in the Week 9 and Week 10 mandatory pre-grading sessions, the entire team will receive a No Pass grade.** **Student Course Requirements** **Expected Hours of Work for This Course** At minimum, you should be working at least eight hours a week on your project, including the Friday lab time but not lecture time. If possible, schedule a three-hour block when you can work with your teammates. Not more than four hours each week can be spent in meetings, doing research, reviewing external assets, or other non-hands-on work. Your hands-on work includes anything that improves your game by the application and iteration of your skills. All students should read the “Programming Roles and Responsibilities” document on the course Moodle and focus on two or more features/specialties such as Engine Programmer, Gameplay Programmer, Graphics, Physics, Audio, etc. **Weekly Work Logs** Each week, every student in the class must write an individual weekly task log. This report should list tasks and the approximate hours spent on each task. It is strongly recommended to update a work log file **every day** you work on GAM tasks. You must keep this information current in your team’s source control or another secure method that is backed up such as an online notes app, rather than writing this week log only at the end of each week. Each missing work log will result in 10 Penalty Points being applied, until corrected. These Weekly Work Logs must be submitted by each student to the team’s MS Team Files folder. This report must be a detailed breakdown of the work you have personally created so far on the project. You will be responsible for the tasks that you are assigned by the team and agree to take on. Any extra work you complete should be included as well. If you take on other responsibilities beyond the work you are responsible for, be sure to note them. You will also include what check-ins you completed each week to your team’s source control repository. Every student must also spend a significant amount of time (at least two hours) for every milestone performing a “best practice” of some kind for the project. See below for additional info on best practices. Be sure to note this as a “best practice” in your weekly work log. The weekly work log should include at least one complete sentence for each task completed, and the estimated hours for that task. For tasks of more than two hours, you must break it down into multiple tasks to help your instructors assess your work. Examples: - Debugged physics code, specifically looking for performance issues (1 hour) - Asked for Help from TA, FirstName LastName, for help on physics issues (1 hour) **Weekly Source Control Check-Ins** Starting in Week 2 and continuing until the end of Week 14, you are required to make at least one check-in every week to your team’s source control repository. This check-in can be code, game content, or assets. Failure to do so will incur Penalty Points. You must list info about your check-ins in your Weekly Work Logs. For questions about this course requirement, email Ellen Beeman at [[email protected]](mailto:[email protected]). **Individual Milestone Reports** This report will contain a literal copy-and-paste compilation of each team member’s individual weekly worklogs, playtesting reports, source repository check-in information, and best practices. The milestone report template will be provided in your team’s MS Teams private site. In addition, the milestone deadline is when playtest reports and code reports are due. **Team Info PowerPoint** Each team will need to maintain a “Team Info” PowerPoint with a list of the current team members and a team photo or photos of individual teammates. This is required for the M0 Kickoff meeting and must be updated any time there is a team roster change. Additional info on this requirement will be discussed in the Producers meeting, and a PowerPoint template will be provided in the Files tab of your team’s channel on MS Teams. **“Requires Improvement” Grade** For your first Individual Milestone Work Report, if you have not completed the course requirements for that specific milestone, such as required code count or playtesting, or you have not turned in your first milestone report, you will receive a “Requires Improvement” grade and details as to what must be corrected. If you receive a “Requires Improvement” notification, you must complete all of the Milestone requirements at least one week prior to the last course withdraw date (Week 8). If you do not meet this deadline, you will be given a No Pass grade for the entire course, and the strong recommendation that you withdraw from the course by the course withdrawal deadline. If you fail to meet this requirement, you will not be allowed to continue working with any sophomore student team as a team member or volunteer. **Mid-Term Grade** The Mid-term grade is based on your first individual milestone report only. **Best Practices** You must also spend a significant amount of time (at least two hours) each milestone performing at least one Best Practice for the project. These must be clearly labelled as part of your milestone report and in your individual weekly work logs. Completing one Best Practice is a requirement… completing additional ones is recommended, as these Best Practices are intended to help you learn how to be a better designer or programmer. **Best Practices for All:** Asking for Help, Offering Help, Team-On-One participation, pairs programming, code reviews **Best Practices for Programmers:** Build automation, build verification testing, test automation, unit testing, code reviews, pairs programming, implementing data analytics that write data locally or to a server. You can also do detailed performance testing, where you are evaluating where you are using up the most resources or CPU cycles, testing on different PCs, etc. To earn credit for the best practice, you must describe what you did in at least one sentence. Only listing the best practice item will result in a required resubmission and potentially Penalty Points. Please ask your instructors if you would like to do a Best Practice other than the ones listed above, to determine whether that will count towards this course requirement. **Code Requirements** **AI Policy** The use of all resources and technologies, including AI-based tools, is allowed to the extent that it does not subvert the learning outcomes or violate the stated policies of this course. You may use AI tools to assist with understanding syntax or clarifying concepts. However, all work submitted must be your own. If you use an AI tool for guidance, you must clearly document how it assisted you in your code or design. **Code Reports** As part of each milestone report, every team must submit a team code report, which will include details about the code each CS student has written. This report will be submitted with the Individual Milestone Work Report on the team’s Files folder. Please follow the “Team Code Contribution Report” instructions provided in your individual team’s “Code Reports” folder in Microsoft Teams. This report must be a detailed breakdown of the lines of code each student has personally written so far on the project (this is cumulative, not just what was done for the one milestone). You must have contributed at least 400 lines of code by Milestone M1 report submission, at least 800 lines of code by Milestone M2 report submission, and at least 1200 lines of code by the final Milestone M3. Please note that this is considered a very minimum requirement. As a programming student, we expect you to exceed this minimum. (For context: in your CS 230 course, you wrote 2000+ lines of code). Code that is not C++ or shader code counts only 75% as much, and you cannot claim more than 1000 lines of code that is not C++ or shader (such as scripting language) as your code count for this semester. Example: 1000 lines of LUA would count as 750 lines towards this requirement. JSON, XML, and other data file formats do not count towards your code count at all. The lines per milestone does not include comments, header files, blank lines, etc. It also does not include cut-and-paste code that should really be in functions, code that is just setting variable values instead of reading them from files, etc. Just padding your line count by writing bad code does not meet this requirement. Make sure that multiple team members do not claim the same code (or clearly mark code that multiple team members worked on). The code you write must also be of sufficient difficulty and complexity (and must work to a decent degree). In general, writing all the graphics code, all of an art pipeline, all of a level editor, all the physics code, all the AI/game logic, all the code of a complex dynamic audio system, or all the core engine code is sufficiently difficult/complex. Most other coding will not qualify, although the instructor can grant exceptions. If you have substantial deprecated code in any milestone, please contact Doug Schilling ([[email protected]](mailto:[email protected])) directly to discuss whether this can count towards your required code count. Please note that a maximum of 250 LOC can be claimed as deprecated code. Code written after your project is submitted for final grading at the end of the semester will not count towards code count. Only code that is included in your team’s source control archive (submitted with your game project at the end of the semester) will be considered towards your code count. CS students who are below the expected code contribution at M1 (end of Week 5) will have a No Pass grade status applied to their midterm grade. This grade penalty can be removed by completing the expected code contribution and reporting it to the instructors **_before_** Week 8. CS students who are below the expected code contribution at M3 (Week 14) will have a grade penalty applied to their final grade, which may result in a No Pass grade in the course. **Playtest Reports** As part of their work in GAM 200, you must do a playtest of another team’s game at least once each milestone for each of the three milestones. You must test a different game each milestone (although additional testing of prior games is allowed in addition). You must write a brief testing report about the testing you have done, submit this to their team’s Files folder and also send it to the team of the game that was tested. Your report must detail what team and game you tested, when you tested, how long each session was, and written observations you personally made, and any conclusions you personally drew. **Optional Additional Resources for Students** **Team-On-Ones and Team Chats** Your team may also contact Rachel Rutherford ([[email protected]](mailto:[email protected]) or via Teams Chat) to schedule a private personal team intensive session. These are entirely optional, as they take a chunk of time. However, they are usually very beneficial, especially if your team is just getting going, is feeling slow or unsure, wants to work with more ease and with less stress, wants to resolve known pain points, has low morale or burnout, or is just generally unclear about what to do next. These are a team debugging and optimization tool, which unblock and level up your team. There are two options: - The 4-hour Team-On-One, which is more thorough and more powerful, but is only available on weekends - The 2-hour Team Chat which is shorter, more flexible, and can take place during the week, in Friday labs if Newton is available, or on weekends Chat with Rachel directly to accommodate needs, work schedules, people’s availability, etc. If your team is potentially interested but wants to know more before deciding whether to request a Team-On-One or a Team Chat, you may also contact Rachel on Teams Chat to schedule a time during lab for her to come meet with your team in person and answer any questions. **Outline and Tentative Dates** This class will roughly follow the outline below, although the order and/or content of the lectures are subject to change. The milestones will only be changed in extreme and unexpected circumstances (and will never be moved earlier). Except on milestone weeks, all labs are reserved for meeting with your team, working on your project, and meeting with the instructors. **All milestone reports, code reports, playtest reports, and weekly logs are due by midnight Sunday of the listed week.** **Week 1 (9/2 – 9/8)** - **(No Monday lecture due to Labor Day holiday)** - 1st Lecture (ALL): “How To GAM 200”: Course requirements, forming teams, best practices- PLATO - Labs: Team formation meetings, helping students find and create teams **Week 2 (9/9–9/15) M0: PLANNING MILESTONE** - 1st Lecture: Source Control, Team Roles - PLATO - 2nd Lecture: Engine Basics/Graphics - PLATO - Labs: M0 meetings begin with teams, instructors, and TAs **Week 3 (9/16–9/22) M0: PLANNING MILESTONE** - 1st Lecture: Serialization/Data-Driven Architecture - PLATO - 2nd Lecture: Dear IMGUI - PLATO - Labs: M0 meetings continue with teams, instructors, and TAs - Friday 5:00-5:50 Supplemental Lecture: Simple Pro Tips for Presentations (by Rachel Rutherford) - MICHELANGELO **Week 4 (9/23–9/29) M0: PLANNING MILESTONE** - 1st Lecture: UI Implementation - PLATO - 2nd Lecture: Scope and ABC Priorities - PLATO - Labs: M0 meetings continue with teams, instructors, and TAs **Week 5 (9/30–10/6) M1: ENGINE AND PROTOTYPE PROOF MILESTONE** - Team presentation sessions will take place instead of lectures and lab, but weekly work logs and repo check-ins are still required - Each team makes the engine and prototype proof presentation to the entire class - **DUE:** Individual Milestone #1 Report, code report, and playtest reports are due at midnight on Sunday **Week 6 (10/7–10/13)** - 1st Lecture: Code Reviews – PLATO - 2nd Lecture: Playtesting (live demo) - PLATO - **DEADLINE**: Last week to change teams, until Week 9 and 10. If you do make team changes, you must email instructors by Sunday midnight. **Week 7 (10/14–10/20)** **(No Monday lecture due to Indigenous Peoples Day/Columbus Day holiday)** - 1st Lecture: Teams! - PLATO **Week 8 (10/21–10/27)** - 1st Lecture: Intellectual Property - PLATO - 2nd Lecture: Rubric Review - PLATO **Week 9 (10/28–11/3) M2: PRE-GRADING MILESTONE** - Pre-grading sessions will take place instead of lectures and lab, but weekly work logs and weekly repo check-ins are still required - Each team participates in the prototype pre-grading in private sessions scheduled with instructors - **DUE:** Milestone #3 report, code report, and playtest reports due at midnight on Sunday **Week 10 (11/4–11/10) PRE-GRADING MILESTONE** - Pre-grading sessions will take place instead of lectures and lab, but weekly work logs and weekly repo check-ins are still required - Each team participates in the prototype pre-grading in private sessions scheduled with instructors **Week 11 (11/11–11/17)** **(Monday, 11/11 is the Veterans Day holiday)** - 1st Lecture: Imposter Syndrome lecture by Jeremy Holcomb - PLATO **Week 12 (11/18–11/24)** - 1st Lecture: Bug Tracking and Prioritization - PLATO - 2nd Lecture: Live demo to entire class by selected teams – PLATO - Labs: Live demo to entire class by selected teams, as needed – PLATO **Week 13 (11/25–12/1)** **(No Friday labs for Thanksgiving Holiday)** - 1st Lecture: Live demo to entire class by selected teams - PLATO - 2nd Lecture: How to Ship - PLATO **Week 14 (12/2–12/8) M3: PRE-PRODUCTION MILESTONE** - No lectures, but weekly work logs are still required. Grading Q&A and pre-grading sessions will occur during lectures and lab. - **DUE:** Game submission is due at midnight on Friday - **DUE:** Milestone #3 report, code report, and playtest reports due at midnight on Sunday **Week 15 (12/9 – 12/15) – Finals Week** **(No lectures or labs)** - Instructors will complete final game and report grading during this week - Game resubmissions may be required in this week