CS/INFO 4152: Advanced Topics in Computer Game Development

Assignment 1
Group Charter

Due: Saturday, February 6th at 11:59 pm

The charter is a document that outlines the your group roles. It also gives us information about organizational issues, like your group meeting time. This helps us send course staff to aid you, and helps us to follow your progress.

The main purpose of this charter is to give you some rules to fall back on should everything fall apart. As a general rule, groups work pretty well in this course. However, there is always one group that falls into problems, and this will give you some protection if you are unfortunate enough to be that group.


Document Format

As part of our attempt to make the charter more formal, we ask that you format your charter as a official looking memo. Memos are popular in industry, and you can find ready made templates for them in Word and LaTeX. Most importantly, a memo has a date, so you can change the date whenever the charter must be changed.

We have made a sample charter for you so that you can see what we are looking for. The memo should be addressed to the course staff, and from the entire group. When you are completing the From: field, you should include both your group name, and the names of everyone on the team. The team name should also be in the Subject: field. Finally, the date of the memo should be whenever you finalized this version of the charter.


Charter Preamble

It is very important that your entire team agrees to the charter before you submit. Reread it carefully once you are finished. Indeed, one of the first things that we want in the charter is an affirmation that every has read the charter and agrees with it.

In addition, each member should discuss with the team the grade the she/he desires. This makes sure that everyone understands the commitment of each team member. This should not be reported to the instructor. However, the charter should state that this has been discussed and understood by all.


Team Roles

The first major section of the charter should list all of the team members and their roles. For each team member we want the following:

  • The member's preferred name
  • The member's preferred contact e-mail
  • The member's role on the team
  • A short, positive-sounding paragraph on the member's skills
  • A bullet-point list of the member's duties

You can see how we formatted this in the sample charter. For the list of bullet points, please pay attention to the writing guidelines for the course. While this document will not be revised in the same way that other documents are, we will reject extremely disorganized charters.

As a reminder, you must fill at least three roles on your team:

Project Leader
This person is in charge of assigning tasks and keeping the group on top of deadlines. They are also responsible for gathering together the information for the bi-weekly reports (though everyone is expected to contribute). This should be someone who can get along with everyone on the team.
Software Lead
This person is in charge of the architecture decisions on the project. They lead the design of the architecture specification, and have final say on all class interfaces. They also assign programming tasks to the other members of the team. This should not be the same person as the Project Leader.
Design Lead
In the case of multiple designers, this is the person who sets the visual aesthetic of the game. They have final say on the artistic style of the game, and the other designers are expected to conform to this style.

Any other roles (Audio Lead, Junior Programmer) are up to you. No matter what the roles are, all students will present and write equally during the term.

You might not be sure about all of the responsibilities that everyone should have. The sample charter reads like one that has been written half-way through the course, once everyone has figured out the best way that they can serve the team. This is okay; you are allowed (and expected) to make changes to the charter later on. Right now, just make a good-faith attempt to assign roles to everyone on the team. It is okay if someone has a single responsibility like "Will complete any programming task assigned to him".


Team Coordination

The next section should give us some information about how your team is going to coordinate its actions all semester long. While you may think of other things that you want to specify, we expect the following information at a minimum.

Meeting Time

Your group is expected to have at least one official meeting one hour a week. This is your "office hours;" we will come to you instead of you coming to us. For that reason, we need both the time and the location so that we can find you if necessary. We prefer prefer times before 8pm, and close to central campus.

If you are going to meet more than once a week that is okay. Please add this to the charter as well. However, you should only write down the times for regular weekly meetings. Do not include ad-hoc meetings.

Minutes

During the official meetings, someone needs to write down what was discussed at the meeting, and what (general) tasks were assigned to each person. Where are these minutes stored? Are they sent in an e-mail? Are they stored in a Google Doc? Let us know.

Communication

Tell us what you plan to use as your main mode of group communication. E-mail? Twitter? Google Hangout? More importantly, what is the expected etiquette for this communication? For example, in the sample charter, we spell out some basic rules for using e-mail. We specify whether everyone is expected to respond, and when they must respond by. This gives us an official way to determine when someone has "stopped communicating" with the rest of the group and should be reported to the instructors.

File Sharing

Everyone is expected to use GitHub to manage source code this semester. If you do not have a GitHub repository, we will assign you one. However, GitHub is not ideal for the artists and designers. If they are going to use something else (e.g. DropBox, Google Drive), tell us here.


Conflict Resolution

The last section is where you spell out how you will deal with conflicts in the group. If you are unsure of what to write here, we strongly recommend that you contact Traci Nathans-Kelly, as she has a lot of experience with this part of team charters. Historically, there are two types of conflicts in this course. There are creative conflicts, where team members cannot agree how the game should be designed. There are also problems when a team member misses a deadline or cannot complete the tasks assigned to him or her.

Creative Conflicts

In dealing with creative conflicts, there are two popular choices. One is to assign each team member "ownership" of a specific part of the game, and give that person final say for any decisions that have to do with that part. This is what we have done in the sample charter. This choice makes decision making very efficient. However, it can make it so that other team members feel like they do not have a real voice in the game design.

The other option is to go full democratic, and vote on decisions. This is fine, but if you do this, your charter must spell out the rules for putting something up for a vote, for counting the votes, and for recording the votes. We find that the groups that run into trouble are always those that take a democratic approach but do not have established rules for voting.

Missed Deadlines

Missed deadlines are very serious. If someone on the group is regularly missing deadlines without an excuse, we want to hear about it in the two-week reports. This is exactly the information that we will use to adjust individual grades at the end of the semester.

However we find that unless there is some immediate "punishment", the team member is unlikely to improve in the future. The individual grade is not assigned until the end of the semester, and the two-week reports can feel very abstract. That is why the example in the sample charter includes a rule for treating the rest of the team to CTB. For minor problems, you might find that this is enough, and that you do not need to report the issue in the two-week reports.


Submission

Due: Saturday, February 6th at 11:59 pm

You should submit a PDF file called charter.pdf containing all of the information above. We ask that the file be a PDF so that we can annotate should we need to return it to you for revision.

In the case of later documents like the concept document, you will be accepted to resubmit the document multiple times (with the final submission part of the Final Document Portfolio). For the charter, we only ask that you submit it once. If we think that it requires revision, we will let you know.

However, you will probably find that you need to revise your charter as the semester goes on. Someone might need to gain new responsibilities, or shift current responsibilities to another team member. You might need to change the Software Lead. You might need to change your rules for handling conflicts. At the end of each two-week report, you will be asked if you have made any changes to your charter. If so, you will resubmit this memo with the changes and the date that they take effect.