I believe this project would be quite popular with many students. Creating a game is a fun way to "see your code on the screen", but there will probably be some students overspending their time on creating a nice looking GUI, rather than focusing on game logic. One way to avoid this would be to give a lot of initial code, but that subverts the goal of creating a larger project from scratch.

The student could also practice using enums and match expressions to represent the different blocks in tetris. The project could also have file interaction through a scoreboard.

Yes, I see your point, but I feel like experience from the previous group-lab, snake, is a pretty good warm-up/preparation so that students have a good understanding of what should be prioritized. Maybe an option is to have most GUI-related code already written for the students, and have them focus on implementing the game logic itself.

Regarding the file interaction, I think you're absolutely right. If I remember correctly there was an optional assignment in one of the previous block-game labs to include this feature, but maybe we could build on it even further here...

Yes there are many things to think about in relation to the set of provided project proposals and the base-line learning goals and how the projects differ. Also, too many projects will make it harder for teaching assistants to know them all.

If we include Tetris, either one other project should be cancelled or it should have a very special angle: for example that it is "branded" as especially challenging for advanced students with special interest in games and in line with that perhaps no code is given but rather natural-language requirements on functionality and architecture/design. This way we can "sell it" as learning how to make something big from scratch.

One option is to require the os lib, part of the new toolkit for reading/writing to file.

I have a bunch of things to complete before summer, but considering this can wait until later.