<?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"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Game Design Research, ala Avellone</title>
	<atom:link href="http://www.edery.org/2007/01/game-design-research-ala-avellone/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.edery.org/2007/01/game-design-research-ala-avellone/</link>
	<description>For those interested in the business of making good video games. Entrepreneurial spirit a must.</description>
	<lastBuildDate>Fri, 09 Jul 2010 16:27:16 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.0</generator>
	<item>
		<title>By: Bongob</title>
		<link>http://www.edery.org/2007/01/game-design-research-ala-avellone/comment-page-1/#comment-41086</link>
		<dc:creator>Bongob</dc:creator>
		<pubDate>Tue, 30 Jan 2007 14:13:28 +0000</pubDate>
		<guid isPermaLink="false">http://www.edery.org/2007/01/game-design-research-ala-avellone/#comment-41086</guid>
		<description>This is great stuff, Chris. I’m absolutely in agreement with you about the importance of expanding your frame of reference. There are already enough games made out of bits of other games, TV made from more TV, movies made of elements of movies. My feeling is that most geeks/devs don’t need much encouragement to keep on consuming the media they’re already into, but need as much encouragement as they can get to start checking out new stuff, especially when it’s old stuff: history, literature, visual arts, let alone news coverage, scientific research or, gulp, Real Life.

You make some excellent points here and your illustrations would drive me mad with envy if they didn’t make me giggle so much, but I’d emphasize the difference between raw data and usable knowledge. For me, it’s part of what separate Pro’s from Paying Punters – Paying Punters point and clap at the puppet show; Pro’s get themselves backstage and work out which string pulls which limb. I don’t think people need much more practice at remembering the Cool Bits from games and movies and TV shows, but almost everyone needs more practice in working out why they’re cool, what it is about that technical solution that made it better than another, how was it put together, and what was so compelling about its presentation: the What isn’t as important as the Why and How. 

For instance, why did New-Monster-Every-Week one-or-two-episode morality play SciFi TV series like Star Trek and Doctor Who come up with the Transporter beam and the Tardis respectively? To what production problem was that the solution? Why didn’t they go with an expensive but heavily repeated sequence to get their protagonists to and from their weekly new locations, like Thunderbirds? The relative production costs of a single special effect shot compared to a three-minute model montage will tell you more than any retro-con backstory explanation.  

So my addendum to your advice to budding devs is to take all the games, TV shows and movies they love, and see those finished works not as monolithic blocks of Cool, but as a consequence of a series of design, direction and production decisions, decisions that can be analysed and reverse-engineered. Steal from the very best, I say! Just learning a few of the technical terms used by screenwriters, storyboard artists, directors, coders, sound designers, composers, actors and developers will give you more insight than memorizing every line of dialogue in every episode of every season of every franchise of StarTrek. Technical language is a kind of toolkit that lets you build something new, not just repeat something old. Knowing every episode featuring the character Data is just, well…data.  

Being able to analyse the Cool Bits doesn’t mean you appreciate them less, quite the reverse – it makes the Cool Bits cooler. As an example, take the famous lots-of-short-shots montage technique pioneered by Sergei Eisenstein. Every movie nerd will be able to tell you about the famous Odessa Steps sequence in The Battleship Potemkin, and most will know that Brian DePalma recreated it almost shot-for-for the train station shootout scene in The Untouchables (even the Great steal from the Best). The more I read about the critical theory that built up around Eisenstein’s technique, the more I appreciated his achievement, and dug the visual syntax of cinema, and how long and broad a shadow it casts on all subsequent movie and TV editing. But this was as nothing compared to the slack-jawed awe I felt when I found out that it was his work-around for a potentially show-stopping production problem: only very short lengths of filmstock were available at the time, so he invented a way of telling stories with very short shots. That’s not just smart, that’s flaming, strobing genius! Future developers, be inspired!</description>
		<content:encoded><![CDATA[<p>This is great stuff, Chris. I’m absolutely in agreement with you about the importance of expanding your frame of reference. There are already enough games made out of bits of other games, TV made from more TV, movies made of elements of movies. My feeling is that most geeks/devs don’t need much encouragement to keep on consuming the media they’re already into, but need as much encouragement as they can get to start checking out new stuff, especially when it’s old stuff: history, literature, visual arts, let alone news coverage, scientific research or, gulp, Real Life.</p>
<p>You make some excellent points here and your illustrations would drive me mad with envy if they didn’t make me giggle so much, but I’d emphasize the difference between raw data and usable knowledge. For me, it’s part of what separate Pro’s from Paying Punters – Paying Punters point and clap at the puppet show; Pro’s get themselves backstage and work out which string pulls which limb. I don’t think people need much more practice at remembering the Cool Bits from games and movies and TV shows, but almost everyone needs more practice in working out why they’re cool, what it is about that technical solution that made it better than another, how was it put together, and what was so compelling about its presentation: the What isn’t as important as the Why and How. </p>
<p>For instance, why did New-Monster-Every-Week one-or-two-episode morality play SciFi TV series like Star Trek and Doctor Who come up with the Transporter beam and the Tardis respectively? To what production problem was that the solution? Why didn’t they go with an expensive but heavily repeated sequence to get their protagonists to and from their weekly new locations, like Thunderbirds? The relative production costs of a single special effect shot compared to a three-minute model montage will tell you more than any retro-con backstory explanation.  </p>
<p>So my addendum to your advice to budding devs is to take all the games, TV shows and movies they love, and see those finished works not as monolithic blocks of Cool, but as a consequence of a series of design, direction and production decisions, decisions that can be analysed and reverse-engineered. Steal from the very best, I say! Just learning a few of the technical terms used by screenwriters, storyboard artists, directors, coders, sound designers, composers, actors and developers will give you more insight than memorizing every line of dialogue in every episode of every season of every franchise of StarTrek. Technical language is a kind of toolkit that lets you build something new, not just repeat something old. Knowing every episode featuring the character Data is just, well…data.  </p>
<p>Being able to analyse the Cool Bits doesn’t mean you appreciate them less, quite the reverse – it makes the Cool Bits cooler. As an example, take the famous lots-of-short-shots montage technique pioneered by Sergei Eisenstein. Every movie nerd will be able to tell you about the famous Odessa Steps sequence in The Battleship Potemkin, and most will know that Brian DePalma recreated it almost shot-for-for the train station shootout scene in The Untouchables (even the Great steal from the Best). The more I read about the critical theory that built up around Eisenstein’s technique, the more I appreciated his achievement, and dug the visual syntax of cinema, and how long and broad a shadow it casts on all subsequent movie and TV editing. But this was as nothing compared to the slack-jawed awe I felt when I found out that it was his work-around for a potentially show-stopping production problem: only very short lengths of filmstock were available at the time, so he invented a way of telling stories with very short shots. That’s not just smart, that’s flaming, strobing genius! Future developers, be inspired!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: TWMC</title>
		<link>http://www.edery.org/2007/01/game-design-research-ala-avellone/comment-page-1/#comment-40253</link>
		<dc:creator>TWMC</dc:creator>
		<pubDate>Fri, 26 Jan 2007 08:22:48 +0000</pubDate>
		<guid isPermaLink="false">http://www.edery.org/2007/01/game-design-research-ala-avellone/#comment-40253</guid>
		<description>I am currently in a game design program, and the above suggestions are exactly what my instructors had my classmates and I done all the time whenever we are developing game ideas.  But from what I learned in the program, the most important thing out of everything a game designer needs to be proficient at, is still the game mechanics; so be sure to have the following questions in mind whenever one is doing research for game in ways mentioned above in the article: setting, theme, characters, weapons, equipments, camera angles, pace, available actions that players can perform, how are the actions being controlled, how is the game being played, kind challenges the players will face, winning and losing condition, single player or multiplayer, saving and loading, game interfaces, music style, image style...etc.

The bottom line is: with the game mechanics being the core, come up with a vision that others have not done before, and is fun to your target audience, so they would want to play your game and enjoy while doing so.</description>
		<content:encoded><![CDATA[<p>I am currently in a game design program, and the above suggestions are exactly what my instructors had my classmates and I done all the time whenever we are developing game ideas.  But from what I learned in the program, the most important thing out of everything a game designer needs to be proficient at, is still the game mechanics; so be sure to have the following questions in mind whenever one is doing research for game in ways mentioned above in the article: setting, theme, characters, weapons, equipments, camera angles, pace, available actions that players can perform, how are the actions being controlled, how is the game being played, kind challenges the players will face, winning and losing condition, single player or multiplayer, saving and loading, game interfaces, music style, image style&#8230;etc.</p>
<p>The bottom line is: with the game mechanics being the core, come up with a vision that others have not done before, and is fun to your target audience, so they would want to play your game and enjoy while doing so.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Mark Nebesky</title>
		<link>http://www.edery.org/2007/01/game-design-research-ala-avellone/comment-page-1/#comment-39524</link>
		<dc:creator>Mark Nebesky</dc:creator>
		<pubDate>Tue, 23 Jan 2007 14:39:32 +0000</pubDate>
		<guid isPermaLink="false">http://www.edery.org/2007/01/game-design-research-ala-avellone/#comment-39524</guid>
		<description>very cool...</description>
		<content:encoded><![CDATA[<p>very cool&#8230;</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Zill</title>
		<link>http://www.edery.org/2007/01/game-design-research-ala-avellone/comment-page-1/#comment-39481</link>
		<dc:creator>Zill</dc:creator>
		<pubDate>Tue, 23 Jan 2007 09:20:19 +0000</pubDate>
		<guid isPermaLink="false">http://www.edery.org/2007/01/game-design-research-ala-avellone/#comment-39481</guid>
		<description>Thanks alot for this, Chris!!
I LOVE reading these kinds of things.
I love reading the ins and outs of game developing from every standpoint, be it programming or even publishing.
I can read this stuff all day, and it\&#039;s made especially better when it\&#039;s written by a designer I\&#039;m familiar with ;P</description>
		<content:encoded><![CDATA[<p>Thanks alot for this, Chris!!<br />
I LOVE reading these kinds of things.<br />
I love reading the ins and outs of game developing from every standpoint, be it programming or even publishing.<br />
I can read this stuff all day, and it\&#8217;s made especially better when it\&#8217;s written by a designer I\&#8217;m familiar with ;P</p>
]]></content:encoded>
	</item>
</channel>
</rss>
