About my process

One thing that I think I am starting to realize about my programming process is how important it is to me to be able to complete a task in a single session.

Each evening when I sit down to work on my game project, I don’t usually have a specific idea about exactly what I want to work on or accomplish. I do have a lot of general ideas. I have a list of things, a backlog of features that I have brainstormed but have yet to implement, or have yet to implement to my complete satisfaction, and a rough idea of the priority I’d like to give on each item in that list. When I sit down to being my development session, I review the list and pick something. As I continue to develop, I continually update the list, usually removing things from it that I’ve completed (it makes me happy/inspired to see the list shrink), but sometimes adding new things if an idea comes to me or I realize a new problem has come up as a result of something I’ve been working on.

I am not strict about working on items in priority order. To some extent I am taking things in order of importance, but mostly I try to work on the most important thing that is also easy to accomplish quickly — the so-called low-hanging fruit type stuff that is easy to do and provides a high value to the project. To a larger extent, I work on things in the order that I can work on them — some things are dependent upon other things and I have to do those things first in order to be able to do the next thing. Or sometimes I need to learn more about something in order to do it, and doing something else first will give me the opportunity to start to get into that topic in a more lightweight and manageable fashion.

Sometimes I just work on something that I happen to be interested in at the moment — it is important to recognize the power that having an interest in something has. If you’re interested in something, engaging with it is easy and natural. If you’re not interested in something, it’s hard. If you’re actually interested in something else, it can be all but impossible.

Having a sense of progress and momentum is extremely important to maintaining my morale and motivation.

I like to work in long, mostly uninterrupted sessions. I’ll start around 6-7pm and stop around midnight-1am. I don’t just work on the project during this session, though — I read my usual websites, do email, make dinner, chat with friends over IM. I find that this does not interfere or impede my progress or ability to focus, and any of these “distractions” makes for a good punctuation mark that allows me to take a breather and come back to the project with renewed energy.

I don’t even spend most of my project time developing and coding. The coding part of the work just doesn’t take that much time. I spend more time building and playing, then going back and tweaking something, building, adding a tiny little bit, and replaying, again and again, until I get what I wanted, or, often, figure out what I wanted. A lot of times, an idea I had at first is not really as good as I thought once I have built it, but something else that is close to that is better. By carefully testing each little change iteratively as I build, I ensure that I move in a steady direction toward a successful design. This is much better than trying to design everything out on paper before I put any time into building it, by far.

When I first sit down to work for the evening, I have in mind a goal to improve some aspect of it, and by the time I am ready to put the project down again, leave the game in a state where it is both playable and improved from the last iteration. I sit down and look at my list, mull things over for a bit, do a little bit of planning and thinking, and then start building. As I build, I document what I’m doing.

The first thing I do with each session is to create a new version of my project. I don’t stop working until I’m satisfied that what I built works the way I wanted it to, and results in a better game than what I started with.

I’m not sure how sustainable this is, this approach of having tiny tasks and completing them in one session, but as much as possible, I want it to be. I find that I am far more productive in my project as I am working if I can complete* some aspect in one sitting, as it were. If I don’t make it, I run the risk of losing my thought process and not being able to pick up where I left off. I think of it like writing a book — you don’t want to just cut off in mid sentence. And ideally, you’d like to be able to complete a chapter, or at least a thought.

*When I say “complete”, I don’t mean “final”. I will likely go back again and make further refinements when the time is right. For example, when I started implementing my enemy objects, at first I just placed them into the game as immobile objects. I next focused on interactions with the player object. In a later session I added very basic movement, and spent a lot of time tweaking that. In upcoming sessions I plan to further refine enemy movement, adding different modes and coming up with some AI routines that determine how the enemy “decides” what mode to be in depending on what’s going on in the game.

My guess is that if you architect your program the right way, you should always, or nearly always be able to use this approach of tiny steps over many iterations. To extend the architecture metaphor a bit, if you’re laying bricks, to build a bigger building you just use more bricks — you don’t suddenly have to switch to bigger bricks that become unmanageable for one person to wrangle. That may not always hold true, but my feeling is that it should most of the time.