i) should be in the middle of the spectrum of ii).
- Health
- Score/Time
- Enemy Living Time (decreases while enemy live, see "Halls of Torment Agony Mode")
- Decrease Player Power: Less Movement Speed, Damage, Abilities, ...
- Increase Environment Power:
- Spawning More Enemies or Objectiles that have to be dodged
- Irritating Visuals: Colors/Rotations/Darkness/...
Prevent that People Can "Exploit" Difficulty-Adaptation by e.g. loosing health on purpose to make the game easier and get higher scores
- Increase score received with higher difficulty level
- Make higher difficulty levels more fun and engaging/visually appealing
One person has to be project leader/organizator, mainly to communicate between roles within the team and with the supervisor.
I recommend to additionally have: one lead programmer and one lead artist, but this is not a must.
Every person should get one rough role for responsibility. Still, be flexible and help each other out, you won't be graded individually but as a group that is communicating difficulties early and clearly to find solutions together. Some roles have less work than others. If you have a role with little work and are finished, you should help other people out that have more work/difficulties than you had.
Roles could be: Project Lead, Lead Programmer, Programmer, Enemy Logic, Attack/Weapon Design, Upgrades/Skill System, Artist, Audio Engineer, Testing, Level Design, Game Design, Visual Effects, Animation, Story, ... You can also combine smaller roles like sound design and story design, depending on the focus of your project. Not all roles are important, again this very depends on what kind of goal and vision you have for your game implementation.
You are free to use any communication tool. You can include your supervisor there, or the project leader has to communicate any questions/difficulties with the supervisor
Regularly you should use the scheduled slot for the course. This can be in person or remotely. The supervisor will attend every week or every two weeks to get updates and give feedback/help advice.
You should only work on one branch! Everytime BEFORE you start to code you should PULL the current state, and AFTER you finish, you should PUSH your results. If you change a lot of things or need longer time, you should communicate in your team where you are working on, so that when some people want to change the same parts, you won't run into big conflicts and get on the same state of project early on.
(You can also use different branches if you have one responsible person in your team for merge conflicts and other git versioning problems)