Lack Of Interest In Programing!!!

A) taking on projects larger than you should

B) not coding to milestones

C) not providing yourself with feedback along the way. That's why I always right my visual stuff first, so I can constantly see how new code is affecting my game.

I think it happens because people just get bored of working at the same project without visible results. You can spend forever coding say the classes used in the game and never be able to put anything on the screen. Its kind of discouraging to people that that much time yields no visible results. People just end up losing interest because developing a game alone can be quite a long hard task.

What exactly are we talking about? A lack of interest in programming (in which case you shouldn't program), or just that you lose interest in the projects you're programming before they're finished? (In which case you should do as said above, set milestones, only take on reasonable projects, make sure you can see some progress)

I'm kinda same as you Mad_Koder
When I begin a new project, (and god knows that did happen quite a few times so far ;) ) I feel full of enthusiasm and motivation.

What I feel prevented me from completing my projects (I havent completed one so far... :/) is I always wanted to start programming things that I like (mainly graphics, and I guess many game programmers like programming game because they like programming graphics stuff) So I always used to start with "ok, so my game will by several layers, lets begin with the main charachter layer...". I think you know what I mean.

As suggested ItsDoh, I've understood that being unaware of what you're unable to do with your current skills and knowledge is a main cause for failure. Usually I start coding what I can code and quickly end up realizing that I'll never have what it takes to "complete" my game (And when I say complete, I mean what I *thought* will be needed to complite, which might in fact be 1% of what will actually be needed to complete)

On the other hand, the countrary happens sometime, mainly because one does not have a good understanding of what a game is. For example one might think of a great adventure game, but what's in his mind is in fact just a landscape and a character, Thats not a game, though thats what one might head for. And once that's done, well, there nowhere to go next, and the project is given up. I think (but thats really IMHO) that many (didnt say all) screenshots posted in the IOTD end up this way, just being a game embryo that will never become a game (I'm not saying the demo isnt great !!!)

Ah... there would be plenty of things to say about that, but I'm done for now, cuz I started making my MMORPG two weeks ago and, well, you know... ;)

You really need some goals to get anywhere. Decide on something that you want to have finished by say, the next two weeks, rather than doing whatever comes into your head when you sit in front of the keyboard.
Also, get more frequent feedback from other people - if its just you doing something because you like to do it, then losing interest is when the project will die. It may sound weird but the more you code something 'for someone else' the more it feels you have a purpose to be doing it.

I've the theory that the brain tends to get tired of thinking the same idea for too long. Like if after some time of thinking about something you reached a local minima and couldn't be able to think anything else beyond what you've done, thus you are unable to advance.

I'm passing trough this right now. I'm working in something I like, the idea seems still good and I want to keep it up, but my brains are stuck. So, I made a backup of everything, and dropped it for a while. I'm sure I'll continue with it soon.

Set more goals, do at least 10 minutes per day, and make sure it's something workable and interesting before you start -- this is where a lengthy design process comes in handy.

It is very easy to burn out when you are starting out -- just selectively restrict yourself to the fields you are capable in and work on that. Before you know it, your area of knowledge will expand.

Yeah, i know now that i'll get tired of a project, so i'll hold off interesting things till later, like i'll right the boring stuff when i'm enthusiastic, and then when i'm bored i'll design the models, logos and levels.

I also make sure i have off ramps, or small mini projects, where i can get off and take a break and get back on quickly.

Starting projects and not finishing it, i realized, just makes it worse and worse for each new one i drop. So now i go all the way through each one to the end, or at least some workable demo.

I've programmed since 1979. I've pumped out seemingly endless lines of code on marathon 16-18 hour days for 3-4 weeks at a time. I must say that even as a professional architect and developer, you go through funks.

In my experience, this is often caused by not being able to see much progress in the hours of work you put in. Do as others have suggested; take your big project and break it down into smaller pieces. My advice is to look into these areas; iterative development, agile methods and test driven development.

Once you see progress; then you'll be back into the swing of things.

Making a little break from time to time is a good idea also, it allows you to reorder your ideas and maybe get some new ones, etc...
Anyway I think ItsDoh underlined the real 3 main reasons.
But that's what fun, it's not that easy to keep up the work to FINISH an engine/game, and that's what matter, who care if you started a really super project ?

work i dont like( but has to be done) gets me down really fast (like 3d,sound,converters) and stuff ... it takes me some days to recover motivation ...

what also screws me up is, if finally find a way to do everything better ... at this point i dont want to continue the old stuff ... but beginning new does include a big load of standard work which bores a lot :/ ... well i didnt finish a decend project either ... only small stuff (last readymade thing is like 2years old ...) ... i do a lot of little experiments at the moment ... nothing real :X

I find that my development process goes alot like this:

1. Write half of a new feature
2. Fix some code somewhere else
3. Write the rest of the new feature
4. Fix bug in new feature
5. Fix bug caused by the "fix" I did elsewhere
6. Program is working
7. Mess about with working code, "fine-tuning"
8. Goto 1

So basically, for me it is important to remember to do a backup at step 7 so I always have something pretty to play around with during the long, hard trudge of steps 1-5.

It can also happen if you run into areas where you have limited knowledge, but you are getting hard to find errors. You finally solve one error that you spend days on just to get another one that takes a few days. 3 or 4 of these types of errors in a row can really take the wind out of your sails and make a project more frustrating than fun.

The only thing I can say to this is just try to stick with it, even if it means taking a break for a few days. When you take a little break, don't start a brand new project, just start a small side project, such as, build a space invaders clone in 72 hours. By finishing even a small project you will get an injection of energy that you can bring into your stalled project.

Also try to look at those tough errors as a learning experience. Those are the errors that you will always remember the solution too. It gets even more satisfying when you can use that solution to help answer a question in the forums.

I am writing a lot of mathematical implementations for my current project. Its boring as hell sometimes I just sit there and think about the most efficient way to implement it.

At former times I had an idea, began to implement it bang somewhen I lost interest and skipped it.
Now to keep me motivated I perform extensive unit testing on the individual modules which is actually some sort of feedback and the conciousness that it actually works.

Poor design is often a matter for lack of motivation since project complexity increases more and more.

I suggest you to divide your implementation ideas into tiny well design components and perform unit testing this has the advantage, you get reuseable and reliable code that shortens production times on the long run.

And don t start with side projects all the time, work on what you need to proceed with you current project. Just start working on it and you will most likely get motivated again.

p.s.: As jester mentioned already, investigate a little and make sure you understand what you are doing, this makes you feel a whole lot better

Quote:

Original post by Mad_Koder...and whalah...

The word is voilà, a french word equivalent of "ta da!", "presto change-o", or any sudden "look there"-type phrase (which is, incidentally, to what 'voilà' translates: voi=look, là=there). "Whalah" is a (likely American) mispronunciation of an actual word.

ItsDoh really hit the nail on the head. Writing 10k lines of code without some sort of "press the bar, get a cookie" obvious or visual reward is difficult if you haven't been programming for long. You can do things to ease your way into larger projects, such as utilizing libraries which do a lot of stuff for you and save you time. The other side of this might be that you aren't working from a design plan, even something simple like:

1. write a reusable sprite library
2. write a resource manager
3. write a config-file reader
4. write a level-map handler
5. ???
6. profit!

A project seems insurmountable when you have something like "step 1... write a game!", but if you actually break the project down into manageable parts like "step 1... write a cpp/h file for reading and playing sounds in stereo", then the job gets that much easier.

I either work a smaller project, or go and play a really graphics intensive game.

1. For the former, I recently decided that I have many, many, many wallpapers, but I don't like having a single one all the time, and I don't like wasting time selecting and changing the wallpaper, so I wrote a program to do it for me.

It started out just finding all the files with a particular extension in a particular directory, selecting one at random and setting the desktop wallpaper to it. Then I developed a small file format so it would keep track of the wallpapers that has been displayed for a single directory (each directory has their own file) and after all the wallpapers in the directory has been displayed, it would reset the file and start all over again.

Then I included support for more than 1 directory (the directories are also chosen from randomaly at runtime), and finally, most recently, I've included tinyXML so I can load the directories and other info from a config file.

That's what I do when I feel unmotivated with my graphics engine. It usually takes only a day or two to include a new feature to my wallpaper program from conception to compiling the release code so I can use the program.

2. For the latter, I recently bought Sin Episodes, and sometimes I just play that and get all excited by the graphics. I keep saying to myself "I want my engine to look like that!" and I then get enough excitement to go and do some more coding.

With me, once I add a feature and work out all the bugs, it's huge, clunky, awkward code. I make a backup, and then I refine the code to make it smaller, if possible, and easier to use. I find that I also have more motivation if, to use something that I finished writing a couple of days ago, I only have to write a line or two, instead of (sometimes) 10 or more.

I usually don't finish the projects I start, too, probably for the same reasons as you. The two exceptions where I can find the motivation to keep the work up are my 4 Elements project and my OS project (the OS project marginally so, I don't work on it that much but I haven't abandoned it, I go and add a new feature every now and then).

Here's what the main loop of my 4E project would look like:



It seems to work sometimes. [smile]

Hahaha, I seem to be a user of lib-boredom (with aimless staring of boredom trance), in fact, while writing this sentance I (ab)used stareAimlessAtWindow() :(