Yeah thats a tough one. I only have a few friends who can beta for me so I try to be very careful about not sending ‘too much’ stuff for them to test/beta. And its really easy for those not invested in it to get burned out of you sending too much, too often.
Especially if its not particularly exciting or fun. Betaing is a lot of boring hardwork! :cranky:
I’ve been working on it for a year, and this is the first time I’ve asked for a bit of input… Anyway one of my testers came thru last night and found a neat usability problem.
First time poster, but I completely understand OP.
There are plenty of projects whether it’s game development, Java or another language where I get to a certain milestone and I just drop and do something else.
I don’t know if it’s ADD kicking in but I definitely need to harness myself into finishing all my projects.
Certain times the reason is because I take the hard way and decide to make some functionality that is tough to code (at least for me) and some of it requires understanding areas I have never dealt with and with that comes learning. Learning is not bad but at times it detracts me from the main point and that is to finish the project.
So don’t worry OP you’re not the only one. I actually worried I was the only one too! ;D
Hi
I advise developers to keep the source code as sexy as possible if they really want to spend a lot of time in, you see what I mean 
Sometimes I’m forced to take a break for months because of personal problems, when looking for a new job and/or a new girlfriend for example. If I didn’t comment my source code enough, my main project would have become quickly unmaintainable.
It depends on your personality. Working in a team almost demotivates me except in a very few projects whereas some people prefer not to work alone.
I was working on a project on FM synthesis well over a year ago, with the hopes of using patches I had created for my Yamaha DX7 synthesizer procedurally instead of as .wav files, and had managed some success. Patches with only two layers, a carrier and a modulator, were working. But I could neither figure out how to implement modulator “feedback” nor cascading modulators, which are important components of most of my favorite patches. The results of all attempts produced unexpected and undesired sounds.
I was unable to get any help at any forum. I found only one article that seemed to touch on the problem but the math was incomprehensible. After a certain amount of thrashing, I got discouraged and shelved the project. I had some ideas for possible tests to try and track down the problem, but never got around to doing them, though the problem remained in the back of my mind.
Two weeks ago, while making a digital flanger, something clicked and I had an insight that led to the solution. It’s not easy to explain, but involved calculating the modulation in a slightly different way, at a stage that was one step removed from what I had done before. It turns out that I had algorithmically hit on the difference between modulating frequency and modulating phase (PM), and the latter turns out to be the preferred method for cascading FM. (Also, none of the tests I was contemplating would have uncovered the problem, which has to do with frequency modulation sometimes creating 0 Hz energy that wreaks havoc with carriers that use FM as opposed to PM. So, it was just as well I let it go instead of wasting time trying hopeless ideas.)
I don’t think I would have figured this out if I hadn’t built the flanger, which has a modulation component to it. While making that, the experience made it possible to concretely understand the two different ways of programming a modulation. Once I had that, it became possible to understand that these (FM and PM) are two different things, and this even helped illuminate some of the math in the article I mentioned before.
So, just saying, sometimes a discouraging project just has to be put on a back burner. But that doesn’t mean there won’t be an insight down the road that will revive it. Sometimes it just takes time to develop the chops that allows one to even frame a problem in a useful way.
With my projects when I come up with an idea im like YER LETS GET CODIN , then I think of what i need to do and just get so demotivated about it.
After having lots of projects I get demotivated with, I compared them to my Ludum Dare entries and projects that I actually pick up again after a while (like Guardian II), and this is what I found:
It is not the scale of the project that demotivates you, it is the sense of “what to do next?”, or “where is this leading?”. Before you start a project, you should have a definite idea of what it will be when it’s complete*.
If you know what the end result will be, then you can work out what you need to do to get there. If you just have a vague idea of a cool mechanic, you will quickly get demotivated, and you will end up with what you planned for: Just a cool mechanic.
If I plan to make an MMORPG, I could probably succeed at that. I could program a server that can handle lots of clients. I could code the world, and it’s contents. I could implement quests etc. But that would be it. I would get demotivated and there would be no decent content.
However, if I plan to make an MMORPG with a set theme, storyline, characters, mechanics, etc. I am much more likely to succeed (at least the programming part. Getting the servers available, and people to play it is a completely different matter).
To summarize: What you plan for when you begin your game is very likely to be the end result.
*Complete and finished are 2 different concepts. The best way to see it is in Minecraft; It is definitely complete, but it is nowhere near finished.
EDIT: YAY! My 100th Medal!
I would just like to thank everyone on this thread.
After reading some of these responses, I finally picked up my project named ‘G581g’.
Thanks a ton!