<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	>
<channel>
	<title>Comments on: Design Documents</title>
	<atom:link href="http://www.stuffwelike.com/stuffwelike/2006/07/12/design-documents/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.stuffwelike.com/stuffwelike/2006/07/12/design-documents/</link>
	<description>Chronicling Internet Culture, One Bit at a Time</description>
	<pubDate>Thu, 20 Nov 2008 19:40:59 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.3</generator>
		<item>
		<title>By: David Rodriguez</title>
		<link>http://www.stuffwelike.com/stuffwelike/2006/07/12/design-documents/#comment-379</link>
		<dc:creator>David Rodriguez</dc:creator>
		<pubDate>Sat, 15 Jul 2006 20:16:07 +0000</pubDate>
		<guid isPermaLink="false">http://www.stuffwelike.com/stuffwelike/2006/07/12/design-documents/#comment-379</guid>
		<description>Exactly. It's tough and will take months to complete but it's definitely worth it in the end.</description>
		<content:encoded><![CDATA[<p>Exactly. It&#8217;s tough and will take months to complete but it&#8217;s definitely worth it in the end.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Kirby</title>
		<link>http://www.stuffwelike.com/stuffwelike/2006/07/12/design-documents/#comment-378</link>
		<dc:creator>Kirby</dc:creator>
		<pubDate>Sat, 15 Jul 2006 02:29:08 +0000</pubDate>
		<guid isPermaLink="false">http://www.stuffwelike.com/stuffwelike/2006/07/12/design-documents/#comment-378</guid>
		<description>I couldn't agree with you more. 

It's very tempting for inexperienced game programmers to overlook the need to "think it through". This can apply even to programmers who ARE experienced, but not with games! 

Games have a much larger design space than most computer applications. If you breezed through academia and think you can sit down and code ANYTHING, you're in for a rude awakening. Any kind of highly interactive, explorable simulation world is going to shock you for the *sheer number of relationships* you must manage. The complexity of this system grows geometricly with the number of components. In fact, games are about as hard as operating systems, only WITHOUT the decades of prior research behind them. 

The point of writing the design doc is not so you can get everything right so you can just program to predefined specs. Lots of things will go wrong when you try to implement even the most carefully written spec. However, having a detailed design doc means you will have explored a big part of the design space beforehand.. this is much more efficient exploration than waiting for your implementation to fail! When you have a real design doc, you can look at it any time during development, and say, oh yeah, I've explored this issue already, and these are the implications of doing that!</description>
		<content:encoded><![CDATA[<p>I couldn&#8217;t agree with you more. </p>
<p>It&#8217;s very tempting for inexperienced game programmers to overlook the need to &#8220;think it through&#8221;. This can apply even to programmers who ARE experienced, but not with games! </p>
<p>Games have a much larger design space than most computer applications. If you breezed through academia and think you can sit down and code ANYTHING, you&#8217;re in for a rude awakening. Any kind of highly interactive, explorable simulation world is going to shock you for the *sheer number of relationships* you must manage. The complexity of this system grows geometricly with the number of components. In fact, games are about as hard as operating systems, only WITHOUT the decades of prior research behind them. </p>
<p>The point of writing the design doc is not so you can get everything right so you can just program to predefined specs. Lots of things will go wrong when you try to implement even the most carefully written spec. However, having a detailed design doc means you will have explored a big part of the design space beforehand.. this is much more efficient exploration than waiting for your implementation to fail! When you have a real design doc, you can look at it any time during development, and say, oh yeah, I&#8217;ve explored this issue already, and these are the implications of doing that!</p>
]]></content:encoded>
	</item>
</channel>
</rss>
