TDDE25 Project: Instructions

Read these documents now!

1. General project information, before you start

2. How to complete a project (this document)

3. Final demo, presentation, hand-in

How to Work Together

With three people in most groups, you will have to divide some aspects of the project among you and work on them individually. Without this you may not finish in time, and more importantly, you may not learn as much!

During scheduled labs we generally have additional computers available. For example, during "ordinary" years, we may have 20 computers for 12 groups, and you should ask students not taking this course to leave so that your group can have two computers. This year we are still waiting for our room assignment from the schedulers.

Everyone still has to do all types of work. For example, everyone must write a significant amount of code. Less experienced members should write more code. The point is to learn, not simply to finish the base project as early as possible. More experienced members who want to write more code can devise their own extensions to be implemented in parallel, as long as this does not impede the other members' progress.

Working alone on a specific feature does not mean working in a vacuum. Everyone must have working knowledge of every part of the project and must be able to explain what others' code does and why. Discuss the code you write, so that everyone understands what the others have written and designed! This is not wasted time: Seeing and understanding what others write helps you learn, which will be rewarded in evaluations.

How will you work together?

In addition to the general instructions above, you as a group have to come to an agreement about how you will work together. You should discuss this openly at the beginning of the project!

In some courses a group contract is set up and signed – here we'll try to keep the discussion less formal, but do not skip it just because there is no paper to sign. Simply bringing up these issues in an honest discussion can help you avoid a lot of misunderstandings and problems later in the course.

Some topics to consider:

• When will you do the work? Will you meet (physically or virtually) during all of the scheduled lab times, and work together as recommended? When will you do the rest of the work that won't fit into the scheduled labs? Remember that a lot of work needs to be done outside of scheduled hours.

• What will you aim for? Do you aim to go as far as possible with your project, or do you just want to pass the course? If you have different aims, how will you reconcile this so that some of you can add more functionalities without "leaving others behind"?

• How would you like to work in the project, in general? What makes you like working together? What do you think would be problematic, given your own experience?

• Will you be splitting off some parts of the project into tasks that individual members can take care of separately? How will you then make sure everyone knows "everything" within the project? Or will you work together, and only together?

• If someone doesn't show up, how will you deal with this?

• What do you need to learn for the project, as individuals or as a group?

Project Phases and Mandatory Tasks

Each project has a mandatory part that every group must complete in order to pass the course. Exactly how this mandatory part is defined depends on the type of project.

• Many projects have an initial core that is linear in nature: There is a natural step-by-step progression where each task forms a stepping stone that is needed in order to reach the next step. In some cases, the core is sufficiently large that nothing more is needed in order to pass the course. Then the mandatory part is also, by necessity, a list of steps to be achieved in sequence. You are then free to build upon the core in any way you want.

• In some projects the initial core is smaller. This opens up the possibility of giving you more freedom in choosing what to implement even in the mandatory part.

In either case, the mandatory part is usually split into two phases, described in the project-specific instructions.

• An introductory phase, where the exercises have detailed instructions and are designed to help you learn about the project topic at hand, such as StarCraft or working with maps. They will also help you gain additional programming experience and learn the programming interfaces to the relevant existing hardware and/or software.

• A main phase, where there will be a set of milestones or tasks but you will be encouraged to use your own creativity and programming skills to determine how to achieve the desired results.

  You may also be able to choose to define your own alternative main project within the boundaries of your project type. In this case you must write your own task definition document that must be approved by the assistant and the senior person involved. Talk to them first!

Lab Sessions and Supervision

There will generally be two four-hour supervised labs booked every week. The intention is to ensure that you get the time to work with your project for longer periods of time without interruption. Project assistants will only be present/available for part of these labs: At least 1 hour, and up to 2 hours if there are many questions.

At these sessions, you can ask the assistants about issues that have come up since the previous supervised lab. You must also use them to demonstrate the results from each of the introductory exercises and discuss them with the assistant. Even if you have nothing in particular to discuss, you should be present during most of the supervised labs so that the assistant can see your progress and perhaps give you some tips. If you skip this, you risk failing the course due to insufficient feedback.

Continuous Examination: Progress Reports

Each week, there is a two-hour progress report session marked as "Redovisning" in the online schedule. All group members must participate in order to discuss the report and demonstrate their current progress. The exact form of the progress report session (physical/virtual) may vary and will be decided later.

The day before the report session, each group member must individually send in a short progress report document according to the template below.

There are two separate reasons for these reports and seesions. First, it gives us a chance to provide comments and guidance relative to your current progress, which gives you a better chance of passing the course at the first attempt. Second, it serves as a form of individual examination allowing you to show to the assistant that you are making progress and should pass the course.

What should be in the progress report document?

The progress report document is individual and must be sent to your assistant in an email the day before the progress session. Send the report in plain text in the email, so that the assistant can easily see it without opening an attached document. You can use Swedish or English regardless of project type.

The format should be as follows. Be careful to follow the template so that assistants can more easily organize the up to 36 reports they must handle each week.

Subject: TDDE25 progress report {Your LiU ID},
         group {Your complete group+subgroup number},
         week {Calendar week number}

What have you personally done in the project since the last report?
{Your answers in Swedish or English}

How many hours did you personally spend during each day?
{Your answers in Swedish or English, for each day}

How do you think the collaboration has worked?
{Your answers in Swedish or English}

Explanations:

1. Note that the important part of the group number is the index of your 3-person group. For example, "SG1-CTF-5" is a complete group number; don't forget to include the "5" as the assistant already knows which project you have.

2. What have you personally done in the project since the last report? You can discuss:

   • Code that you have implemented
   • Problems you have had, solutions you have tried
   • Bugs you have fixed
   • Information you have gathered
   • And so on...

   Relate this to specific milestones or tasks in the project description, and please be reasonably detailed.

   If you have worked closely with others in your group, you can explain this – but still explain what your particular contribution was, and what role you took, during this teamwork.

3. How many hours did you personally spend during each day since the last report? This is partly for your own immediate benefit (giving you a better idea of where you are spending the most time), partly for the long term (in case of conflicts within the group, which are rare but do happen), and partly a basis for discussing your progress.

4. How do you think the collaboration has worked? Are you getting a chance to write code? Is everyone present? Do you agree on what should be done and how? This is your chance to bring up potential problems at an early stage. Doing this is not disloyal -- it is just a way of letting the assistant know that the group as a whole may need some help.

Sending in this information in advance lets the assistant spend less time taking notes during the progress report session.

What will we discuss during the progress report session?

During the session, each group will demonstrate and discuss their current progress with their assistant. Around 7-10 minutes will be available for each group. Use this time wisely, and be well prepared! (Groups who are not currently reporting will of course continue working on their projects.)

The following topics are examples of what may be discussed. All members must be able to answer questions about any part of the project, including code they did not write. One member might be asked to answer all questions during one session!

1. What is the current state of your project?

   The reports should already have given the assistant a good idea about where you are and what the problems were, in some detail.

   During the session you instead give a brief demonstration of what you have done by running the code you have written so far. Don't worry too much about being able to give a "perfect" demo of all features – we need to see how far along you are, but we are just as interested in seeing what difficulties you have as in seeing what works perfectly. See this as an opportunity for feedback. At the same time you should have something that actually runs, not just some code that won't start. Keep track of "working" revisions in Git so that you can bring back a stable working version if necessary.

   Be prepared: decide what you want to show, and test it before the session.

2. How did you reach the current state of your project?

   Which parts were easy and which parts were difficult? Which difficulties have you encountered in the last week? How have you resolved them, or how are you planning to resolve them?

3. How do you intend to continue?

   What do you think you will do in the following week (which milestones, which subproblems, which issues to resolve, what progress is expected)? Do you foresee any new problems?

If there is no progress in terms of tasks and milestones, simply saying "we didn't get anywhere" isn't sufficient: Explain clearly what you wanted to do, how you tried to do it, what happened, and why this direction was not appropriate. This does not represent progress in producing a product, but it can definitely represent progress in learning about programming!

What if I can't come, or I miss the report or session?

If you miss sending in the report on the day before a progress session, the assistant can't prepare properly for the session. If you miss the actual session, the assistant can't ask you questions. This means you have a problem in terms of showing us that you should pass the course.

If you miss a report and/or session at most twice, you will get a second chance to complete the course by filling in a longer report template that will be provided at that time. This is not a punishment but simply an alternate means of examination, which will cover the questions that could otherwise have been asked at the weekly progress report session. The longer report must be handed in by Wednesday the week after the missed report/session. The assistant may add additional requirements for examination purposes.

If you are sick, please inform the assistant before the session. You will still have to write the longer report: The examination is necessary for everyone, regardless of circumstances.

If you miss a report and/or session more than twice, the longer reports will not be sufficient: We do need regular opportunities to talk to you and ask additional questions, and this should be done during the actual report sessions. In this case you must email the project coordinator Jonas Kvarnström, who will discuss the issue with your assistant and the senior advisor for your project type. Include an explanation of why this happened.

Resources: Requesting Assistance

Throughout the project we expect you to encounter a large variety of problems that need to be solved. For each problem you need to do your best to strike a good balance between trying to find a solution on your own and asking your assistant for help.

If you immediately ask the assistant, you lose an opportunity to practice independent problem solving and to develop your own skills. Therefore you should generally start by discussing within the group, searching the web for information, discussing with other groups, and using whatever other channels are appropriate depending on the problem or question you have.

On the other hand, you lose too much valuable time if you spend days trying to solve a single problem on your own, and for some problems (in particular when it comes to unclear instructions) it may be obvious that asking the assistant is better.

If you send questions by mail, make sure that you include all relevant information about the problem itself, how you have already tried to solve it, and why the solutions did not work or did not seem appropriate. If you don't provide enough information you will receive questions instead of answers! Learning how to describe an issue in a useful way is also important for your education.

Assistants will be available by email throughout the period but will not necessarily be at their computers at every moment. If you don't receive a reply within 48 hours (during weekdays, not weekends!), please try again. We cannot guarantee that every problem is actually solved within this time limit, but you should still receive a reply telling you that the question was received.