Deadlines

Please see the Calendar for the due dates.

Project Topic

For your project, you will first need to choose learning goals: these are the things that users of your game will learn by playing it. You can pick anything that might plausibly be taught in a K-12 school. For example, you can teach spelling, multiplication tables, history of the US Civil War, or anything else. Keep this focused: don’t try to teach all of grade school math. But make sure you pick something that is flexible enough to be interesting: for example, if you want to teach spelling, make the word lists customizable. Some sources of inspiration can be found in MECC software. Choose something that is already familiar to all members of the team. For example, you can pick a foreign language if it’s one that everyone in the team already speaks, but this is not the time to make everyone else go study ancient Greek (even though it would make a cool project). Don’t pick something that is going to force you to spend a lot of time arguing about the subject (some aspects of history may lead to productive but fierce debate and distract you from your software project). One good strategy is to use standards from the Common Core, though this is not required.

Your game will need to include mini-games. These provide a different environment or context than the main game. For example, the main Oregon Trail game also includes a “rafting” mini-game and a “hunting” mini-game. If you have played recent Zelda games (don’t worry if you haven’t!), you know they include “shrines” mini-games where the goals and rules are different from the main game. This requirement serves three purposes. First, it will enable you to divide your project work better at an early stage, when otherwise it might be difficult for more than one person to contribute to the code. Second, it will provide additional variety for players. Third, it will offer additional interesting design challenges for you.

How many mini-games are required? It will depend on your group size at the end of the course. Consult this table:

You may have more mini games if you like; there’s no upper limit.

Team and Project Organization

Your team should follow an Agile process using scrum. Starting week 5, you will be responsible for one of the following roles:

• Product owner (one per week)
• Scrum master (one per week)
• Development team member (allocate from the following as needed)
  • Developer
  • Tester
  • Designer
  • Technical writer

Communication is your biggest risk, since you probably have disparate schedules; this mutates into a coherence/consistency risk, amongst others. You’ve been warned!

Teamwork

Teamwork may be the most challenging part of the class. You will be working with teammates with whom you may not worked before and who may be different from you in ways that are hard to predict. Learning to work effectively in diverse teams is a learning goal of this class. It’s okay if it’s challenging!

The course staff are here for you to help you work through and problems you may encounter. We want everyone to have a positive experience. To that end, students and staff will follow the UCSD Principles of Community and the Nondiscrimination Policy. Harassment of any kind will not be tolerated.

It is always easier to address challenging interpersonal situations early rather than letting them fester. If you encounter any situation that makes you feel uncomfortable or that you think should have gone differently, please contact any member of the course staff right away. When appropriate, we will try to resolve issues within the context of the course; after all, teamwork is a learning goal! However, if necessary, we may contact the Center for Student Accountability, Growth, and Education or the Office for Prevention of Harassment and Discrimination. Please be aware that both TAs and faculty members are considered responsible employees and are required to report incidents of sexual harassment to OPHD.

If you observe behavior that might make someone uncomfortable but are not the target of the behavior, and you have standing to speak up, it is your responsibility to do so. If you don’t feel comfortable doing so, please set up a meeting with course staff to discuss the matter and make a plan.

Each member of the team brings unique skills, experiences, and interests. This diversity can lead to challenges. For example, one member of your team may be an expert in a technology that the team is using, while another is unfamiliar with that technology. Contributions will be judged according to individual starting points: a small contribution from a member who is new to a particular technology may be an “A”-level contribution when accompanied by appropriate learning. A larger technical contribution or, alternatively, mentoring other members of the team, may be expected from team members who are already experts at that technology. When assigning roles to team members, teams must consider individual learning goals in addition to team technical objectives.