Pompi Pompi – A Gamers and Developers blog for indie games

I had a rough time the last week. Some stuff related to my game were frustrating me, and some difficult events at work. The thing is, a week ago I had a lot of motivation and everything was going fine and smooth.
I am not sure this is accurate or the absolute truth, but there seem to be a matter of inertia in motivation and developing a game. If you are already feeling good about working on your game and you are excited about it, its easier to keep on doing it. However, something like events related and not related directly to your game, could stop your wheel from rolling. After you stopped developing and doing the stuff you enjoyed doing, suddenly its very difficult to get back to it.
I was too lazy to work on my game, even though I knew that two weeks ago I had a lot of fun doing just that. Then I told myself what I have already learned from these kind of situations, you have to force yourself to work on your game. Even though its boring, you have to start pushing the wheel, and its hardest to push a standing wheel.
But it didn’t help, I was still too lazy to do it. Then I had thought to refine this “force yourself” method. I know it worked for me before, but now its not working. The refinement would be, start with the easiest things at first that would motivate you. Such as writing this blog(another good reason to write development blogs). Another thing is to have others set deadlines for you. For instance, if you work with a sound guy, you can decide that you have one month to complete the sound effects. Soon he will be sending you sound effects and you will have to work on them, because you have set a deadline.
We can learn from this that not all the things have the same difficulty when you are unmotivated. And if you see that you are too lazy to do something, it doesn’t mean you can’t do anything. You just need to find easy things to do first, soon you will start catch up and do the harder stuff as well. Finding external motivators can also help, such as having someone you work with set up a deadline to force you work on stuff. And eventually, remember that starting is the most difficult part, and after you start it will soon become easier. Although you have to remember this might be more complicated, but it might still help you thinking about it.
I will be glad to hear about your own experience and your own insights.

For the project Banana Jump, Barrel Kick, I thought to use Tortoise SVN. I have used Tortoise at work a bit, but I never got to install it or read about it. After installing Tortoise I have decided to start reading the Help file. However, I was also working on Labyrinthia which means I had to work on either one of them, or both of them simultaneously.

Part of the builds and compiling of Laby took a long time, leaving me the option to read on one computer while my other computer is building. The first problem I encountered is that I didn’t know when the other computer completed a build. And since Laby is my primary project, that was a problem. I solved this in Visual C++ 2005 by simply adding a Dos command line that plays a wav file every time the build was completed.
In “Project->Properties->Configuration Properties->Build Events->Post-Build Event”, I have added the command line "c:\Program files\Windows Meida Player\mplayer2.exe" /play /close "D:\Projects\Music\MenuMusic.Wav"
This is a partial solution, because it would only play music if the build was successful. But that was enough for my needs at that time.

I was multi tasking reading and building for a while, but unlike the previous technical problem, I encountered a problem of a different nature. The Tortoise Help document has a few chapters in it. The first few chapters are short and can be read quickly. However, I reached a chapter that I feared was too long to be going back and forth, and I wouldn’t be able to understand it this way. This is a very important point, this fear was irrational. I wasn’t actually scared of anything, I just wanted to move back to the usual patterns in my brain that told me to work on only a single task at a time. I was back to working on a single task, developing Laby. Very quickly I found myself surfing the Internet, waiting for compilations to complete. It took me a while, but eventually I thought, what if I would read the Help file and work on Laby simultaneously, even though its a long chapter? The answer is, I didn’t have an answer. But I didn’t even try. Only by trying I would know if I could handle it. Then I also thought, what if I would read and won’t understand? I can always read it again and its better than just surfing the web. So there is no big loss here as well. That drove me to try read the “big” chapter and develop simultaneously. After actually trying to do it, I realized it was really easy. This might be just the case with me, but I think my brain don’t like to “break the patterns” and prefer to do what is familiar, even if its not the best choice.
I think trying to do something different than what you are used to, could be beneficial, even if you didn’t achieve the ultimate goal by doing that. And in respect to programming, you should try to work on two things simultaneously, even if you think you wouldn’t be able to.