<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/1.5.2" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comments on: Write a FAQ for your favorite game</title>
	<link>http://www.patrickcurry.com/thoughts/write-a-faq-for-your-favorite-game/</link>
	<description>A new game idea every week and other ramblings on game design from an upstart game designer.</description>
	<pubDate>Mon, 06 Sep 2010 15:05:47 +0000</pubDate>
	<generator>http://wordpress.org/?v=1.5.2</generator>

	<item>
 		<title>Comment on Write a FAQ for your favorite game by: Patrick</title>
		<link>http://www.patrickcurry.com/thoughts/write-a-faq-for-your-favorite-game/#comment-13306</link>
		<pubDate>Sat, 30 Jun 2007 07:09:58 +0000</pubDate>
		<guid>http://www.patrickcurry.com/thoughts/write-a-faq-for-your-favorite-game/#comment-13306</guid>
					<description>I’m personally a big fan of GDDs.  If for no other reason then I can write down everything I think about an idea, feature, or mode... and when people on the team come ask questions I can quickly look up the answers for them.  But I also like having a roadmap for making games.  Sure, we take tons of detours along the way, and sometimes we come back to a GDD and decide that it's crap.  But we usually start prototyping what's in the GDD.

I'm also a huge Cerny fan, but even he will tell you to make a detailed production plan and schedule.  At some point you have to have written down everything you plan to do, and more or less how you're going to do it.  This can come after a ton of prototyping... or if you're making a game in an established genre or a sequel, you can probably do it before you're even done with the first game.  On a team like ours that's very design-driven, a GDD is as good a place for that plan to start as any.</description>
		<content:encoded><![CDATA[	<p>I’m personally a big fan of GDDs.  If for no other reason then I can write down everything I think about an idea, feature, or mode&#8230; and when people on the team come ask questions I can quickly look up the answers for them.  But I also like having a roadmap for making games.  Sure, we take tons of detours along the way, and sometimes we come back to a GDD and decide that it&#8217;s crap.  But we usually start prototyping what&#8217;s in the GDD.</p>
	<p>I&#8217;m also a huge Cerny fan, but even he will tell you to make a detailed production plan and schedule.  At some point you have to have written down everything you plan to do, and more or less how you&#8217;re going to do it.  This can come after a ton of prototyping&#8230; or if you&#8217;re making a game in an established genre or a sequel, you can probably do it before you&#8217;re even done with the first game.  On a team like ours that&#8217;s very design-driven, a GDD is as good a place for that plan to start as any.
</p>
]]></content:encoded>
				</item>
	<item>
 		<title>Comment on Write a FAQ for your favorite game by: gman</title>
		<link>http://www.patrickcurry.com/thoughts/write-a-faq-for-your-favorite-game/#comment-13245</link>
		<pubDate>Wed, 27 Jun 2007 18:04:30 +0000</pubDate>
		<guid>http://www.patrickcurry.com/thoughts/write-a-faq-for-your-favorite-game/#comment-13245</guid>
					<description>GDD = bad

http://www.gamasutra.com/features/slides/cerny/index.htm

At least that's my experience. Teams that didn't have a GDD got their stuff done and on time. Teams that had a GDD were approaching the problem the wrong way. Expecting team members to reference a constantly updated 400 page GDD is ignoring reality.

I know it's probably wrong for me to equate having a GDD with bad practices but what is the point of a GDD? To spell out the game design so it can be built. And how do you know what the game design is? By building the game and trying things out. Hmmm, sounds like a catch 22. You can't write the GDD until you know what works, you can't know what works until you build the game and by most logic you can't build the game until you write a GDD. So, don't write a GDD. Just build the game.

Sure you need a general outline but you don't need a GDD.</description>
		<content:encoded><![CDATA[	<p>GDD = bad</p>
	<p><a href='http://www.gamasutra.com/features/slides/cerny/index.htm' rel='nofollow'>http://www.gamasutra.com/features/slides/cerny/index.htm</a></p>
	<p>At least that&#8217;s my experience. Teams that didn&#8217;t have a GDD got their stuff done and on time. Teams that had a GDD were approaching the problem the wrong way. Expecting team members to reference a constantly updated 400 page GDD is ignoring reality.</p>
	<p>I know it&#8217;s probably wrong for me to equate having a GDD with bad practices but what is the point of a GDD? To spell out the game design so it can be built. And how do you know what the game design is? By building the game and trying things out. Hmmm, sounds like a catch 22. You can&#8217;t write the GDD until you know what works, you can&#8217;t know what works until you build the game and by most logic you can&#8217;t build the game until you write a GDD. So, don&#8217;t write a GDD. Just build the game.</p>
	<p>Sure you need a general outline but you don&#8217;t need a GDD.
</p>
]]></content:encoded>
				</item>
</channel>
</rss>
