What to turn in:
If you want a text adventure game, you might start from the codebase in http://anh.cs.luc.edu/170/examples/zuul/. There are advantages to planning something from scratch, or alternately modifying a give codebase that is mostly a core of what you want. Reading a major project is also a way to gain familiarity with a language.
You are strongly encouraged to keep your project text based, and not go through the large learning curve to do something with graphics.
You will be assigned to groups of 3-4 people to work on a project that will extend until the end of the semester, with little other work introduced in class, and of course your final exam. This leaves a chunk of course time for concentrating on the project. This ends with presentations in final exam period. Your group will be designing and implementing a project of your choosing. You could choose to make a text based game, starting from our game skeleton or not, or something completely different, started from scratch. The project should have some clear focus or aim, For instance a game should be able to be won.
You are encouraged to write the project in Java, to gain familiarity after our quick switch. If there is a particular reasoin to write in Pythin instead, that will be allowed.
Start by brainstorming and listing ideas -- do not criticize ideas at this point. That is what is meant by brainstorming - having your internal critic going inhibits creativity. After you have a large list from brainstorming, it is time to think more practically and settle on one basic situation, and think of a considerable list of features you would like it to have. Order the features, considering importance, apparent ease of development, and what depends on what else. Remember iterative development! Get something simple working, and then add a few features at a time, testing the pieces added and the whole project so far. Test, debug, and make sure the program works completely before using your past experience to decide what to add next. This may different than what you imagined before the work on your first stage! Like the provided base project, early stages do not need to be full featured, but make sure that you are building up to a version with an aim, and which includes interesting features. You should end with a program that has enough instructions provided for the user, so someone who knows nothing of your implementation process or intentions can use the program successfully. Your implementation should also be documented, imagining that a new team of programmers is about to take over after your departure, looking to create yet another version.
Your instructor will tell you about team makeup.
There are a number of roles that must be filled by team members. Some will be shared between all members, like coder, but for each role there should be a lead person who makes sure all the contributions come together. Each person will have more than one role. All members are expected to pull their own weight, though not all in exactly the same roles. Everyone should make sustained contributions, documented in the periodic reports. Understand that this project will be the major course commitment for the rest of the semester. These roles vary from rather small to central. Not all are important immediately.
Leader: Makes sure the team is coordinated, encourage consensus on the overall plan, oversee that the agreements are carried through, be available as contact person for the team and the TA and your instructor.
Lead programmer: Keep track of different people's parts to make sure they fit together.
Coder/unit tester: Everyone must have a significant but not necessarily equal part in this job. Each person should have primary responsibility for one or more cohesive substantive units, and code and test and be particularly familiar with those parts. Do your best to make individual parts be cohesive and loosely coupled with other people's work, to save a lot of pain in the testing and debugging phase. When coding, you are still encouraged to do pair programming, though what pair from the team is working together at different times may be fluid. The lead programmer might be involved in pairs more often than others, but be sure the other coders get to "drive" often.
Librarian/version coordinator: The default should be for you to have a Google Drive folder shared with your whole team and me and your TA, with all as editors. (Use my login as anharrington@gmail.com.) Your folder should have the name of your team. You should always have a folder that contains the latest working version of the project. You should also keep old versions, for instance copied into numbered version folders.
This folder-based structure does not handle successive versions automatically. You can choose to use the more capable professional version control combination of git and github (built into IntelliJ and PyCharm). Git will have a major learning curve, and in that case this person should be the best informed on git. Git gets particularly complicated when more than one member contributes directly to the uploaded version at github. If you use git, I strongly suggest that uploads all be handled through one person, while updating downloads by all are easy and harmless.
Report coordinator: Gather the contributions for reports from team members and make sure the whole reports get to posted on schedule. Your instructor needs a clear idea of the contributions of each member in each report interval. If a team member is not clear on this to the report writer, the report writer needs to be insistent.
Instruction coordinator: Make sure there are clear written documents and help within the program for the user, who you assume is not a programmer and knows nothing about your program at the start.
Documentation coordinator: Make sure the documentation is clear for method users/consumers. This includes the documentation for programmers before the headings of methods and classes. This is for any time someone wants to use (not rewrite) a class or method you wrote. Also have implementer documentation, for someone who will want to modify or debug your code and needs to understand the details of your internal implementations. The extent of this can be greatly minimized by good naming.
Quality manager: Take charge of integrated tests of the whole program (following coder's unit tests). Make sure deficiencies are addressed.
Conflict resolution: You will certainly have disagreements and possibly conflicts. Try to resolve them within the team. When that is not working, anyone can go to the instructor with a problem. Do not delay coming to me if things are clearly not working with the team.
Initial:
On individual versions:
You are strongly encouraged to follow modern programming practice which involves splitting each of these formal versions into much smaller steps that can be completed and tested following a similar process. Order pieces so you only need to code a little bit more before testing and combining with pieces that already work. This is enormously helpful in isolating bugs! This is really important. If you thought you spent a long while fighting bugs in your small homework assignment, that is nothing compared to the time you can spend with a large project, particularly if you make a lot of haphazard changes all at once.
Make good use of the separation of public interface and detailed implementation. If your project has loosely coupled class, the main part of the public interface should be limited and easy to comprehend.
Ideally have one individual (or pair) assigned a whole class. One useful feature for allowing compiling is to first generate a stub file that includes the public interface documentation, headings, and dummy return values and compiles but does nothing. Post this under a folder for the current version number. You will then provide your team members with something that tells them what they can use and allows them to compile their own part. Then later substitute more functional classes.
Your instructor and you will want to review your code. We do not want to have to reread almost the same thing over and over: Use the editor copy command with extreme caution. If you are considering making an exact copy, clearly use a common method instead. If you copy and then make substitutions in the same places, you are likely better off with a method with the common parts and with parameters inserted where there are differences. You can make a quick test with a couple of copied portions, but then convert to using a method with parameters for the substitutions. Besides being a waste of effort to define seven methods each defining a tool, with just a few strings differing from one method to the next, we will require you to rewrite it, with one method with parameters, and just seven different calls to the method with different parameters. Save yourself trouble and do it that way the first time, or at least after you code a second method and see how much it is like the first one you coded....
If you are making many substitutions of static textual data, put the data into a resource file like it the sample Zuul project.
You only want to commit working code into the shared current version folder. Comment out incomplete additions that you want to show to everyone, or comment out the call to a method that compiles but does not yet function logically. An alternative is to have a separate folder for in-process code to share for comment, so you will not try to compile it with the current working version.
Reports are due from the report writer on a schedule specified by the instructor, weekly for a full semester course, twice weekly for a half semester course.
Group Submission:
One submission of the group work is due one hour before the final presentations.
Look through the list of deliverables again, before sending files, and check with the whole team to make sure your collection is complete.
Your Assessment of Individuals in the Group:
This is due electronically 10 minutes after the final class presentation period, from each team member, independently, turned in a manner specified by your instructor, like other homework assignments.
Change the name of the linked stub file Indiv-Mem-Assessment.rtf to your teamAbbreviation-yourName.rtf. You may want to tweak it after the group presentation, but have it essentially done beforehand.
Writing this is NOT a part of your collective group deliberations. It is individual in two senses: both in being about individual team members and in being the view of one individual, you. For this document only, everyone should be writing separately, privately, and independently from individual experience. If you lack data on some point, say so, rather than using what others are saying.