Final Project

Games

Team #1: R.U.N

Alex Clark: Artist
Jimmiy Madio: Artist, Trello Manager
Nicholas Molina: Lead Programmer

Team #2: Run, Hide, Fight

Alex Weitzner: Team Lead, Programmer, User Interface, Scrum Master
Jarod Ossofs: Programmer
Clay Stewart: Artist

Team #3: Road to Recolory

Alex Hartman: Creative Director, Designer, Programmer
Andrew Fulop: Designer, Programmer, Project Manager
Chad Reilly: Art Director, PR Director, Designer

Boss Crunch

Sean Murphy: Game Lead, Lead Gameplay/Level Designer, Lead Programmer

Freelancers

Freelancing Rules of Engagement

Teams Responsibilities
  • Each team must provide a list of at least 5 freelance tasks on your Trello page by the time class starts every Monday. Each week without tasks listed on time, the team loses a point on their final shared grade.
  • Freelance tasks must be clearly labelled on Trello. Please provide the minimum time required to complete each task, anything needed to complete the task, and specify where to post completed work. Pleas try to design tasks to be two weeks long. If they only work as shorter tasks, that's fine.
  • The team may: accept the work, reject the work, or request it to be redone. This decision must be made before class starts on Monday.
  • Other things:
    • Invite all freelancers to your Trello page.
    • By posting a freelance task, you are agreeing that it may be completed by any freelancer.
    • One of those tasks can always be a playtest.
Freelancers Responsibilities
  • Freelancers must accept new freelance tasks by Monday midnight. If you do not accept one by then, you are expected to work on improving a previous assignment of your own.
    To accept a task, please do the following:
    • Let the team know you are taking on the task. Ask if you need to meet prior to completing the task to get direction.
    • Assign yourself the task on the team's Trello (drag your name onto the card to claim it).
    • Make a note in your Trello that you are taking on the task.
  • Freelancers must keep a personal Trello page, where you have list of cards for each week and document all your work. The first card on the left should state what project you are currently working on.
  • Tasks must be completed by Sunday at midnight. If nothing is posted by then, it’s a zero.
  • If a meeting is required as a part of the task and you do not attend, it's a zero on your weekly progress.
  • The 50% rule: at least half of your weekly contributions must be freelance tasks. The other portion can be improvements on previous projects of your choice. If you do less than half, you will lose 50pts on all biweekly individual grades w/o a freelance task.

Team Formation

In all previous iterations of GDD410 and GDD411, there has been a requirement: no group in 410 could be the same as 411 unless a team decided to work on the same project. Even then, continuing teams must be open to adding members, dependent on class composition.

I'm open to any type of functional team formation strategy, however, in order to have a working class, we must avoid the following:

  • Completely unbalanced teams (i.e. a team of all artists or coders).
  • Conversations about team formation where individuals are simply stating their desire to work ONLY with person x,y, and z. If there is no room for compromise, there is no conversation.
  • Group formation conversations where students are disrespectful of one another.
  • Teams of six or more.

I'm open to other types of arrangements, however, the whole class must agree to it and all its implications. Here are some other options:

  • Freelancers (where an individual works on multiple teams — note: it can be challenging organizationally)
  • Individuals working as a part of a team where some members are not in our class.

If the class can form teams naturally that avoid all of the scenarios described above, then great. If not, we may have to introduce some randomness in team formation to keep things fair for everyone.

Guidelines

Team Makeup
  • Students may pick their own teammates. Teams of three to five students will be allowed to work together without questions asked. (note: to facilitate this, teams must be willing to include additional teammates if asked.
  • Each team should have the following roles identified. Leadership roles must also have additional production roles as well (e.g. UI design, sound design) (note: a team member may take on multiple leadership roles, but will be responsible for all responsibilities listed):
    • Team Lead: Responsible for general leadership of the game's production. Ensure the functioning and well-being of the team. Resolve disputes. If there are team issues, this will be my point of contact.
    • Scrum Lead: Responsible for organizing task lists w/individual team members. Ensure effective communication w/r/t development. Ensure integration.
    • (Consider): Art Lead, Programming Lead, Design Lead.
  • Students are highly encouraged to write up a simple agreement before starting on the project. Consider the potential life of the game outside of the classroom.
Mission Statement
  • All teams should be guided by a clear mission statement. It's OK for that mission statement to change, but you must announce to the class when it's changing.
  • The mission statement will be use both to guide your development and decisions you make as well as how your game will be evaluated.
Design Document
  • Teams will work together on creating one game design document. The document should consist of both written and visual documentation.
Process
  • Students will be required to implement a simplified version of SCRUM, which will entail weekly sprints. Teams may use Trello, Google Documents, or Office365 to organize their process. Other software can be approved upon request.
  • Students will be evaluated on their individual progress which should dovetail with the weekly SCRUM documentation. These grades will consider both the quality and quantity of individual efforts. Students must document their individual contributions on Trello through a weekly completed task list (e.g., artist should share artwork and screenshots, programmers should share tasklists, builds, code, and screenshots).
  • After the first week, there will be a quick deadline for a successful MVP. All teammates must work towards a successful completion of this task. Artists should consider creating paper prototypes when appropriate.
  • Class time will be one of the following formats:
    • Presentations: Every week, teams will present progress. We may consider having one team or overflow presentations the next weekly meeting depending on number of teams.
    • Playtesting/Evaluations: Every other week, we will have a playtest/anonymous eval session. Each student must play all class games (aside from their own). Playtests questions will have a few general questions, with the option to add specific ones as well. These evals will be graded in some way (either as a cumulative eval grade or maybe a part of biweekly individual grades).
    • Development: Every other week, we will have development days. I will check in with each team during this time.
Project Grades

Details forthcoming. Roughly 30-40% will be shared grades, roughly 60-70% will be individual contributions.

  • Weeks 1 and 2 Progress (individual)
  • Weeks 3 and 4 Progress (individual)
  • Midterm Grade (shared)
  • Weeks 5 and 6 Progress (individual)
  • Weeks 7 and 8 Progress (individual)
  • Playtest Grade (individual)
  • Final Grade (shared)