Motivation, as Orbity pointed out, comes from you. If you're not that interested in the project or programming in general, it's going to be a struggle to keep motivated for a long time. That will eventually hurt you professionally if you decide to become a programmer as many projects are longer than a few months (except for short term contract jobs).
As a note, my first 2.5 years of professional experience was on a large, ongoing project that had no real end. It was a massive piece of VB3 software (2-tier client/server) that had constant improvement requests and programming opportunities (ie, bugs). I finally left to be closer to my wife, but I'm SO glad I did. Along with a new job, I got on some new contracts where I actually had goals, such as finishing a project
While some of the "finished" projects are still ongoing, I felt a tremendous sense of accomplishment when the first project "went live" to the users. It's invigorating to start a new project, but I still feel proud about having completed the other ones.
As Orbity mentioned, I'd try to figure out why it is you don't finish some projects. Maybe you don't like programming, maybe you don't like the projects you've chosen, maybe the fun is getting some graphics to show up, but not as much fun to add the menus, the AI logic, and such. Maybe your designs weren't quite right or you had no designs and you just got frustrated by the thought of rewriting a bunch of code. If
that's the case, I'd definitely stick with it. If you're coding and think "crap, this isn't going to work" then STOP coding immediately. Don't try and fix it right there (unless it's a tiny bit of code). Think about what went wrong, what you'll need to do to fix it and then do it. Don't be afraid to scrap a bunch of code versus tweaking existing code. "Clean" code is much easier to fix later when the bugs show up (and they will, I guarantee).
I've been lucky enough to work with a GREAT bunch of guys, almost all of whom like to do things the "right way". If we start discussing something and realize that we did something wrong, we don't try to get a quick hack in place to fix it. We'll take the time to get it right. Or, if there's not enough time, make sure that future code is done right and assign the cleanup of the "wrong" portions to a low priority task, to be completed as the other code is touched. Clean is one thing, being obsessive/compulsive about it is another
/end long windedness
-Nerseus