When I first joined BYOND, I was a “game making machine”. I could work on one game for months and easily move onto a new project. But at the same time, I could still work on the preceding project with no loss of enthusiasm. Those days are long gone; I can barely stay with one project for more than a day.

We all suffer from the “loss of motivation disease” while programming. You would imagine after being on BYOND for a few years, and having a pleasant grip on the language, that we could “pop” out great games non stop. But when programming, we usually get far with our project but then move on to something else. Although, you could also blame it on the lack of ideas we have, but I will save that topic for another post.

In my previous post I spoke about several rules which would be great to follow if you want to help prevent the “loss of motivation disease”. Now in this post, I hope to accomplish the task of expanding on the Repetition/Challenge rule.

What I have found, which is widespread knowledge, was that working on a project in which the code is very similar to a previous project will cause motivational loss. Having to construct an extensive proc, which could extend on for a few hundred lines, is just exhausting.

Even creating an essential login snippet bores people. But what exactly is boredom? Wikipedia defines it as an emotional state experienced during periods of lack of activities or when individuals are uninterested in the activities surrounding them. We are not interested with the current section we are programming. This is why I previously said to pick something that will challenge you when you attempt to program it.

It is tedious for us to repeat the same action over and over, so having the television on while programming just lengthens the process of creating your game. Mainly because what ever is on the television is a lot less dull.

A question comes to mind, “How can I complete a game if repetition will eventually ‘kill’ my project?” The best answer to such a question is by making a Modular System. What I mean by that is, once you finish lets say a death check proc, you can easily transfer it into a new project without having to change it much. By doing such a thing, you will no longer have to repetitively generate a 100 line proc from scratch.
You're still cool :)
This is sort of why I postponed GrimTunnel. I wanted to release some libraries to take care of the repetitive stuff. I recently uploaded the last one I planned. Now GrimTunnel will be a test of the libraries in an actual project and I won't have to rewrite as much code in my next game.
I made my library's from previous creations, I gave up making them then just released things that BYOND didn't have, or already had but was poorly programed.
IainPeregrine had a post on modular procs? If I had know that, I would have just told people about his, rather than making my own!
100 line proc? The only thing I've written which is quite that large is the parse_grid proc in the dmp_reader, and that's commented, and a source of embarrassment for me.

The largest procs I write now-a-days are around 50 lines, because I generally farm out arithmetic to other objects.
At various points in a project its easy to feel like you're not making any progress. This is why I find it is best to map out your project before you start. This way you can look at what you've done against the map and know that you've actually made progress.

I think the reason why people get such a buzz from programming earlier on is that everything is amazing. You make a HUD and you're genuinely impressed with yourself. This buzz gives you a sort of hyper-motivation.
Later on even when you're breaking new ground there isn't much challenge too it. You may not have made that specific system before, but you went into it completely understanding the core elements of it. It was simply a new way of applying your old knowledge.
At this point you lose this hyper-motivation and downgrade to just normal 'I'd like to complete this' motivation, which isn't enough to get most people to put themselves through what is honestly a pretty boring process.
Occasionally you'll tackle a problem from a new, unexpected angle and it'll change the way you thought about things, but for the most part the sense of accomplishment from completing the day-to-day aspects of the game is gone.

This is why a lot of developers make more progress once their project is released (even if it was released in a less than perfect package). You've got not only the standard motivation, but you've also got pressure from the people playing your game.