Now that you've completed your individual game jams, it's time to form up into groups and get ready for the big one, the final project, the Group Game Jam. This is a one-month project in teams of two to four (but hopefully at least three) where you'll be working together to produce a new game. To prepare you for what lies ahead, remember the resources that you were told about in Lesson 13, and read on to find some information on project management, and on working as a team.

The Agile Approach

There's an approach to software development that has become common in many offices and studios in the past decade. This is the Agile approach. The basics are these:

There is a defined, big goal in mind. The team comes together to break that big goal down into a number of smaller goals, and works on the smallest and most completable of those goals first.
The initial plan you work on should work towards a "minimum viable" product. That program needs to have all of the requirements the group considers absolutely necessary for the project.
Once you have your minimum viable done, you save your files, back them up, and start improving on a copy of those files so you can make a better version of the system. Once that new version meets all requirements, save it again, and continue the cycle.
The group should meet regularly (say, every day or two) and talk about where they are and how things are going. They should also meet formally with their supervisor (that is, the teacher) once a week to give a report on how things are going with the project.
Constantly test your code. Know what tests are necessary, and if you find they aren't doing the job, change the test suite you're using. When you add features, you'll need to test that those features are performing correctly. If everything is running properly, even when you do something strange in game, you're doing great!

This differs from the traditional approach to project development, where typically the bulk of the work beforehand was in planning out every detail of the project, then the process of making the project would start, and if problems arose that would require changing the plan, it could take ages to get through the re-design phase to get back to making the new version of the project again. (Agile documents sometimes call this the "Waterfall" approach, but I've never seen it outside of that context, so take that with a grain of salt.)

Agile gets around the pitfalls of the traditional method of development by being immensely flexible to changing requirements, or to unexpected problems. If the original plan won't work, you can change it without having to redo tons of work you've already done. It's ideal for rapid development in a short time frame, such as in game jams.

Decision Making in Teams

You'll need to decide how to do things going forward. Ideally, you should be deciding on things such that everyone is happy with where the project is going. Your team is small enough this should be possible. In cases where people don't have strong dislike of a given approach, but disagree on which way to do things is best, you might want to go with democracy, and have the majority decide which way to go.

When you meet up to discuss where the project should go, make sure someone is taking notes, and that everyone can agree that the notes accurately depict what happened during the meeting. Keep the records of what decisions were made during the meeting, and possibly also of any ideas that were brought up, even if you don't see any use for them right now. You never know when an old idea might come in handy again.

If one member is clearly not liking the direction things are going, but the vast majority of the team is doing well, there are two possibilities: either there's a serious problem that member sees, but the rest of the team don't; or that member's way of doing things is a bad fit for the rest of the team, and they might do better in a different team. You should probably ask your teacher for advice if this comes up.

One of your early meetings should be to decide who is going to do what in the team.

At least one person should lead the effort in deciding game mechanics; this is the lead game designer.
The person with the best programming skills should take the lead programmer position.
Whoever is best at making sprites and/or backgrounds should take the artistic lead.
The same but for sound / music should be the lead musician or lead sound designer.
If your game has multiple levels (or the equivalent) you're going to need level designers.
Every game needs to be tested; at least one person is likely good enough at it to be the lead tester.

None of these positions are hard and fast options. You can have more than one person doing game design, programming, art, music, and so on. You are bound to have some overlap, so at least one or two people will have multiple jobs that could be considered "lead positions." There may also be other positions that you might want, such as voice actor, that aren't in this list; don't consider the list to be a limitation, but instead a set of suggestions.

Whatever each person takes as their position(s), list them as that in the credits.

Managing Multiple Tasks from Multiple People

[An example Gantt chart, from http://www.advsofteng.com/doc/cdpydoc/gantt.htm]

Often when working with a team, you'll have multiple tasks going at once, each done by one or more different people. Sometimes, some of those tasks will depend on other tasks. A Gantt chart is a useful tool for approximating how a group should go about those tasks. You can add to the above template by having tasks that are dependent on other tasks link to those tasks with a line.

Because of the Agile philosophy, if you use Gantt charts, they will likely change on a regular basis. Being able to redraw them when necessary, during meetings, would be a must. This is if you want to use this tool, of course, but often having such a visual aid helps a lot more than merely saying what goals you have in mind, and which immediate tasks you need to do in order to be ready for the next leg of that journey. With Gantt charts, you can see visually how the tasks stack on top of one another, and link them together by their prerequisites.

Pert charts are another option. Pert charts more resemble a network or "graph" than the sets of stacked bars in a Gantt chart, and are more abstract. Depending on how your group works, a Pert chart solution may be more effective than a Gantt chart, especially if time constraints are difficult to determine for given tasks.

You should have all you need to get into the final jam. If you have any further problems arise with your teamwork or project management, make sure to contact your teacher to help get guidance.

Exercise: Final! Group Game Jam

This is it, your final assignment! You have one month to work together on this assignment. Using the instructions in Lesson 14 above, and everything you've learned, work together to make a game. You can improve on one of the games you made during the Individual Game Jam, or you can make something entirely new for this jam.

These same rules apply as for the previous game jam: your game must have reachable winning and losing states, and you must explain the rules of the game to the player. This time, you can't just put them in the README.txt file, however; the rules must be explained in the game well enough for the player to understand, without having to read anything outside of the game. And as always, you must credit all creators of work you use in this project that are from outside of your team, too. Don't use any outside resources without permission, either!

To this, add the following:

You must have creditable work from every member of the team. Making game resources from scratch counts. Level design counts. Designing game mechanics (not just programming them) also counts. Testing the game counts, so long as the testing includes useful feedback to the rest of the team.
Your game cannot simply be a game one of you already made. You must make significant improvements to an existing game from the Individual Game Jam if you use one as a starting point. You have four times the time, and at least double the number of people (and likely more), so you should be in pretty good shape to get this done.

With all that said, get yourselves in the flow, and have fun making a game together!