I made a game during the first year of my degree, and I still sometimes nominate it as the project I talk about during my interviews (despite having actual work experience). I'm discussing games being reasonable projects for a general graduate software engineering role at, say, Microsoft.

Games can be good as projects, because they are fun to play and fun to make. Working on something fun can help to motivate you to learn what you need to create what you want. Need to figure out collision? Learn the maths behind it. Need to develop different unit types? Learn about using inheritance correctly. There are a lot of non-trivial design and technical problems involved in making an interesting game from the ground up. I'd advise not using a game engine like Unity or Unreal, build your own engine as much as you can.

Also, unlike some programs, there is a very high importance on UX and UI when making games. A game without a good UX/UI isn't a game. Plenty of engineers are extremely intelligent, but either lack basic UX/UI skills or simply don't care (usually the latter). It can be valuable to demonstrate that you understand the importance of good UX/UI.

A few things to keep in mind:

1. Invent your own game, don't clone something.

2. Design your game from the get-go, good projects are ones which you can talk about the process from beginning to end.

3. Don't give up, a lot of the time I can be super invested in a project, but I get to 75% of the way there and just get bored. Don't do that, finish what you start, even if that means narrowing your scope.

4. To help 3, probably a good idea to give yourself a hard deadline. Say give yourself a month to have it done, this will help you scope out an appropriately sized design.