It was your average Tuesday, happy and warm. In truth, the day is vague in my memory, but I do suspect it wasn’t as warm as I’ve lead you to believe.
I’m sorry for the misunderstanding. We’re still friends, right?
It was December third (so in fact a Wednesday) when Shaun and I concluded that a contest was in order, described as follows:
A rough game demo playable for approximately two minutes. Emphasis on the word rough, which reminds me, i’ll go back and embolden it now. All art assets and code are to be poorly constructed, and no mind is to be paid to elegance and efficiency.
Why? It is a problem, if not instilled by, then certainly reinforced by Computer Science; this obsession with generality and elegance.
While good for a final product, for maintainability and adaptability, it is horrible – absolutely horrible – for getting things done quickly and simply.
It is completely psychological and I’m sure many of you share this affliction. You start to feel sick when you think of the structure of the project. All the needless interlinkings forming a confusing, chaotic, and side-effect prone web. All the places where efficiency, in hindsight and with usage statistics, could be increased. You end up in an endless loop; rewriting parts that work for greater efficiency or cleanliness, or worse still, restarting the entire project.
It gets to the point where, when you have to make a change or progress with the project, you simply don’t. The thought of increasing the detriments above by addition halts you in your queasy tracks. It is, I suppose, a form of debilitating perfectionism.
The result is nothing ever gets done, at least not to your satisfaction. There’s always something you could have done slightly better with what you know now.
The deadline is coming up (January third). We’ve kept our games secret from each other, so I’d better not reveal any details just yet, but I’ve done almost as much as I’m going to do for the demo itself. Which is good, because there’s still the design doc to go.
Design doc, you ask? Well, every contest has a winner. Wait; every good contest has a winner. And the winner of ours gets their demo rebuilt with nicer code and art. The result ideally being a polished demo for all to enjoy.
The design doc is to describe its development in depth, providing us with more than just the rough example to guide us.
I don’t really know how to write a design doc, so as I’ve learned at other businesses but try to avoid for my own, I’m going to wing it.
Either way, come December third, I’ll post some relevant links.