<?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: Physician, Advise Thyself</title>
	<atom:link href="http://brokentoys.org/2009/11/04/physician-advise-thyself/feed/" rel="self" type="application/rss+xml" />
	<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/</link>
	<description>Random Comments About Games and Tractors</description>
	<lastBuildDate>Thu, 18 Mar 2010 22:38:33 -0700</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
		<item>
		<title>By: Wolfhsead</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36197</link>
		<dc:creator>Wolfhsead</dc:creator>
		<pubDate>Tue, 10 Nov 2009 11:22:13 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36197</guid>
		<description>Forget game design and the video game industry entirely unless you are a masochist and like working long hours for moron. If you really must get a job in the industry then become a programmer/coder; you&#039;ll make far more money and you have quantifiable and bankable skills. 

Instead get a job in the government. It&#039;s far less work, they&#039;ll promote you if you&#039;re mediocre, you great benefits and job security.</description>
		<content:encoded><![CDATA[<p>Forget game design and the video game industry entirely unless you are a masochist and like working long hours for moron. If you really must get a job in the industry then become a programmer/coder; you&#8217;ll make far more money and you have quantifiable and bankable skills. </p>
<p>Instead get a job in the government. It&#8217;s far less work, they&#8217;ll promote you if you&#8217;re mediocre, you great benefits and job security.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: geldonyetich</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36062</link>
		<dc:creator>geldonyetich</dc:creator>
		<pubDate>Sat, 07 Nov 2009 06:04:44 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36062</guid>
		<description>@gyrus
A difficult assertion to prove.</description>
		<content:encoded><![CDATA[<p>@gyrus<br />
A difficult assertion to prove.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gyrus</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36061</link>
		<dc:creator>gyrus</dc:creator>
		<pubDate>Fri, 06 Nov 2009 22:43:21 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36061</guid>
		<description>@geldonyetich,
I would disagree that game design is hard.  I believe it is (partly) an art.
A such, some people can and some people can&#039;t.  Even people who understand all the technical details may never ever get &#039;good&#039; at it.</description>
		<content:encoded><![CDATA[<p>@geldonyetich,<br />
I would disagree that game design is hard.  I believe it is (partly) an art.<br />
A such, some people can and some people can&#8217;t.  Even people who understand all the technical details may never ever get &#8216;good&#8217; at it.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Axecleaver</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36054</link>
		<dc:creator>Axecleaver</dc:creator>
		<pubDate>Fri, 06 Nov 2009 20:17:44 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36054</guid>
		<description>&quot;I wish I knew how to interview people more effectively. It seems like an art form unto itself.&quot;

It is. 

I do a lot of technical hiring - programmers, DBAs, analysts and customer facing relationship management people. The most important advice I ever got on hiring is to use an experiential interview methodology. Don&#039;t ask &quot;how would you approach the design of the economic portion of this game?&quot; Ask instead, &quot;At your last job, how did you contribute to the design of the economic portion of the game?&quot; 

Because the fact is, 80% of the people who you interview can tell you what you want to hear about how to design games. Very few people have actually done it successfully, anywhere, and can back that up with articulate experienced-based stories about how they did that. Watch their body language when they&#039;re telling these stories for clues they&#039;re making it all up. If you find someone who is telling the truth and has complete, well-developed narratives about how the design process works, you hire them. 

Scott, regarding your process, which seems to involve years of design in a vacuum followed by surprise that people don&#039;t read what you developed while you were completely disconnected from the implementation team, have you ever considered implementing an Agile methodology for game design? Typically Agile is used when the requirements are poorly defined or the entire universe of requirements is unknown, and development must start before requirements can be frozen. Game design isn&#039;t like that. But another nice benefit of Agile is that it delivers iterative demos of functionality that get the product closer and closer to perfect. This helps you actually ship a product, instead of spending two years in the design stage, you spend thirty day sprints defining requirements, designing, constructing, testing, and finally building and delivering a demo. 

This gives your developers a chance to interact meaningfully with design people very early in the product lifecycle. You don&#039;t waste a year designing something impractical that can never be implemented.</description>
		<content:encoded><![CDATA[<p>&#8220;I wish I knew how to interview people more effectively. It seems like an art form unto itself.&#8221;</p>
<p>It is. </p>
<p>I do a lot of technical hiring &#8211; programmers, DBAs, analysts and customer facing relationship management people. The most important advice I ever got on hiring is to use an experiential interview methodology. Don&#8217;t ask &#8220;how would you approach the design of the economic portion of this game?&#8221; Ask instead, &#8220;At your last job, how did you contribute to the design of the economic portion of the game?&#8221; </p>
<p>Because the fact is, 80% of the people who you interview can tell you what you want to hear about how to design games. Very few people have actually done it successfully, anywhere, and can back that up with articulate experienced-based stories about how they did that. Watch their body language when they&#8217;re telling these stories for clues they&#8217;re making it all up. If you find someone who is telling the truth and has complete, well-developed narratives about how the design process works, you hire them. </p>
<p>Scott, regarding your process, which seems to involve years of design in a vacuum followed by surprise that people don&#8217;t read what you developed while you were completely disconnected from the implementation team, have you ever considered implementing an Agile methodology for game design? Typically Agile is used when the requirements are poorly defined or the entire universe of requirements is unknown, and development must start before requirements can be frozen. Game design isn&#8217;t like that. But another nice benefit of Agile is that it delivers iterative demos of functionality that get the product closer and closer to perfect. This helps you actually ship a product, instead of spending two years in the design stage, you spend thirty day sprints defining requirements, designing, constructing, testing, and finally building and delivering a demo. </p>
<p>This gives your developers a chance to interact meaningfully with design people very early in the product lifecycle. You don&#8217;t waste a year designing something impractical that can never be implemented.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Vetarnias</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36041</link>
		<dc:creator>Vetarnias</dc:creator>
		<pubDate>Fri, 06 Nov 2009 17:54:21 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36041</guid>
		<description>@Geldon

Yeah, I have a tendency to go on tangents like that, but it&#039;s not in an attempt to enter the games industry, I assure you. :P

It&#039;s just that it&#039;s something I like to discuss, and I&#039;m semi-notorious for my meandering posts (or at least, I should be). I may wander off course, but I never stray too far, and always come back to the original topic.

Yeah, I don&#039;t doubt that game design is hard, even if it were free of all extraneous concerns (*cough* &quot;WoW killer&quot;), so I admire independents who design games, as opposed to large studios that don&#039;t really care about design as long as the game sells.</description>
		<content:encoded><![CDATA[<p>@Geldon</p>
<p>Yeah, I have a tendency to go on tangents like that, but it&#8217;s not in an attempt to enter the games industry, I assure you. <img src='http://brokentoys.org/wp-includes/images/smilies/icon_razz.gif' alt=':P' class='wp-smiley' /> </p>
<p>It&#8217;s just that it&#8217;s something I like to discuss, and I&#8217;m semi-notorious for my meandering posts (or at least, I should be). I may wander off course, but I never stray too far, and always come back to the original topic.</p>
<p>Yeah, I don&#8217;t doubt that game design is hard, even if it were free of all extraneous concerns (*cough* &#8220;WoW killer&#8221;), so I admire independents who design games, as opposed to large studios that don&#8217;t really care about design as long as the game sells.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: geldonyetich</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36038</link>
		<dc:creator>geldonyetich</dc:creator>
		<pubDate>Fri, 06 Nov 2009 17:26:52 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36038</guid>
		<description>&lt;blockquote&gt;Hmm, so MMORPG.com has added both Travian and Evony.
[...]
And underneath it all, what concerns me is the revisionism this would involve, you know, that UO wasn’t really an MMORPG because it wasn’t in 3D
[...]
I was not too sure what “crop locking” was, but after looking it up, I just realize it’s a Travian-specific term for someone being a larger player’s perpetual farm. [...]  In Utopia, for example, the game resetted every few months [...] it would just be a vicious circle from which no escape was possible. [...] The same old kingdoms, with the same old people, who knew every trick, used every add-on [...] The big fish went after the medium fish, the medium fish went after the small fish, and so on. [...] The official term for such a thing was “bottom-feeding”.
[...]
I got into the game on a server already well under way, with three friends, and we formed our own clan. [...] until you looked at the map, and realized that the number one clan controlled an entire quadrant[...]The writing was on the wall, so I quit. &lt;/blockquote&gt;
I think you might have wandered a little off course there, buddy.  The topic was what constitutes game designer qualifications.

Oh wait, I get it, you&#039;re demonstrating you can indeed give your opinion about what was wrong with the past games you played in a verbose manner.  Well, okay - one does what they&#039;ve got to do to seem visible in this job market, I suppose.

Honestly, I couldn&#039;t do that.  Sure, I&#039;ve got some 26 years of hardcore game-playing experience, but I started to clam up after I started to design games in my spare time.  There something about discovering first hand that game design is &lt;b&gt;hard&lt;/b&gt; that makes one a bit more forgiving.

Many of the issues you outlined here, for example, with crop-locking and so on - a better question is how to &lt;i&gt;solve&lt;/i&gt; the problems at hand.  In my current design, &lt;a href=&quot;http://www.byond.com/members/Geldonyetich?command=view_post&amp;post=84933&quot; rel=&quot;nofollow&quot;&gt;last entry I spoke about it&lt;/a&gt;, I mentioned that I want to keep the number of player numbers small in order to allow players to have an intimate, X-Com squaddie-like, connection to their units.  However, that wasn&#039;t the only reason - the other reason is because if you give players too much power - too many units or territory under control - all of the problems you just mentioned about &quot;the writing being on the wall&quot; will manifest because it snowballs.  If you want fights to be fair, and players to have to perpetually work towards success, you have to limit them.  Otherwise, it&#039;s just a matter of disproportional time investment leading to imbalance, which you can bank on occurring.

So, yes, the best education of a game designer?  The same as any other valued skill.  Practice, practice, practice.</description>
		<content:encoded><![CDATA[<blockquote><p>Hmm, so MMORPG.com has added both Travian and Evony.<br />
[...]<br />
And underneath it all, what concerns me is the revisionism this would involve, you know, that UO wasn’t really an MMORPG because it wasn’t in 3D<br />
[...]<br />
I was not too sure what “crop locking” was, but after looking it up, I just realize it’s a Travian-specific term for someone being a larger player’s perpetual farm. [...]  In Utopia, for example, the game resetted every few months [...] it would just be a vicious circle from which no escape was possible. [...] The same old kingdoms, with the same old people, who knew every trick, used every add-on [...] The big fish went after the medium fish, the medium fish went after the small fish, and so on. [...] The official term for such a thing was “bottom-feeding”.<br />
[...]<br />
I got into the game on a server already well under way, with three friends, and we formed our own clan. [...] until you looked at the map, and realized that the number one clan controlled an entire quadrant[...]The writing was on the wall, so I quit. </p></blockquote>
<p>I think you might have wandered a little off course there, buddy.  The topic was what constitutes game designer qualifications.</p>
<p>Oh wait, I get it, you&#8217;re demonstrating you can indeed give your opinion about what was wrong with the past games you played in a verbose manner.  Well, okay &#8211; one does what they&#8217;ve got to do to seem visible in this job market, I suppose.</p>
<p>Honestly, I couldn&#8217;t do that.  Sure, I&#8217;ve got some 26 years of hardcore game-playing experience, but I started to clam up after I started to design games in my spare time.  There something about discovering first hand that game design is <b>hard</b> that makes one a bit more forgiving.</p>
<p>Many of the issues you outlined here, for example, with crop-locking and so on &#8211; a better question is how to <i>solve</i> the problems at hand.  In my current design, <a href="http://www.byond.com/members/Geldonyetich?command=view_post&amp;post=84933" rel="nofollow">last entry I spoke about it</a>, I mentioned that I want to keep the number of player numbers small in order to allow players to have an intimate, X-Com squaddie-like, connection to their units.  However, that wasn&#8217;t the only reason &#8211; the other reason is because if you give players too much power &#8211; too many units or territory under control &#8211; all of the problems you just mentioned about &#8220;the writing being on the wall&#8221; will manifest because it snowballs.  If you want fights to be fair, and players to have to perpetually work towards success, you have to limit them.  Otherwise, it&#8217;s just a matter of disproportional time investment leading to imbalance, which you can bank on occurring.</p>
<p>So, yes, the best education of a game designer?  The same as any other valued skill.  Practice, practice, practice.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Blackblade</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36036</link>
		<dc:creator>Blackblade</dc:creator>
		<pubDate>Fri, 06 Nov 2009 17:23:01 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36036</guid>
		<description>@Steve


You&#039;re sort of illustrating a point for me. You are asking from a programmers perspective, but is a &quot;Designer&quot; in the context of game design just a Programmer? Are game Game Designers, not Developers or Programmers,  really working out pathing functions for character movements? It seems to me they would be very distinct jobs, and part of the problem might be that when people say &quot;Designer&quot;, it&#039;s definition gets mixed and mingled with what I would view as a Developer or Programmer.


Assuming that a &quot;Designer&quot; is someone who actually thinks out the ebb and flow of the game (Zone layout, quest layout, theme and feel of the world - Content, to use a very generic term), clearly an understanding of programming is helpful, especially when considering what is possible. But do they often find themselves often developing key code systems like that?


As I&#039;ve never been in the business, I honestly don&#039;t know. But I do know, that as a DBA, my job is typically ensuring the performance and support for our databases and all applications that connect to it. Doing backups, security, configuration, enforcing imposed constraints (object naming, etc), troubleshooting connection and performance issues, and other maintenance tasks such as maintaining database size and index fragmentation constitute my primary job. Since we are a relatively small IT team, I&#039;m also a Database Developer - Building tables, functions, stored procedures, views, reports, ETL operations, query optimizations, etc., for the entire company.  Clearly having an understanding of both sides helps  me perform both jobs better, but certainly if this were a larger department,  I&#039;d like to have a developer who can take the time and focus to ensure what&#039;s developed is of the highest quality, while I could focus on maintaining the systems themselves. That isn&#039;t to say they should never overlap, but there are certain points where we could concretely say, &quot;This is a developer issue, this is an administration issue.&quot;


I guess I&#039;m wondering where those distinctions are made in the game industry, because they way you describe it, it sounds like a &quot;Designer&quot; is just a &quot;Developer&quot; with content work piled on top. And maybe that&#039;s the way it&#039;s supposed to be(?).</description>
		<content:encoded><![CDATA[<p>@Steve</p>
<p>You&#8217;re sort of illustrating a point for me. You are asking from a programmers perspective, but is a &#8220;Designer&#8221; in the context of game design just a Programmer? Are game Game Designers, not Developers or Programmers,  really working out pathing functions for character movements? It seems to me they would be very distinct jobs, and part of the problem might be that when people say &#8220;Designer&#8221;, it&#8217;s definition gets mixed and mingled with what I would view as a Developer or Programmer.</p>
<p>Assuming that a &#8220;Designer&#8221; is someone who actually thinks out the ebb and flow of the game (Zone layout, quest layout, theme and feel of the world &#8211; Content, to use a very generic term), clearly an understanding of programming is helpful, especially when considering what is possible. But do they often find themselves often developing key code systems like that?</p>
<p>As I&#8217;ve never been in the business, I honestly don&#8217;t know. But I do know, that as a DBA, my job is typically ensuring the performance and support for our databases and all applications that connect to it. Doing backups, security, configuration, enforcing imposed constraints (object naming, etc), troubleshooting connection and performance issues, and other maintenance tasks such as maintaining database size and index fragmentation constitute my primary job. Since we are a relatively small IT team, I&#8217;m also a Database Developer &#8211; Building tables, functions, stored procedures, views, reports, ETL operations, query optimizations, etc., for the entire company.  Clearly having an understanding of both sides helps  me perform both jobs better, but certainly if this were a larger department,  I&#8217;d like to have a developer who can take the time and focus to ensure what&#8217;s developed is of the highest quality, while I could focus on maintaining the systems themselves. That isn&#8217;t to say they should never overlap, but there are certain points where we could concretely say, &#8220;This is a developer issue, this is an administration issue.&#8221;</p>
<p>I guess I&#8217;m wondering where those distinctions are made in the game industry, because they way you describe it, it sounds like a &#8220;Designer&#8221; is just a &#8220;Developer&#8221; with content work piled on top. And maybe that&#8217;s the way it&#8217;s supposed to be(?).</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gyrus</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36029</link>
		<dc:creator>gyrus</dc:creator>
		<pubDate>Fri, 06 Nov 2009 15:56:06 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36029</guid>
		<description>I think it helps to understand the capabilities of a system and programming language though.
In my current job I have to work with company software which, to be very very kind, is not very good.
Sadly though, many people simply &#039;accept it&#039; and in most cases that is because the IT departments and teams tell then that this and that is &#039;not possible&#039;.
I started a huge row a couple of years ago by showing that something a customer requested was in fact possible (the programmers concerned were just being lazy - it was to do with alpha numeric inputs and sorting of that data).
So while I agree that a designer need not need to be a programmer - it certainly doesn&#039;t hurt.</description>
		<content:encoded><![CDATA[<p>I think it helps to understand the capabilities of a system and programming language though.<br />
In my current job I have to work with company software which, to be very very kind, is not very good.<br />
Sadly though, many people simply &#8216;accept it&#8217; and in most cases that is because the IT departments and teams tell then that this and that is &#8216;not possible&#8217;.<br />
I started a huge row a couple of years ago by showing that something a customer requested was in fact possible (the programmers concerned were just being lazy &#8211; it was to do with alpha numeric inputs and sorting of that data).<br />
So while I agree that a designer need not need to be a programmer &#8211; it certainly doesn&#8217;t hurt.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: UnsGub</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36027</link>
		<dc:creator>UnsGub</dc:creator>
		<pubDate>Fri, 06 Nov 2009 15:42:35 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36027</guid>
		<description>&quot;This is due to the designer not consulting with programmers until they’ve finished their design. Personally I think designers and programmers (and artists) should work together on a design right from the start.&quot;

Designing to unknown requirement is going to end up where one could imagine and it is not pretty.  Designers, programmers, and artists all have to create in a defined space, largely dependent on tech if the produce resides on a computer. If they do not ask what their limits are early they will be playing catchup against those limits for significant periods of time.</description>
		<content:encoded><![CDATA[<p>&#8220;This is due to the designer not consulting with programmers until they’ve finished their design. Personally I think designers and programmers (and artists) should work together on a design right from the start.&#8221;</p>
<p>Designing to unknown requirement is going to end up where one could imagine and it is not pretty.  Designers, programmers, and artists all have to create in a defined space, largely dependent on tech if the produce resides on a computer. If they do not ask what their limits are early they will be playing catchup against those limits for significant periods of time.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: IainC</title>
		<link>http://brokentoys.org/2009/11/04/physician-advise-thyself/comment-page-1/#comment-36024</link>
		<dc:creator>IainC</dc:creator>
		<pubDate>Fri, 06 Nov 2009 15:11:07 +0000</pubDate>
		<guid isPermaLink="false">http://brokentoys.org/2009/11/04/physician-advise-thyself/#comment-36024</guid>
		<description>I&#039;m a designer and I have zero programming knowledge. My initial design experience came from writing miniature wargaming rules for Games Workshop. Nowadays I work for an FPS where I&#039;m writing designs for social and massive systems in that context.

The interview process for me consisted of a written design test and then going to dinner with my prospective colleagues where we talked a lot about different games that we played and why we liked them. There was a more formal interview the next day but that was mostly to satisfy HR that I wasn&#039;t a sociopathic axe murderer or something.</description>
		<content:encoded><![CDATA[<p>I&#8217;m a designer and I have zero programming knowledge. My initial design experience came from writing miniature wargaming rules for Games Workshop. Nowadays I work for an FPS where I&#8217;m writing designs for social and massive systems in that context.</p>
<p>The interview process for me consisted of a written design test and then going to dinner with my prospective colleagues where we talked a lot about different games that we played and why we liked them. There was a more formal interview the next day but that was mostly to satisfy HR that I wasn&#8217;t a sociopathic axe murderer or something.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
