A fair amount of folks have taken the last few posts (on making games more cheaply and on rigid programming philosophies) to a bit of an extreme further than I intended. So in the spirit of contradicting myself, here are some good reasons to write new code.

When you have something new to learn.

I still remember how proud I was when I independently invented the bubble sort in response to a problem. Then how baffled I was when I tried to figure out how quicksort works.

Writing your own version of a known solution is a fantastic learning tool.  Trying to learn how to write jazz progressions? Grab a jazz song, change the key, and start modestly tweaking the chords (an 11th into an augmented, or whatever). Then build your own melody on top of it. Trying to learn how to draw? Start copying people who know how. Trying to figure out how a given game genre works? Try cloning or reverse-engineering a game in that genre. It’s a classic method of learning and there is no shame in it. If you have any creative spark, you’ll quickly move past this sort of journeyman work and start adding your own elements to it. (This is one of my caveats to Dan Cook’s post on game cloning).

Read the rest of this entry »

Rigid programming philosophies are the devil.

Look, I am upfront about the fact that I am not an amazing programmer. I am not even a really competent one. I hack. I didn’t go through a CS degree, I don’t actually know a lot of the lingo, etc.

On the other hand, I have in fact been credited as a programmer on published games. I have programmed in quite a lot of languages, I prototype my own stuff regularly, and my name is on several technical patents. I seem to have a knack for seeing architectural solutions to problems, and for inventing technical solutions. (I generally prefer to partner with a genius coder for the actual implementation thereof — and have been lucky enough to work with many of them!).

So take everything I am about to say with the appropriate grain of salt.

Read the rest of this entry »