This page covers the logistics of selecting games and the process that will be used thoughout the semester. The Team Information page contains useful links and contact information for the team and the link for it will be on the site's home page. For the overview of the deliverables, go to the Game Deliverables page (DELIVS.) The Documents page (DOCS) has the detailed descriptions of all elements. End of the semester dates will be posted on the calendar.
On Tuesday, January 26, we will have client presentations on the games. This document has the information about the proposed games.
You are to submit your preference form by 8:00 p.m. on Tuesday, January 26. This means that your team will need to communicate quickly. Team assignments will be determined on Wednesday and I will inform clients at end of day Thursday. This gives us time to make adjustments, but you need to talk to me quickly. (For example, two students may want to swap recitations or a student may want to move to a different recitation if that keeps all recitations at 3 or 4 students.)
Aside from your interest in the topic and willingness to work on the needed platform (if there is one), you should also consider the development environment that you will need to use. In particuler, if you do not have regular access to a Mac, developing for iOS is not practical. I have had teams remote access a server or build a hackintosh (a Mac virtual machine). Neither of these solutions is great, but they are possible. If you want to build a Mac virtual machine for your laptop, it is now legal to do so. There is information on the web on how to build it (for example, How to Run macOS on Windows 10 in a Virtual Machine). Neither of these are great solutions, but are viable. Consider the implications before you choose this path.
Independent of the operating, there are a lot of game engines available. If you look st the Resources page, you will find a long list. What I will capture here is experience that we have had with different platforms.
This is a list of other resources that students have found helpful.
This project is a team effort to design and build a serious game. The intent is that the design be quite complete. The level of implementation will differ by teams and will be agreed upon between the team and the instructor at the end of the second sprint. The objective of the game is defined by the client.
The course follows an agile development process for the implementation itself. This means that a broad direction is set at the start of the development, but specific deliverables are planned at each step. Teams will commit to deliverables on a sprint basis (every 2 weeks) and you are graded on these deliverables. In order to improve the chances of meeting those goals, teams will commit to weekly deliverables. These are not specifically graded except as how they relate to your effort. Each sprint requires that documentation be kept up to date and this too will be part of the sprint grade. Specifically, you need to keep the development documentation up to date. The document will not be graded in detail, but I will spot check that key changes have been made.
Part of the agile process is a daily "stand-up" meeting where team members answer three simple questions:
With teams working remotely, it is imperative that this type of regular communication be mainteined. To simulate this process, teams are to use Geekbot, a slack bot that sends you a daily reminder and shares the information with your teammates. The instructor is to be included in these notifications in order to be aware of the team progress and potential problems.
Some teams have found daily messages too obtrusive as the rhythm for students is not that consistent. It is okay to use a less frequent check in, but if the check-ins are too far apart, you lose the benefit.
As part of the deelopment process, each team must maintain a system of tasks to be accomplished and bugs to be fixed. I recommend using the githus tracking system as this allows you to have it in the same system as your repository.
For more on running the agile process remotely, I recommend that you look at the article Can you be remotely agile? from the Agile Alliance.
Each student will receive a grade and feedback at the end of each sprint. It will be posted on Sakai. The totality of the sprint grades constitutes half of your team game grade. A significant purpose of quick grades is to allow students to correct problems. In order for these grades to be meaningful, teams are going to need to be honest with one another about how things are going. To keep the team well-informed of what is happening, we will be using a Slack bot that provides an asynchronous daily stand-up meeting. Documentation of how to use the bot and the Slack channel for each team will be available after team assignments have been completed.
The design of the game follows a different process. One of the expectations is that you will develop a much more thorough design for the game than you will be able to implement. Your design document will identify both what you were able to implement as well as the vision that you have for the game. You are expected to learn more about games as the semester proceeds, so I do not expect a polished game design at the beginning of the semester. However, the team needs to quickly converge on a base design. Because there will be difference in each game, sprints will also define which elements should be further expanded. At the end of the semester, you will have an opportunity to make whatever changes in the design document needed.
Your game grade will be determined by individual grades for the sprints and the final deliverables grade (50% each). The final deliverables include
In addition, each student is given a "multiplier" on their grades based on their contribution to the project. If everything is even, all members are given a "1". A slackard can be given a lower grade. A grade above 1 is not earned by taking over other people's reaponsibilities; such a grade may be earned if an individual goea above and beyobd in helping their teammates. I try hard not to use the multiplier; I would prefer to fix problems as the semester progresses.
While I do not take attendance in class, I do take attendance for weekly meetings. When you know that you are going to miss a meeting, You need to inform me and a teammate. (They need to be able to report on what you have done.) For last minute absences, make sure someone knows that you will not be there so that we don't wait for you.
Each week we will review your progress and it will be recorded on a document private to the team. This is where you will have feedback from me and the plan for the following week. Sprint dates can be found on the calendar.
The last Friday of class, we will do a practice handoff of games. Specifically, teams will be paired up and will attempt to create a development environment and deployment of each other's game, including a minor change (as proposed by the game's owner). The purpose of this exercise is to update the development section of your design document to assure that another team or individual will be able to take over the game. Teams will divide into two groups, one helping the testing team and updating the documentation and the other being the testers for the other game. Teams can choose how to divide
Given that the Friday session isonly 50 minutes, you will need to give the other team documentation prior to the session. The evening before should be sufficient for them to familiarize themselves with the material.
Teams will be paired up to minimize the work required to set up the development environment, but the expectation is that the development section of the design document has all the information available about how to set it up. This should include versions of software that are used, additional packages that need to be installed, and where the software (and installation instructions) can be found. It also needs to tell how to set up a test environment if it is different than the deployment. (In contrast, the deployment section needs to tell how to run the game for the client's environment.) For the purposes of this task, either may be used. I do not expect anyone to set up a new server as part of this exercise.
Here's the process that we will be using:
Because we are unable to play games during the gamefest this year, each team needs to schedule a final playthrough of the game with me BEFORE the gamefest. The definition of a playthrough is that I can play the game. I should be able to do this throughout the semester, but it is critical for this meeting. Scheduling must be done no later than our last team meeting; teams may do it earlier to get a preferred time. Playthroughs should be easily completed within 30 minutes. The playthroughs will need to be done some time between the last class and the final exam.
During the same time as the playthroughs, each team is to schedule a handoff meating with their client. I need to be in attendance for this meeting. Again, 30 minutes should suffice for these meetings.