My problem is, whenever I start programming a clone of a game (for practice) or my own game or some other problem I stop somewhere in the middle of the development, because I lost interest in it.
How do you keep up the interest in developing a game, or developing in general?
As a designer, I tend to think of people as collections of stats and variables. When you pose your question, I can easily picture [Pong_Dev_Interest] decreasing and [Spa_Inv_Dev_Interest] increasing. When the difference between the two is greater than [Dev_Project_Inertia] (somewhat related to [Dev_Completion_Desire]), activity on [Pong_Dev] halts and [Spa_Inv_Dev] starts.
In English: You fail to complete the project because your raw desire to see a finished product is overridden by your lack of interest in the current project. If you really want to finish one, the only solution is to pick one (I'd go with your pong clone) and finish it. Say to yourself "Self, I know that maybe I could have refined that clone some more but gosh darn it sure feels good to kick a project out the door". Then keep working.
When you are bored, keep working. When it's going great, keep working. When it's falling to crap, keep working! Persevere! Be the Little Dev That Could! I believe in you!
Ahem. Got a bit overexuberant there. But you get the drift.
I am following my own advice daily. I got my environment and actors working, built in my win and loss conditions and created the objects the Player will use. I'm basically ready to start doing some level design and my interest tanked. But I do some every day. Every day. One day I will be done.
And it will feel so goooooood.
I always ask myself the same question and there are a couple of things you can do to motivate yourself (a lot of them already posted here). What works well for me is something I heard at one of the Indie Talks at this year's GDC, I think it was the guy making the Monaco game :-)
First, find a project that's well in your line of experience. I.e. don't start out to make a FPS if you don't even know the basics of OpenGL/DirectX. (unless you're using a game engine but that's not the point here ;-))
Then, make yourself a list of things to do and milestones you like to achieve, so you always know where to go. The TODOs is the important part. Define your tasks such that each task can easily be done on a day or in a couple of hours. So when you start out coding, designing, modeling etc. you already see the light at the end of the tunnel. Nothing is more depressing than designing and coding your big Game Engine for a month without getting nearer to the finishing line. Break down big tasks into smaller ones. Finishing a task quickly is really rewarding and keeps you going. For example, this was my task list for a small space shooter game at one time :
All these tasks were easy to do and once they work in the game, you can iterate on those areas and polish them.
And hey, I finished a small game. It's not pretty but it's basically done which was really rewarding in the end :-)
You have to identify the problem before you can solve it. Why do you lose interest?
For me, it usually happens because I am spending so much time on the framework, and after weeks, I couldn't even get a single gameplay element up.
One way I find to improve my motivation is to do iterative prototyping, or some form of Test Driven Development. Usually that involves automating test cases, but as games are graphics intensive, you can't automate screens and animations as tests, but your game logic could be automated.
For the parts which can't be automated, basically I'll plan a couple of milestones for the game. Milestone 1 probably would be render a sprite on the screen and get WASD to work, for example. Gradually, I will add more features, and refactor.
It's a form of divide and conquer. Break into small chuncks, work on the one you are comfortable with, then integrate. Rinse and repeat. Eventually you may see a better way of re-arranging stuff, and you can refactor your code. It's messy not to have an architecture up front, but usually when getting started in programming it's hard to visualize the architecture till you have some years of experience.
I try to find some easier part to make. Like if I can't figure out how to make something or don't wan't to, I shift gears and model or write a shader, etc.
If you don't know how to correctly structure a game, you should start learning how to abstract their elements into game-independant blocks. This may help you in many ways (besides being interesting), such as: experience dividing abstractions from implementations, a better exploiting of inheritance and interface design, or just how to put the game into multiple files for it to look pro (or to provide a fexibility of implementations by the use of dynamic link libraries or other interface uses). Sooner or later you'll realize that everything can be done and then you will find yourself without that motivation problem anymore (you just do it).
I had the same problem when I got stuck at first, but the best solution is to keep moving, or you can stall forever until something resets you somehow (and it may take too long). It doesn't matter if you just code 2 lines some days, but every day you have at least to open the project and try to improve something (it's a neverending task but that's not the problem).
If at some point the program doesn't work, you should undo what you did last (keep a backup use an svn or at least a .rar with the name of the date) to a point it did work, and try to do it again, or work on other changes you need to do until you want to try again.
At first you should try to fix the error with the help of the debugger, but I don't know if your language even supports a debugger... but if you by chance use C++ or something like that (which I would recommend if you want to make games), you should make better use of your debugger as it will help you a lot for finding the error fast in a single run.
Reading about game programming is also a good thing to keep on the topic if you don't want to work on anything in particular. There are some good books and articles about game engines and design you can find online.
You won't be able to do anything if you don't practice. Trying to find a bug can be very frustrating at first but then you learn that it's actually easy if you know how to do it. This is something you learn how to avoid with the time, by coding in a way your changes don't impact in the whole program, decreasing the amount of places on where to look for the error. If every time it gets difficult you give up, then every next time you think on making a game you will give up before starting. Just learn how to overcome the bad moment by overcoming it :P If you don't pass through that moment in which you lose motivation, your laziness will win, and you will lose, that's how it works, until you learn how to regain motivation without much effort.
PS I was wondering... what are you using to make the game?
[meant to be left as a comment to anon's answer, which was deleted as I posted it. He mentioned that he had all this functionality working, then split the single file code into multiple files, only for everything to fall apart]
Re: refactoring, stuff can happen, even to pros. Sometimes even with good tools like Git, a merge can fail so instead of feature A and feature B both working, neither work! The only choice is to go back to A and try again. Luckily version control will save this code for you; if you don't use real version control, at least do it manually by zipping your dev folder regularly -- HD space is cheap! In conclusion, go back to what works and refactor in smaller steps, making sure the game still works at each step. It is really depressing to clean up code only to see everything fall apart. Just revert to old code.
To stay motivated, keep telling yourself that you are making a game, not a game engine -- well, unless that's your thing. And that's cool, game engines are great, but they too often get in the way of making games.
To illustrate my point, I can tell you how things often go: at first you create a few sprites, move them on the screen with your proto-framework and you are thrilled! You can see your progress and it is going well; you can show your friends.
Then, once you have played with your concept a bit you realize that you need to make your framework (or game engine) more flexible. Or that you should re-factor some class that are not following the latest patterns. And from there, you embark on a spiral of death: you stop working on a game and you start working on a game engine. And game engines are not nearly as fun to make. You can spend hours refactoring and have nothing to show for it - in the game. And then, you lose interest.
So, remember: make games, not game engines. Only refactor when you need to. Don't be too flexible - just the bare minimum.*
*: of course refactoring and flexibility are important. But not as important as actually having a finished game.
Try to make a playable version in a day, no matter how simple. Then iterate.
Don't try to make your game too complicated!
Split your task into small, specific, measurable subtasks. If any subtask seems too big, then subdivide it further.
Ensure that you write "DONE" in big letters on your task list (I use a .txt file) when your task is done. Don't remove the task, because then it won't look like you're making progress.
This is what I do. It's worked in the past.