Learning to work in a group is a major part of this course. You will work collaboratively with your group to create a small piece of software (e.g. a game). You will use the communication tools typically used in industry, and work with your group in a professional way. The group project is divided into the following components:
|Project Plan||4%||October 13, 9:00pm|
|Design Review Presentation||5%||Presentation in weeks 6 and 7 tutorials
Slides due Oct 21, 11pm
|Code Commit (Individual)||2%||October 27, 9:00pm|
|Documentation (Individual)||2%||November 10, 9:00pm|
|Project Repository||8%||December 4, 9:00pm|
|Final Presentation||10%||Presentations in weeks 10 and 11 tutorials
Slides due Nov 18, 11pm
Group Membership Assignment
Groups will be assigned in tutorial 4. You will not be able to choose your group, so that you gain valuable skills working with people that you may not have met. Working with strangers is something you will frequently have to do in industry.
For your project, you'll be implementing a small, computer game. You can select a game from the following list, or propose another game. If there is another software that your team would prepfer to build, please speak to Lisa.
Your group will not receive extra credit for choosing a harder game, but can do so out of personal interest (make sure you have the entire team's buy-in!). You may also propose a game not on this list for instructor approval. A maximum of 1 group per tutorial section can choose the same game.
You should use Python to build the game. If you prefer to use another language, please speak to Lisa. If you want to use Java, the discussion with Lisa should be fairly quick, and is just to make sure that every team member has some Java experience. I recommend that your team use a library like pygame for your Python game.
Unless agreed upon otherwise with the instructor, your project code will be open-source and hosted on GitHub. If your team would like to use a different platform, or keep the code close-source, please speak to the instructor.
Since many of these games are trademarked, your repository name should avoid using the "official" names of the game.
We will be using Microsoft PowerPoint as the standard presentation software for this course. You will be required to set up your slides to advance automatically without intervention, to avoid running over time. If you do not have MS PowerPoint, you can download the software from here.
All portions of the assignment must be completed as a group. Every student must participate in all parts of the group assignment in order to earn the marks. If a group member is not contributing, please contact the instructor immediately.
You may have limited class time during tutorials to work on the group assignment. Your attendance to these classes will be recorded. Your attendance to these classes are a way that you demonstrate to the instructor that you are participating in your group work.
In the end, your primary responsibility is to your team members. If they report to me that you have not contributed to a part of the assignment, you may be removed from the group and receive a zero for all parts of this assignment.
Late group work will be assigned a grade of zero, so please submit early! The presentation slides must be submitted on time so that the TAs has time to review and queue them for the presentation day.
Presentations must be delivered in tutorials, as scheduled. Please contact the instructor in advance if you require special considerations. In case of illness or other disasters, contact the instructor as soon as possible.
A project plan outlines the various aspects of a project to internal stakeholders, including the projects scope, goals, stakeholders, deliverables, and deadlines. The purpose of a project plan is to come to an agreement with your team about:
- what the goals and motivations are of your project, and what success looks like
- how work will be divided, and how to ensure that the division is fair
- how team members will work together, including tools that you will use and meetings that you will hold
- how your team members can contribute ideas and work
- who will be responsible for submitting the deliverables on Markus
- who will be responsible for checking if team members need help
- what the protocols are if a team member is having difficulties
- what your deliverables will be, including "internal" deliverables that are *not* graded
- what your milestones will be, and when you expect to hit those milestones
- what your risks are and how to mitigate them (e.g. if a group member drops the course, if a group member does not show up to a presentation)
When writing complex software with a team of developers, it is important to plan ahead. In particular, many organizations hold design reviews, where developers present their ideas on how to design software to their peers and more experienced team members. The goal of the design review is to receive critical feedback to improve the design of your software.
The design review presentation will be less interactive than an actual design review meeting. Instead, you team will deliver a 6-8 minute presentation on how you plan to build your software.
Each team member will submit one substantial commit, to show both their participation in the project, and to show the use of good coding practices. The commit should be decently sized, but not too large since each commit should be atomic. However, the commit should not be a simple typo fix or other trivial code.
Each submission will be graded on whether the code is readable, whether the commit message is clear, and whether the commit is consistent with the rest of the project.
Each team member will write a short (1-page) description of all their code contributions to the project, and how their team members should use the code.
The final presentation is an opportunity to present the software that you have developed to your tutorial group. Your presentation should include
- A description of how to install and play your game.
- At least one screenshot of the game.
- The way that your github repo, directory and code is structured.
- What you learned from building the game and working together, and what you would do differently in the future.
The final deliverable for the CSC290 group project is the project repository. This project repository should contain clean code and a well-written README that you are proud to show to potential employers. If done well, the repository shows not only your coding skills, but also your ability to work together in a team, and your ability to communicate with a technical audience.