I was overly motivated, but in a slightly different sense.
For example, the software tools class I took required building an assembler. I picked up the assembly language for the prototyping board I owned (M6800) and worked out the entire grammar, then built the whole thing. It had a few bugs due to my being new to C, but it ran well enough to cause one of the TAs to worry that I had copied existing commercial code.
I did it that way because I could, and I wanted the experience. And because I was scared of working with other students. If I had my own problem to work on, I had an excuse to work by myself.
It took enough time that I ran out of time to do the other project, a threaded-interpreter language. I implemented a full Forth for that, as well, but I ended up turning it in late. (And my performance in the industry has unfortunately reflected what I did there.)
Students tend to do what they have confidence they can do.
So you need to have a section of the course that covers problem solving, where, as others have suggested, you don't use any text. I would even suggest you tell them to just bring ten or so blank pieces of paper, a pencil, and an eraser, and joke about taking points off for having highlighters out. (Make sure they know it's just a joke.)
The project is simple. Say the problem is a shoe ordering app, and you know it needs x, y, z, and a mini-app that converts shoe sizes used in different markets. Lay out the stubs for x, y, and z, and ask them how the conversion mini-app fits in.
Let the students direct it. Don't lead. Make sure you go out of your way to ask the highlighter abusers to make suggestions, but don't tease them if they get stuck. Get several suggestions and then get a consensus and move ahead.
Let the students write it. Once it's working, let them critique it. Let this cover several classes, and keep the current source where the students can copy it and play with it on their own. Strongly urge them to do so, and maybe even strongly hint that there is a test question hidden in the parts not covered in class. (Just one, and not too many points, of course.)
And probably set aside x, y, and z once the mini-app is done, for a later project which might never come.
The point of this is to deny them the material to highlight, of course, but also to expose them to basic problem solving.
If it's a large class, you might think there are too many students. Or if it's a small class, you might think that you won't have anyone that will respond. These problems work out in practice, if you are willing to communicate with the students as you go.
It might help to build the thing yourself before you start, but that might also leave you tempted to do too much leading. You have to decide on that one.
If you have problems communicating because of the room, say it's too big and has too poor acoustics for them all to hear you, you've found one of the factors, right there.