<?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: Band-aids and Surgery</title>
	<atom:link href="http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/</link>
	<description>a group of adventurers on an epic quest</description>
	<pubDate>Tue, 07 Oct 2008 14:25:21 +0000</pubDate>
	<generator>http://wordpress.org/?v=2.6.2</generator>
		<item>
		<title>By: yunk</title>
		<link>http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25381</link>
		<dc:creator>yunk</dc:creator>
		<pubDate>Fri, 04 Jan 2008 13:32:45 +0000</pubDate>
		<guid isPermaLink="false">http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25381</guid>
		<description>"Fixing the fundamental only gets worse once you already have a dozen band-aids on the wound"

I think this is always the biggest problem with the band-aid approach. With each fix, we have to ask "am I saving money by using a band-aid rather than recreating a new solution, or am I only postponing the inevitable investment required?" 

If we have to keep adding bandaids, then that may actually cost more in continued maintenance than it would cost to re-write the core modules and re-test everything. But you have to analyze the costs, and the opportunity cost of other things there are to work on, and decide what the best investment is. 

After all, we all like to create elegant solutions, but the bottom line is the solutions have to either make or save money.

I definitely prefer to just rewrite the core pieces so everything is nice and ordered and easy to maintain but just like your post indicates I have to check myself since I can get carried away and the time I spend rewriting and testing is sometimes to the detriment of time I should be spending on other things, and to my customers waiting for their fancy new apps.</description>
		<content:encoded><![CDATA[<p>&#8220;Fixing the fundamental only gets worse once you already have a dozen band-aids on the wound&#8221;</p>
<p>I think this is always the biggest problem with the band-aid approach. With each fix, we have to ask &#8220;am I saving money by using a band-aid rather than recreating a new solution, or am I only postponing the inevitable investment required?&#8221; </p>
<p>If we have to keep adding bandaids, then that may actually cost more in continued maintenance than it would cost to re-write the core modules and re-test everything. But you have to analyze the costs, and the opportunity cost of other things there are to work on, and decide what the best investment is. </p>
<p>After all, we all like to create elegant solutions, but the bottom line is the solutions have to either make or save money.</p>
<p>I definitely prefer to just rewrite the core pieces so everything is nice and ordered and easy to maintain but just like your post indicates I have to check myself since I can get carried away and the time I spend rewriting and testing is sometimes to the detriment of time I should be spending on other things, and to my customers waiting for their fancy new apps.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: John H.</title>
		<link>http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25359</link>
		<dc:creator>John H.</dc:creator>
		<pubDate>Sat, 29 Dec 2007 20:25:44 +0000</pubDate>
		<guid isPermaLink="false">http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25359</guid>
		<description>&lt;i&gt;A fundamental system in your game is broken or inadequate. You know it, the developers know it, everyone can see the proud nail sticking up. Why do they keep making tweaks to make the game work around it rather than just fixing it?&lt;/i&gt;

You're exactly right on this point, but there's something else that might also factor into the decision not to remove the system.  That is, the fact that most MMORPGs ultimately resolve down to being the same game.

Yeah, this is like saying all fighting games are the same, or all first-person shooters are the same.  Yet, actually, they are.

Details may vary tremendously, of course, and enthusiasts will see how the various subtle differences between all those games require different strategies and what-not, but to a casual player this doesn't matter for much, and it also doesn't hide the fact that the games all feature similar paradigms for games that should be as different from each other as night is from day.

I think some developers might stick with broken mechanics because they identify their game, they make it different from the others, they help to hide the ultimate similarity between it and Generic MMORPG Archetype.  They're sharp edges and corners that exist for their own sake, because the alternative is becoming a round ball, free of any individuality.

City of [Hero&#124;Villain]s' inventory-less system is an example: I remember reading an interview in which a developer said that he thought most casual players thought inventory and item manipulation was too complicated to fuss with, so they just left it out of the game, with the exception of the rather bland inspiration and enhancement system.  Then World of Warcraft showed up and showed how misguided that opinion actually was.  Since then, they've taken various half-measures to adding more collectable abilities to the game: temporary powers, salvage, and most recently inventions, added to inspirations and enhancements.

Each of these features has its own UI, when a single inventory system could encapsulate them all easily.  So why don't they just move to a full inventory then?  I suspect it's because they see the game's lack of one as an identifying characteristic.  It would make the game seem unlike what players perceive as CoX.

Well, that's how it looks from my end anyway....</description>
		<content:encoded><![CDATA[<p><i>A fundamental system in your game is broken or inadequate. You know it, the developers know it, everyone can see the proud nail sticking up. Why do they keep making tweaks to make the game work around it rather than just fixing it?</i></p>
<p>You&#8217;re exactly right on this point, but there&#8217;s something else that might also factor into the decision not to remove the system.  That is, the fact that most MMORPGs ultimately resolve down to being the same game.</p>
<p>Yeah, this is like saying all fighting games are the same, or all first-person shooters are the same.  Yet, actually, they are.</p>
<p>Details may vary tremendously, of course, and enthusiasts will see how the various subtle differences between all those games require different strategies and what-not, but to a casual player this doesn&#8217;t matter for much, and it also doesn&#8217;t hide the fact that the games all feature similar paradigms for games that should be as different from each other as night is from day.</p>
<p>I think some developers might stick with broken mechanics because they identify their game, they make it different from the others, they help to hide the ultimate similarity between it and Generic MMORPG Archetype.  They&#8217;re sharp edges and corners that exist for their own sake, because the alternative is becoming a round ball, free of any individuality.</p>
<p>City of [Hero|Villain]s&#8217; inventory-less system is an example: I remember reading an interview in which a developer said that he thought most casual players thought inventory and item manipulation was too complicated to fuss with, so they just left it out of the game, with the exception of the rather bland inspiration and enhancement system.  Then World of Warcraft showed up and showed how misguided that opinion actually was.  Since then, they&#8217;ve taken various half-measures to adding more collectable abilities to the game: temporary powers, salvage, and most recently inventions, added to inspirations and enhancements.</p>
<p>Each of these features has its own UI, when a single inventory system could encapsulate them all easily.  So why don&#8217;t they just move to a full inventory then?  I suspect it&#8217;s because they see the game&#8217;s lack of one as an identifying characteristic.  It would make the game seem unlike what players perceive as CoX.</p>
<p>Well, that&#8217;s how it looks from my end anyway&#8230;.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Yumcha</title>
		<link>http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25357</link>
		<dc:creator>Yumcha</dc:creator>
		<pubDate>Sat, 29 Dec 2007 18:53:27 +0000</pubDate>
		<guid isPermaLink="false">http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25357</guid>
		<description>As a programmer in the day-to-day world (as opposed to the online world), I definitely understand the "joys" of finding a huge oversight early on and trying to fix it.  Sometimes, it's just easier to program around it because if you  fix it, you may end up breaking more in the process.  And from there, it just trickles on :-\

Now I need to call you before you come out here... all this talk of cake... :D</description>
		<content:encoded><![CDATA[<p>As a programmer in the day-to-day world (as opposed to the online world), I definitely understand the &#8220;joys&#8221; of finding a huge oversight early on and trying to fix it.  Sometimes, it&#8217;s just easier to program around it because if you  fix it, you may end up breaking more in the process.  And from there, it just trickles on :-\</p>
<p>Now I need to call you before you come out here&#8230; all this talk of cake&#8230; :D</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: gattsuru</title>
		<link>http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25356</link>
		<dc:creator>gattsuru</dc:creator>
		<pubDate>Sat, 29 Dec 2007 17:11:41 +0000</pubDate>
		<guid isPermaLink="false">http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25356</guid>
		<description>That raises the rather obvious yet oft-overlooked question of why any sane game designer -- ignore, for now, the contradiction in terms -- would allow any one equation to take input from so many other portions of the game.

Maybe it's just me.  I think from a Cisco networking viewpoint : each layer should be as independent of other layers as possible, while still getting its functionality done.  But looking at City of Heroes or World of Warcraft, and I don't see any reason that the accuracy system should depend on that many values.  The same goes for a damage scalar that relies on twenty other variables, or drop rates that think the phase of the moon is a good metric.

(for that matter, the accuracy system in City of Heroes is often cited as being unnecessarily complex.  Despite that, in my experience on the Current Defender Issue list, the vast, vast majority of issues tend to be basic number errors.  Those that did involve code changes, such as the big Defense code change, required minimal changes outside of its domain.)</description>
		<content:encoded><![CDATA[<p>That raises the rather obvious yet oft-overlooked question of why any sane game designer &#8212; ignore, for now, the contradiction in terms &#8212; would allow any one equation to take input from so many other portions of the game.</p>
<p>Maybe it&#8217;s just me.  I think from a Cisco networking viewpoint : each layer should be as independent of other layers as possible, while still getting its functionality done.  But looking at City of Heroes or World of Warcraft, and I don&#8217;t see any reason that the accuracy system should depend on that many values.  The same goes for a damage scalar that relies on twenty other variables, or drop rates that think the phase of the moon is a good metric.</p>
<p>(for that matter, the accuracy system in City of Heroes is often cited as being unnecessarily complex.  Despite that, in my experience on the Current Defender Issue list, the vast, vast majority of issues tend to be basic number errors.  Those that did involve code changes, such as the big Defense code change, required minimal changes outside of its domain.)</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Inhibitor</title>
		<link>http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25355</link>
		<dc:creator>Inhibitor</dc:creator>
		<pubDate>Sat, 29 Dec 2007 17:09:42 +0000</pubDate>
		<guid isPermaLink="false">http://www.killtenrats.com/2007/12/29/band-aids-and-surgery/#comment-25355</guid>
		<description>Very, very true, Zub, and very well put. I would like to point out something else, though...with an MMO (unlike non-MMO games), when you're baking your cake, you're working in an open-air bakery on a crowded street, with thousands of people begging to taste the batter. A portion of those that do immediately start telling everyone else in the crowd that your cake sucks, the balance between sugar and butter is waaaaay off, and it's not going to matter how much frosting you put on it at the end, it'll still suck.

If you realize you screwed up the recipe before you put your cake in the oven, you're going to lose some credibility with the crowd if you chunk it and start over. Unlike cooking up a single-player cake, everyone's watching every move you make.

If you don't realize you screwed up the recipe until the cake is done and you're frosting it...well, those people are waiting to pay you for a slice of cake (they're practically screaming for it at this point), and you've got payroll to meet.

Let them eat cake. :)

And in answer to the "Why didn't the baker listen when the batter-tasters said it was screwed up!?!" question: Well, since over half of them didn't say anything (they were just in it for free cake batter), and of the ones that did complain, half of those griped about the batter having too much paprika in it. There is no paprika in it, you've looked and you don't even have any paprika in the freakin' kitchen, but you can see how the nutmeg/cinnamon combination would make people think that, so you ignore them all, since you don't have time to filter through the millions of stupid comments to get to the ones that would actually help you bake a better cake.

Good lord, Z...now I want cake.</description>
		<content:encoded><![CDATA[<p>Very, very true, Zub, and very well put. I would like to point out something else, though&#8230;with an MMO (unlike non-MMO games), when you&#8217;re baking your cake, you&#8217;re working in an open-air bakery on a crowded street, with thousands of people begging to taste the batter. A portion of those that do immediately start telling everyone else in the crowd that your cake sucks, the balance between sugar and butter is waaaaay off, and it&#8217;s not going to matter how much frosting you put on it at the end, it&#8217;ll still suck.</p>
<p>If you realize you screwed up the recipe before you put your cake in the oven, you&#8217;re going to lose some credibility with the crowd if you chunk it and start over. Unlike cooking up a single-player cake, everyone&#8217;s watching every move you make.</p>
<p>If you don&#8217;t realize you screwed up the recipe until the cake is done and you&#8217;re frosting it&#8230;well, those people are waiting to pay you for a slice of cake (they&#8217;re practically screaming for it at this point), and you&#8217;ve got payroll to meet.</p>
<p>Let them eat cake. :)</p>
<p>And in answer to the &#8220;Why didn&#8217;t the baker listen when the batter-tasters said it was screwed up!?!&#8221; question: Well, since over half of them didn&#8217;t say anything (they were just in it for free cake batter), and of the ones that did complain, half of those griped about the batter having too much paprika in it. There is no paprika in it, you&#8217;ve looked and you don&#8217;t even have any paprika in the freakin&#8217; kitchen, but you can see how the nutmeg/cinnamon combination would make people think that, so you ignore them all, since you don&#8217;t have time to filter through the millions of stupid comments to get to the ones that would actually help you bake a better cake.</p>
<p>Good lord, Z&#8230;now I want cake.</p>
]]></content:encoded>
	</item>
</channel>
</rss>
